私たちはいくつかのプロジェクトでまさにこれを行っています。これを達成する方法の概要を以下に示します。これは 1 つの方法にすぎないことを覚えておいてください。独自のメンバーシップ プロバイダーを作成することにも成功しています。
主なプロジェクトは 3 つあります。
- Data.project - クラス ライブラリ
- WebApp.project - MVC アプリケーション
- API.project - WCF サービス
すぐに使用できる組み込みの .NET メンバーシップ プロバイダーを使用します。これにより、基本的な登録、パスワードの変更、ロール管理、および MVC および API プロジェクトでの簡単なコントローラー ベースのロール許可とアクセス制御が可能になります。
既定のメンバーシップ プロバイダーは、独自のテーブルを使用してユーザー データを格納します。
次に、独自の User および Profile テーブルとデータ構造を作成し、外部キーをユーザーの .NET MembershipId に戻します。これにより、ユーザー プロファイルで行う必要があるアプリケーション固有の処理をすべて柔軟に実行できると同時に、既定のプロバイダーにアクセスできるようになります。
MVC プロジェクトでの認証は簡単です。.NET メンバーシップ メソッドを使用して、ユーザー名とパスワードで認証できるようになりました。
if(Membership.ValidateUser(username,password)){
FormsAuthentication.SetAuthCookie(username,password);
}
WCF プロジェクトの場合、FormsAuthentication を利用することはできませんが、既定のメンバーシップ プロバイダーを使用してユーザーの資格情報を検証することはできます。
その後の認証の処理方法はあなたとあなたのプロジェクト次第ですが、基本的なニーズについては、通常、検証後に WCF サービスによって返される認証トークンを使用します。このトークンは、各 WCF 要求に含まれており、通常は要求ヘッダーで検証されていることを証明します。
WCF の場合、資格情報をサーバーに送信するときにユーザー名とパスワードを Base 64 エンコードし、成功した場合は認証トークンを返します。
string decoded = System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(Authmodel));
//convert your string into your authentication model here then
if(Membership.ValidateUser(model.user,model.pass))
{
//return new authentication token
}
また、登録時に独自のユーザー テーブルとプロファイル テーブルを構築する追加のロジックも含めます。これはデータ プロジェクトで処理されるため、WCF と MVC の両方がアクセスできます。
さらに、データ プロジェクトは、ユーザー テーブルとプロファイル テーブル、および .NET メンバーシップ プロバイダー テーブルのリンクを処理するため、両方のアプリケーションから情報にアクセスできます。
これは非常に漠然としていますが、統一された方法で認証を処理するための 1 つのオプションを考えるのに役立つかもしれません。特定の部分について質問がある場合はお知らせください。この情報がお役に立てば幸いです。