ASP中基于角色的访问控制（RBAC）与基于声明的访问控制（CBAC）。网络MVC

Question

使用CBAC和RBAC的主要好处是什么？什么时候使用CBAC更好，什么时候使用RBAC更好？

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

Answer 1

我不完全同意埃姆兰的回答

[Authorize(Roles="Sale")]

他太天真了

问题是怎么做

  [Authorize(Roles="CustomerCreator")]

是不同于

 [ClaimAuthorize(Permission="CanCreateCustomer")]

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

我想是因为

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

索赔的其他例子。

>

“Gold”是由“MYGYMApp”提供的“MYGYM.Membershiptype”类型的索赔

Answer 2

我现在已经实现了很多次安全模型，并且也不得不对这些概念绞尽脑汁。经过多次实践，以下是我对这些概念的理解。

什么是角色

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

一方面，角色是权限的集合。我喜欢称之为权限配置文件。当定义一个角色时，基本上是向该角色添加一组权限，因此从这个意义上说，角色就是一个权限配置文件。

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

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

什么是团体

组=用户集合

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

什么是许可

权限=主体可以做什么

什么是权限集

权限集=权限集合

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

用户、组、角色和权限的组合方式

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

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

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

什么是索赔

索赔=主体“是什么”

声明不是权限。正如前面的回答所指出的，主张是主体“所能做的”，而不是主体“所能做的”。

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

何时使用索赔

我发现当用户不能被添加到角色中或者该决定不是基于用户与权限的关联时，需要做出授权决定时，声明是有用的。Facebook用户的例子导致了这一点。脸书用户可能不是被添加到“角色”中的人...他们只是一些通过脸书认证的访问者。尽管它并不完全适合RBAC，但它是一个需要做出授权决定的信息。

@CodingSoft在前面的回答中使用了夜总会的比喻，我想对此进行扩展。在该回答中，驾驶执照被用作一个示例，其中包含一组声明，其中出生日期代表其中一项声明，而出生日期声明的值用于根据授权规则进行测试。签发驾驶执照的政府是提供索赔真实性的机构。因此，在夜总会场景中，门口的保镖会查看此人的驾照，通过检查其是否为假身份证（即必须是有效的政府颁发的身份证）确保其由可信机构颁发，然后查看出生日期（驾照上的众多主张之一），然后使用该值确定此人是否足够大，可以进入俱乐部。如果是这样，则该人通过授权规则的依据是拥有有效的声明，而不是担任某个角色。

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

尽管如上所述，访客进入公共夜总会区域是通过一项单独的索赔授权的，但员工需要按角色进入其他非公共受限房间。对他们来说，驾驶执照是不够的。他们需要的是一个员工徽章，他们可以扫描进入大门。某个地方有一个RBAC系统，它授予经理角色中的徽章进入顶层的权限，以及员工角色中的徽章进入其他房间的权限。

如果出于任何原因，某些房间需要按角色添加/删除，则可以使用RBAC进行添加/删除，但这不适合索赔。

软件中的权限

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

最后一个音符。

同意与拒绝

稳健的RBAC系统甚至CBAC系统都应区分授权和拒绝。

向角色添加权限应附带授予或拒绝。当权限被选中时，所有GRANTed权限都应该被添加到有效权限的用户列表中。然后，在所有这些操作完成后，拒绝权限列表应导致系统从有效权限列表中删除这些权限。

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

事实上，这将是一个很好的索赔候选人。如果用户具有声明“性别=男性”，则担任经理角色可以访问所有房间，但女卫生间也要求声明性别=女性，男卫生间要求声明性别=男性。这样，就不必为男性用户配置拒绝权限，因为声明强制使用单个授权规则为每个人都提供了这样的权限。然而，这两种方法都可以做到。

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

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

我希望这有帮助。

这是上述RBAC的示意图

根据@Brent（谢谢）的反馈于2019年4月7日更新。。。删除了对以前答案的不必要引用，并解释了@CodingSoft提供的“夜总会”隐喻的原始基础，以便在不必阅读其他答案的情况下理解此答案。

Answer 3

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

什么是角色？

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

索赔是什么？

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

基于角色的访问控制

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

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

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

基于声明的访问控制

用外行的话说，在基于声明的访问控制中，在确定对页面的访问权限时，检查声明而不是角色。

（这是一个伪代码。声明授权不是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

好的，现在，如果你问基于角色的权限改造或基于声明的权限改造有什么好处，那么，想想这个页面“ViewImagesOf暴力”。在决定是否允许用户访问该页面时，检查索赔“18岁以上的成年人”不是更直观吗？简而言之，使用声明，您可以在用户中比较角色创建更多的细分市场。在抽象的意义上，所有的角色都可以是权利主张，但是权利主张不能被认为是角色。

基于权限的访问控制

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

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

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

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

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

现在，你意识到一些营销人员一定不能创造客户，但是不可能为那些营销人员分配不同的角色。所以，你被迫允许所有营销人员创建客户。

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

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

您可以定义一些权限集，如下所示：

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

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

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

请注意，[Authorize（权限="CanCreateClient"）]可能不会内置到MVC类库中，我只是作为一个抽象意义上的例子来展示。可以有一个Nuget包，它将具有授权类中的权限属性。

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

谁将获得权限？

可以将一组权限直接分配给用户。但不要那样做。要做到这一点将极其困难。相反，

您可以为角色分配一组权限，也可以为声明分配一组权限（推荐）。

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

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

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

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