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

【问题标题】：Hierarchical role/permissions based access基于分层角色/权限的访问
【发布时间】：2015-11-20 21:25:12
【问题描述】：

我想构建分层角色库访问控制。这是我当前的架构：

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

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

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

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

这是矫枉过正吗？

【问题讨论】：

不要把它变成层次结构。麻烦多于其价值。相反，只需创建 N 个不同的“角色”（每个角色都将其包含的权限表示为单独的属性）并为每个用户分配一个角色（或更多角色）。在多个角色的情况下，只需将权限扁平化为固定阶段即可。
我不明白为什么继承会很麻烦。似乎节省了大量的编码和实体访问。
因为它 1) 复杂得多 2) 在这种情况下增加的价值很少（如果有的话）。但无论如何，做你想做的事。
在 OOP 方法中，user 类扩展了它的配置文件子项。并发症在哪里？
一点也不。你可以;但没有必要。我的意思是，即使使用#1（这是非分层基础），用户也没有理由只有一个角色 - 如果这个帐户可以使系统保持相当灵活且仍然简单。然而，权限聚合处理的是角色，而不是层次结构。

【解决方案1】：

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

我曾使用过类似的系统并取得了巨大的成功。虽然起初这种方法可能看起来“结构较少”，但它相对简单且非常灵活；何时允许每个用户拥有多个角色并定义聚合权限的规则。

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

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

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

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

角色，没有“父类型”依赖，功能更像“OO 接口” - 好吧，如果要扩展类比，也许Trait composition 会更合适。每个角色的实现（阅读：授予的权限）可以独立改变任何其他角色，使其非常灵活。和接口一样，可以将多个角色分配给给定的用户/实体。

在 SQL 中针对平面 User <M-M> Role <M-M> Permission 模型的查询要简单得多（有或没有递归支持，或额外的结构），因为没有需要遍历的角色层次结构。

Windows ACL Groups（让我们忽略嵌套组）的工作方式与角色很相似；用户属于一个或多个授予（或拒绝，但情况不同）权限的组。

我推荐并在上面暗示过的变体是允许跨角色聚合权限。一个简单的聚合模型是这样的：

因此，每个角色的权限绑定很少或没有重叠，如“方法 #2”所示，但有以下区别：没有层次结构。

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

使用非分层多角色功能的系统可以清晰地实现这一点，摆脱层次结构的负担，同时仍然提供灵活/可组合/可配置的角色原型。

¹ 这不是一个特别好的例子。实际上，角色应该有不同的名称（例如“帐户支持”或“内容版主”）并涵盖不同的权限集；这些可能会根据反复试验和当月的业务规则随时间而变化。

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

【讨论】：

感谢您的洞察力。不去追求层次结构真的很有意义。 “很少或没有重叠”与“联合”相结合真的很适合我目前的项目。在您的“特殊管理员”示例中，在分配了“基本用户”和“有限管理员”两个角色之后，特殊管理员将不具有付费用户的权限。这完全有道理。是的，在某些情况下，分层角色会起作用，但这意味着权限和角色不会（可能会有一点）随着时间的推移而改变。这不是我的情况。可以有很多变化。