0 RBAC 和 ABAC
-
RBAC：Role-Based Access Control 基于角色的访问控制
-
ABAC：Attribute-Based Access Control 基于属性的访问控制
-
美国国家标准与技术研究院为RBAC分了4级，为RBAC0-3
1 RBCA基础概念
-
RBAC：Role-Based Access Control，基于角色的访问控制。
-
通过引入 角色 这一概念，将用户和权限解耦，来满足权限的批量管理。
-
实现最简单的RBAC系统(也就是RBAC0)一共需要五张表：三张信息表和两张关系表。
- 三张信息表：用户信息表、角色信息表和权限信息表
- 两张关系表：用户-角色关系表、角色-权限关系表
-
模型操作
- 授权：通过给用户分配不同的角色，来改变其拥有的权限。
- 例子：管理员应用增删改查四种权限，访问者只有查的权限，对于新增用户老李，直接授予去管理者或者访问者角色，获得对应的权限
- RBAC中只需在用户-角色关系表中增加一个数据即可
- 鉴权：验证某个是否拥有某个权限
- 过程：
-
- 传入用户和权限信息
-
- 根据用户-角色表获得该用户的所有角色
-
- 根据角色-权限表获得该用户拥有的所有权限
-
- 对比权限数据
-
- 过程：
- 权限变更：收回或者增加权限
- 操作：收回权限只需在角色-权限表中删除对应的一条数据即可，增加同理
- 授权：通过给用户分配不同的角色，来改变其拥有的权限。
-
RBAC0的缺点
-
- 在复杂的业务场景中，同一个角色在不同的情况下拥有不同的权限。
-
- 对于管理员或者超级管理员这类上层角色，拥有很多权限，每当出现一个权限，都要将权限绑定给他们，当这类管理角色增多时，RBAC0的模型成本会上升，这一问题在RBAC1中得到解决
-
- 角色爆炸时，RBAC模型难以维护，这是可以转为ABAC模型
-
2 RBAC进阶
2.1 RBAC1
- 动机举例：
- 一个企业有老板，主管，员工等角色，则整体结构如下
- 该结构中上级有下级的所有权限，不同的角色间有着重叠的权限，此时如果新增一条员工的权限，需要同时绑定给主管和老板，否则会出现员工有权限，老板没权限的情况
- 为此，RBAC1中引入了角色继承，在RBAC1中，角色之间有层级关系，上级角色默认拥有下级角色的全部权限，于是新的结构如下
- 此时就不会出现下级角色拥有上级角色所没有的权限了，由于生活中的各种角色也具有类型的层级关系，因此，RBAC1是最常用的权限模型。
- 一个企业有老板，主管，员工等角色，则整体结构如下
- 模型结构：
- 实现
- 三张数据表：用户表、角色表、权限表。
- 三张关系表：用户-角色关系表、角色-继承关系表、角色-权限关系表。
- 实现中的一个细节：角色-权限关系表有两种方案
-
- 仅记录与角色直接关联的权限。
- 优点：生效快，角色继承关系一旦生效，那么鉴权就能通过
- 缺点：鉴权时，需要先拿到用户的所有角色及其子角色(读扩散)，然后对比全部角色的全部权限点。在角色数量比较多的时候，会影响鉴权接口的响应时间。
- 优势场景：角色继承关系频繁变动的场景。
-
- 记录与角色直接关联的权限，且记录从子角色继承而来的权限。
- 优点：鉴权较快，不存在读扩散的问题。
- 缺点：每次角色继承关系变动的时候，都需要对上层角色进行大量的权限绑定与解绑操作(写扩散)。
- 优势场景：角色继承关系变化很少的场景。
-
- 两全其美的方法：我全都要
- 使用两张角色权限关系表，一张仅记录直接关联的权限，一张记录全部权限。
- 鉴权时：优先查询全部权限关系表，若鉴权失败，则自动降级查询继承关系的鉴权模式。
RBAC2
- 静态职责分离（SSD）
- 互斥角色：同一用户只能分配到一组互斥角色集合中至多一个角色，比如用户不能同时拥有会计和审计两个角色
- 基数约束：一个用户可拥有的角色数目受限；一个角色可被分配的用户数量受限；一个角色对应的权限数目受限
- 先决条件角色：用户想要成为上级角色，必须先成为下一级角色，比如游戏中的转职
- 动态职责分离（DSD）
- 允许一个用户具有多个角色，但在运行时只能激活其中某些角色，比如BOSS直聘，一个用户既可以是招聘者也可以是应聘者，但同时只能选择一种身份进行操作
RBAC3
RBAC1 + RBAC2，既有角色继承，也有各种限制条件。
3 RBAC中的用户划分
3.1 用户组
- 用户组是一群用户的组合，而角色是用户和权限之间的桥梁。
- 用户组把相同属性的用户组合起来，比如同一个项目的开发、产品、测试可以是一个用户组，同一个部门的相同职位的员工可以是一个用户组， 一个用户组可以是一个职级，可以是一个部门，可以是一起做事情的来自不同岗位的人。
- 用户可以分组，权限也可以分组，权限特别多的情况下，可以把一个模块的权限组合起来成为一个权限组，权限组也是解决权限和角色对应关系复杂的问题。
此时RBAC模型为
3.2 组织
- 每个公司都有自己的组织架构，很多时候权限的分配可以根据组织架构来划分。统一组织内的人权限大都一样
- 按组织分配角色的优势
- 实现权限分配的自动化： 和组织关系打通之后，按照组织来分配角色，如果有新入职的用户，被划分在某个组织下面之后，会自动获取该组织下所有的权限，无需人工分配。又比如有用户调岗，只需要把组织关系调整就可以了，权限会跟着组织关系自动调整，也无需人工干预。这么做首先需要把权限和组织关系打通。
- 控制数据权限： 把角色关联到组织，组织里的成员只能看到本组织下的数据，比如市场推广和大客定制，市场推广针对的是零散的客户，大可定制针对的是有一定体量的客户，相互的数据虽然在一个平台，但是只能看自己组织下的数据。
- 加入组织后的模型图
3.3 职位
一个组织下面会有很多职位，比如财务管理会有财务总监、财务主管、会计、出纳员等职位，每个职位需要的权限是不一样的，可以像组织那样根据职位来分配不同的角色，由于一个人的职位是固定的，所以用户跟职位的对应关系时一对一的关系，职位跟角色的对应关系可以是多对多的关系。
4 理想的RBAC模型
把RBAC、RBAC1、RBAC2、用户组、组织、职位汇总起来的模型如下所示：
5 权限系统的表设计
5.1 标准RBAC模型表设计
5.2 理想RBAC模型表设计
