概念
RBAC(Role Based Access Control)：基于角色的访问控制，这应该是当今IT系统使用的最多的权限管控模型
描述
角色即为 操作（API） 的聚合 ，RBAC通过给用户绑定某个角色，使用户具备了某些操作的能力，这是最简单的RBAC模型，学术上也称为RBAC0，与之对应的还有RBAC1、RBAC2、RBAC3，RBAC1是引入了角色继承的关系。
角色继承(Hierarchical Role)
角色继承很容易理解，即角色B继承了角色A，那么当用户绑定了角色B的时候，也就具备了角色A的操作能力；RBAC2是引入了角色互斥的关系，比如如果用户绑定了角色A就不能绑定角色B，这是因为考虑到现实世界中如果是运动员就不能是裁判这样的业务场景；RBAC3则是结合了RBAC1和RBAC2的能力，同时拥有角色互斥和角色继承的功能。
职责分离(Separation of Duty)
为了避免用户拥有过多权限而产生利益冲突，例如一个篮球运动员同时拥有裁判的权限（看一眼就给你判犯规狠不狠？），另一种职责分离扩展版的RBAC被提出。
职责分离有两种模式：静态职责分离(Static Separation of Duty)：用户无法同时被赋予有冲突的角色。<br>动态职责分离(Dynamic Separation of Duty)：用户在一次会话（Session）中不能同时激活自身所拥有的、互相有冲突的角色，只能选择其一。
扩展<br>
在有的权限系统的中，为了方便用户的使用，还衍生出了权限组或者是用户组的实体模型，权限组是一类API的聚合，比如用户操作权限组就可以包含对用户数据的增删查改操作，使用权限组的时候，角色不是和api去绑定，而是去和权限组绑定；用户组是将某一类用户分组，这个分组和角色去绑定，而不是用户和角色绑定，这样只要用户加入了这个组，就具备了某些操作权限，现实世界中这个组也有可能是公司部门等实体。
总结
我们可以看出来，在RBAC中，不管实体怎么变，角色（Role） 的本质其实就是一系列API操作的聚合，通过用户与角色的直接或者间接绑定，使用户具备了某些操作的能力，这也是RBAC的本质。
