访问控制- RBAC是否值得在分级用户管理系统中实现？

Question

最近，我一直在考虑在我的应用程序中使用最好的访问控制模型。我一直在阅读RBAC，角色概念很不错(特别是如果您拥有大量不同的权限)，但是，我不确定它是否适用于分层用户管理，如下所示：

每个用户都属于一个或多个组。组被组织成一棵树(就像目录结构)。可以为组和用户分配权限(或者角色，如果我们正在讨论RBAC)，并且可能存在某种继承(即用户和组继承其所属组的权限)和重写功能。组本身的目的并不仅仅是权限管理--它们在应用程序中还有其他用途。

如果没有角色使用权限(在RBAC术语中，“角色”是权限的集合)，那么以上所有这些都不会对进一步的设计和实现造成太大的问题，因为权限是非常细粒度的，而角色则更单一。在组/用户级别实现权限继承/重写并不太困难。对角色做同样的操作可能会更棘手，但另一方面，对于普通用户来说，角色更容易理解。

现在，我本人更倾向于“权限仅限”模式，因为：

• 这个应用程序可能不会有超过30个不同的权限；
• 组本身可以用来设置权限，这已经提供了角色的优点之一？？多个用户的权限管理容易。
• 这一概念似乎很清楚，因此易于实施。

然而，如果我得到了一个逻辑的、易于理解的基于角色的模型，它比“权限仅限”模型更有优势，我会认真地看一看。是否有明确定义的RBAC模型(论文、实现等)？已经可以应用/调整到上面的需求了(我已经搜索了很长一段时间了，但是我发现这些需求要么限制太强，要么没有考虑到分级用户管理)？你对这件事的总体看法是什么？在这种情况下，RBAC值得吗？

Answer 1

我认为基本的RBAC系统就像使用权限系统一样简单。

请注意，RBAC中的“角色”一词可能会限制实现。我的意思是，传统的RBAC系统通常有这样的规则：

allow (a) role (to do an) action (on an) object

在伪代码中，可能有这样的方法：

myRbac.allow(Member, View, Post)

但是，没有什么可以阻止您抽象角色。角色通常是字符串名。使用该字符串名称，还可以命名组和用户。然后，如果你创造性地使用“‘Role”，那么它允许的不仅仅是角色。将其称为基于对象或其他东西，但本质上是一样的:允许某物对某物进行操作。

allow (an) object (to do an) action (on an) object

如果您从这个角度来看，IMHO，您的实现将非常简单，足以证明实现的成本是合理的。不要让“角色”这个术语限制了实现的简单性。如果你能这么简单地实现它，为什么不去做呢？

你似乎知道PHP。如果您查看Zend，您将看到一个基于角色的实现。也许这会激励你。

编辑:关于层次结构:不难实现角色的层次结构(对象或扩展名称)。检查请求的对象-动作对象是否有任何规则。如果没有，则在允许或拒绝之前，在层次结构中向上移动。如果用户可以有多个角色(例如成员的角色，并且在组管理员(也称为AdministratorGroup)中)，则必须选择拒绝是否超过了允许，反之亦然。当级别是平行的时，我更喜欢允许获胜(例如，角色A允许动作，但是角色B被拒绝，我们的用户同时拥有角色A和B，角色A和角色B不相关，而不是在层次结构中)。

您的示例层次结构。在Zend框架ACL中，这可能是这样的：

$acl->addRole(new Zend_Acl_Role('Role1'))
    ->addRole(new Zend_Acl_Role('Group1', array('Role1'))
    ->addRole(new Zend_Acl_Role('Group2', array('Group1));
$acl->allow('Role1', 'someAction', 'someObject'); // permission 1
$acl->allow('Role1', 'otherAction', 'otherObject'); // permission 2
$acl->deny('Group2', 'someAction', 'someObject');

老实说，自从我创建自己的系统以来，我已经有一段时间在Zend_Acl中这样做了。

Answer 2

使用组进行自定义应用程序权限的挑战是，组与它们要用于保护的资源之间缺乏任何关系。例如，如果我使用一个AD组在我的自定义应用程序中授予访问权限，我真的不知道该组还授予什么访问权限--如果我在组中添加一个用户，认为我正在授予我的应用程序读和批准权限，我可能无意中将它们添加到一个授予对共享文件夹、其他应用程序的访问权限的组中。如果编写自己的应用程序，我会建议您使用基于角色的系统(更好的角色作为索赔模型的一部分，在应用程序代码之外维护所有安全性)，其中角色和它可以用来授予访问权限的资源之间的关系有限--这样您就可以从所有维度中看到谁有权访问什么和为什么。从可见度的角度来看，群体代表了一个黑洞。

我们在我们的产品中实现了一个相当复杂的RBAC，它具有多种业务角色和技术角色，这些角色对它们所保护的每种资源都有限制--微软的http://blog.identitymanagement.com/downloads/有一个新的基于声明的编程框架，称为Windows --为您处理大部分管道。

帕特里克·帕克