首页 文章

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

提问于
浏览 次
7

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

每个用户都属于一个或 more 组 . 组被组织成树（如目录结构） . 可以为组和用户分配权限（或角色，如果我们正在谈论RBAC）并且应该存在某种类型的继承（即用户和组继承其所属组的权限）和覆盖功能 . 组本身的目的不是 only 权限管理 - 它们将在应用程序中具有其他用途 .

我想，如果使用权限_1190854_ roles（"roles"是RBAC术语中的权限集合），进一步设计和实现上述所有内容都不会太成问题，因为权限非常精细，而角色更加单一 . 在组/用户级别实现权限继承/覆盖不会太困难 . 对角色执行相同操作可能会更棘手，但另一方面，普通用户更容易理解角色 .

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

  • 该应用程序可能不会超过30个不同的权限;

  • 组本身可用于设置权限，这些权限已经提供了角色的一个优点 - 易于对多个用户进行权限管理

  • 这个概念似乎很清楚，因而很容易实现

但是，如果我看到一个逻辑且易于理解的基于角色的模型，该模型比“仅权限”模型具有优势，我会认真地看一下它 . 是否有任何明确定义的RBAC模型（论文，实现等）可以应用/适应上述要求（我已经搜索了一段时间了，但我发现那些限制太多或者没有将层级用户管理纳入会计？你对此事的总体看法是什么？ RBAC在这种情况下是否值得？

access-control rbac

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是否有任何规则 . 如果在允许或拒绝之前，层次结构中没有任何内容 . 如果用户可以拥有多个角色（例如，成员的角色并且位于组管理员（也称为管理员组）中），则必须选择拒绝否决允许，反之亦然 . 当级别并行时，我更喜欢允许获胜（例如，角色A允许操作但是角色B拒绝，我们的用户同时具有角色A和B，角色A和B不相关，不在层次结构中） .

    Re：您的示例层次结构 . 在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中实际完成了这个，因为我正在创建自己的系统 .

    回复于
  • 1

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

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

    帕特里克帕克

    回复于

相关问题