RBAC模型

前言

权限管理几乎是所有后台管理系统必要的组成部分，主要针对不同权限的人对资源的访问控制，可以避免因权限缺失而导致不必要的风险问题，如资源数据泄露、或误入系统操作不当导致的风险。

目前我所了解的权限框架有：

• Apache Shrio
• Spring Security

权限模型

目前普及度最高的就是 RBAC 模型（Role-Based Access Control）

RBAC模型主要分为RBAC0、RBAC1、RBAC2、RBAC3，RBAC0是所有模型的基础，其他三种是基于RBAC0模型的扩展与变形。

RBAC0模型

RBAC0是基础，定义了能构成RBAC模型的最小集合。

用户

发起操作的主体。不限于单个用户，也可以是用户组。只要是对资源有访问需求的都可以称之为用户。

角色

起到了桥梁的作用，连接了用户和权限的关系，每个角色可以关联多个权限。如果一个用户关联多个角色，那么用户就拥有了多个角色的权限许可。简而言之就是权限的集合。

权限许可

用户对资源的访问权限许可。包括：页面权限，操作权限，数据权限等。

会话

用户通过会话对角色进行操作，即用户对角色的分配控制操作。

RBAC1模型

RBAC1模型引入了角色继承的概念，即角色拥有上下级关系或等级关系。父类角色拥有子类角色的所有的权限。

角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。

而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。这种设计可以给角色分组和分层，一定程度简化了权限管理工作。

比如：部门主管只能更改该部门的员工信息，经理能更改所有部门主管的信息和所有部门的员工信息。

RBAC2模型

RBAC2 在 RBAC0 的基础上引入了静态职责分离（Static Separation of Duty，简称SSD）和动态职责分离（Dynamic Separation of Duty，简称DSD）两个约束概念。他们两个作用的生命周期是不同的。

• SSD 作用于约束用户和角色绑定时。

  1. 互斥角色：就像上面的例子你不能既是A又是B，互斥的角色只能二选一 ;

  2. 基数约束：用户的角色数量是有限的不能多于某个基数；

  3. 条件约束：只能达到某个条件才能拥有某个角色。经常用于用户等级体系。

• DSD 作用于会话和角色交互时。当用户持有多个角色，在用户通过会话激活角色时加以条件约束，根据不同的条件执行不同的策略。

RBAC3模型

1 + 2 = 3 —> RBAC1 + RBAC2 = RBAC3

整合了RBAC1、2的模型，目前迭代后的最全面版本。

用户组

我们前面提到过用户组，当平台用户基数增大，角色类型增多时，并且有一些用户具有相同的属性，比如研发部的所有员工，如果直接给用户分配角色，管理员的工作量就会很大，如果把相同属性的用户归类到某用户组，那么管理员直接给用户组分配角色，此时用户组的每个用户都拥有该角色。之后其他用户加入到该用户组后，会自动获取用户组的所有角色，退出用户组同时也会撤销该角色，无需手动管理角色。