クレームベースのIDの概要

Microsoftスタックでアプリケーションを開発するとき、現在のユーザーに関する情報を非常に頻繁に（より正確にはほぼ常に）取得するために、そのようなコードのセクションまたはラッパーを見つけることができます：



HttpContext.User.Identity.Name

HttpContext.User.IsInRole(...)









または



Thread.CurrentPrincipal.Identity.Name

Thread.CurrentPrincipal.IsInRole(...)









これらの呼び出しの目的は、何らかの関数またはメソッドへの呼び出しの許可に関する決定、現在のユーザーに関する情報の表示などを行う必要がある場合があります。



これらのクラスには、データベースからのデータの読み取り、フォーム認証、NTLMトークン、Kerberosトークンなど、さまざまな方法でユーザー情報が表示されました。 いずれの場合も、ユーザーに関する情報、ユーザーの認証、および追加情報の取得というタスクが解決されました。



「曇り前」では、ほとんどのアプリケーションでこれで十分でした。 これで十分でない場合は、さまざまな種類の独自のフレームワークが作成されましたが、主な質問は多くの場合、主な質問でした。ユーザーには特定の役割がありますか。 ある時点までは、ユーザーリポジトリが1つになるまでこれで十分でした。ビジネスパートナーなどと対話する必要はありませんでした。 クラウド、分散システム、SaaSアプリケーション、および現代のWebを想像するのが難しい他の利点の出現により、たとえば、パートナーの従業員がCRMの特定の機能にアクセスできるようにしたい場合、このモデルは十分ではありませんでした。 アプリケーションの開発と進化の問題がしばしば発生します。たとえば、最初はユーザーと管理者の2つのユーザーグループを使用し、コード内で寛大に承認を設定することを計画していました。

ビュー属性：



[Authorize("Administrators")]

public ActionResult DoSomeHardcoreAdminStuff()

{

...

}









そして、1年後、ビジネスは、異なるレベルのアクセス権を持つ複数の異なるユーザーグループを持ち、他のすべてのもの（この状況のドラマ全体を理解するため）がSystemAdministratorとSecurityAdministratorに対する管理者の権利を区別するのが良いと判断しました。 これらの要件はビジネスの想像力によってのみ制限されるため、これは制限ではありません。



開発者の観点から見ると、これらすべてがテクノロジーと松葉杖の動物園をもたらしました。 各アプリケーションは、独自の方法でユーザーを認証しました。 ユーザーは、OAuth、Forms、Windowsなどを使用して認証できます。 特定のケースごとに、私は独自の認証および承認ロジックを作成する必要がありました。Apiがある場合は、自転車も同様に描画します。



これに対応して、2008年に、Windows Identity Foundation（WIF）の最初のリリースがマイクロソフトの深部からリリースされ、クレームベースのIDの概念が導入されました。 このフレームワークの目標は、これがどのように機能するかの詳細に入ることなく、ユーザーの要件を表現するための抽象的なメカニズムを提供することです。



要するに、WIFのアイデアは、かなり単純な実例で説明できます。

あなたは18歳になり、映画館に行くことにしました。 アダルト映画。 しかし、残念ながら、彼らはこれまでパスポートまたは他の身分証明書を取得することができませんでした（まあ、またはあまりにも怠zyでした）。 パスポートを受け取り、しばらくしてパスポートを提示し、パスポートを提示したら、お気軽に大切なチケットを購入してセッションに行ってください。 そして、ここではWIFの観点から見ます：







件名、つまり、IDプロバイダー（パスポートオフィス）に移動し、Birth CertificateTokenに基づいてPassportTokenを取得します。 次に、このPassportTokenを使用して、証明書利用者（映画）にアクセスし、年齢を確認してからサービスにアクセスします。



この例から引き出せる主なアイデア：



1.アダルトセッションへの訪問者としてあなたを承認するために、映画館は顧客ベースを維持したり、どこに行ったりする必要はありません。 彼が必要とするのは、自分が信頼する身分証明書（パスポート、軍事ID、権利）だけです。



2.パスポートオフィスでは、パスポートの提示場所がわかりません。 （WIFの観点から、私はまだ少し知る必要がありますが、これは必要ではありません）。



3.パスポートを使用すると、映画館に行ってからウイスキーを購入したり、州が発行した書類を信頼する機関で住宅ローンなどを購入したりできます。 機関。



OAuth、WS-Trust、WS-Fed、SAML-Pなどのプロトコルをすでに使用している人がいるため、この相互作用スキームはおなじみのものです。 要するに、特定の形式のトークンの形で信頼できるIDプロバイダーからユーザーに関する情報を取得し、それを使用してアプリケーションで決定を下します。 退化した場合、たとえばフォーム認証では、あなた自身がこの認証機関であり、この情報を使用します。 WIFはそのようなシナリオを許可します。 WIFは、あらゆる種類のシナリオをサポートするのに十分な柔軟性を備えています。



WIFを使用すると、認証プロセスを信頼できる当事者に「外部委託」でき、認証および承認プロセスで開発者が介入する必要性を最小限に抑えます。 アプリケーションに提示されるすべてのIDは、ClaimsPrincipalおよびClaimsIdentityタイプにキャストされます。 これらのタイプは、標準の* Principalおよび* Identityに非常に似ていますが、IPrincipalおよびIIdentityインターフェイスも実装しますが、追加のプロパティがあります。これは、現在のユーザーに関して利用可能なすべてのステートメントのコレクションです。 さらに、互換性のために、IIdentityおよびIClaimsPrincipalを使用するさまざまな既存の方法がサポートされています。たとえば、



[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]

static void CheckAdministrator()

{

Console.WriteLine("User is an administrator");

}









これを行うには、ユーザーが「Administrators」という値を持つロールタイプのステートメント（ロールとして使用されるステートメントのタイプを設定できます）を持っているだけで十分です。



ASP.NET MVCアプリケーションでは、これは次のようになります。



[ClaimsAuthorize(ClaimTypes.Role, "Administrators")]

public ActionResult DoSomeHardcoreAdminStuff()

{

...

}









または：



[ClaimsAuthorize(ClaimTypes.Permission, "DoSomeHardcoreAdminStuff")]

public ActionResult DoSomeHardcoreAdminStuff()

{

...

}









特定のリソースへのアクセスを確認したり、ユーザーの年齢、住所、自宅の電話番号を取得したりするためのより複雑なシナリオがあります。



これらのすべての変換の結果として、ロールベースのセキュリティアプローチはアプリケーションに課せられなくなり、必要なチェックを実行する方法、ベース、場所を自由に選択でき、場合によっては、アプリケーション内にユーザー情報を保存するメカニズムを完全に削除できます。 とりわけ、ユーザーがどのように認証されたかは気にしません。それは、標準のログインとパスワードのペアであろうと、スマートスマートカードであろうとです。 これは、IDプロバイダーのタスクです。



現在、Microsoftプラットフォームでのこのようなアプローチには、ADFS（Active Directory Federation Services）とAzure ACSの2つの主要なソリューションがあります。 どちらも自分に合わない場合は、サンプルを含むテンプレートがすぐにスタジオに入れられるので、自分でサービスを自由に作成できます。 また、独自の製品を開発できるオープンソースのIdentityServerサーバーもあります。



いくつかの事実：



すぐに使用できるWIFは、次のプロトコルをサポートしています。

1. WSフェデレーション

2. WS-Trust

3. WS-Security

4. WS-SecurityPolicy

5. WS-Addressing



SAML-PプロトコルのサポートはCTP状態です。 RTMバージョンに関する情報はまだありません。 OAuth2拡張機能もあります。



SAML1.1およびSAML2資格情報が標準でサポートされています。 ただし、SWTおよびJWT（Json Web Token）のサポートを追加するライブラリは既にかなり開発されています。



これは、System.Security名前空間で何が起こっているかについてのごくわずかな余談でした。 入門記事の一部として、詳細に立ち入りたくない

ところで、.Net 4.5では、クレームベースのIDとWIFが山の王になりました。 すべてのタイプ*プリンシパルはClaimsPrincipalから継承され、内部のKerberosトークンには一連のステートメントなどが含まれます。 誰かがこのトピックに興味を持っているなら、コメントにあなたの希望を書いてください。私はきっと時間を書きます。



便利なリンク：

1. msdn.microsoft.com/en-us/security/aa570351.aspx-MSDNのページ。

2. claimid.codeplex.com-コード例と無料の本。

3. leastprivilege.com -Dominick Baierブログ。

4.github.com/thinktecture/Thinktecture.IdentityServer-オープンソースのIdentity Server。



PS。 レビューを提供してくれたXaocCPSに感謝します。