我将尝试用外行的术语解释基于角色/声明/权限的访问控制概念。我将在这里展示的代码片段是伪代码，可能会也可能不会编译。

什么是角色？

角色可以被认为是职位。像“销售经理”、“市场经理”、“管理员”等。

索赔是什么？

声明可以比角色更广泛。您可以将 Claim 视为 TAG。例如，您可以将一个人标记为“友好”、“健谈”、“欧洲人”、“摄影师”、“18
岁的成年人”等。从技术上讲，一个角色可以被认为是索赔。

基于角色的访问控制

很简单。让我们展示一些例子，而不是使用单词。比如说，您允许通过检查角色来访问您网站上的某些页面。像这样：

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

    [Authorize(Roles="Marketing Manager")]
    public ActionResult EditLandingPage()
    {
        return View();
    }

基于声明的访问控制

通俗地说，在基于声明的访问控制中，您在确定对页面的访问时检查声明而不是角色。

（这是一个伪代码。ClaimsAuthorize 不是 MVC 中的内置类，相反，您可能会找到一些 NuGet 包，或者您可以自己编写）

    [ClaimsAuthorize(Claims="Senior-Employee, Award-Winner-Employee, Experienced-On-Sales")]
    public ActionResult CreateCustomer()
    {
        return View();
    }


    [ClaimsAuthorize(Claims="Trust-worthy-Employee, President")]
    public ActionResult DeleteCustomer()
    {
        return View();
    }

    [ClaimsAuthorize(Claims="Adult-over-18years")]
    public ActionResult ViewImagesOfViolence()
    {
        return View();
    }

请注意，我们允许访问基于用户声称是谁的页面，而不是检查角色。

RBAC 与 CBAC

好的，现在，如果你问基于角色的访问控制或基于声明的访问控制有什么好处，那么，想想这个页面“ViewImagesOfViolence”。在确定是否应允许用户访问该页面时，检查“18
岁以上成人”声明不是更直观吗？总之，使用声明，您可以在用户中创建更多细分来比较角色。在抽象意义上，所有的角色也可以是声明，但声明不能被认为是角色。

基于权限的访问控制

在允许查看页面的权限时，与其检查角色或声明，不如考虑基于权限的访问控制。让我告诉你一些痛点。

当您使用基于角色的身份验证时，如果您有一个创建客户的操作，并且您希望处于“销售”角色的人应该能够做到这一点，那么您可以编写如下代码：

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

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

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

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

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

基于权限的访问控制是一种将各种权限分配给各种用户或各种角色或各种声明并检查用户是否有权在运行时从代码执行操作的方法。如果您将权限分配给角色或声明，那么您将检查该登录用户的角色或声明。然后，您将检查哪些权限可用于这些角色或声明。

您可以像这样定义一些权限集：

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

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

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

请注意，[Authorize(Permission=”CanCreateCustomer”)] 可能没有内置到 MVC
类库中，我只是在抽象意义上作为示例展示。可以有一个 NuGet 包，该包将在 Authorize 类中具有 Permission 属性。

现在，您可以看到，CreateCustomer 操作方法将始终需要“CanCreateCustomer”权限，并且它永远不会改变或几乎不会改变。

谁将获得权限？

您可以将一组权限直接分配给用户。但不要那样做。管理它将非常困难。相当，

您可以将一组权限分配给角色，或者您可以将一组权限分配给声明（推荐）。

正如我所提到的，角色也可以被认为是声明。因此，您可以将角色视为声明。然后，您可以在数据库中创建一个声明表。然后，创建另一个表来保存每个声明可以包含多个权限的关系。

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

每当有人登录时，您的应用程序将检查该用户可用的任何权限，并且该权限集将作为当前登录用户的附加属性提供，因此您不必一直从数据库中检查权限集.
底线是，如果您应用基于权限的访问控制，您可以更好地控制应用程序中的安全逻辑。

如果您的应用程序是一个非常小的应用程序，其中只有 2
个角色：客户和管理员，并且客户除了在您的应用程序中应该做的事情之外，没有机会做任何其他事情，那么也许，简单的角色基于权限的访问控制将达到目的，但是随着您的应用程序的增长，您将在某些时候开始感到需要基于权限的访问控制。