ASP.NET MVCでの役割ベースのアクセス制御（RBAC）とクレームベースのアクセス制御（CBAC）
ASP.NET MVCコンテキストでクレームベースのアクセス制御を活用する方法を紹介します。
役割ベースの認証を使用している場合、顧客を作成するアクションがあり、「販売」役割の人がそれを行えるようにするには、次のようなコードを記述します。
[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
return View();
}
後に、「マーケティング」ロールの人々が顧客を作成できることがあることに気づきました。次に、そのようなアクションメソッドを更新します
[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
return View();
}
これで、マーケティング担当者の一部は顧客を作成できてはいけませんが、マーケティング担当者に別の役割を割り当てることはできません。したがって、すべてのマーケティング担当者が顧客を作成できるようにする必要があります。
マーケティング担当者に顧客の作成を許可する必要があると判断した場合は、別の問題に気づいたときは、MVCアクションメソッドのすべての属性を更新し、アプリケーションをコンパイルし、テストしてデプロイする必要があります。数日後、マーケティングではなく他のロールがタスクを実行できるようにする必要があると決定したため、コードベースで検索し、Authorize属性からすべての「マーケティング」を削除し、Authorize属性に新しいロール名を追加します...健康的なソリューション。その時点で、アクセス許可ベースのアクセス制御が必要になります。
権限ベースのアクセス制御は、さまざまな権限をさまざまなユーザーに割り当て、実行時にコードからアクションを実行する権限があるかどうかを確認する方法です。さまざまな権限をさまざまなユーザーに割り当てた後、ユーザーが「Facebookユーザー」、「長期ユーザー」などのプロパティを持っている場合、一部のユーザーにコードの実行を許可する必要があることに気付きます。例を挙げましょう。ユーザーがFacebookを使用してログインしている場合、特定のページへのアクセスを許可するとします。次に、そのユーザーに「Facebook」の許可を作成しますか？いいえ、「Facebook」は許可のようには聞こえません。それは？むしろ主張のように聞こえます。同時に、権限も申請のように聞こえます!!したがって、申し立てを確認してアクセスを許可することをお勧めします。
それでは、クレームベースのアクセス制御の具体例に戻りましょう。
このようなクレームのセットを定義できます：
「CanCreateCustomer」、「CanDeleteCustomer」、「CanEditCustomer」..など.
これで、次のようにアクションメソッドを装飾できます。
[ClaimAuthorize(Permission="CanCreateCustomer")]
public ActionResult CreateCustomer()
{
return View();
}
（注、[ClaimAuthorize（Permission = "CanCreateCustomer"）]はMVCクラスライブラリに組み込まれていない可能性があります。単に例として示しています。このようなAttributeクラス定義を持つクラスライブラリを使用できます）
これで、CreateCustomerアクションメソッドには常に 'CanCreateCustomer'権限が必要であり、変更されないか、ほとんど変更されないことがわかります。そのため、データベースで、許可（クレーム）とユーザー許可関係のテーブルを作成します。管理パネルから、何をすることができる各ユーザーに許可（クレーム）を設定できます。 「CanCreateCustomer」権限（請求）を好きな人に割り当てることができ、許可されたユーザーのみが顧客を作成でき、許可されたユーザーは顧客のみを作成でき、他のユーザーは作成できません（同じユーザーに他の権限を割り当てない限り）。
このセキュリティモデルは、クリーンなコードプラクティスを提供します。さらに、アクションメソッドを記述するとき、このメソッドを使用できるユーザーを考える必要はありません。むしろ、このメソッドを使用しているユーザーに、管理者から適切な許可（クレーム）が与えられることを常に保証できます。その後、管理者は誰が何を実行できるかを決定できます。開発者としてではありません。これが、ビジネスロジックとセキュリティロジックを分離する方法です。
誰かがサインインするたびに、アプリケーションはそのユーザーが使用できる権限をチェックし、その権限（クレーム）セットは現在ログインしているユーザーの追加プロパティとして使用できます（通常、クレームセットはログインしているユーザーのCookieとして保存されます）そのため、データベースから許可セットを常に確認する必要はありません。結論として、ロールベースのアクセスではなくクレームベースのアクセスを適用すると、アプリケーションのセキュリティロジックをより詳細に制御できます。実際、ロールもクレームと見なすことができます。
アプリケーションが非常に小さなアプリケーションであり、顧客と管理者の2つの役割しかない場合、顧客がアプリケーションで行うこと以外のことを行うことができない可能性があります。アクセス制御が目的を果たしますが、アプリケーションが成長するにつれて、ある時点でクレームベースのアクセス制御の必要性を感じ始めます。
私はエムランの答えに完全に同意しません
[Authorize(Roles="Sale")]
素朴です
問題はどのようにか
[Authorize(Roles="CustomerCreator")]
とは異なります
[ClaimAuthorize(Permission="CanCreateCustomer")]
両方が同等に優れている場合、なぜクレームが必要なのでしょうか？
私は思う
クレームの概念は、役割に比べてより一般的です
上記の例のコンテキストでは、「CustomerCreator」は「Asp.NETroleProvider」によって提供される「role」タイプのクレームであると言えます。
クレームの追加例。
「AAA」は、「MYExamSite.com」が提供するタイプ「MYExamSite.Score」のクレームです。
「ゴールド」は、「MYGYMApp」によって提供されるタイプ「MYGYM.Membershiptype」の申し立てです
受け入れられた答えは、ロールを鈍いオブジェクトとして、クレームを柔軟なツールとして位置付けているように見えますが、それ以外はほとんど同じように見えます。残念ながら、このポジショニングはクレームの概念に反し、基本的にそれらの目的のわずかな誤解を反映している可能性があります。
ロールは存在し、暗黙のスコープ内でのみ意味をなします。通常、これはアプリケーションまたは組織の範囲です（つまり、Role = Administrator）。一方、クレームは誰でも「作成」できます。たとえば、Google認証では、ユーザーの「メール」を含むクレームが生成され、そのメールがIDに添付されます。 Googleが主張を行うと、アプリケーションはその主張を理解して受け入れるかどうかを選択します。アプリケーション自体は、「ASP.NET MVC Core Identityが行うように」値が「Google」である「authenticationmethod」と呼ばれるクレームをその後添付する場合があります。各クレームにはスコープが含まれているため、クレームが外部、ローカル、またはその両方の意味を持っているかどうかを識別できます（または必要に応じてよりきめ細かく）。
重要な点は、すべてのクレームがIDに明示的に添付され、明示的な範囲を含むことです。もちろん、これらのクレームは承認に使用できます。ASP.NETMVCはAuthorize属性を介してそのサポートを提供しますが、それがクレームの唯一または必ずしも主要な目的でもありません。もちろん、ローカルスコープの承認とまったく同じ方法で使用できるロールとは区別されません。
したがって、ロールまたはクレーム、またはその両方を許可の目的で使用することを選択でき、それらのロールとクレームの範囲がローカルに限定されている限り、どちらにも固有の利点または欠点は見られません。しかし、たとえば、承認が外部ID要求に依存している場合、ロールは不適切になります。外部クレームを受け入れて、それをローカルスコープのロールに変換する必要があります。必ずしもそれが間違っているわけではありませんが、間接的な層を導入し、コンテキストを破棄します。
私はこれまで何度もセキュリティモデルを実装してきましたが、これらの概念についても頭を悩ませる必要がありました。何回もやってきたので、ここにこれらの概念の私の理解があります。
役割とは
役割=ユーザーと権限のunion。
一方、ロールは権限のコレクションです。許可プロファイルと呼びたいです。ロールを定義するとき、基本的にそのロールに多くのパーミッションを追加します。その意味で、ロールはパーミッションプロファイルです。
一方、ロールはユーザーのコレクションでもあります。 BobとAliceをロール「Managers」に追加すると、「Managers」にはグループのような2人のユーザーのコレクションが含まれるようになります。
真実は、ロールはユーザーの集合とパーミッションの集合の両方であるということです。視覚的には、これはベン図として見ることができます。
グループとは
グループ=ユーザーのコレクション
「グループ」は、厳密にはユーザーのコレクションです。グループとロールの違いは、ロールにもパーミッションのコレクションがありますが、グループにはユーザーのコレクションしかありません。
許可とは
許可=サブジェクトができること
許可セットとは
権限セット=権限のコレクション
堅牢なRBACシステムでは、ユーザーのようにアクセス許可をグループ化することもできます。グループはユーザーのみのコレクションですが、権限セットは権限のみのコレクションです。これにより、管理者はパーミッションのコレクション全体を一度にロールに追加できます。
ユーザー、グループ、ロール、およびパーミッションの統合方法
堅牢なRBACシステムでは、ユーザーをロールに個別に追加してロール内のユーザーのコレクションを作成したり、グループをロールに追加してユーザーのコレクションをロールに一度に追加したりできます。いずれにしても、ロールはユーザーのコレクションを個別に追加したり、グループをロールに追加したり、ユーザーとグループの組み合わせをロールに追加したりします。許可も同じように考えることができます。
権限をロールに個別に追加して、ロール内に権限のコレクションを作成したり、権限セットをロールに追加したりできます。最後に、権限と権限セットの組み合わせをロールに追加できます。どちらにしても、ロールは、個々に追加されるか、ロールにパーミッションセットを追加することで、パーミッションのコレクションを取得します。
ロールの全体的な目的は、ユーザーを許可に結びつけることです。したがって、ロールはユーザーと権限の結合です。
クレームとは
クレーム=サブジェクトが「であるもの」
クレームは許可ではありません。前の回答で指摘したように、クレームとは、対象が「できる」ことではなく、対象が「ある」ことです。
クレームはロールや権限に取って代わるものではなく、承認の決定に使用できる追加情報です。
クレームを使用する場合
ユーザーをロールに追加できない場合、またはユーザーの権限への関連付けに基づいていない場合に承認の決定を行う必要がある場合、クレームが役立つことがわかりました。 Facebookユーザーの例がこれを引き起こします。 Facebookユーザーは、「ロール」に追加された人ではないかもしれません...彼らはFacebookを通じて認証された単なる訪問者です。 RBACにはきちんと収まりませんが、承認の決定を行うための情報です。
@CodingSoftは、以前の回答でナイトクラブのメタファーを使用しましたが、これを拡張したいと思います。その回答では、生年月日がクレームの1つを表し、承認規則に対するテストにDateOfBirthクレームの値が使用されるクレームセットを含む例として、運転免許証が使用されました。運転免許証を発行した政府は、請求に信authentic性を付与する機関です。したがって、ナイトクラブのシナリオでは、ドアの警備員が個人の運転免許証を調べ、偽造ID（つまり、政府発行の有効なIDである必要があるか）を調べることにより、信頼できる機関によって発行されたことを確認します。次に、生年月日（運転免許証に関する多くの主張の1つ）を調べ、その値を使用して、その人がクラブに入るのに十分な年齢であるかどうかを判断します。その場合、その人は、何らかの役割を担っているのではなく、有効な主張を持っているという理由で許可規則に合格します。
さて、そのベースを念頭に置いて、それをさらに拡張したいと思います。ナイトクラブがある建物には、クラブの従業員だけが入ることができるオフィス、部屋、キッチン、他の階、エレベーター、地下室などがあると仮定します。さらに、特定の従業員は、他の従業員がアクセスできない特定の場所にアクセスできる場合があります。たとえば、マネージャーは、他の従業員がアクセスできないオフィスフロアにアクセスできます。この場合、2つの役割があります。マネージャーと従業員。
上記のように、訪問者のパブリックナイトクラブエリアへのアクセスは1回の申し立てによって承認されますが、従業員はロールによって他の非パブリック制限室にアクセスする必要があります。彼らにとって、運転免許証は十分ではありません。必要なのは、ドアに入るためにスキャンする従業員バッジです。どこかに、マネージャーロールのバッジに最上階へのアクセスを許可し、従業員ロールのバッジに他の部屋へのアクセスを許可するRBACシステムがあります。
何らかの理由で特定の部屋をロールで追加/削除する必要がある場合は、RBACを使用してこれを実行できますが、申し立てには適していません。
ソフトウェアの許可
アプリケーションへのロールのコーディングは悪い考えです。これにより、ロールの目的がアプリケーションにハードコーディングされます。アプリケーションに必要なのは、機能フラグのように機能する許可だけです。機能フラグが構成によってアクセス可能になる場合、アクセス許可は、ユーザーが配置されているすべてのロールから収集されたアクセス許可のDISTINCTコレクションによって派生するユーザーセキュリティコンテキストによってアクセス可能になります。これを「有効なアクセス許可」と呼びます。アプリケーションは、機能/アクションに対する可能な許可のmenuのみを提示する必要があります。 RBACシステムは、ロールを介してユーザーにこれらのアクセス許可を結合するジョブを実行する必要があります。このように、ロールのハードコーディングはなく、パーミッションが変更されるのは、それが削除されたとき、または新しいロールが追加されたときだけです。許可がソフトウェアに追加されたら、変更しないでください。必要な場合（つまり、新しいバージョンで機能が廃止された場合）にのみ削除する必要があり、新しい機能のみを追加できます。
最後のメモ。
許可と拒否
堅牢なRBACシステム、さらにはCBACシステムでも、許可と拒否を区別する必要があります。
ロールへの許可の追加には、GRANTまたはDENYが必要です。許可がチェックされたら、すべての付与された許可を有効な許可のユーザーリストに追加する必要があります。その後、すべての処理が完了した後、拒否されたアクセス許可のリストにより、システムはこれらのアクセス許可を有効なアクセス許可のリストから削除する必要があります。
これにより、管理者はサブジェクトの最終的な権限を「微調整」できます。権限をユーザーに直接追加することもできれば最適です。この方法では、管理者ロールにユーザーを追加して、すべてにアクセスできますが、ユーザーは男性であるため、女性用トイレへのアクセスを拒否したい場合があります。そのため、男性のユーザーをマネージャーロールに追加し、DENYを使用してユーザーオブジェクトにアクセス許可を追加すると、その女性の部屋へのアクセスのみが削除されます。
実際、これはクレームの良い候補です。ユーザーがクレーム「gender = male」を持っている場合、管理者ロールにいるとすべての部屋にアクセスできますが、女性用トイレにはClaim gender = femaleが必要で、男性用トイレにはClaim gender = maleが必要です。この方法では、男性のユーザーに対して拒否のアクセス許可を構成する必要はありません。これは、単一の承認ルールを持つすべてのユーザーに対してクレームの執行が対応するためです。ただし、どちらの方法でも可能です。
重要な点は、アクセス許可を拒否すると、例外を実装できるため、ロールの管理が容易になることです。
以下は、私がずっと前に作成した、RBACモデルを示す図です。クレームのグラフィックはありませんが、それらはどこにいてもユーザーに付加された単なる属性であると想像できます。また、図にはグループが表示されません（ある時点で更新する必要があります）。
これがお役に立てば幸いです。
2019年4月7日に更新@Brentからのフィードバックに基づいて（ありがとう）...以前の回答への不要な参照を削除し、この回答を他の回答を読まなくても理解できるようにするために、@ CodingSoftが提供する「ナイトクラブ」のメタファー。
ロールは、クレームの1つのタイプにすぎません。そのように、他の多くのクレームタイプが存在する可能性があります。たとえば、ユーザー名はクレームタイプの1つです
RBACとCBACの基本は次のとおりです。
RBAC：アクションの実行を許可するには、ユーザーをロールに割り当てる必要があります。
CBAC：ユーザーは、承認されるために、アプリケーションによって期待される正しい値のクレームを持っている必要があります。クレームベースのアクセス制御は、書くのがエレガントで、保守が簡単です。
クレームは、アプリケーション（証明書利用者）によって信頼されている発行承認サービス（セキュリティサービストークンSTS）によってアプリケーションに発行されます。
どの方法が最適であるかを決定する前に、最初に認証に必要なものを分析することが重要です。以下のMicrosoftのドキュメントから、「クレームは対象者ができることではありません。たとえば、地元の運転免許局によって発行された運転免許証を持っている可能性があります。運転免許証には誕生日があります。この場合クレーム名はDateOfBirth、クレーム値は生年月日、たとえば1970年6月8日、発行者は運転免許局になります。クレームベースの承認は、最も簡単な方法で、クレームの値をチェックし、その値に基づいたリソース。たとえば、ナイトクラブへのアクセスが必要な場合、承認プロセスは次のようになります。6 "ドアのセキュリティ担当者は、あなたの生年月日の請求の値と発行者（運転免許機関） ）アクセスを許可する前。
この例から、クレームベースの承認で近くのクラブにアクセスすることは、ナイトクラブで働くスタッフが必要とする承認のタイプとはまったく異なることがわかります。この場合、ナイトクラブのスタッフはナイトクラブの訪問者はすべてナイトクラブで共通の目的を持っているため、ナイトクラブの訪問者には不要な役割ベースの承認。したがって、この状況では、クレームベースの承認はナイトクラブの訪問者に適しています。
ロールベースの認証 https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/roles 2016/10/14 IDが作成されると、1つ以上に属する場合があります役割。たとえば、トレーシーは管理者とユーザーの役割に属し、スコットはユーザーの役割にのみ属することができます。これらの役割の作成および管理方法は、承認プロセスのバッキングストアによって異なります。ロールは、ClaimsPrincipalクラスのIsInRoleメソッドを通じて開発者に公開されます。
要求ベースの承認 https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/claims 2016/10/14 IDが作成されると、1つまたは信頼できる当事者によって発行されたより多くのクレーム。クレームは、サブジェクトが何ができるかではなく、サブジェクトが何であるかを表す名前と値のペアです。たとえば、地元の運転免許局によって発行された運転免許証を持っている場合があります。運転免許証には生年月日が記載されています。この場合、クレーム名はDateOfBirth、クレーム値は生年月日（1970年6月8日など）、発行者は運転免許局になります。クレームベースの承認は、最も単純な方法で、クレームの値をチェックし、その値に基づいてリソースへのアクセスを許可します。たとえば、ナイトクラブへのアクセスが必要な場合、承認プロセスは次のようになります。
ドアのセキュリティ担当者は、アクセスを許可する前に、あなたの生年月日請求の価値と、発行者（運転免許機関）を信頼するかどうかを評価します。
IDには、複数の値を持つ複数のクレームを含めることができ、同じタイプの複数のクレームを含めることができます。
クレーム方式でロールを管理することもできます。
ビジネスロールを反映する承認ロールを作成する代わりに、アクションロールを反映するロールを作成します。 CreateCustomer、EditCustomer、DeleteCustomer。必要に応じてメソッドに注釈を付けます。
特に役割リストが大きくなるにつれて、個人を一連のアクション役割にマッピングすることは簡単なことではありません。したがって、ビジネスロールをより低い粒度（たとえば、営業、マーケティング）で管理し、ビジネスロールを必要なアクションロールにマッピングする必要があります。つまり、ユーザーをビジネスロールに追加し、既存の承認テーブルで必要な（アクション）ロールにマップします。
ビジネスロールをオーバーライドし、アクションロールに直接人を追加することもできます。
すでに機能しているものの上に構築するため、既存の承認プロセスを元に戻しません。このアプローチを実装するには、さらにいくつかのテーブルが必要です。
この質問はデータベースの見込みから答えられると思います。この注入に関係するテーブルがどのようになっているかに気付いた場合、次のことがわかります。
- AspNetUsers：各ユーザーには、電子メール、電話番号、パスワードなど、すべてのユーザーが必要とするすべての属性を含む1行があります。
- AspNetRoles; GM、CTO、HRM、ADMIN、EMPなどのアプリケーション要件ごとに異なるロールを定義します。各役割が定義するものは、アプリケーションのニーズごとです。
- AspNetUserRoles：各行はAspNetUsersとAspNetRolesをリンクし、1人のユーザーと多くのロールを効果的にリンクします。
- AspNetUserClaims：各行には、AspNetUsersのキーと1つのタイプと値があります。実行時に追加/削除できるユーザーごとに1つの属性を効果的に追加します。
このテーブルの使用法は、特定のニーズに合わせて、ユーザー/アプリケーションのライフタイムの瞬間に微調整することができます。
「購入マネージャー」（PM）の初期段階を考えて、3つのアプローチがあります。
アプリケーションは、AspNetUserRolesに1行を入力して、「PM」の購入権を付与します。任意の金額の発注書を発行するには、ユーザーは「PM」ロールのみが必要です。
アプリケーションは、AspNetUserRolesに1行を入力して「PM」に購入する権利を付与し、AspNetUserClaimsにTYPE「Purchasing Amount」タイプおよび「<1000」値の請求を設定して、金額制限を設定します。発注書を発行するには、ユーザーは「PM」を持っている必要があり、注文額は請求タイプ「購入額」の請求額よりも少なくする必要があります。
アプリケーションはAspNetUserClaimsにTYPE 'Purchasing Amount'タイプと "<1000"値のクレームを入力します。このユーザーの請求タイプ「購入金額」の請求額よりも少ない金額を指定すると、すべてのユーザーが発注書を発行できます。
お気づきかもしれませんが、役割ベースはシステム管理の観点からアプリケーションユーザーの生活を簡素化する厳格な権利の粗い粒度です。ただし、ビジネス要件の観点からユーザーの能力が制限されます。一方、クレームベースは、各ユーザーに割り当てる必要がある非常に細かい権利です。クレームベースはビジネスにも限界を押し上げますが、システム管理は非常に複雑になります。