1 一个用户只属于一个用户组
2 一个角色包含多个权限，
3 一个用户本身（非继承）可以拥有多个角色和多个权限
4 一个用户组可以有多个角色、多个权限
5 一个权限也可以属于多个角色。
6 用户的角色和权限由两部分组成。 一部分继承自所有父用户组的角色和权限，另一部分来自专门分配给它的角色和权限。
7 用户组可以排除角色rbac角色权限表设计，一旦该角色被包含在其子用户组或用户上，该用户或用户组将重新获得该角色。
8 用户或用户组可以拒绝（不允许）某个权限。 一旦被拒绝技能特效，无论哪里允许（允许），都无济于事。
9 管理员可以做任何事情，没有任何限制
10 用户组是用户的集合，角色是权限的集合。
=================================================== =========================================
基于RBAC（Role-based Access Control）的权限访问控制。 也就是说，一个用户可以有多个角色，一个角色可以有多个权限。 通过分离角色和权限，提高了设计的可扩展性。 通常，一个用户有多个角色，一个角色也属于多个用户。 （多对多），一个角色拥有多个权限，一个权限也属于多个角色（多对多）。
2.最简单的版本
假设：我们得到一个用户对象，
可以通过：用户id –> 角色id –> 角色名（什么角色） –> 权限id –> 权限标识 –> 来获取权限。 最终获得获取角色信息的权限。
角色：可以简单理解为很多权限的集合。 例如二级管理员和三级管理员。
3.用户组模式
如果用户数量比较多，可以加入用户组模式。 需要对用户进行分组。 每个用户组中有多个用户。 除了对用户进行授权外，还可以对用户组进行授权。 最终用户拥有的所有权限=单个用户拥有的权限+用户所属用户组拥有的权限。 （这个设计和svn中的用户权限类似3D道具，比如将一个svn用户添加到一个组，然后设置该组的权限，如果以后添加更多的用户，就不需要一一设置用户权限了）一。）
4.权限分类
大部分是针对功能模块的，如信息记录的增删改查（信息状态的修改、文件的删除和修改等）、菜单的访问、输入框、按钮的可见性、是否新建下级等有些权限设计会将功能操作视为一类，将文件、菜单、页面元素等视为另一类，从而形成“用户-角色-权限-资源”的授权模型。 在做数据表建模时，可以对功能操作和资源进行统一管理，即直接与权限表关联起来，这样可能会更加方便，并且具有可扩展性。
5.完整版
请注意，权限表中有“权限类型”一栏。 我们根据其值来区分它是哪种类型的权限。 例如“MENU”表示菜单的访问权限，“OPERATION”表示功能模块的操作权限，“FILE”表示文件修改权限，“ELEMENT”表示页面元素的可见性控制等。
优点：（1）不需要区分哪些是权限操作，哪些是资源（其实有时候很难区分，比如菜单，我们应该理解为资源还是功能模块权限？）。
(2)方便扩展。 当系统想要控制新事物的权限时，我只需要新建一个关联表“权限XX关联表”rbac角色权限表设计，并确定该权限的权限类型字符串即可。
这里需要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表之间是一一对应的关系。 （同样适用于文件、页面权限、功能操作等）。 也就是说，每次添加菜单时，都必须同时向这三个表中各插入一条记录。 这样就不需要权限菜单关联表，直接将权限表与菜单表关联起来。 这时候就必须在权限表中添加一个新列来保存菜单的ID。 权限表是通过“权限类型”和这个ID来区分的。 该类型下有哪些记录。
文章来源:https://blog.csdn.net/u010730870/article/details/91490705
