asp.net-mvc - ASP.NET Identity 中角色与声明的最佳实践

Question

我对在 ASP.NETIdentity 中使用 claims 完全陌生，并且希望了解使用 Roles 和/或声明。

读完所有这些内容后，我仍然有这样的问题......

问:我们不再使用角色吗？
问:如果是这样，为什么仍然提供角色？
问:我们应该只使用声明吗？
问:我们应该一起使用角色和声明吗？

我最初的想法是我们“应该”一起使用它们。我将Claims视为它们支持的Roles的子类别。

例如:
角色:会计
声明:CanUpdateLedger、CanOnlyReadLedger、CanDeleteFromLedger

问:它们是相互排斥的吗？
问:还是只进行 claim 并“完全符合”您的 claim 要求更好？
问:那么这里的最佳实践是什么？

示例:同时使用角色和声明
当然，您必须为此编写自己的属性逻辑...

[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();
}

Answer 1

角色是一个符号类别，它将共享相同级别安全权限的用户集合在一起。基于角色的授权需要首先识别用户，然后确定为用户分配的角色，最后将这些角色与有权访问资源的角色进行比较。

相比之下，声明不是基于群体的，而是基于身份的。

来自Microsoft documentation :

When an identity is created it may be assigned one or more claims issued by a trusted party. A claim is a name value pair that represents what the subject is, not what the subject can do.

安全检查稍后可以根据一项或多项声明的值确定访问资源的权利。

您可以同时使用这两种类型，或者在某些情况下使用一种类型，在其他情况下使用另一种类型。这主要取决于与其他系统的互操作以及您的管理策略。例如，对于经理来说，管理分配给某个角色的用户列表可能比管理分配了特定声明的用户更容易。声明在 RESTful 场景中非常有用，您可以将声明分配给客户端，然后客户端可以提供声明以进行授权，而不是为每个请求传递用户名和密码。