访问控制 - 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)

然而，没有什么可以阻止您使用抽象角色。角色通常是一个字符串名称。使用该字符串名称，您还可以命名您的组和用户。如果您创造性地使用基于“角色”的角色，那么它所允许的功能远不止角色。将其称为基于对象或其他名称，但本质上是相同的：您允许某物对某物执行操作。

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

恕我直言，如果您从这个角度来看，您的实施将足够简单，足以证明实施成本是合理的。不要让“角色”术语限制实现的简单性。如果你能这么简单地实现它，为什么不去尝试呢？

看来你了解 PHP。如果您查看 Zend Framework ACL，您将看到一个基于角色的实现。也许这会对你有所启发。

编辑：关于层次结构：实现角色的层次结构（对象或扩展名）并不困难。检查请求的对象-动作-对象是否有任何规则。如果没有，则在层次结构中上升，直到您获得允许或拒绝为止。如果一个用户可以拥有多个角色（例如，成员角色并且属于管理员组（也称为 AdministratorGroup 角色）），则您必须选择是拒绝否决允许，还是反之亦然。我更喜欢在级别并行时允许获胜（例如，角色 A 允许某个操作，但角色 B 被拒绝，我们的用户同时具有角色 A 和 B，并且角色 A 和 B 不相关，不在层次结构中）。

回复：您的示例层次结构。在Zend Framework 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 中实际完成此操作了一段时间了。