我对ASP.NETIdentity中的声明的使用是全新的，并希望了解使用角色和/或声明的最佳实践。
毕竟这个阅读，我还有一些问题，如…
问：我们不再使用角色吗？
问：如果是这样，为什么Roles仍然提供？
问：我们应该只使用版权声明吗？
问：我们应该使用角色&索赔在一起？
我最初的想法是，我们“应该”一起使用它们。我看到声明作为他们支持的角色的子类别。
例如：
角色：会计
声明：CanUpdateLedger，CanOnlyReadLedger，CanDeleteFromLedger
问：他们是否打算互相排斥？
问：或者最好是仅仅声明和“完全限定”您的声明？
问：那么这里的最佳做法是什么？
示例：使用角色&一起索赔
当然，你必须为此写自己的属性逻辑…
[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
// Do stuff here
return View();
}
示例：完全限定您的声明
[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
// Do stuff here
return View();
}
解决方法
角色是一个符号类别，用于一起收集共享相同级别的安全权限的用户。基于角色的授权要求首先识别用户，然后确定用户被分配到的角色，最后将这些角色与被授权访问资源的角色进行比较。
相反，索赔是用户识别自己的权利。换句话说，“我允许这样做，因为我有这个索赔。一般来说，基于声明的授权包含基于角色的授权。确切地说，角色成员资格是基于身份确定的，身份只是权利价值的一种权利。角色本质上是一种非常具体的声明，即“因为我的用户名是这个，我是这个角色的成员，因为我是这个角色的成员，我可以访问这个资源。
您可以一起使用，或在一些情况下使用一种类型，而在其他情况下使用另一种类型。它主要取决于与其他系统的互操作和您的管理策略。例如，管理员管理分配给角色的用户列表可能比管理分配了特定声明的用户更容易。在RESTful方案中，声明可能非常有用，您可以向客户端分配声明，然后客户端可以提交声明，以授权，而不是传递每个请求的用户名和密码。
