我仍然对所有这些身份的东西感到困惑。
首先,我仍然对角色、政策/声明之间的区别感到困惑。从我读到的角色是旧的做事方式,并且是为了向后兼容而保留的,那么这是否意味着 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
然后在我的代码中创建所有不同的“ClaimTypes”并创建一个策略,看看他们是否说“CanAddUserToBranch”,然后另一个声明或策略来检查他们所在的分支,以确保他们正在尝试向正确的分支添加一些东西?
编辑
你认为我需要使用基于资源的授权吗?