RBAC基于角色的权限访问控制

RBAC是什么？能解决什么问题？

RBAC是Role-Based Access Control的首字母，翻译成中文就是基于角色的权限访问控制，说白了就是用户通过角色与权限进行关联。一般一个用户可以有多个角色，每一个角色拥有若干权限，如此就构成了“用户-角色-权限”的授权模型，在这种模型中，用户和角色之间、角色和权限之间都是多对多的关系。RBAC是一种思想，根据RBAC思想进行数据库设计以便更好的完成权限控制。
在我们实际的工作中，权限管理系统就成了重复开发效率最高的一个模块之一，而在多套系统中，对应的权限管理只能满足自身的系统管理需要，无论是在数据库设计、权限访问和权限管理机制方式上都可能不同，这种不一致性也就导致了一些弊端：

• 维护多台系统，重复造轮子；
• 用户管理、组织机制等数据重复维护，数据的完整性、一致性很难得到保障；

RBAC是基于不断实践之后提出的一个比较成熟的访问控制方案，实践表明，采用基于RBAC模型的权限管理系统具有以下优势：

• 重用性强；
• 能够灵活的支持应用系统的安全策略，并对应用系统的变化有很大的伸缩性；
• 由于角色与权限的数据更新频率比角色与用户的数据更新频率要低的多，减少了授权管理的复杂性，降低管理开销；
• 在操作上，权限分配直观、容易理解、便于使用；

RBAC模型的分类

RBAC模型可以分为：RBAC0、RBAC1、RBAC2和RBAC3这四种，其中RBAC0是基础，也是最简单的，相当于是底层逻辑，其余三种都是RBAC0的升级版。一般情况下RBAC0就可以满足常规的权限管理系统设计了。

RBAC0模型

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

• 用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。目前我开发维护的系统就是这种关系的设计。
• 用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。

那什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？如果系统功能比较单一，使用人员较少，岗位权限相对清晰且确保不会出现兼岗的情况，此时可以考虑用多对一的权限体系。其余情况尽量使用多对多的权限体系，保证系统的可扩展性。如：张三既是行政，也负责财务工作，那张三就同时拥有行政和财务两个角色的权限。

RBAC1模型

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

RBAC2模型

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

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

RBAC3模型

RBAC3模型：称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内，综合了RBAC0、RBAC1和RBAC2的所有特点，这里就不在多描述了。

基于RBAC模型实现数据权限

权限

权限是资源的集合，这里的资源指的是软件中所有的内容，包括模块、菜单、页面、字段、操作功能（增删改查）等等具体的权限配置上，目前形式多种多样，根据我个人的理解，可以将权限分为：页面权限、操作权限和数据权限。

• 页面权限：所有系统都是由一个个的页面组成，页面再组成模块，用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。
• 操作权限：用户凡是在操作系统中的任何动作、交互都是操作权限，如增删改查等。
• 数据权限：一般业务管理系统都有数据私密性的要求：哪些人可以看到哪些数据，不可以看到哪些数据。简单举个例子：某系统中有销售部门，销售专员负责推销商品，销售主管负责管理销售专员日常工作，经理负责组织管理销售主管作业。按照实际理解，‘销售专员张三’登录时，只能看到自己负责的数据；销售主管2登录时，能看到他所领导的所有业务员负责的数据，但看不到其他团队业务员负责的数据。

什么是数据权限？

数据权限是指用户是否能够看到某些数据。 说的通俗点就是设置用户只能查看哪些数据，这就是数据权限，主要应用在数据有保密要求或数据量大或数据非常敏感的，需按用户或角色来进行区分时，例如：财务主管在后台可以看到公司所有人的工资流水，但普通员工只能看到自己的工资流水。在这里可能有的同学或许认为：既然我们的权限是跟角色关联，为什么“查看工资流水”这个权限精确到每个用户了呢？其实这就是RBAC-2的一种，权限与角色关联后增加了限制条件，不过这种限制条件无法在页面上灵活配置，数据权限的颗粒度由粗到细可以分为菜单级、栏目级、字段级，一般配置页面都可以灵活操作。

如果还不太容易理解的话，我们再举个例子，在我们开发SCRM系统时，系统的使用者涉及到了销售、财务等工作人员，它们对数据是非常敏感的，因此要求对数据权限进行控制， 而且我们是基于SAAS的产品，所以对于基于集团性的应用系统而言，就更多的需要控制好各自公司的数据，如设置只能看本公司或者本部门的数据，对于特殊的领导，可能需要跨部门的数据， 因此程序不能硬编码哪个领导该访问哪些数据，需要进行后台的权限和数据权限的控制，比较特殊的是系统管理员admin，默认系统管理员admin拥有所有数据权限，默认角色拥有所有数据权限（如不需要数据权限不用设置数据权限操作）。在我们SCRM系统中数据权限支持以下几种：

• 全部数据权限
• 自定义数据权限
• 部门数据权限
• 部门及以下数据权限
• 仅本人数据权限

如何实现数据权限

要实现数据权限有多种方式：

• 可以利用RBAC1模型，通过角色分级来实现。
• 在‘用户-角色-权限’的基础上，增加用户与组织的关联关系，用组织决定用户的数据权限。

当然，具体的实现方案还要结合具体的业务场景以及项目的现状来确定使用什么样的技术实现方案是最优。

用户组的使用

当平台用户基数增大，角色类型增多时，如果直接给用户配角色，管理员的工作量就会很大。这时候我们可以引入一个概念“用户组”，就是将相同属性的用户归类到一起。例如：加入用户组的概念后，可以将部门看做一个用户组，再给这个部门直接赋予角色（1万员工部门可能就几十个），使部门拥有部门权限，这样这个部门的所有用户都有了部门权限，而不需要为每一个用户再单独指定角色，极大的减少了分配权限的工作量，同时也可以为特定的用户指定角色，这样用户除了拥有所属用户组的所有权限外，还拥有自身特定的权限。
用户组的优点，除了减少工作量，还有更便于理解、增加多级管理关系等。如：我们在进行组织机构配置的时候，除了加入部门，还可以加入科室、岗位等层级，来为用户组内部成员的权限进行等级上的区分。

实例分析

上面介绍了那么多关于RBAC的相关内容，那么如何设计RBAC权限系统呢？

首先，我们思考一下一个简单的权限系统应该具备哪些内容？答案显而易见，RBAC模型：用户-角色-权限。所以最基本的我们应该具备用户、角色、权限这三个内容。

接下来，我们思考究竟如何将三者关联起来。角色作为枢纽，关联用户、权限，所以在RBAC模型下，我们应该：创建一个角色，并为这个角色赋予相应权限，最后将角色赋予用户。其实说到这里，大家应该就明白了，就是我们开发一个后台管理系统时的普通的角色权限的设计，这就是RBAC模型。

现在，基本的流程逻辑已经抽象出来了，接下来，分析该如何设计呢？常规情况下的设计是这样的：
第一步，需要角色管理列表，在角色管理列表能快速创建一个角色且创建角色的同时能为角色配置权限，并且支持为创建成功的角色列表能随时进行权限配置的的修改；
第二步，需要用户管理列表，在用户管理列表能快速添加一个用户且添加用户时有让用户关联角色的功能。

常规情况下简单的权限系统设计就包含以上两步，接下来为大家进行实例分析，分析一下RBAC1中角色分级具体如何设计？
在RBAC0的基础上，加上角色等级这个字段。权限分配规则制定：低等级角色只能在高等级角色权限基础上进行删减权限。比如等级1可以自由选择分配权限；等级2只能在等级1的基础上删减权限；等级3则只能在等级2的基础上删减权限，以此类推。以上就是简单的RBAC系统设计，若需更复杂的，还需要研发人员根据上面的分析结合具体需求自行揣摩思考，万变不离其宗，理解清楚RBAC模型后，结合自己的业务就可以设计出一套符合自己平台需求的角色权限系统，具体的就不再多阐述了。