8

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

每个用户都属于一个或多个组。组被组织成一棵树（如目录结构）。组和用户都可以被分配权限（或角色，如果我们在谈论 RBAC）并且可能应该有某种继承（即用户和组继承他们所属组的权限）和覆盖功能。群组本身的目的不仅仅是权限管理——它们在应用程序中还有其他用途。

我想如果在没有角色的情况下使用权限（“角色”是 RBAC 术语中的权限集合），上述所有内容对于进一步设计和实施都不会造成太大问题，因为权限非常精细，而角色更加单一。在组/用户级别实现权限继承/覆盖不会太困难。对角色做同样的事情可能会更棘手，但另一方面，角色对于普通用户来说更容易理解。

现在，我自己更倾向于“仅限权限”模型，因为：

  • 该应用程序可能不会拥有超过 30 种不同的权限；
  • 组本身可用于设置权限，这已经提供了角色的优点之一 - 易于对多个用户进行权限管理
  • 这个概念看起来很清晰，因此很容易实现

但是，如果向我展示了一个逻辑且易于理解的基于角色的模型，它比“仅权限”模型具有优势，我会认真考虑一下。是否有任何定义明确的 RBAC 模型（论文、实现等）已经可用，可以应用/适应上述要求（我已经搜索了一段时间，但我发现的那些要么限制性太强，要么没有'不考虑分级用户管理）？您对此事的总体看法是什么？在这种情况下，RBAC 值得吗？

4

2 回答 2

4

我认为基本的 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，您将看到一个基于角色的实现。也许这会激励你。

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

于 2009-12-29T15:46:07.750 回答
1

将组用于自定义应用程序权限的挑战在于组与它们用于保护的资源之间缺乏任何关系。例如，如果我使用 AD 组在我的自定义应用程序中授予访问权限，我真的不知道该组还可能授予访问权限 - 如果我将一个用户添加到组中，认为我正在授予读取和批准我的权限我可能会无意中将它们添加到授予访问共享文件夹、其他应用程序以及几乎任何东西的权限的组中。如果编写自己的应用程序，我会建议使用类似基于角色的系统（甚至更好的角色作为声明模型的一部分，所有安全性都在您的应用程序代码外部维护），其中角色与可能的资源之间存在受限关系用于授予访问权限 - 这样您就可以从所有维度查看谁有权访问什么以及为什么访问。从可见性的角度来看，组代表一个黑洞。

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

帕特里克·帕克

于 2009-12-30T02:27:54.363 回答