RBAC简介（*）

一.RBAC是什么

1.RBAC模型概述
RBAC是Role Based Access Control的英文缩写，意思是 基于角色的访问控制。
RBAC实际上就是针对产品去挖掘需求时所用到的Who（角色）、What（拥有什么资源）、How（有哪些操作）的方式。
在RBAC模型中，who、what、how构成了访问权限三元组，也就是“Who对What进行How的操作。
RBAC主要包含四个子模型：RBAC0、RBAC1、RBAC2和RBAC3，整体又叫做RBAC96。

RBAC0
RBAC0是RBAC96模型家族中的基础，也称作核心部分，RBAC1、RBAC2和RBAC3是在此基础之上发展演变而来的。

可以理解它是由四个部分组成的：用户、角色、会话、权限
这就导致了这种分配关系是多对多：用户对应多个角色、角色对应多个权限。
用户与会话一对一，会话与角色一对多。

RBAC1
RBAC1是在RBAC0模型基础上增加了角色分层概念和角色之间的继承关系。

角色分层指的是同一个角色可以有不同等级，不同等级又对应着不同的权限；
角色继承关系指的是子角色可以对父角色的权限进行继承，但是子角色的权限一定小于父角色。

RBAC2
RBAC2是在RBAC0模型基础上增加了角色约束，主要约束哪些操作是可进行的，哪些是不可进行的。

主要约束有以下三个方面：

• 角色互斥约束：是指在系统运行中，只可以同时激活运行时互斥角色集合中的一个角色;
• 角色基数约束：是限制某一个用户最多被分配或者激活的角色数目,或者限制某一个角色最多被赋予的权限数目;
• 先决条件角色约束：是指某些用户只有在己经拥有特定角色的前提下,才能被分配到某种角色,或者某种角色只有在已经被分配到特定权限的前提下,才能被赋予某些权限

RBAC3
RBAC3则是集聚了RBAC1和RBAC2的全部特点,同时将角色继承关系和约束条件关系两者都融入到模型中。

2.RBAC的组成
在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。

RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理。

下面在讲解之前，先介绍一些名词：

• User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色
• Role（角色）：不同角色具有不同的权限
• Permission（权限）：访问权限
• 用户-角色映射：用户和角色之间的映射关系
• 角色-权限映射：角色和权限之间的映射

它们之间的关系如下图所示：

例如下图，管理员和普通用户被授予不同的权限，普通用户只能去修改和查看个人信息，而不能创建用户和冻结用户，而管理员由于被授予所有权限，所以可以做所有的操作。

3.RBAC支持的安全原则
RBAC支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则

• 最小权限原则：RBAC可以将角色配置成其完成任务所需的最小权限集合
• 责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个计账员和财务管理员共同参与统一过账操作
• 数据抽象原则：可以通过权限的抽象来体现，例如财务操作 用借款、存款等抽象权限，而不是使用典型的读、写、执行权限。

4.RBAC的优缺点
（1）优点：

• 简化了用户和权限的关系
• 易扩展、易维护

（2）缺点：

• RBAC模型没有提供操作顺序的控制机制，这一缺陷使得RBAC模型很难适应那些对操作次序有严格要求的系统

5.RBAC的3种模型
（1）RBAC0
RBAC0，是最简单、最原始的实现方式，也是其他RBAC模型的基础。

在该模型中，用户和角色之间可以是多对多的关系，即一个用户在不同场景下可以有不同的角色，例如：项目经理可能是组长也可能是架构师。同时每个角色都至少有一个权限。这种模型下，用户和权限被分离独立开来，使得权限的授权认证更加灵活。

（2）RBAC1
基于RBAC0模型，引入了角色间的继承关系，即角色上有了上下级的区别。

角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。
这种模型适合于角色之间层次分明，可以给角色分组分层。

（3）RBAC2
RBAC2，基于RBAC0模型的基础上，进行了角色的访问控制。

RBAC2中的一个基本限制是互斥角色的限制，互斥角色是指各自权限可以互相制约的两个角色。对于这类角色，一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。

该模型有以下几种约束：

• 互斥角色：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
• 基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人是有限的；
• 先决条件角色：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指 要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。
• 运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

二.如何设计RBAC

这一节，我会介绍设计基于RBAC模型的权限系统的功能模块组成、流程以及数据库的设计。
1、RBAC的功能模块

2、RBAC执行流程

3、RBAC数据库设计

三.完整的权限设计
很多人都知道以角色为基础的权限管理设计（RBAC），但是大部分人似懂非懂，不知道完整的权限管理系统都包括哪些内容。

在此以权限管理的使用场景来说明一下完整的权限管理内容。

1.一是鉴权管理，即权限判断逻辑。
（1）最基本的权限管理就是菜单管理，用户没有权限的功能模块在菜单节点上是不显示的。（很多人以为这就是权限管理！）

示例：普通业务人员登录系统后，是看不到【用户管理】菜单的。

（2）功能权限管理，B/S系统的功能体现为URL，所以功能权限管理主要是针对URL访问的管理。（很多人都不清楚权限管理的对象是什么？）

示例：

经过授权，部门经理可以查看【用户管理】菜单，并查看部门用户信息，但权限设计要求，该部门经理没有添加用户的权限。

所以在访问【添加用户】的功能（URL）时，应该有 没有授权的提示信息。

同时在【用户管理】页面上，【添加用户】的按钮应该灰色显示，不能点击。

（3） 行级权限管理
示例：

论坛管理员，权限设计要求 A能管理论坛 【新闻版块】，不能管理论坛 【技术交流】

此时的权限设计就应该根据论坛的相应ID来判断权限信息。

（4）列级权限管理
示例：

业务权限设计要求，除销售人员以外，其他用户不能看到客户的联系方式信息。

此时的权限设计要判断相应的字段（列）是否可以显示。

(5)组织机构/部门级数据权限管理
示例:

业务权限设计要求，销售一部的人员只能看到本部门的销售订单，销售二部的人员只能看到本部门的销售订单，但销售经理可以同时看到销售一部和销售二部的销售订单。

此时的权限设计就要根据销售订单数据本身的部门属性来做判断。

（6）范围型业务数据权限管理

示例：

大卖场销售人员在下销售订单时，要选择相应的产品所在的仓库信息。

业务权限设计要求，【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】，而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】

2.是授权管理，即权限分配过程。以上的权限管理内容都要通过系统的授权功能来分配给具体的用户，授权功能应该足够灵活。

（1）直接对用户授权，直接分配到用户的权限具有最优先级别。
（2）对用户所属岗位授权，用户所属岗位信息可以看作是一个分组，和角色的作用一样，但是每个用户只能关联一个岗位信息。
（3）对用户所属角色授权，用户所属角色信息可以看作是一个权限分组，每个用户可以关联多个角色。
（4）角色直接关联具体的功能权限（URL），也可以关联负权限，即此角色关联的权限不能使用负权限功能。负权限具有优先级别。
（5）分级授权，系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。

总结：
rbac就是基于角色的权限控制设计
用户、角色、权限。
基本表：用户表、角色表、用户角色关联表、权限表、角色权限关联表。
用户关联角色，角色关联权限。
（1）一个用户可以属于多个角色，某某既是项目经理，又是架构师。一个角色下也可以有多个用户。用户表和角色表是多对多。
（2）一个角色可以有多个权限。一个权限也可以属于多个角色。角色表和权限表是多对多。
权限分类：访问权限（菜单权限、数据权限）、操作权限
访问权限即用户登录系统后能不能看到。
操作权限即用户登录系统后能不能操作。不能操作可以通过控制前端操作按钮不能点击，或者访问对应功能url，给出提示信息。
一个权限就是一条权限表信息记录。将权限信息记录返回给前端，前端来控制即可。
某用户有什么样的权限就是该用户在权限表中关联了哪些数据信息。