作者：麻雀
链接： www.cnblogs.com/zwq194
公众号注：更多结构文章点击文末阅读原文直达
基于角色的访问控制(RBAC )是用户通过角色与权限相关联。
简而言之，一个用户有几个角色，每个角色都有几个权限。 这将建立“用户-角色-权限”许可模式。 在该模型中，用户与角色之间、角色与权限之间，一般人存在多对多的关系。 (下图)
作用是什么？ 可以理解为一定数量的权限集合、权限的载体。 例如，在一个论坛系统中，“超级管理员”和“版主”都是角色。 版主可以管理版本中的帖子、版本中的用户等。 这些是权限。 要将这些权限授予用户，不需要直接授予用户权限，而是授予用户“版主”角色。
在用户非常多的情况下，为系统中的每个用户授予一个权限(授予角色)是一件非常麻烦的事情。 在这种情况下，必须将用户分组，每个用户组有多个用户。 除了授予用户许可外，还可以授予用户组许可。
也就是说，用户拥有的所有权限都是用户个人拥有的权限与该用户所在的用户组拥有的权限之和。 (下图为用户组、用户、角色三者的关联关系)
在APP应用系统中，权限代表什么？ 功能模块的操作、上传文件的删除、菜单的访问，甚至页面上的某个按钮、某个图像的可见性控制也属于权限范围。
在某些权限设计中，功能操作是一个类，文件、菜单、页面元素等是另一个类，从而配置“用户-角色-权限-资源”许可模式。 在对数据表建模时，可以统一管理功能操作和资源，即直接与权限表相关联，这可能会提高便利性和可扩展性。 (参照下图)
请注意“权限”表中有“权限类型”列。 “MENU”区分菜单的访问权限，“OPERATION”区分功能模块的操作权限，“FILE”区分文件的修改权限，“ELEMENT”区分页面元素的可见性控制等权限。
这样设计的好处有两个。
其一，不需要区分哪个是权限操作，哪个是资源。 (实际上，有时很难区分它是理解为资源，还是理解为功能模块权限，就像菜单一样。 请参阅。
其二，扩展简单，系统对新的进行权限控制时，只需创建新的关系表“权限XX关系表”，并确定此类权限的权限类型字符串。
必须注意的是，权限表和权限菜单关联表、权限菜单关联表和菜单表都是一对一的关系。 (文件、页面权限点、功能操作等也相同)。 也就是说，每次添加菜单时，都必须同时在这三个表中插入一个记录。
这样，就可以不需要权限菜单关系表，直接将权限表与菜单表关联起来。 在这种情况下，必须在权限表中添加用于保存菜单的ID。 权限表根据权限类型和此ID来区分记录类型。
至此，RBAC权限模型扩展模型的完整设计图如下。
随着系统的增长，为了便于管理，可以部署角色组对角色进行分类管理。 与用户组不同，角色组不参与审批。
例如，在一个电网系统的权限管理模块中，角色挂在区局下面，但区局在这里充当角色组，不参与权限分配。 另外，为了便于管理和检索上述各主表自身，可以采用菜单树、功能树等树结构。 当然，它们不需要参与权限分配。
以上从基本的RBAC模型进行了扩展，但具体设计需要根据项目业务的需要进行调整。 欢迎大家的批评意见！
读正文有收获吗？ 请转发给更多的人进行共享