工作时遇到了需要设计一套权限系统，所以做了一些调研。目前业界比较通用的权限系统设计都是采用RBAC模型，那么我们详细理解下RBAC模型的概念以及一些实际使用中建议的使用规范：

RBAC权限模型

首先了解下RBAC权限模型的基本概念和几种模型分类。

1 RBAC权限模型

RBAC（Role-Based Access Control）即：基于角色的权限控制。通过角色关联用户，角色关联权限的方式间接赋予用户权限，增加权限设置的扩展性。

为什么要有角色的概念：对于批量的用户权限调整，只需调整用户关联的角色权限，无需对每一个用户都进行权限调整，既大幅提升权限调整的效率，又降低了漏调权限的概率

2 RBAC模型分类

RBAC模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四种，其中RBAC0是基础，也是最简单的，相当于底层逻辑，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级

1-2-1 RBAC0模型

最简单的用户、角色、权限模型。这里面又包含了2种：

• 用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。一般适用于小型系统，角色岗位较为清晰，不会有兼岗的情况
• 用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。一般适用于较为复杂的系统，一个人可能既是人事HR，又是招聘负责人。

当前我们使用的场景一般都是：用户和角色是多对多关系的，简单多对一关系场景覆盖不全

使用场景：在某个公司，一个人可能既是人事HR，又是招聘负责人

1-2-2 RBAC1模型

相对于RBAC0模型，增加了子角色，引入了继承概念，即子角色可以继承父角色的所有权限，但是子角色必须是在父角色的基础上减少权限点

使用场景：如某个业务部门，有经理、主管、专员。主管的权限不能大于经理，专员的权限不能大于主管，如果采用RBAC0模型做权限系统，极可能出现分配权限失误，最终出现主管拥有经理都没有的权限的情况。而RBAC1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持在经理权限上删减主管权限。

1-2-3 RBAC2模型

基于RBAC0模型，增加了对角色的一些限制：角色互斥、基数约束、先决条件角色等。

• 角色互斥：同一用户不能分配到一组互斥角色集合中的多个角色，互斥角色是指权限互相制约的两个角色。案例：财务系统中一个用户不能同时被指派给会计角色和审计员角色。
• 基数约束：一个角色被分配的用户数量受限，它指的是有多少用户能拥有这个角色。例如：一个角色专门为公司CEO创建的，那这个角色的数量是有限的。
• 先决条件角色：指要想获得较高的权限，要首先拥有低一级的权限。例如：先有副总经理权限，才能有总经理权限。
• 运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色

各类角色特性关系图如下：

1-2-4 RBAC3模型

称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内，综合了RBAC0、RBAC1和RBAC2的所有特点

权限系统实现

所以一个权限系统需要具备如下的几个关键要素：

• 项目：对权限服务来说，一个项目，即为一个服务对象，不同项目间的权限数据是相互隔离的。
• 权限点：业务系统定义的一个具体的权限，一般定义为一种动作，如：签约、审批、增、删、查、改等，都可以是一个权限点。权限点不直接分配给用户。
• 角色：一定数量权限点的集合。权限分配的单位与载体,目的是隔离用户与权限点的逻辑关系。
• 权限约束：对一个权限点的附加限制，可配置为权限点的数据范围或附加条件。
• 角色属性：对一个角色的附加属性，如：虚拟角色。角色属性通过"全局权限点"实现。（业务系统可自行定义，自行解释角色属性）
• 全局权限点：是一种特殊的权限点，角色关联全局权限点后，全局权限点约束的键、值将作为角色属性返回。

全局权限点主要是当做角色属性来使用的，配置后，不需要为每个角色再配一遍，例如系统的首页查看权限，不是特别敏感，该项目下的用户列表都有权限查看

权限配置分类

我们平时使用的权限其实是有分类的，大体上分为三类：页面权限、操作权限、数据权限。

使用的时候，页面权限和操作权限通过配置成相应的权限点实现，数据权限通过配置约束并附着在操作权限上生效。

权限配置规范

使用时需要有一些基本规范和建议，总体而言一个权限系统要设计的简单易用为妙，也不要被业务场景赶着跑，最好有全局意识：

• 【强制】不要用约束定义操作行为。约束的作用就是限定权限点范围的，操作行为应该被定义为权限点，约束是控制数据范围的
• 【建议】权限验证代码建议放到controller层，包括参数验证，参数转换，这一层的职责就是判定入参有效性，参数有效才向下一层传递，通用的业务无关权限代码可以放到一个类里，具体类的业务逻辑如有需要可继承实现。
• 【建议】使用上不需要单独定义【xxx-数据权限】、【xxx-操作权限】，权限点要具体而实际，对应一个url路径或者一个接口，而权限点上配置的约束自然能充当该权限点的数据范围约束
• 【建议】不要使用互斥权限，增加系统复杂度，并且用处感觉也不太大，在业务上也并没有实际场景，只是为了防止配错，这个概念是个负担
• 【建议】不生造概念，不搞白名单或者其它自己想象的概念，所有的落地都是角色，依据角色的实际使用场景给它命名

总而言之，操作的落点是权限点，约束是权限点更细粒度的数据范围控制，而角色是和用户进行绑定的，简单用，搞复杂了会增加代码复杂度和理解难度