具有ASP.NET Core 2.1身份的基于权限的授权 [英] Rights-based authorization with ASP.NET Core 2.1 Identity

问题描述

过去，使用.NET Framework上的ASP.NET MVC，我总是在内置的基于角色的授权之上实现基于权限的授权层. 基于权利"是指为每个角色分配一个枚举的权利列表，并且在运行时，每个调用都检查一个权利，而不是角色.

例如例如说OrdersController上的Post方法需要AddOrEditOrder权限.看起来像Post操作上的[MyAuthorize(MyRights.AddOrEditOrder)].然后在其他地方，您可以配置只有Manager和CustomerRep角色才具有该权限.

我一直认为这个小抽象层易于实现，并且极大地改善了可维护性，即使角色权限映射仅从配置文件而不是从UI更新也是如此.来自IMO，这是基于Windows的IT设置.

但是，转向ASP.NET Core Identity，我们对Claims有了所有这些新奇的幻想.现在，我意识到要求和权利根本不是一回事.但是，您可以使用Claims并将其分配给Roles并有效地完成我在上文中所述的工作吗?

它基于数据库架构显示，您可以将Claims分配给Roles，并且可以将Roles分配给Users.因此，从理论上讲，将声明"AddOrEditOrder"同时添加到经理"和"CustomerRep"角色中将可以完成我的想法.然后我将[Authorize("AddOrEditOrder")]放在OrdersController的Post操作上，中提琴就可以了！...对吗?

我可以使用Claims&这样的角色没有引起严重的反感吗?

使用政策，而不是声明

正如@ Ruard-van-Elburg给出的有帮助的答案所建议的那样，我错误地写了"Claims"，意思是"Policies".用一个替换另一个，我说的一切都奏效. 权利"的另一个词是权限"，在此相关问题及其最高答案中有一些非常有用的建议:解决方案

这不是应使用声明的方式.声明应该模拟用户的身份，而不是权限.请阅读文章身份与权限以获取一些解释. >

您可以使用政策.

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthorization(options =>
    {
        options.AddPolicy("AddOrEditOrder", policy =>
            policy.RequireRole("Manager", "CustomerRep"));
    });
}

并使用相同的属性:

[Authorize("AddOrEditOrder")]

还有许多其他选项可添加授权.您还可以查看 PolicyServer .

In the past, with ASP.NET MVC on .NET Framework, I always implemented a Rights-based authorization layer on top of the Roles-based authorization that was built-in. By "Rights-based", what I mean is that a list of enumerated Rights are assigned to each Role, and at runtime, each call checked for a Right, not a Role.

e.g. say the Post method on the OrdersController required the AddOrEditOrder Right. That would look like [MyAuthorize(MyRights.AddOrEditOrder)] on the Post action. Then somewhere else you'd be able to configure that only the Manager and CustomerRep Roles had that Right.

I always thought this little abstraction layer was easy to implement and greatly improved maintainability, even if the rights-to-roles mapping was only updated from a config file and not a UI. Coming from a Windows-based IT setting, this is just "how it's done right", IMO.

However, moving to ASP.NET Core Identity, we have all this newfangled fanciness with Claims. Now, I realized Claims and Rights are not at all the same thing. However, can you use Claims, assign them to Roles, and effectively accomplish what I described above?

It appears based on the database schema that you can assigned Claims to Roles, and you can assign Roles to Users. So, in theory, adding the Claim "AddOrEditOrder" to both the "Manager" and "CustomerRep" Roles would do what I'm thinking. Then I'd just put [Authorize("AddOrEditOrder")] on the Post action of the OrdersController, and viola, it would work!... right?

Can I use Claims & Roles this way without serious sanfus?

EDIT: Use Policies, not Claims

As the helpful answer from @Ruard-van-Elburg suggests, I mistakenly wrote "Claims" where I meant "Policies". Substitute one for the other, and everything I said works. Another word for "Rights" is "Permissions", and there are some very useful suggestions in this related question and its top answer: How to implement Permission Based Access Control with Asp.Net Core

解决方案

This is not the way claims should be used. Claims are supposed to model the identity of a user, not permissions. Please read the article Identity vs Permissions for some explanation.

In your case you can use policies.

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthorization(options =>
    {
        options.AddPolicy("AddOrEditOrder", policy =>
            policy.RequireRole("Manager", "CustomerRep"));
    });
}

And use the same attribute:

[Authorize("AddOrEditOrder")]

There are many other options to add authorization. You can also take a look at the PolicyServer.

这篇关于具有ASP.NET Core 2.1身份的基于权限的授权的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！