access-control - 访问控制 - 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，您将看到一个基于角色的实现。也许这会激励你。

编辑:关于层次结构:为角色(对象或扩展名)实现层次结构并不困难。检查请求的对象- Action -对象是否有任何规则。如果没有在层次结构中上升，直到您有一个允许或拒绝。如果用户可以拥有多个角色(例如，成员角色并且在组管理员中(也称为 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 中完成了一段时间。