ClaimsPrincipalの役割は何ですか？なぜ複数のIDがあるのですか？
アプリケーション（証明書利用者）の要求に基づいて.NETの背後にあるセキュリティモデルを理解しようとしています。
私は2つの主要なクラスがあることを知っています：
- ClaimsPrincipal-実行中のプロセスのセキュリティコンテキスト
- ClaimsIdentity-ユーザーに関する情報を格納します-認証ステータスとクレーム
実は、ClaimsPrincipalにはIDのコレクションと現在使用されているIDへのポイントのみが含まれていますが、私の知る限りでは、プリンシパルは通常、複数のIDを含むことはありません。アイデンティティ。
私にとって、ClaimsPrincipalは、現在のIDを取得するためにそれを使用する以外に、私の無知を許し、それは役に立たない。
私が述べたこと以外に何が欠けているのか、そしてClaimsPrincipalクラスに関して後方互換性があるとしましょうか？
実は、ClaimsPrincipalにはIDのコレクションと現在使用されているIDへのポイントのみが含まれていますが、私の知る限りプリンシパルは通常、複数のIDを含むことはありません。 2つ以上のIDでログインしたことはありません。
これは間違った仮定です。実際、アプリケーションがn要素認証（n> 1）を必要とする場合、コンテキスト内のClaimsPrincipalは常に複数のIDを持ちます。
このように見てみてください。
プリンシパル=ユーザー
ID =運転免許証、パスポート、クレジットカード、Googleアカウント、Facebookアカウント、RSA SecurID、指紋、顔認証など
警察に引っ張られても、運転免許証だけでは、本人かどうかは確認されません。彼らもあなたの顔を見なければなりません。それ以外の場合は、誰かの運転免許証を表示することができます。
したがって、それは理にかなっています。なぜ認証が複数のIDに基づくことが可能であり、時にはそうである必要があるのでしょう。そのため、1 ClaimsPrincipalは任意の数のClaimsIdentityを持つことができます。
重要なセキュリティ原則の1つは、「だれが言っているか」です。つまり、IDに対してクレームを主張している当事者を信頼します。そのため、特定のClaimsPrincipalに対して、それぞれが異なるクレームセットを主張している異なるIDを持っている可能性があります。アプリケーションの全体的なアクセス制御、
アプリケーションデータベースにあるチームまたは部門に基づいてアクセス制御をアサートしたいWindows認証を介して認証されているエンタープライズアプリケーションの例を見てみましょう。
ClaimsTransformationManagerを使用して、これら2つのセットを統合できます。つまり、ユーザーを認証した後、データベースでユーザーのチーム/部門を検索し、アプリケーションによって発行された一連のクレームを作成できます。
これで、Windowsによってアサートされるロール（内部ではクレーム）と、チームまたは部門のカスタムクレームをアサートするアプリケーションIDができました。