web-dev-qa-db-ja.com

それはクレーム、役割、またはポリシーである必要がありますか？

ロールとクレームの違いは、ロールは一連のユーザーを表し、クレームはユーザーのプロパティを表すことです。したがって、ロール「Administrator」が存在する可能性がありますが、クレーム「HasElevatedPrivilegeBadge」も存在する可能性があります。どちらも同じアクションを許可できます。特定の人だけが特定のことをできるようにしたい場合は、次のうちどれを選択すればよいですか。

CanAddItem, CanUpdateItem, CanDeleteItem,
CanAddProduct, CanUpdateProduct, CanDeleteProduct

ロール「Administrator」を作成し、それに「CanAddItem」、「CanUpdateItem」などのクレームを追加することはできますが、「Canそれは、クレームがすべきことではない、ユーザーができることを述べていますか？

別のアプローチは、次のようなポリシーを作成することです。

policy.AddPolicy("CanAddItem", policy => {
    policy.RequireAuthenticatedUser()
          .RequireRole("Administrator");
});

しかし、20を超えるポリシーの場合、Startupクラスのかなりの量が必要になります。これを行う他の方法はありますか、またはこれらのいずれかが推奨されますか？

.Net Core Identityのソリューションを具体的に探していることを指摘しておきます。フレームワークによって提供されるIdentityテーブルに要件を適合させる方法に関するソリューションを求めています。

c#authorizationasp.net-core.net-corerazor
5
FCin

基本的に、役割と権限のマッピングを記述しています。

これは、暗黙の権限がCanExecuteThisActionであるコントローラーアクションの標準[Authorize（Role = xxx）]でほぼカバーされていると思います。それらは単にマッピングとして機能し、問題を混乱させる可能性があり、多くのボイラープレートコードを追加するため、追加のポリシーは必要ありません。

ポリシーは、ユーザーのクレームまたはその他のプロパティに対していくつかのロジックを実行する必要がある、より複雑なアクセス許可を目的としているようです。例として、ユーザーが生年月日であるAtLeast21ポリシーがあります。

カスタムAuthorizeAttributeクラスを置き換えると思います。

デフォルトのAuthorize属性がロールチェックなどでそれ自体で処理できる場合は使用しません。

4
Ewan

ロール「Administrator」を作成し、それに「CanAddItem」、「CanUpdateItem」などのクレームを追加することはできますが、「Can.

あなたの見方によっては、あなたの例は少し実用的すぎるかもしれません。

別の見方をすると、21歳の人も法定年齢の飲酒ですが、飲酒はできませんでしょ？

あなたの例に戻って、 `Product Creator、Product Changerとあなたの例の違いは何ですか？私にとっては、それは単なる視点であり、彼らが何であるか、何ができるかを説明するものです... 実際には同じことですがあなたの主張に関しては。

1
Erik Philips

私は一般にポリシーを選択します。それは、認可をきめ細かく表現力豊かに制御できるためです。スタートアップクラスで領域を占有するという懸念に対処するには、ポリシーを静的クラスに分割します。

internal static class Policies
{
  public static void CanAddItem(AuthorizationPolicyBuilder policy)
  {
    policy.RequireAuthenticatedUser()
      .RequireRole("Administrator");
  }
}

そしてStartup.csで各ポリシーを登録するとワンライナーです

services.AddAuthorization(options =>
{
  options.AddPolicy(nameof(Policies.CanAddItem), Policies.CanAddItem);
});

さらに制御が必要な場合は、プログラムでポリシーを解決できるカスタムIAuthorizationPolicyProviderを追加することを検討できます。

https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/iauthorizationpolicyprovider?view=aspnetcore-2.1

1
Eric Damtoft

免責事項：私は以前にポリシーを使用したことがありません。問題への答えは、使用しているIDプロバイダーにも依存すると思います。 IDプロバイダーが独自のアプリケーションではなくサードパーティのIDプロバイダーである場合OR IDサーバー4などの標準化された製品OAUTH/openidconnectが機能するため、ロールとクレームを使用する方が良いでしょうロール/クレームネイティヴリーで。

私たちはあなたのスキーマのようなスキーマを使用しますが、少しひねりを加えています：1.複数の役割があります。管理者、itemManager、およびユーザー。 2.「item.add」、「item.delete」、「item.create」などのクレームがあります。3。各ロールはN個のクレームを持つことができます。4。各ユーザーはN個のロールを持つことができます。これにより、多くの構成可能性が可能になります。ユーザーは、管理者になっているか、itemManagerであるため、「item.delete」というクレームを取得できます。

クレーム名をある程度標準化する必要があり、その粒度がアプリケーションに適していることが重要です。たとえば、アイテムを作成して更新する権利が論理的に関連付けられている場合は、クレームを2つではなく1つだけ作成します。

さらに、product.maxnumber.200のように、ロールを使用して少しのビジネスロジックを挿入することができます=>ユーザーは最大200の製品しか持つことができず、ビジネスロジックによって検証する必要があります。

最後に、私が先月読んだいくつかのセキュリティペーパー（OWASP）は、「ユーザーがそれを実行できるか」という質問が頻繁にあるため、ビジネスロジックの横に承認を配置することを推奨しています。ビジネスロジックのコンテキスト内で回答する必要があります。「ユーザーにはproduct.addの役割があり、かつproduct.maxnumber未満の製品しかありませんか？」 ->このようなコンテキストは、特定のリクエストでは簡単に取得できますが、ポリシーのように一般的に答えることは困難です。

0
Christian Sauer