我不完全同意Emran的回答

[Authorize(Roles="Sale")]

是天真的

问题是如何

  [Authorize(Roles="CustomerCreator")]

不同于

 [ClaimAuthorize(Permission="CanCreateCustomer")]

如果两者都是一样的好，为什么我们需要声明?

我想是因为

声明概念比角色更通用

在上面的例子中，我们可以说“CustomerCreator”是由“Asp. Asp. creator”提供的类型为“role”的声明。NETroleProvider”

索赔的其他例子。

“AAA”是类型为“MYExamSite”的索赔。分数由“MYExamSite.com”提供 “黄金”是MYGYM类型的索赔。“MYGYMApp”提供的会员类型

我认为这个问题可以从数据库的角度来回答。 如果您注意到表是如何参与这个植入的，您将发现以下内容

AspNetUsers : each user has one row with all the attributes required by all users like email, address phone, password..... AspNetRoles ; defines different roles as per application requirements like GM , CTO, HRM,ADMIN, EMP. what each roles defines is as per application needs. AspNetUserRoles: each row links AspNetUsers and AspNetRoles and effectively links between one user and many roles. 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.

这个表的使用可以在用户/应用程序生命周期的某个时刻进行调整，以匹配特定的需求。

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

Application populates AspNetUserRoles with one row to grants 'PM' right to buy. To issue purchasing order with any amount, user only need "PM" role. 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'. 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.

可以注意到，基于角色的是粗粒度的刚性权限，从系统管理的角度来看，这将简化应用程序用户的生活。然而，从业务需求的角度来看，这将限制用户的能力。 另一方面，基于索赔的是非常精细的权利，需要分配给每个用户。以索赔为基础会把业务推到极限，但会使系统管理非常复杂。

公认的答案似乎将角色定位为钝器，而声明定位为灵活的工具，但在其他方面使它们看起来几乎相同。不幸的是，这种定位有损于索赔的概念，并可能从根本上反映出对其目的的轻微误解。

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.)

关键点在于，所有声明都显式地附加到一个标识，并包括一个显式的范围。这些声明当然可以用于授权-和ASP。NET MVC通过Authorize属性提供了对此的支持，但这不是claim的唯一目的，甚至不一定是主要目的。它当然不会与role区分开来，后者可以以完全相同的方式用于本地范围的授权。

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.

RBAC和CBAC的基本原理是:

RBAC:用户必须被分配到某个角色，才能被授权执行某个操作。

CBAC:用户必须拥有应用程序所期望的具有正确值的声明，以获得授权。基于声明的访问控制编写起来很优雅，也更容易维护。

除此之外，索赔由您的应用程序信任的发出授权服务(安全服务令牌STS)发出给应用程序(依赖方)。

角色只是Claim的一种类型。与此类似，还可以有许多其他声明类型，例如用户名就是声明类型之一

在决定哪种方法是最好的之前，首先分析身份验证需要什么是很重要的。来自基于声明的授权:

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: 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.

从这个例子我们可以看到,使用声明式授权访问几乎俱乐部退出不同的授权类型需要的员工在夜总会工作,在这种情况下,员工俱乐部需要一个基于角色的授权而不是必需的夜总会游客的夜总会的游客都有一个共同的目的在夜总会因此在这种情况下的声明式授权适用于夜总会游客。

来自基于角色的授权:

当创建一个标识时，它可能属于一个或多个角色。例如，Tracy可能属于管理员和用户角色，而Scott可能只属于用户角色。如何创建和管理这些角色取决于授权过程的备份存储区。角色通过ClaimsPrincipal类上的IsInRole方法向开发人员公开。