作者 | izecsonli(李文林)
导读
任何一款产品或多或少都会涉及到用户和权限的问题，本片文章就带你了解权限界的明星级设计方案RBAC。
一、背景
我们在做任何一款产品的时候，或多或少都会涉及到用户和权限的问题。譬如，做企业类软件，不同部门、不同职位的人的权限是不同的；做论坛类产品的时候，版主和访客权限也是不一样的；再例如一款产品的收费用户和免费用户权限也是迥然不同的。
本文是在开发过程中对角色权限控制的思考，分享给大家。
二、概念
用户：就是账号，用户只有授权后才允许访问相应的资源。
角色：角色代表了操作集合，可以理解为权限的集合，一般情况下我们会赋予用户角色而不是权限，即这样用户可以拥有一组权限，赋予权限时比较方便。典型的如：产品经理、催收员、审核员、开发工程师等都是角色，不同的角色拥有一组不同的权限。
隐式角色：即直接通过角色来验证用户有没有操作权限，如在应用中产品经理、催收员、审核员、开发工程师可以使用打印机，假设某天不允许产品经理使用打印机，此时需要从应用中删除相应代码。再如在应用中催收员、审核员催收员、审核员催收员、审核员可以查看用户、查看权限；突然有一天不允许催收员查看用户、查看权限了，需要在相关代码中把催收员角色从判断逻辑中删除掉。粒度是基于角色为中心进行访问控制的，粒度较粗。如果进行修改可能造成多处代码修改。
显示角色：在程序中通过权限控制谁能访问某个资源，角色聚合一组权限集合；假设哪个角色不能访问某个资源，只需要把角色代表的权限集合中删除即可。无须修改代码。粒度是基于资源为中心的，粒度较细。
权限：所谓权限,无外乎是用户能否看到，能否操作/，大到某一个菜单，某一个页面，小到某一个按钮，某一行数据，都可以称之为权限。权限一般可以分为以下三类：1.菜单级别：也就是菜单的显示与隐藏；2.页面元素级别：页面上增加、删除、修改按钮的显示与隐藏；3.数据级别：不同的人，不同的组织展示数据不一样，一般和组织架构关联起来；
资源：用户可以访问到的东西，比如访问html页面、增加/编辑按钮、某个文件等等都是资源。用户只要授权后才能访问。
三、RBAC模型
1. RBAC模型是什么
在传统权限模型中，我们直接把权限赋予用户。而在RBAC中，增加了“角色”的概念，我们首先把权限赋予角色，再把角色赋予用户。由于增加了角色，授权会更加灵活方便。在RBAC中，根据权限的复杂程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中，RBAC0是基础，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度，选取适合的权限模型。
2. 基本模型RBAC0
RBAC0是基础，很多应用只需根据RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。
举个例子，我们做一款税务系统，如果按传统权限模型，给每一个用户赋予权限则会非常麻烦，并且做不到批量修改用户权限。这时候，可以抽象出几个角色，譬如税务审核员、税务科员、税务科长等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是以后的修改权限，只需要修改用户和角色的关系，或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，譬如王科长既负责审核部也负责组织部，那么可以给王科长赋予两个角色，即审核员+组织部科长，这样他就拥有这两个角色的所有权限。
3. 角色分层模型RBAC1
RBAC1建立在RBAC0基础之上，在角色中引入了继承的概念。简单理解就是，给角色可以分成几个等级，每个等级权限不同，从而实现更细粒度的权限管理。
基于之前RBAC0的例子，我们又发现一个税务局的科长可能是分几个等级的，譬如除了科长，还有副科长，而副科长只有科长的部分权限。这时候，我们就可以采用RBAC1的分级模型，把科长这个角色分成多个等级，给副科长赋予较低的等级即可。
4. 角色限制模型RBAC2
RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图：
还是基于之前RBAC0的例子，我们又发现有些角色之间是需要互斥的，譬如给一个用户分配了审核员的角色，就不能给他再赋予科长的角色了，否则他即可以录入资料又能自己审核资料；再譬如，有些公司对角色的晋升十分看重，一个销售员要想升级到销售经理，必须先升级到销售主管，这时候就要采用先决条件限制了。
5. 统一模型RBAC3
RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也包括可以增加各种限制。
统一模型RBAC3可以解决上面三个例子的所有问题。当然，只有在系统对权限要求非常复杂时，才考虑使用此权限模型。
6. 基于RBAC的延展——用户组
基于RBAC模型，还可以适当延展，使其更适合我们的产品。譬如增加用户组概念，直接给用户组分配角色，再把用户加入用户组。这样用户除了拥有自身的权限外，还拥有了所属用户组的所有权限。
比如，我们可以把一个部门看成一个用户组，如人工审核部，催收部，再给这个部门直接赋予角色，使部门拥有部门权限，这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权，且不影响用户本来就拥有的角色权限。
四、基于RBAC的数据库设计
RBAC(Role-Based Access Control，基于角色的访问控制)，就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成"用户-角色-权限"的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般是多对多的关系。
当用户的数量非常大时，要给系统每个用户逐一授权(授角色)，是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成"用户-角色-权限-资源"的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。
请留意权限表中有一列"权限类型"，我们根据它的取值来区分是哪一类权限，如"MENU"表示菜单的访问权限、"OPERATION"表示功能模块的操作权限、"FILE"表示文件的修改权限、"ELEMENT"表示页面元素的可见性控制等。
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，(实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？)。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表"权限XX关联表"，并确定这类权限的权限类型字符串。这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过"权限类型"和这个ID来区分是种类型下的哪条记录。
到这里，RBAC权限模型的扩展模型的完整设计图如下：
随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参与权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参与权限分配。
五、RBAC在项目中的实践
如何在实际项目中开发出一个灵活、通用、方便的权限管理系统呢？
简单来说，我们需要对系统的所有资源进行权限控制。那么系统中的资源包括哪些呢？我们可以把这些资源简单概括为静态资源(功能操作、数据列)和动态资源(数据)，也分别称为对象资源和数据资源，后者是我们在系统设计与实现中的叫法。系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。
下面是公司的鹰眼系统的权限管理部分。这里简单的给大家展示用户-角色-权限的页面和数据库设计。如果大家权限管理系统感兴趣，可以看一下统一用户以及权限管理系统需求分析报告。
1. 数据库的设计
2. 用户管理
3. 角色管理
4. 资源管理
