ASP .NET Identityの主張は何ですか

新しいASP.NET Identity Coreでのクレームメカニズムの意味を誰かが説明できますか？

私が見ることができるように、そこにあるAspNetUserLogins含まれているテーブル、UserId、LoginProviderとProviderKey。

しかし、それでもデータがAspNetUserClaimsテーブルに追加されたとき、およびこのテーブルがどのような状況で使用されているかに関する情報を理解または見つけることができません。

新しいASP.NET Identity Coreでクレームメカニズムは何を意味しますか？

RoleとClaimに基づく2つの一般的な承認アプローチがあります。

ロールベースのセキュリティ

ユーザーは、ユーザーがアクセス権を取得するための1つ以上のロールに割り当てられます。また、ユーザーをロールに割り当てると、ユーザーはそのロールに定義されているすべてのアクセス権をすぐに取得します。

クレームベースのセキュリティ

クレームベースのIDは、クレームのセットです。クレームは、エンティティ（ユーザーまたは別のアプリケーション）がそれ自体について行う声明であり、単なるクレームです。たとえば、要求リストには、ユーザーの名前、ユーザーの電子メール、ユーザーの年齢、アクションに対するユーザーの承認を含めることができます。ロールベースのセキュリティでは、ユーザーは資格情報をアプリケーションに直接提示します。クレームベースのモデルでは、ユーザーはアプリケーションに資格情報ではなくクレームを提示します。クレームが実用的な価値を持つためには、アプリケーションが信頼するエンティティからのものである必要があります。

以下の手順は、クレームベースのセキュリティモデルで発生するシーケンスを示しています。

1. ユーザーがアクションを要求します。証明書利用者（RP）アプリケーションはトークンを要求します。
2. ユーザーは、RPアプリケーションが信頼する発行機関に資格情報を提示します。
3. 発行局は、ユーザーの資格情報を認証した後、クレーム付きの署名済みトークンを発行します。
4. ユーザーはトークンをRPアプリケーションに提示します。アプリケーションはトークン署名を検証し、クレームを抽出し、クレームに基づいて要求を受け入れるか拒否します。

しかし、データがAspNetUserClaimsに追加されると、このテーブルがどのような状況で使用するのかを理解して見つけることができません。

ロールベースのセキュリティが使用されていない状況で、クレームベースのセキュリティを使用することを選択した場合、AspNetUserClaimsテーブルを使用する必要があります。ASP.NET Identityでクレームを使用する方法については、以下のリンクを参照してください。

http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html

更新

ロールベースのセキュリティを使用する必要があるのはいつですか？いくつかの例を書いていただけませんか？

ロールベースまたはクレームベースのセキュリティを使用する、または使用しないという明確な状況はありません。BではなくAを使用する場合とは異なります。

ただし、クレームベースのアクセス制御により、承認ルールをコアビジネスロジックからより適切に分離できます。承認ルールが変更されても、コアビジネスロジックは影響を受けません。クレームベースのアプローチの使用を好む場合があります。

時々、クレームは必要ありません。これは重要な免責事項です。内部アプリケーションのホストを持つ企業は、統合Windows認証を使用して、クレームによって提供される多くの利点を実現できます。Active DirectoryはユーザーIDの保存に最適です。KerberosはWindowsの一部であるため、アプリケーションに多くの認証ロジックを含める必要はありません。構築するすべてのアプリケーションが統合Windows認証を使用できる限り、すでにIDユートピアに到達している可能性があります。ただし、Windows認証以外のものが必要になる理由はたくさんあります。Windowsドメインにアカウントを持っていないユーザーが使用するWeb向けアプリケーションがあるかもしれません。もう1つの理由は、あなたの会社が他の会社と合併して、信頼関係を持たない（または持たない可能性がある）2つのWindowsフォレスト間で認証に問題が発生した。おそらく、.NET Framework以外のアプリケーションを使用している別の会社とIDを共有したい場合や、異なるプラットフォーム（Macintoshなど）で実行されているアプリケーション間でIDを共有する必要がある場合があります。これらは、クレームベースのIDが適切な選択である場合のほんの一部の状況です。

詳細については、http：//msdn.microsoft.com/en-us/library/ff359101.aspxにアクセスしてください。

@Linが上で言ったことをさらに追加するだけです。私は特に質問に言及しています：

ロールベースのセキュリティを使用する必要があるのはいつですか？いくつかの例を書いていただけませんか？

技術者とマネージャがいるクロッキングシステムがある場合を考えてみます。技術者は毎週の終わりに、その週に職人が働いた時間を示す計時情報を含むレポートを作成する必要があります。これは、統合されて給与計算で使用されます。このようなシステムは、従業員の過払いや過小支払いをしたくないため、最終報告が提出される前に修正または修正する必要があることがよくあります。Role-Based作成するにより、マネージャと技術者のためのアプローチを使用できますManager RoleしてTechnician Role。しかし、それManager Roleは職人の計時情報にアクセスして編集する機能を備えたものです。一方、Technician Roleその情報にアクセスするこれらの能力なし。しかし、ここが興味深い部分です。管理者は、クレームを作成し、技術者がクロッキングシステムにアクセスしてレポートを作成することを許可できます。したがって、要求は編集なしのアクセスに対してのみ行うことができます。またはアクセスおよび編集機能を使用して行うことができます。

それは、まあ、デフォルトではマネージャとして、技術者がアクセスできないいくつかの情報にアクセスできます。しかし、私はいつもオフィスにいるわけではありませんか？私がいないときでも彼が仕事をすることができるように私は何ができますか？これを解決するために、システムはマネージャーが特定の情報にアクセスできない人々のためのクレームを作成するための機能を持つことができます。これらは、ERPシステムのいたるところで見られます。一部のモジュールへのアクセス権がなく、昇格したユーザーは、ERPシステムのより多くのモジュールへのアクセス許可を与えており、同じユーザーの役割を維持している場合があります。

これは、クレームと役割をさらに理解するために検討できる例です。

ASP.Net IDには2種類の認証があります。

1. ロールベース
2. クレームベース

どちらか一方または両方を同時に使用できます。非常に明確なものがある場合は、役割ベースを使用します。たとえば、2つのロラ教師と生徒を作成します。教員のみが科目を追加できます。したがって、教科を追加するアクセス権を付与するユーザーに教師の役割を割り当てました。

クレームベースはより柔軟です。一部の学生が科目も追加できるという要件があるとします。この場合、学生になることができるもう1つのロールと、サブジェクトを追加するためのアクセス権を作成する必要があります。しかし、クレームベースを使用している場合は、非常に簡単です。addSubjectのようなクレームを作成し、それをaubjectを追加するためにアクセスしたい任意のユーザーに割り当てます。