asp.net-mvc ASP.NET MVC 中基于角色的访问控制 (RBAC) 与基于声明的访问控制 (CBAC)

Role-based access control (RBAC) vs. Claims-based access control (CBAC) in ASP.NET MVC

提问by Mr. Pumpkin

What are the main benefits of using CBACvs. RBAC? When is it better to use CBAC and when is it better to use RBAC?

使用CBAC与RBAC的主要好处是什么？什么时候用CBAC比较好，什么时候用RBAC比较好？

I'm trying to understand the general concepts of the CBAC model but the general idea is still not clear for me.

我试图理解 CBAC 模型的一般概念，但总体思路对我来说仍然不清楚。

回答by Emran Hussain

I will try to show how you can benefit from Claim Based Access Control in an ASP.NET MVC Context.

我将尝试展示如何从 ASP.NET MVC 上下文中的基于声明的访问控制中受益。

When you are using Role based authentication, if you have an action for creating customer and you want that the people who are in 'Sale' role should be able to do that, then you write code like this:

当您使用基于角色的身份验证时，如果您有创建客户的操作，并且您希望处于“销售”角色的人员能够执行此操作，那么您可以编写如下代码：

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Later, you realized that, sometimes, people from 'Marketing' role should be able to create Customer. Then, you update your Action method like that

后来，您意识到，有时，“营销”角色的人员应该能够创建客户。然后，你像这样更新你的 Action 方法

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Now, you realized that, some of the marketing people must not be able to create Customer, but it is not possible to assign a different role for those people who are in Marketing. So, you are forced to allow all marketing people to create Customers.

现在，您意识到，某些营销人员不能创建客户，但不可能为营销人员分配不同的角色。因此，您被迫允许所有营销人员创建客户。

you spotted another problem, anytime you decide that Marketing people should be allowed to create customers, you have to update all of your MVC Action methods Authorize attribute, compile your application, test and deploy. Some days later, you decided, not marketing but some other role should be allowed to do the task, so you search in your codebase and delete all 'Marketing' from Authorize attribute and add your new role name in Authorize attribute... Not a healthy solution. At that point, you would realize a need for Permission Based Access Control.

您发现了另一个问题，无论何时您决定允许营销人员创建客户，您都必须更新所有 MVC 操作方法 Authorize 属性、编译您的应用程序、测试和部署。几天后，你决定，不是营销而是允许其他角色来完成任务，所以你在你的代码库中搜索并从授权属性中删除所有“营销”，并在授权属性中添加你的新角色名称......不是一个健康的解决方案。那时，您会意识到需要基于权限的访问控制。

Permission Based access control is a way of assigning various permissions to various users and checking if a user has permission to execute an action from the code in run time. After you assign various permissions to various users, you realize that you need to allow some users to execute some code if the user has some property like "Facebook User", "Long time User" etc. Let me give an example. Say you want to allow access to a specific page if the user is logged in using Facebook. Now, would you create a permission 'Facebook' for that user ? No, 'Facebook' does not sound like a permission. Does it ? Rather it sounds like a claim. At the same time, Permissions can sound like Claim too !! So, it is better to check for claims and allow access.

基于权限的访问控制是一种将各种权限分配给各种用户并检查用户是否有权在运行时从代码执行操作的方法。在为不同的用户分配了不同的权限后，你意识到如果用户具有“Facebook 用户”、“长期用户”等属性，你需要允许一些用户执行一些代码。让我举个例子。假设您希望在用户使用 Facebook 登录时允许访问特定页面。现在，您会为该用户创建一个权限“Facebook”吗？不，“Facebook”听起来不像是一种许可。可以 ？相反，这听起来像是一种主张。同时，Permissions 听起来也像 Claim ！！因此，最好检查声明并允许访问。

Now, lets go back to the concrete example of claim based access control.

现在，让我们回到基于声明的访问控制的具体示例。

You can define some set of claims like this :

您可以像这样定义一些声明：

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer".. etc..

“CanCreateCustomer”、“CanDeleteCustomer”、“CanEditCustomer”……等等。

Now, you can decorate your Action Method like this:

现在，您可以像这样装饰您的操作方法：

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(please note, [ClaimAuthorize(Permission="CanCreateCustomer")] may not be built into MVC class library, I am just showing as an example, you can use some class library which has such Attribute class definition)

（请注意，[ClaimAuthorize(Permission="CanCreateCustomer")] 可能没有内置到 MVC 类库中，我只是举例说明，您可以使用一些具有此类 Attribute 类定义的类库）

Now, you can see that, CreateCustomer action method will always need permission 'CanCreateCustomer' and it will never change or hardly change. So, in your database, you create a table of permissions (claims) and user-permission relation. From your admin panel, you can set permission (claim) for each user who can do what. You can assign 'CanCreateCustomer' permission (claim) to anyone you like and only permitted user will be able to create customer and permitted user will be able to create only customer and nothing else (unless you assign other permissions to the same user).

现在，您可以看到，CreateCustomer 操作方法将始终需要权限“CanCreateCustomer”，并且永远不会或几乎不会更改。因此，在您的数据库中，您创建了一个包含权限（声明）和用户-权限关系的表。从您的管理面板，您可以为每个可以做什么的用户设置权限（声明）。您可以将“CanCreateCustomer”权限（声明）分配给您喜欢的任何人，只有获得许可的用户才能创建客户，获得许可的用户只能创建客户而不能创建其他任何权限（除非您为同一用户分配其他权限）。

This security model offers you clean code practice. Moreover, when you write your Action Method, you dont have to think about who can use this method, rather you can always be assured that whoever is using this method will have proper permission (claim) given by the Admin. Then, Admin can decide who will be able to do what. Not you as a developer. Thats how your business logic is separated from Security logic.

此安全模型为您提供干净的代码实践。此外，在编写 Action Method 时，您不必考虑谁可以使用此方法，而是可以始终确保使用此方法的任何人都将获得 Admin 的适当许可（声明）。然后，管理员可以决定谁可以做什么。不是您作为开发人员。这就是您的业务逻辑与安全逻辑分离的方式。

Whenever someone signs in, your application will check whatever permissions are available for that user and that permission (claim) set will be available as additional properties of currently logged in user (usually the claim set is stored as cookie for the logged in user), so you don't have to check permission set all the time from database. The bottom line is, you get more control of your security logic in your application if you apply claim based access rather than role based access. In fact, a Role can be considered as a Claim too.

每当有人登录时，您的应用程序将检查该用户可用的任何权限，并且该权限（声明）集将作为当前登录用户的附加属性可用（通常声明集存储为登录用户的 cookie），所以你不必一直从数据库中检查权限集。最重要的是，如果您应用基于声明的访问而不是基于角色的访问，您可以更好地控制应用程序中的安全逻辑。事实上，角色也可以被视为声明。

If your application is a very little application where there would be only 2 roles : Customer and Admin and there is no chance that Customer will be able to do anything else other than what they are meant to do in your application, then perhaps, Role based access control will serve the purpose, but as your application grows, you will start to feel the need of claim based access control at some point.

如果您的应用程序是一个非常小的应用程序，其中只有 2 个角色：客户和管理员，并且除了他们在您的应用程序中打算做的事情之外，客户不可能做任何其他事情，那么也许是基于角色的访问控制将达到目的，但随着您的应用程序的增长，您将开始感觉到需要基于声明的访问控制。

回答by Ricardo

I have implemented security models many times now and have had to wrap my head around these concepts as well. Having done it many times, here is my understanding of these concepts.

我已经多次实施安全模型，并且也不得不围绕这些概念进行思考。做了很多次，这里是我对这些概念的理解。

What Are Roles

什么是角色

Role = The unionof Users and Permissions.

角色 =用户和权限的联合。

On one hand, a Role is a collection of Permissions. I like to call it a Permission Profile. When defining a Role you basically add a bunch of Permissions into that Role so in that sense a Role is a Permission Profile.

一方面，角色是权限的集合。我喜欢称之为权限配置文件。在定义角色时，您基本上将一堆权限添加到该角色中，因此从这个意义上说，角色是一个权限配置文件。

On the other hand, a Role is also a collection of Users. If I add Bob and Alice to the Role "Managers" then "Managers" now contains a collection of two Users sort of like a Group.

另一方面，角色也是用户的集合。如果我将 Bob 和 Alice 添加到角色“Managers”，那么“Managers”现在包含两个用户的集合，有点像一个组。

The truth is that a Role is BOTH a collection of Users and a collection of Permissions put together. Visually this can be viewed as a Venn diagram.

事实是，角色既是用户的集合，也是权限的集合。从视觉上看，这可以看作是维恩图。

What is a Group

什么是组

Group = Collection of Users

组 = 用户集合

A "Group" is strictly a collection of Users. The difference between a Group and a Role is that a Role also has a collection of Permissions but a Group only has a collection of Users.

“组”严格来说是用户的集合。组和角色的区别在于，角色也有权限的集合，而组只有用户的集合。

What is a Permission

什么是权限

Permission = What a subject can do

权限 = 主题可以做什么

What is a Permission Set

什么是权限集

Permission Set = A Collection of Permissions

权限集 = 权限集合

In a robust RBAC system, Permissions can also be grouped like Users. Whereas Groups are a collection of Users only, a Permission Set is a collection of Permissions only. This allows an administrator to add whole collections of Permissions to Roles at one time.

在强大的 RBAC 系统中，权限也可以像用户一样分组。组仅是用户的集合，而权限集仅是权限的集合。这允许管理员一次将整个权限集合添加到角色。

How Users, Groups, Roles, and Permissions Come Together

用户、组、角色和权限如何结合在一起

In a robust RBAC system, Users can be added to a Role individually to create the collection of Users in the Role or Groups can be added to a Role to add a collection of Users to the Role at one time. Either way, the Role gets its collection of Users from being individually added or by adding Groups to the Role or by adding a mix of Users and Groups to the Role. Permissions can be thought of in the same way.

在强大的 RBAC 系统中，可以将用户单独添加到角色以创建角色中的用户集合，或者可以将组添加到角色以一次性将用户集合添加到角色。无论哪种方式，角色都可以通过单独添加或通过向角色添加组或通过向角色添加用户和组的混合来获取其用户集合。可以以同样的方式考虑权限。

Permissions can be added to Roles individually to create the collection of Permissions inside the Role or Permission Sets can be added to a Role. Finally, a mix of Permissions and Permission Sets can be added to a Role. Either way, the Role gets its collection of Permissions from being individually added or by adding Permission Sets to a Role.

权限可以单独添加到角色以创建角色内的权限集合，或者权限集可以添加到角色。最后，可以将权限和权限集的混合添加到角色。无论哪种方式，角色都可以通过单独添加或通过向角色添加权限集来获取其权限集合。

The whole purpose of Roles is to marry Users to Permissions. Therefore, a Role is the UNION of Users and Permissions.

角色的全部目的是将用户与权限结合起来。因此，角色是用户和权限的联合。

What Are Claims

什么是索赔

Claim = What a Subject "is"

声明 = 主题“是什么”

Claims are NOT Permissions. As pointed out in previous answers, a Claim is what a subject "is" not what a subject "can do".

声明不是权限。正如之前的答案所指出的，Claim 是一个主题“是”的东西，而不是一个主题“可以做的”。

Claims do not replace Roles or Permissions, they are additional pieces of information that one can use to make an Authorization decision.

声明不会取代角色或权限，它们是可用于做出授权决定的附加信息。

When to Use Claims

何时使用声明

I have found Claims to be useful when an Authorization decision needs to be made when the User cannot be added to a Role or the decision is not based on the association of User to Permission. The example of a Facebook User causes this. A Facebook User may not be someone who is added to a "Role" ... they are just some Visitor authenticated through Facebook. Though it doesn't fit neatly into RBAC it is a piece of information to make a authorization decision on.

我发现，当无法将用户添加到角色或决策不是基于用户与权限的关联时，需要做出授权决策时，声明很有用。Facebook 用户的例子导致了这种情况。Facebook 用户可能不是被添加到“角色”的人……他们只是通过 Facebook 进行身份验证的一些访客。尽管它不完全适合 RBAC，但它是用于做出授权决定的一条信息。

@CodingSoft used the night club metaphor in a previous answer, which I'd like to extend. In that answer, the Driver's License was used as an example that contained a set of Claims where the Date of Birth represents one of the Claims and the value of the DateOfBirth Claim is used to test against the authorization rule. The government that issued the Driver's License is the authority that gives the Claim authenticity. Therefore, in a night club scenario, the bouncer at the door looks at the the person's Driver's License, ensures that it was issued by a trusted authority by examining whether or not it is a fake ID (i.e. must be valid government issued ID), then looks at the Date of Birth (one of the many claims on a Driver's License), then uses that value to determine if the person is old enough to enter the club. If so, the person passes the authorization rule by virtue of having a valid Claim, not by being in some Role.

@CodingSoft 在之前的回答中使用了夜总会的比喻，我想扩展一下。在那个答案中，驾驶执照被用作包含一组索赔的示例，其中出生日期代表其中一个索赔，并且出生日期索赔的值用于测试授权规则。颁发驾照的政府是赋予索赔真实性的权威。因此，在夜总会场景中，门口的保镖会查看此人的驾驶执照，通过检查它是否是假身（即必须是政府颁发的有效身）来确保它是由受信任的机构颁发的，然后查看出生日期（驾照上的众多声明之一），然后使用该值来确定此人的年龄是否足以进入俱乐部。如果是这样的话，

Now, with that base in mind I'd like to now extend that further. Suppose that the building where the night club is contains offices, rooms, a kitchen, other floors, elevators, a basement, etc. where only employees of the club can enter. Furthermore, certain employees might have access to certain places that other employees may not. For example, a Manager may have access to an office floor above that other employees cannot access. In this case there are two Roles. Manager and Employee.

现在，考虑到这个基础，我现在想进一步扩展它。假设夜总会所在的建筑物包含办公室、房间、厨房、其他楼层、电梯、地下室等，只有俱乐部的员工才能进入。此外，某些员工可能可以访问其他员工可能无法访问的某些地方。例如，经理可能有权访问其他员工无法访问的上层办公室。在这种情况下，有两个角色。经理和员工。

While visitors' access to the public night club area is authorized by a single claim as explained above, employees need access by Role to other non-public restricted rooms. For them, a Driver's License is not enough. What they need is an Employee Badge that they scan to enter doors. Somewhere there is an RBAC system that grants badges in the Manager Role access to the top floor, and badges in the Employee Role access to other rooms.

虽然访客进入公共夜总会区域是由上述单一声明授权的，但员工需要按角色进入其他非公共限制房间。对他们来说，驾照是不够的。他们需要的是一个员工徽章，他们通过扫描来进门。某处有一个 RBAC 系统，它授予经理角色中的徽章访问顶层，以及员工角色中的徽章访问其他房间。

If for whatever reason certain rooms need to be added/removed by Role, this can be done using RBAC, but it is not a good fit for a Claim.

如果出于某种原因需要通过角色添加/删除某些房间，这可以使用 RBAC 来完成，但它不适合索赔。

Permissions in Software

软件权限

Coding Roles into the application is a bad idea. This hard codes the purpose of the Role into the application. What the application should have is just Permissions that act like Feature Flags. Where Feature Flags are made accessible by configuration, Permissions are made accessible by the User Security Context that is derived by the DISTINCT collection of Permissions gathered from all Roles the User has been placed in. This is what I call the "Effective Permissions." The application should only present a menuof possible Permissions to features / actions. The RBAC system should do the job of marrying those Permissions to Users through Roles. This way, there is no hard coding of Roles and the only time a Permission changes is when it is removed or a new one is added. Once a Permission is added to the software it should never be changed. It should only be removed when necessary (i.e. when a feature is discontinued in a new version) and only new ones can be added.

将角色编码到应用程序中是一个坏主意。这将角色的用途硬编码到应用程序中。应用程序应该拥有的只是类似于功能标志的权限。在通过配置访问功能标志的情况下，权限由用户安全上下文访问，该用户安全上下文由从用户所在的所有角色收集的权限的 DISTINCT 集合派生。这就是我所说的“有效权限”。应用程序应该只显示一个菜单功能/操作的可能权限。RBAC 系统应该通过角色将这些权限与用户结合起来。这样，就没有角色的硬编码，并且权限更改的唯一时间是在删除或添加新权限时。一旦将权限添加到软件中，就不应再更改。只有在必要时才应该删除它（即当一个特性在新版本中停止时）并且只能添加新的特性。

One final note.

最后一点。

Grant vs Deny

授予与拒绝

A robust RBAC system and even a CBAC system should distinguish between Grants and Denials.

一个强大的 RBAC 系统甚至 CBAC 系统应该区分授予和拒绝。

Adding a Permission to a Role should come with either a GRANT or a DENY. When Permissions are checked, all GRANTed Permissions should be added to the Users list of Effective Permissions. Then after all that is done, a list of DENIED Permissions should cause the system to remove those Permissions from the list of Effective Permissions.

向角色添加权限应该带有 GRANT 或 DENY。选中权限后，应将所有授予的权限添加到有效权限的用户列表中。然后在完成所有这些之后，拒绝权限列表应该会导致系统从有效权限列表中删除这些权限。

This allows administrators to "tweak" the final Permissions of a subject. It is best if Permissions can also be added to Users directly. This way, you can add a User to a Manager Role and they get access to everything, but perhaps you want to DENY access to the Lady's Restroom because the User is a male. So you add the male User to the Manager Role, and add a Permission to the User object with DENY so it takes away only that Lady's room access.

这允许管理员“调整”主题的最终权限。最好也可以直接将权限添加到用户。这样，您可以将用户添加到经理角色，他们可以访问所有内容，但也许您希望拒绝访问女士洗手间，因为该用户是男性。因此，您将男性用户添加到经理角色，并使用 DENY 向用户对象添加权限，这样它只会取消该女士的房间访问权限。

Actually, this would be a good candidate for a Claim. If the User has a Claim "gender=male", then being in the Manager Role gives access to all rooms but the Lady's restroom also requires the Claim gender=female and the Men's restroom requires Claim gender=male. In this way one would not have to configure a DENY permission to male Users since the Claim enforcement takes care of that for everyone with a single authorization rule. However, it could be done either way.

实际上，这将是索赔的一个很好的候选者。如果用户有声明“gender=male”，那么作为经理角色可以访问所有房间，但女士洗手间也需要声明性别=女性，而男士洗手间需要声明性别=男性。通过这种方式，人们不必为男性用户配置拒绝权限，因为声明强制执行使用单个授权规则为每个人处理此问题。但是，它可以通过任何一种方式完成。

The point is that with DENIAL of Permissions it makes the management of the Roles easier because exceptions can be implemented.

关键是通过拒绝权限，它使角色的管理更容易，因为可以实现异常。

Below is a diagram I made a long time ago that shows the RBAC model. I don't have a graphic for the Claims but you can imagine they are just attributes attached to the Users wherever they are. Also, the diagram doesn't show Groups (I need to update it at some point).

下面是我很久以前制作的一张图表，它显示了 RBAC 模型。我没有声明的图形，但您可以想象它们只是附加到用户的属性，无论他们在哪里。此外，图表不显示组（我需要在某个时候更新它）。

I hope this helps.

我希望这有帮助。

This is a Diagram of the RBAC Described Above

这是上面描述的 RBAC 的图表

Update on April 7, 2019Based on feedback from @Brent (thank you) ... removed unnecessary references to previous answers and explained the original basis of the "night club" metaphor provided by @CodingSoft in order to make this answer understandable without having to read other answers.

2019 年 4 月 7 日更新基于@Brent 的反馈（谢谢）......删除了对以前答案的不必要引用，并解释了@CodingSoft 提供的“夜总会”隐喻的原始基础，以使该答案易于理解而无需阅读其他答案。

回答by Pushpendra

I don't fully agree with Emran's answer

我不完全同意 Emran 的回答

[Authorize(Roles="Sale")]

Is naive

天真

The question is how

问题是如何

  [Authorize(Roles="CustomerCreator")]

is different from

不同于

 [ClaimAuthorize(Permission="CanCreateCustomer")]

If both are equally good, why we need claim ?

如果两者都一样好，为什么我们需要 claim ？

I think because

我想因为

Claims concept is more generic compared to Role

与角色相比，声明概念更通用

In context of the example above we can say "CustomerCreator" is a claim of type "role" provided by "Asp.NETroleProvider"

在上述示例的上下文中，我们可以说“CustomerCreator”是“Asp.NETroleProvider”提供的“角色”类型的声明

Additional examples of claims.

索赔的其他示例。

1. "AAA" is claim of type "MYExamSite.Score" provided by "MYExamSite.com"

2. "Gold" is claim of type "MYGYM.Membershiptype" provided by "MYGYMApp"

1. “AAA”是“MYExamSite.com”提供的“MYExamSite.Score”类型的声明

2. “金”是“MYGYMApp”提供的“MYGYM.Membershiptype”类型的声明

回答by hemp

The accepted answer appears to position Roles as a blunt object and Claims as a flexible tool, but otherwise makes them seem nearly identical. Unfortunately, this positioning does a disservice to the concept of claims and may fundamentally reflect a slight misunderstanding of their purpose.

公认的答案似乎将 Roles 定位为一个生硬的对象，将 Claims 定位为一个灵活的工具，但在其他方面使它们看起来几乎相同。不幸的是，这种定位损害了索赔的概念，并且可能从根本上反映了对其目的的轻微误解。

Roles exist and make sense only within an implicit scope. Generally that is an application or organizational scope (i.e. Role=Administrator). Claims, on the other hand, can be 'made' by anyone. For example, Google authentication may produce claims including a user's "email", thus attaching that email to an identity. Google makes the claim, the application chooses whether to understand and accept that claim. The application itself might subsequently attach a claim called "authenticationmethod" (as ASP.NET MVC Core Identity does) with a value of "Google". Each claim includes a scope so that it's possible to identify whether a claim has meaning externally, locally, or both (or more fine grained as needed.)

角色存在并且仅在隐式范围内有意义。通常这是一个应用程序或组织范围（即角色=管理员）。另一方面，任何人都可以“提出”索赔。例如，Google 身份验证可能会产生包括用户“电子邮件”在内的声明，从而将该电子邮件附加到身份中。谷歌提出索赔，应用程序选择是否理解和接受该索赔。应用程序本身随后可能会附加一个名为“authenticationmethod”的声明（如 ASP.NET MVC Core Identity 所做的那样），值为“Google”。每个声明都包含一个范围，以便可以确定声明是否具有外部、本地或两者（或根据需要更细粒度）的含义。

The key points are that all claims are explicitly attached to an identity and include an explicit scope. Those claims may of course be used for authorization - and ASP.NET MVC provides support for that via the Authorize attribute, but that is not the only or necessarily even primary purpose for Claims. It certainly doesn't distinguish it from Roles, which can be used in exactly the same ways for locally scoped authorization.

关键点是所有声明都明确附加到身份并包括明确的范围。这些声明当然可以用于授权 - 并且 ASP.NET MVC 通过 Authorize 属性提供支持，但这不是声明的唯一目的，甚至不一定是主要目的。它当然不会与角色区分开来，角色可以以完全相同的方式用于本地范围的授权。

So one can choose to use Roles, or Claims, or both for the purpose of authorization and likely find no inherent advantage or disadvantage to either, so long as those Roles and Claims are locally scoped. But if, for instance, authorization depends upon external identity claims, then Roles will be inadequate. You would have to accept the external claim and translate it into a locally scoped role. There isn't necessarily anything wrong with that, but it introduces a layer of indirection and discards context.

因此，可以选择使用角色或声明，或两者都用于授权，并且可能不会发现任何一种固有的优势或劣势，只要这些角色和声明是本地范围的。但是，例如，如果授权取决于外部身份声明，那么角色将是不够的。您必须接受外部声明并将其转换为本地范围的角色。这不一定有什么问题，但它引入了一个间接层并丢弃了上下文。

回答by David Brossard

More broadly, you should consider attribute-based access control (ABAC). RBAC and ABAC are both concepts defined by NIST, the National Institute of Standards and Technology. CBAC, on the other hand, is a model pushed by Microsoft which is very similar to ABAC.

更广泛地说，您应该考虑基于属性的访问控制 (ABAC)。RBAC 和 ABAC 都是由美国国家标准与技术研究院 NIST 定义的概念。另一方面，CBAC 是微软推出的一种模型，与 ABAC 非常相似。

Read more here:

在此处阅读更多信息：

• Role-based access control NIST page
• Attribute-based access control NIST page

• 基于角色的访问控制NIST 页面
• 基于属性的访问控制NIST 页面

回答by Venkat Naidu

Role is just one type of Claim. Like that, there can be many other claim types, for example user name is one of the claim type

角色只是一种类型的声明。像这样，可以有许多其他声明类型，例如用户名是声明类型之一

回答by CodingSoft

It is important to first analyse what the Authentication is required for before deciding on which method is best. From Microsoft documentation below, it says "A claim is not what the subject can do. For example, you may have a driver's license, issued by a local driving license authority. Your driver's license has your date of birth on it. In this case the claim name would be DateOfBirth, the claim value would be your date of birth, for example 8th June 1970 and the issuer would be the driving license authority. Claims based authorization, at its simplest, checks the value of a claim and allows access to a resource based upon that value. For example if you want access to a night club the authorization process might be:6" The door security officer would evaluate the value of your date of birth claim and whether they trust the issuer (the driving license authority) before granting you access.

在决定哪种方法最好之前，首先分析需要什么身份验证是很重要的。从下面的 Microsoft 文档中，它说“索赔不是主体可以做的事情。例如，您可能拥有由当地驾驶执照当局颁发的驾驶执照。您的驾驶执照上有您的出生日期。在这种情况下索赔名称将是 DateOfBirth，索赔价值将是您的出生日期，例如 1970 年 6 月 8 日，颁发者将是驾驶执照当局。最简单的基于索赔的授权检查索赔的价值并允许访问基于该值的资源。例如，如果您想访问夜总会，授权过程可能是：6”

From this example we can see that accessing a nigh club with a Claims-Based Authorization is quit different from the type of Authorization that will be required by the staff who work in the night club, in this case the staff of the night club will require a Role based Authorization which is not required for the night club visitors as the night club visitors all have a common purpose at the night club hence in this situation a Claims-Based Authorization is suitable for the night club visitors.

从这个例子中我们可以看到，使用基于声明的授权访问夜总会与在夜总会工作的员工所需的授权类型不同，在这种情况下夜总会的工作人员将需要夜总会访客不需要基于角色的授权，因为夜总会访客在夜总会都有一个共同的目的，因此在这种情况下，基于索赔的授权适用于夜总会访客。

Role based Authorization https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles10/14/2016 When an identity is created it may belong to one or more roles. For example, Tracy may belong to the Administrator and User roles whilst Scott may only belong to the User role. How these roles are created and managed depends on the backing store of the authorization process. Roles are exposed to the developer through the IsInRole method on the ClaimsPrincipal class.

基于角色的授权 https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles10/14/2016 创建身份后，它可能属于一个或多个角色。例如，Tracy 可能属于管理员和用户角色，而 Scott 可能只属于用户角色。如何创建和管理这些角色取决于授权过程的后备存储。角色通过 ClaimsPrincipal 类上的 IsInRole 方法向开发人员公开。

Claims-Based Authorization https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims10/14/2016 When an identity is created it may be assigned one or more claims issued by a trusted party. A claim is name value pair that represents what the subject is, not what the subject can do. For example, you may have a driver's license, issued by a local driving license authority. Your driver's license has your date of birth on it. In this case the claim name would be DateOfBirth, the claim value would be your date of birth, for example 8th June 1970 and the issuer would be the driving license authority. Claims based authorization, at its simplest, checks the value of a claim and allows access to a resource based upon that value. For example if you want access to a night club the authorization process might be:

基于声明的授权 https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims2016 年 10 月 14 日创建身份后，可能会为其分配一个或多个由受信任方发布的声明。声明是名称值对，表示主题是什么，而不是主题可以做什么。例如，您可能拥有当地驾驶执照当局颁发的驾驶执照。您的驾照上有您的出生日期。在这种情况下，索赔名称将是 DateOfBirth，索赔价值将是您的出生日期，例如 1970 年 6 月 8 日，颁发者将是驾驶执照当局。最简单的基于声明的授权检查声明的值并允许基于该值访问资源。例如，如果您想进入夜总会，授权过程可能是：

The door security officer would evaluate the value of your date of birth claim and whether they trust the issuer (the driving license authority) before granting you access.

门安全员会在授予您访问权限之前评估您的出生日期声明的价值以及他们是否信任颁发者（驾驶执照当局）。

An identity can contain multiple claims with multiple values and can contain multiple claims of the same type.

一个身份可以包含多个具有多个值的声明，并且可以包含多个相同类型的声明。

回答by Benjamin Nguyen

The fundamental between RBAC and CBAC is that:

RBAC 和 CBAC 之间的基本原理是：

RBAC: a user must be assigned to a role to be authorized to perform an action.

RBAC：必须为用户分配一个角色才能被授权执行操作。

CBAC: user must have a claim with the correct value, as expected by the application, to be authorized. Claims-based access control is elegant to write and easier to maintain.

CBAC：用户必须具有正确值的声明，如应用程序预期的那样，才能获得授权。基于声明的访问控制编写优雅且易于维护。

Beside that claims are issued to the application by an issuing authorize services (Security Service Token STS) that is trusted by your application (Relying Party)

此外，声明是由您的应用程序（依赖方）信任的颁发授权服务（安全服务令牌 STS）向应用程序发出的

回答by pixelda

It is also possible to manages roles in a claims manner.

还可以以声明方式管理角色。

Instead of creating authorisation roles that reflect a business role, create roles that reflect action roles, e.g. CreateCustomer, EditCustomer, DeleteCustomer. Annotate methods as required.

不是创建反映业务角色的授权角色，而是创建反映操作角色的角色，例如 CreateCustomer、EditCustomer、DeleteCustomer。根据需要注释方法。

It is not a simple matter to map individuals to a set of action roles, especially as the role list gets larger. Therefore, you'll need to manage the business roles at a lower level of granularity (e.g. Sales, Marketing) and map the business Role to the action roles required. I.e., add a user to a business role and it maps them to the required (action) roles in the existing authorisation table.

将个人映射到一组动作角色并不是一件简单的事情，尤其是当角色列表变大时。因此，您需要在较低的粒度级别（例如销售、营销）管理业务角色，并将业务角色映射到所需的操作角色。即，将用户添加到业务角色，并将它们映射到现有授权表中所需的（操作）角色。

You can even override the business role and add a person to an action role directly.

您甚至可以覆盖业务角色并将人员直接添加到操作角色。

Because you build on top of what already works, you don't undo the existing Authorisation process. You need only a few more tables to implement this approach

因为您建立在已经有效的基础之上，所以您不会撤消现有的授权过程。你只需要多几个表就可以实现这种方法

回答by Ahmed Bahtity

I think this question could be answered from the database prospective. if you noticed how the tables involved in this implantation you will find the following

我认为这个问题可以从数据库的角度来回答。如果您注意到此植入所涉及的表格，您会发现以下内容

1. AspNetUsers : each user has one row with all the attributes required by all users like email, address phone, password.....
2. AspNetRoles ; defines different roles as per application requirements like GM , CTO, HRM,ADMIN, EMP. what each roles defines is as per application needs.
3. AspNetUserRoles: each row links AspNetUsers and AspNetRoles and effectively links between one user and many roles.
4. AspNetUserClaims: each row has key to AspNetUsers and one type and value. so effectively add one attribute for each user that could be added/removed at run time.

1. AspNetUsers ：每个用户都有一行，其中包含所有用户所需的所有属性，如电子邮件、地址电话、密码.....
2. AspNet角色；根据应用要求定义不同的角色，如 GM、CTO、HRM、ADMIN、EMP。每个角色定义的是根据应用程序的需要。
3. AspNetUserRoles：每一行链接 AspNetUsers 和 AspNetRoles，有效链接一个用户和多个角色。
4. AspNetUserClaims：每一行都有 AspNetUsers 的键和一个类型和值。如此有效地为每个用户添加一个可以在运行时添加/删除的属性。

The usage of this tables could be tweaked at one moment of user/application life time to match specific needs.

可以在用户/应用程序生命周期的某个时刻调整此表的使用，以满足特定需求。

Consider the early stage of "Purchasing Manager" (PM), we could have three approachs

考虑“采购经理”（PM）的早期阶段，我们可以有三种方法

1. Application populates AspNetUserRoles with one row to grants 'PM' right to buy. To issue purchasing order with any amount, user only need "PM" role.

2. Application populates AspNetUserRoles with one row to grants 'PM' right to buy, and populates the AspNetUserClaims a claim of TYPE 'Purchasing Amount' type and "<1000" value to set the amount limit. To issue purchasing order, user need to has 'PM'and the order amount be less than claim value of claim TYPE 'Purchasing Amount'.

3. Application populate AspNetUserClaims with claim of TYPE 'Purchasing Amount' type and "<1000" value. Any user can issue purchasing order, given the the amount to be less than claim value of claim TYPE 'Purchasing Amount' for this user.

1. 应用程序用一行填充 AspNetUserRoles 以授予“PM”购买权。要发出任何金额的采购订单，用户只需要“PM”角色。

2. 应用程序用一行填充 AspNetUserRoles 以授予“PM”购买权，并填充 AspNetUserClaims TYPE 'Purchasing Amount' 类型和“<1000”值的索赔以设置金额限制。要发出采购订单，用户需要有“PM”并且订单金额小于索赔类型“采购金额”的索赔值。

3. 应用程序使用 TYPE 'Purchasing Amount' 类型和“<1000”值的声明填充 AspNetUserClaims。任何用户都可以发出采购订单，前提是金额小于该用户的索赔类型“采购金额”的索赔值。

As it could be noticed, role based is coarse grained of rigid rights that would simplify the life of the application user from the system management point of view. however it will limits the user abilities from the business requirements point of view. At the other hand claim based is very fine rights that need to be assigned to each user. claim based will push the business too the limit, however will make the system management very complex.

可以注意到，基于角色的严格权限是粗粒度的，从系统管理的角度来看，这将简化应用程序用户的生活。但是，从业务需求的角度来看，它会限制用户的能力。另一方面，基于声明是需要分配给每个用户的非常好的权利。基于索赔的做法将业务推向了极限，然而会使系统管理变得非常复杂。