后台系统设计——角色权限

一、前言

不论是哪种后台管理系统，“人员权限”始终是绕不开的话题。无论是移动端，PC端产品，登陆都需要一个账号。只是对于C端的产品，大多都是用户自己注册即可。

而对于后台产品而言，是需要公司内部人员去创建账号的。每个使用系统的用户都有一个独一无二的账号，每个账号都有自己对应的权限。

多数情况下，除了超级管理员外，我们会对大多数的账号的权限做一些限制，以此来管理不同用户的使用权限问题。

譬如，做企业使用类软件，不同部门、不同职位的人的权限是不同的；再例如一款收费产品的收费用户和免费用户权限也是迥然不同的。

如果每个用户都单独做权限控制的话，当系统用户体量非常大的时候，就会发现以下问题：

很多账号权限都是一样的，但每次都要再配一次；

当某类权限用户的权限需要修改时，无法批量修改，只能一个个去修改非常耗时；

二、经典模型——RBAC

这时候，聪明的产品先人就创建了“角色”的概念，通过对权限集的抽象，创立了角色，通过修改角色的权限，来控制拥有该角色的人员账号的权限。

1、RBAC——基于角色的访问控制（Role-Based Access Control ）

其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。

这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。

按照百度百科对RBAC的定义，我们可以理解为此模型是通过角色关联用户，角色关联权限的方式，间接赋予用户权限。

2、分类

RBAC 模型分为RBAC0、RBAC1、RBAC2、RBAC3

RBAC0：是RBAC的核心思想。完全支持RBAC概念的任何系统的最低需求。

RBAC1：是把RBAC的角色分层模型。增加了角色分级的概念，一个角色可以从另一个角色继承许可权。

RBAC2：增加了RBAC的约束模型。增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。

RBAC3：其实是RBAC2 + RBAC1。称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族；

下面，我以最为基础的RBAC0为例来讲下角色权限体系：

三、RBAC0

1.用户-角色-权限之间的关系

通过上面的分析，我们已经知道，在这个模型里，涉及到3个专有名词，那就是用户、角色、权限，下面是我对这3个词的简单定义：

用户：使用系统的人；

角色：权限的的集合；

权限：数据权限、功能权限（页面权限+操作权限）；

在这个RBAC0模型中，我们把权限赋予角色，再把用户关联角色来继承角色所对应的权限。用户和角色，角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限的并集；

 

 

接下来我们一一来剖析，如何把这3个名词巧妙的联合，来打造一个完整的系统用户权限管理。

2.用户管理

 

 

新增用户有2个关键点，第一是需要关联角色，第二是关联组织部门。

关联角色：我们通过RBAC0模型的关系图1已经知道，用户与角色之间是多对多的关系，所以如图2中的用户“吴京”，关联了战狼、伪装者的角色，那么他就拥有战狼、伪装者这2个角色权限的并集。

用户权限亦可单独修改，修改用户的权限不影响角色本身的权限。如修改角色权限会修改角色下关联的所有用户的对应权限。

关联组织部门：什么是组织部门呢？且看下回分解——权限管理；

2.权限管理

权限可以分为数据权限、功能权限两大类：

数据权限

顾名思义，就是账号能查看哪些数据，例如当一个公司存在多个独立的运营中心时，如何保证每个运营中心信息的独立性，如何实现运营中心之间相互不能查看业务数据，这个就涉及到数据权限。

数据权限一般通过数据权限树来控制，那什么是数据权限树呢？

数据权限树在一定程度上等于公司的组织结构，当然我们可以根据公司的特性去修改，并不一定要严格按照公司的部门结构来建立，只要能让此结构更为方便的为公司服务即可，如下图

 

例如：当一个公司旗下有3个子公司，那么每个子公司都是一个独立的业务部门，这样，在给每个子公司的用户配置权限时，只需要给他配置其子公司下的数据即可；

当业务单据需要跨公司的时候，可能需要做些特殊的处理，比如建单的时候，在选择公司时，权限放开，因为并不能确定哪些公司之间会有合作。

查询页面的显示原则：凡涉及本公司业务的单据，拥有该公司业务数据权限的人皆可以查看。以电商中常见的仓库调拨单为例：

 

此单据可以查看的人员有：

A公司拥有业务组1权限的人员+B公司有B仓权限的业务组的所有人员。有点拗口哈，但不妨碍我们把事儿说清楚。

功能权限

功能权限是页面权限+操作权限的集合。页面权限是指你的系统分为哪些个页面，比如说销售单查询页、商品库存页等等。操作权限是指页面上能看到的：查询、新增、删除、导出等等操作。

页面权限：所有系统都是由一个个的页面组成，用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。

操作权限：用户凡是在操作系统中在任何页面做的任何动作，都是操作权限，如增、删、改、查、导出、审核等等。

 

以后台系统功能权限为例，如图4，一般来说，功能权限的配置方式都是以模块+页面名称+页面对应的操作为模型进行配置的，这样配置既清晰，出错的概率也比较小。

3.角色管理

角色管理是RBAC0模型的关键，以下是角色管理的图文说明：角色的建立主要包括3个模块，基础信息功能权限、数据权限。

其中基础信息和功能权限为必填，数据权限可选填。数据权限一般在用户的账号上再进行配置。

如果角色适用于所有的组织机构那么就可以配上数据权限，如角色是针对于某一个组织机构建立的，那配置数据权限反而是累赘。

例如：以图3的公司结构为例，如果每个子公司都有自己的财务，并且最后需要汇总到总公司的财务体系下，这时系统如果只建立1个财务角色，那此时，就只需要配置功能权限，数据权限在新增用户的时候对总公司的财务、分公司的财务配置不同的数据权限即可；

如果系统如果分别建立2个及以上个财务角色，1个叫总公司财务，一个叫子公司1财务、子公司1财务，那么每个财务角色就可以在新建的时候把数据权限、功能权限都配置好，新建用户的时候就无需再去配置。

具体角色应该怎么新建，各公司可根据自身的实际情况进行灵活配置。

 

四、总结

RBAC0模型基本可以满足任何一个系统去建立一套相对完整的权限体系，当然它也存在着一些不足，比如：

一个用户拥有多个角色，多角色之间如果存在互斥关系如何处理？

当角色存在层级关系时如何给角色建立层级关系？

......

这时候我们就需要引入以下这些升级模型：

1、RBAC1：是把RBAC的角色分层模型。增加了角色分级的概念，一个角色可以从另一个角色继承权限。

 

2、RBAC2：增加了RBAC的约束模型。添加了责任分离关系，规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

互斥角色: 同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。比如财务部有会计和审核员两个角色,他们是互斥角色,那么用户不能同时拥有这两个角色,体现了职责分离原则

基数约束: 一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配

先决条件角色: 即用户想获得某上级角色,必须先获得其下一级的角色

3、RBAC3：其实是RBAC2 + RBAC1。称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。

以上是我根据自己主导过，使用过的系统，得出的对角色权限系统的归纳和总结，有不足之处，希望大家多多交流。

链接：https://www.jianshu.com/p/29c2d7721924