接続しているクライアント(作成および制御するHTML5/JSクライアント)を認証する必要があるWeb API 2.1サービスを開発しています。残念ながら、ユーザー情報(ユーザー名、パスワードハッシュ、ロール、その他多くの情報)は、読み取りアクセス権しか持たない既存の(SQL Server)データベースに保存されます。ユーザーデータベーステーブルは、セキュリティフレームワークへの参照なしで5〜6年前に作成されたため、完全にカスタム形式です。データまたはデータベース構造に変更を加えることはできません。
この記事 に触発されて、ユーザー認証のトークンベースの独自の方法を展開しましたが、確立されたセキュリティフレームワークを使用する完全性と(再)保証に欠けています。
既存のフレームワークを統合する方法はありますか?上記の制約を考慮して、現在のプロジェクト内のOAuth2ですか?違いがあるかどうかはわかりませんが、OWINを使用してセルフホスティングしています。
これは、同様の質問に対する良い答えです。それは基本的に言う:
IUser
を実装するカスタムユーザークラスを作成するpublic class UserStoreService : IUserStore<CustomUser>, IUserPasswordStore<CustomUser>
を実装するカスタムユーザーストアを定義する答えはかなり広範囲なので、基本的な手順を提供しただけです...詳細はこちらです: asp.net web api 2の独自のテーブルセットに認証をカスタマイズする方法?
これは、Web APIにも適用される非常に貴重なコンテンツでもあります。
JumpStartによるIDを使用したASP.NET認証のカスタマイズ
https://channel9.msdn.com/Series/Customizing-ASPNET-Authentication-with-Identity
HTH
Web API内でJSONトークン認証を実装しようとしたときに、私は自分のソリューションを見つけました。私のソリューションは、Httpリクエストの認証ヘッダーを介してjsonトークンを送信することで認証を処理することに注意することが重要です(cookiesを経由しない)およびnotMicrosoft.Identityフレームワークを使用。
とにかく、私は基本的にクックブック形式で、ここでTaiseer Joudehが有用に説明したソリューションを実装しました: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api- 2-jwt-owin-authorization-server /
注目すべき重要な点は、次のコードです。
_//Dummy check here, you need to do your DB checks against memebrship system http://bit.ly/SPAAuthCode
if (context.UserName != context.Password)
{
context.SetError("invalid_grant", "The user name or password is incorrect");
//return;
return Task.FromResult<object>(null);
}
_
当然、上記のコードの一部を、(おそらく既存の)ユーザーデータベースをチェックする独自の方法に置き換えます。これを実装したら、Visual Studioがインストールする新しいコードファーストIDフレームワークを使用する必要がないことに気付きました。
これを機能させるために、次のことを行いました。
1)空のプロジェクトを作成し、認証/個人ユーザーアカウントの変更を選択しました。これにより、Cookieによるトークン認証とコードファーストIDフレームワークファイルを使用するために必要なほとんどの必要な参照とファイルがインストールされます。
2)Taiseer Joudehのリードに従ってこれらのファイルを編集しました。これには、特にCustomOAuthProvider.csなどの新しいオブジェクトが必要です。そして、このコードブロックをカスタマイズして、独自のユーザー/パスワードチェックを実装する必要があります。
if (context.UserName != context.Password) { context.SetError("invalid_grant", "The user name or password is incorrect"); //return; return Task.FromResult<object>(null); }
Taiseer Joudehの指示へのリンク: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/ =
3)無関係なファイル(AccountBindingModels.cs、AccountViewModels.cs、IdentityModels.cs、ApplicationOAuthProvider.cs、identityConfig.cs、AccountBindingModels.cs、AccountViewModels.cs)のプロジェクトを整理しました。基本的に、Microsoft ID参照はこれ以上ありません。
Microsoft.identityのことは素晴らしいと確信していますが、異なる構造などのレガシーデータベースを既に使用していたときに、データベースのコードファースト実装に悩まされていました。これが役に立てば幸いです。私はその結果にかなり満足しています(数日間、いじって動作させた後)。
私は既存のクラスを使いたくありませんでした。
var userName = context.UserName;
var password = context.Password;
var userService = new UserService(); // our created one
var user = userService.ValidateUser(userName, password);
if (user != null){
.......
}
詳細はこちらをご覧ください OAuth Web APIトークンベース認証とカスタムデータベース
カスタムデータベースを使用したロールベース認証 役立つことを願っています
能力を持っている他の誰かがオプションを説明できます。ただし、サービスとしての認証がオプションの場合は、Auth0 @ https://auth0.com を確認してください。
HTML/JSとネイティブのWindows Phoneアプリケーションの両方を使用して、単純なSql ServerテーブルとADに対して(Azureプラグインとして)サービスをテストしました。頭痛がほとんどない作品。
これは完全に狂った無効なアプローチかもしれませんが、同様の課題に直面しました。新しいWebアプリ(MVVM + WebAPI)、トークンの発行と検証に使用されるレガシーシステムです。 http://tech.pro/tutorial/1216/implementing-custom-authentication-for-aspnet に触発され、私のアプリケーションは主に付属のGUI(MVVM webapp)で使用されるため、 FormsAuthenticationによって生成された「Cookieベースの」トークンを使用することにしました。 FormsAutnenticationのCookie /チケットは、.netの内部マジックセキュリティ(IDは完全に安全で壊れないものと想定しています)によって保護されています。
私の場合、Cookieはレガシーシステムによって発行されたチケットを保持するだけです(ただし、カスタムタイプをJSONSerializingするなどして、詳細を格納することもできます)。承認中に、私のシステムはレガシーシステムに対してトークンを検証します。似たようなものをカスタムAuthorizationFilterと一緒に使用できると思います。