一种基于角色的访问控制数据库模式
我目前正在为这里的一个本地协会开发成员管理，目前我正在开发数据库模式。我想与你分享它来改进它，并给其他人一个基于角色的访问模型(RBAC)的例子。我非常感谢任何建设性的批评，特别是关于我使用的表之间的关系。
链接至最高链接：http://i.stack.imgur.com/WG3Vz.png
模式如下：
它的工作原理：
我将现有客户端(实际上是协会的成员)从外部应用程序映射到我的管理应用程序中。(客户端表)
该协会的结构分为部门、子部门等(intern_structures表)。每个客户都可以是多个部门、子部门、部门等的成员。
每个客户在这样的成员资格中可以有一个或多个角色(部门，...)例如总裁、精算师、财务主管等，每个角色都有某些特权，角色所有者可以将这些特权应用于他的部门、细分、部门等其他人员。
凭证连接到应用程序的某个操作。凭证的所有者可以在其作用域中的其他成员上执行此操作。可以有多个“独立”应用程序，但它们都共享相同的身份验证/授权系统。
一个应用程序是在模块/子模块/动作等中构建的。一个例子可以是“个人详细信息”模块，这个模块包含一个叫做“图片”的子模块，你可以在这个图片上应用“查看、删除、编辑”动作。但您不能删除任何图片，除非您尝试删除其图片的人所在的部门/部门中，您有足够的角色来执行此操作。
内部和应用程序结构都是树，实现为邻接表和嵌套集。邻接表确保了完整性，嵌套的集合让我可以快速遍历树。
例外情况是，您可以直接向某人提供某些凭据(client_credentials)。如果有人需要对不在他的部门/部门中的人执行某些操作，则需要使用此功能。
因此，某人可以成为多个部门/部门的成员，并在他所属的每个部门/部门中获得多个角色。我将合并某人通过多个角色拥有的所有凭据。并且凭据始终是正的，这意味着不可能有限制性凭据。
回答 2
Stack Overflow用户
发布于 2011-03-29 15:21:00
我将给出另一个我非常喜欢的RBAC系统的例子。请查看由Tony Marston here编写的radicore框架。
我不确定它是否满足您的所有要求，但您可以将您的工作与之进行比较的东西可能会有所帮助。
Stack Overflow用户
发布于 2014-02-09 14:19:45
我似乎没有看到太多的RBAC映射，例如：
Operation = Any action, such as CRUD operations
Object = Reference to any object instance
Permission = Mapping of 'Operation' + 'Object'我不确定你所有的“凭证”表是什么？凭证通常包含用于证明身份的属性(即:用户名/密码)。为什么您有角色的凭据？
https://stackoverflow.com/questions/3686516
复制相似问题