RBAC模型
一 什么是RBAC模型
RBAC：基于角色的权限模型。通过角色关联用户，角色关联权限的方式间接赋予用户权限
二 RBAC分类
2.1 RBAC0：最简单的用户、角色、权限模型
- 用户与角色多对一：一个用户只能有一种角色，一个角色有多个用户
- 用户与角色多对多：一个用户可以有多个角色，一个角色可以有多个用户
当系统功能单一，使用人员较少，岗位权限清晰且确保不会出现兼岗时，可以使用多对一，其他情况尽量使用多对多。
2.2 RBAC1：增加子角色，子角色可以继承父角色的所有权限
2.3 RBAC2：增加了一些角色互斥、基数约束、先觉条件角色
- 角色互斥：同一个用户不能被分配到互斥角色集合中的多个角色。
- 基数约束：一个角色被分配的用户数量有限制，不能过设置的角色的数量
- 先觉条件角色：要获得比较高的权限，必须要现有低一级的权限
- 运行时互斥：允许一个用户有多个角色，但在运行时不可以同时激活多个角色
2.4RBAC3:统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内，综合了RBAC0、RBAC1和RBAC2的所有特点
三 什么是权限
权限是资源的集合，是软件中的所有内容，包括模块，菜单，页面、字段，操作功能等
四 用户组
当平台用户基数增大，角色类型增多时，如果直接给用户配角色，管理员的工作量就会很大。这时候我们可以引入一个概念“用户组”，就是将相同属性的用户归类到一起。
例如：加入用户组的概念后，可以将部门看做一个用户组，再给这个部门直接赋予角色（1万员工部门可能就几十个），使部门拥有部门权限，这样这个部门的所有用户都有了部门权限，而不需要为每一个用户再单独指定角色，极大的减少了分配权限的工作量。
同时，也可以为特定的用户指定角色，这样用户除了拥有所属用户组的所有权限外，还拥有自身特定的权限。
用户组的优点，除了减少工作量，还有更便于理解、增加多级管理关系等。如：我们在进行组织机构配置的时候，除了加入部门，还可以加入科室、岗位等层级，来为用户组内部成员的权限进行等级上的区分。
ABAC模型
一 什么是ABAC模型
基于属性的访问控制是一种灵活的授权模型。是通过实体的属性、操作类型、相关的环境来控制是否有对操作对象的权限。
二 ABAC的使用场景
ABAC授权模型理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。简单的场景也是可以使用ABAC的，但是使用基础的ACL或者RBAC也能满足需求。
场景一：
还是拿上面的例子来说：P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。在需要根据环境属性和操作属性来动态计算权限的时候，使用其他的授权模型可能不太能满足需求。这个时候就需要使用ABAC授权模型。
场景二：
ABAC也适用于公司成员（角色）快速变化的场景，由于ABAC 是通过用户的属性来授权的。在新建用户/修改用户属性时会自动更改用户的权限，无需管理员手动更改账户角色。在属性的组合比较多，需要更细粒度地划分角色的情况下，RBAC需要建立大量的角色，ABAC授权模型会更加灵活。
ABAC对比RBAC
ABAC的优势：
- 对于大型组织，基于RBAC的控制模型需要维护大量的角色和授权关系，相比而言，ABAC更加灵活；
- 新增资源时，ABAC仅需要维护较少的资源，而RBAC需要维护所有相关的角色，ABAC可扩展性更强、更方便。
- ABAC支持带有动态参数的授权规则，RBAC只能基于静态的参数进行判断。
- ABAC权限控制的粒度比RBAC更细。
RBAC的优势：
- 对于中小型组织，维护角色和授权关系的工作量不大，反而定制各种策略相对麻烦，更容易接受RBAC授权模型。
