基于权限的授权与ASP.NET Core 2.1身份验证

3
过去,使用.NET Framework上的ASP.NET MVC时,我总是在内置的基于角色的授权层之上实现了一个基于权限的授权层。所谓“基于权限”,是指为每个角色分配了一组枚举权限,并且在运行时,每个调用都会检查权限而不是角色。
例如,假设OrdersController上的Post方法需要AddOrEditOrder权限。那么在Post操作上看起来像[MyAuthorize(MyRights.AddOrEditOrder)]。然后你可以在其他地方配置只有经理和客户代表角色拥有该权限。
我一直认为这个小抽象层易于实现,大大提高了可维护性,即使将权限与角色映射仅从配置文件更新而不是UI。对于来自基于Windows的IT环境的人来说,这就是“正确的做法”,在我看来。
然而,转向ASP.NET Core Identity后,我们有了所有这些新奇的花哨功能。现在,我意识到声明和权限根本不是同一回事。但是,您可以使用声明,将它们分配给角色,并有效地完成我上面描述的任务吗?
根据数据库模式,您可以将Claims分配给Roles,还可以将Roles分配给Users。因此,理论上,将Claim“AddOrEditOrder”分配给“Manager”和“CustomerRep”角色将实现我所想的功能。然后,我只需在OrdersController的Post操作中放置[Authorize(“AddOrEditOrder”)],就可以达到预期效果!这样做是否存在严重问题,我能否使用Claims和Roles?
编辑:使用策略而非Claims
正如@Ruard-van-Elburg提供的有益答案所建议的那样,我错误地写成了“Claims”,而实际上我是指“Policies”。将其替换为另一个单词,“Rights”的另一个单词是“Permissions”,在此相关问题及其顶部答案中提供了一些非常有用的建议:How to implement Permission Based Access Control with Asp.Net Core
1个回答

3
这不是应该使用声明的方式。声明应该模拟用户的身份,而不是权限。请阅读文章Identity vs Permissions以获取更多解释。
在您的情况下,您可以使用策略
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthorization(options =>
    {
        options.AddPolicy("AddOrEditOrder", policy =>
            policy.RequireRole("Manager", "CustomerRep"));
    });
}

同时使用相同的属性:

[Authorize("AddOrEditOrder")]

添加授权的其他选项很多。您还可以查看PolicyServer


啊!谢谢你!直到你说了那句话,我才回头看了身份证文档和 AuthorizeAttribute 的源代码,意识到我误解了策略如何与用户、角色和声明配合使用。(自己打脸) - pbristow
1
权限可以成为特定用户的声明,就像角色一样。 - Konrad

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接