web-dev-qa-db-ja.com

Asp.net Core Identity AspNetUserClaimsまたはAspNetRoleClaimsを使用していますか？

私はまだこのすべてのアイデンティティーについて混乱しています。

最初に、ロール、ポリシー/クレームの違いをまだ混乱させています。私が役割を読んだことから、物事を行う古い方法であり、後方互換性のために保持されていたので、それはAspNetRoleClaimsがこの後方互換性の一部であることを意味しますか？

ポリシーは基本的に合格する必要がある一連のルールであり、すべてのコードを実行して役割を変更することなくルールを変更できるように、クレームとポリシーを個別に考えると理解できると思います。

申し立てだった場合、基本的にはそのユーザーについて保証されている信頼できるソースです（つまり、これは政府のソースから来た可能性のある年齢です）。

今、私を混乱させるのは、それをすべてまとめることです。

IDテーブルを生成し、表示します

AspNetUsers
AspNetUserRoles
AspNetRoles
AspNetRoleClaims
AspNetUserClaims
AspNetUserLogins

AspNetUsersテーブルの機能とAspNetUserLoginsを取得します（外部ログインプロバイダーのように使用しているようです）。

AspNetRoleClaimsとAspNetUserClaimsの違いについて混乱しています。 AspNetUserClaimsを使用するだけですか、それともすべてを使用しますか？

このシナリオがあるとしましょう

私には多くの支店がある会社があり、各支店でその支店の管理者となり、支店を完全に支配し、他の支店では何もできません。会社レベルでは、会社レベルおよび支店で何でもできる管理者がいます。最後に、ブランチに新しい従業員を追加できる人がいます。

これはどのように見えますか？ 3つのロールを作成しますか？

CompanyAdmin
BranchAdmin
AddUsersAtBranchLevel (or is this some sort of claim??)
What do the tables look like? Is there anything going to be in AspNetRoleClaims? AspNetUserClaims?

ユーザーがブランチ管理者であるかどうか、およびブランチを編集しようとしているかどうかを確認するポリシーを作成できますか？

または、私はすべての役割のものを忘れてAspNetUserClaimsに持っていますか

User1   CanAddUserToBranch true
User1 CanDeleteUserBranch true
User1 CanAddUserToCompany true

次に、私のコードでそれらをすべて異なる「ClaimTypes」にし、「CanAddUserToBranch」と言っているかどうかを確認するポリシーを作成し、正しいブランチに何かを追加しようとしていることを確認するために別のクレームまたはポリシーを作成します？

編集

リソースベースの認証を使用する必要があると思いますか？

asp.net-coreasp.net-identityclaims-based-identityrole-based
15
chobo2
+------------------+------------------+
|      Table       |   Description    |
+------------------+------------------+
| AspNetUsers      | The users.       |
| AspNetRoles      | The roles.       |
| AspNetUserRoles  | Roles of users.  |
| AspNetUserClaims | Claims by users. |
| AspNetRoleClaims | Claims by roles. |
+------------------+------------------+
  • 役割は、ユーザーに割り当てられたものです。
    • 例えば。ジェーンは管理者です。
  • クレームは、ユーザーが主張するものです。
    • 例えば。ジェーンの生年月日は1990-10-1です。
  • 役割要求とは、役割によって要求された要求です。
    • 例えば。管理者はダッシュボードにアクセスできます。

ロールとクレームがわかりにくい場合、それはおそらくロールがクレームの特殊なケースである、つまりロールがクレームであるためです。

役割とポリシー

  • 役割ベースの許可の場合、許可システムは、指定されたリソースへのアクセスに必要な役割がユーザーに割り当てられているかどうかを確認します。

    • たとえば、管理者ロールを持つユーザーのみがダッシュボードにアクセスできます。

  • ポリシーベースの承認の場合、リソースアクセスを承認する必要があるかどうかを判断するために、いくつかのビジネスロジックが実行されます。

    • 例：40歳以上の管理者のみが財務データにアクセスできます。

このシナリオがあるとしましょう

私には多くの支店がある会社があり、各支店でその支店の管理者となり、支店を完全に支配し、他の支店では何もできません。会社レベルでは、会社レベルおよび支店で何でもできる管理者がいます。最後に、ブランチに新しい従業員を追加できる人がいます。

これを行う1つの方法を次に示します。

2ロール：Admin、TheRoleThatCanAddUsers
クレームBranchと呼ばれ、ブランチID（またはブランチを識別するためのその他のもの）を取ることができます。会社の管理者は、"CompanyWide"または0または-1などの値を使用できます。

次に、RoleおよびBranchクレームをチェックし、ユーザーを許可するかどうかを決定するポリシーを作成します。

17
gldraphael