我仍然对所有这些身份的东西感到困惑。
首先，我仍然对角色，策略/声明之间的区别感到困惑。从我读到的内容来看，角色是旧的做事方式，并且是为了向后兼容而保留的，那么这是否意味着AspNetRoleClaims是这种向后兼容性的一部分？
我想我理解声明和政策时，当考虑它们时，就像政策基本上是一组必须通过的规则，并赋予更改规则的能力，而不必通过所有代码和更改角色。
如果是一个声明，基本上是一个值得信赖的来源为该用户担保(即这是他们的年龄，可能来自政府来源)。
现在让我感到困惑的是把它们放在一起。
我生成了标识表并看到
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
然后在我的代码中制作所有不同的"声明类型"，并创建一个策略，看看他们是否说"CanAddUserToBranch"，然后是另一个声明或策略来检查他们所在的分支，以确保他们试图向正确的分支添加一些东西？
编辑
您认为我需要使用基于资源的授权吗？
+------------------+------------------+
| Table | Description |
+------------------+------------------+
| AspNetUsers | The users. |
| AspNetRoles | The roles. |
| AspNetUserRoles | Roles of users. |
| AspNetUserClaims | Claims by users. |
| AspNetRoleClaims | Claims by roles. |
+------------------+------------------+
- 角色是分配给用户的东西。
- 例如。简是一名管理员。
- 声明是用户声明的内容。
- 例如。简的出生日期是1990-10-1。
角色声明 - 是由角色声明的声明。
- 例如。管理员有权访问仪表板。
如果您发现角色和声明令人困惑，可能是因为角色是声明的特殊情况，即角色是声明。
角色与策略
对于基于角色的授权，授权系统会检查是否已为用户分配了访问给定资源所需的角色。
- 例如：只有具有管理员角色的用户才能访问仪表板。
对于基于策略的授权，将执行一些业务逻辑来决定是否应授权资源访问。
- 例如：只有年龄在 40 岁以上的管理员才能访问财务数据。
假设我有这种情况
我有一家公司，有很多分支机构，在每个分支机构中，他们将成为该分支机构的管理员，他们对分支机构拥有全部权力，可以在另一个分支机构做任何事情，但什么都不做。在公司级别，将有一个管理员可以在公司级别和任何分支机构执行任何操作。最后，我在分支机构有一个人可以添加新员工。
这是一种方法：
2 个角色：Admin、TheRoleThatCanAddUsers
一个名为Branch的声明，可以采用分支 ID(或其他任何内容来标识分支)。公司管理员可以使用"CompanyWide"或0或-1等值。
现在创建一个策略，用于检查角色和分支声明，并决定是否应授权用户。