基于分层角色/权限的访问

Question

我想构建一个Hierarchical Role Base访问控制。 这是我目前的架构：

目前我有两个选项来构建这个系统：

1. 将所有必需的权限附加到角色（非分层）

2. 仅附加特殊的“级别”权限并继承具有较低级别的权限

是否有更好的方法或仅仅取决于我的项目需求？

我只是因为简单而倾向于选择Hierarchical。 如果我这样做，有没有更好的方法来选择权限级别，也许使用二进制数字？

选项2会有一些角色级别，我会有一些级别的权限。 因此，当我创建Full Administrator ，角色将继承所有其他权限，因为这将是级别4，而其他权限将具有小于级别4（或4000）的数字。

这有点矫枉过正吗？

Answer 1

我建议使用“方法＃1”的变体 - 非分层角色。

我已经使用类似的系统取得了巨大的成功。 虽然起初这种方法可能看起来“结构化程度较低”，但它相对简单并且非常灵活; 允许多个角色的每用户时 ，并且限定用于聚合的权限规则。

反对层次结构（用于角色）

与“OO层次结构”一样，使用角色层次结构会导致严格的替换关系。 这使得根据不断变化的需求定义角色变得更加困难。

例如，未来可能需要一个“管理员”帐户，该帐户无法创建自己的帖子。 层次结构（以及它具有的替换关系）在不改变树结构本身的情况下阻止了这种情况，因为“完全管理员”是“付费用户”。

针对真实层次结构的查询在SQL中更复杂; 特别是在不支持递归查询的实现中，比如MySQL。 使用嵌套集或物化方法切换到层次结构会强制仅在父子关系上使用其他结构。

你只是不需要它; 更复杂的软件更难以编写和维护。 虽然在某些情况下层次结构非常好 - 例如使用物料清单或族谱或目录结构 - 但在大多数角色/组权限模型中根本没有“需要”。

对于（多）角色

没有'父类型'依赖的角色更像'OO接口' - 好吧，如果类比要被拉伸， 特征组合可能更容易。 每个角色的实现（读取：授予权限）可以独立于任何其他角色进行更改，使其非常灵活。 和接口一样，可以为给定的用户/实体分配多个角色。

针对平面User <MM> Role <MM> Permission模型的查询在SQL中更简单（有或没有递归支持或其他结构），因为根本没有要遍历的角色层次结构。

Windows ACL组 （让我们忽略嵌套组）的工作方式与Roles非常相似; 用户属于一个或多个授予（或拒绝，但这是一个不同的情况）权限的组。

有你的蛋糕，也吃它

我建议并且已经暗示过的变 体是允许跨角色聚合权限 。 一个简单的聚合模型是这样的：

• 用户具有来自所分配的所有角色的权限的并集。

  （有效权限通常在授权期间构建，但是没有层次结构，在SQL中查询也相对简单。）

因此，权限按每个角色绑定，很少或没有重叠，如“方法＃2”中所示，具有这种差异： 没有层次结构 。

例如，要允许可以搜索帖子（并删除“错误”帖子）的特殊管理员，可以只分配“基本用户” 和 “受限管理员”角色¹ 。

使用非分层的多角色功能系统可以干净利落地摆脱层次结构的负担，同时仍然提供灵活/可组合/可配置的角色原型。

---

¹这不是一个特别好的例子。 实际上，角色应该有不同的名称（例如“帐户支持”或“内容主持人”），并涵盖不同的权限集; 这些可能会随着时间的推移而变化，这取决于反复试验和错误的业务规则。

虽然我已经反对这种层次结构，但在更复杂的系统中，可能需要允许角色之间的关系，主要是为了对这种关系进行分组。 此关系通常应独立于所应用的有效权限，存在用于其他管理目的。