介绍
上一期指出了ACL的短板，然后介绍了解决了ACL短板的RBAC0模型。
本期将要介绍扩展了RBAC0 的模型：
RBAC1：引入子角色，增加角色继承的概念。最常用的模型。RBAC2：增加了角色限制，角色互斥、基数约束、先决条件角色。RBAC3：RBAC1 + RBAC2
RBAC1
举例
举个例子：一个公司里有老板、主管、员工等角色。
若采用RBAC0来设计，那么整体结构如下图所示：
由于具有公司的岗位具有上下级关系，且上级拥有下级的所有权限：
员工：员工的权限
主管：员工的权限、主管的权限
老板：员工的权限、主管的权限、老板的权限
我们会发现，不同的角色之间存在着重叠的权限。
存在的弊端是：每当增加一条员工的权限，都需要同时绑定给【员工】、【主管】和【老板】。倘若将【老板】漏了，那么就会出现【员工有权限，而老板没权限】的情况了。
为了避免这种情况的发生，RBAC1模型引入的角色继承就完美的解决了这个问题。
在RBAC1中，角色之间是有层级关系的，上级角色默认拥有下级角色的全部权限。
于是，这个例子的结构就变成了这个样子：
在RBAC1中，就不会出现下级角色拥有上级角色所没有的权限了。
由于生活中的各种角色也具有类型的层级关系，因此，RBAC1是最常用的权限模型。
模型
我们再来整体的看一下该模型的结构：
实现
三张数据表：用户表、角色表、权限表。
三张关系表：用户角色关系表、角色继承关系表、角色权限关系表。
六张平平无奇的表，里面藏着一个小细节。
角色权限关系表有两种方案：
- 仅记录与角色直接关联的权限。
- 记录与角色直接关联的权限，且记录从子角色继承而来的权限。
下面来说说两种记录方案的优缺点：
仅记录直接关联权限：
- 优点：生效快，角色继承关系一旦生效，那么鉴权就能通过。
- 缺点：鉴权时，需要先拿到用户的所有角色及其子角色(读扩散)，然后对比全部角色的全部权限点。在角色数量比较多的时候，会影响鉴权接口的响应时间。
- 优势场景：角色继承关系频繁变动的场景。
记录全部权限：
- 优点：鉴权较快，不存在读扩散的问题。
- 缺点：每次角色继承关系变动的时候，都需要对上层角色进行大量的权限绑定与解绑操作(写扩散)。
- 优势场景：角色继承关系变化很少的场景。
那么有没有两全其美的方法呢？当然是有的，那就是把两种方式结合起来，两种方式都用。
使用两张角色权限关系表，一张仅记录直接关联的权限，一张记录全部权限。
鉴权时：优先查询全部权限关系表，若鉴权失败，则自动降级查询继承关系的鉴权模式。
RBAC2
- 互斥角色：同一个用户在两个互斥角色中只能选择一个。
- 基数约束：一个用户拥有的角色是有限的，一个角色拥有的权限也是有限的。
- 先决条件约束：用户想要获得上层角色，首先必须拥有下层角色。
- 运行时互斥 ：允许一个用户具有两个角色，一次鉴权只能使用一个角色。
目前还没有碰到使用场景，不做展开讲解，了解概念即可。
RBAC3
RBAC1 + RBAC2，既有角色继承，也有各种限制条件。
下期预告
到目前为止，简单的介绍了两种常见的权限模型：ACL和RBAC。下一期将要讲解在实际业务情况中，这些模型存在的问题，以及在落地时，需要进行怎样的变化。敬请期待！
