编辑导语：用户权限体系的搭建，是许多系统建设的基础，尤其是在B端产品设计中都会涉及到这一功能模块。那么我们该如何从零开始着手搭建用户体系？作者总结了相关步骤，希望能够给你带来一个全局性的认识，做到心中有数。

搭建用户权限体系，是很多系统建设的基础，特别是很多B端产品都会涉及到这一功能模块。那么我们如何从零开始着手这件事呢？

下面的内容希望能带给你一个全局性的认识，即使是之前从来没有涉及过的小白，也能帮助你做到心中有数。

一、系统资源

用户权限管理是一种对系统资源的访问控制，那么系统有什么样的资源需要进行权限分配呢？有3类：

1．菜单

菜单的授权意味着用户可以使用该菜单下相关的功能。属于高层级的授权。

2．操作

增删改查的权限控制，有的角色只能看不能改，有的角色具有增删改查全部权限。

3．数据

数据的权限控制，不同角色看到的数据范围不同，有的角色只能看到基础数据，有的角色能看到全部数据。

二、分配方式

了解了系统有哪些需要进行权限分配的资源后，接下来面临的问题是：系统有很多的用户，也有很多的资源，那么怎么实现给每一个用户分配好合适的权限呢？有两种实现路径：

1．直接分配，即ACL模型

给每一个用户直接进行权限的逐一分配。

这种方式的好处是非常灵活，能最大化满足每个用户对于权限的个性化需求。

缺点也显而易见，那就是不便于操作，权限的分配与管理效率比较低。

权限管理人员需要对系统有深入的了解，如果管理层级比较多时，系统的权限分配与管理无法大规模下放和向下有效分散，容易产生高层级管理人员觉得工作量大、基层人员觉得不能自主操控不方便等问题。

2．基于角色进行权限分配，即RBAC模型

这是一种间接分配方式，在用户集合和权限集合之间建立一个角色集合，用户通过角色与权限进行关联，形成“用户-角色-权限”的授权模型。

这种方式的好处是不必在每次给用户分配权限时都把系统所有的资源分配一遍，只要分配用户相应的角色即可，用户就拥有了这些角色所关联的权限。

而且角色的权限变更比用户的权限变更要少得多，也能实现权限的动态管理，即当角色的权限发生了变化以后，所有拥有该角色的用户也同时更新了权限状态。

下面重点来介绍一下RBAC模型。

在RBAC模型中，用户是真实的，而角色是我们为了方便管理权限集合而虚拟出来的。本质上，角色是一组权限的集合。

RBAC模型又可以分为RBAC0、RBAC1、RBAC2、RBAC3。

RBAC0：基本模型。用户和角色可以是一对一，也可以是多对对，一个用户拥有的权限是他所有角色的集合。

RBAC1：角色分层模型。RBAC1是在RBAC0的基础上增加角色分层，引入了继承概念。将角色分成多个等级，等级高的角色可以继承等级低的所有权限。

如某个部门，有助理工程师和工程师，助理工程师的权限不能大于工程师。如果采用RBAC0，极有可能出现权限分配失误，最终出现助理工程师拥有工程师都没有的权限的情况。

RBAC1很好地解决了这个问题，创建完助理工程师的角色并配置好权限后，工程师的角色继承助理工程师的权限并且增加特有的权限即可。

RBAC2：角色限制模型。RBAC2是在RBAC0的基础上增加了对角色的一些限制，包含角色互斥、基数约束、先决条件、运行时互斥。

• 角色互斥：一个用户不能同时拥有互斥的两个或多个角色。如财务系统中，一个用户不能同时拥有会计员角色和审核员角色。
• 基数约束：一个角色被分配的用户数量是有限制的，不能无限地添加，即有多少用户能够拥有这个角色。如一个角色是为CEO创建的，那么这个角色的数量是有限的。
• 先决条件：想要获得更高权限时，首先需要获得低一级的权限。如先有助理工程师的权限，才能有工程师的权限。
• 运行时互斥：一个用户允许具有两个角色，但在运行时不可同时激活这两个角色，如家长和老师，一个用户可能既是家长又是老师，但在使用系统时，只能选择一个角色。

RBAC3：统一模型。RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也可以增加各种限制。

基于RBAC的延展。了解完RBAC模型本身以后，我们还需要了解一组与之相关的概念：用户组、角色组、权限组。这3个概念的出现都是为了方便管理。

用户组：用户组是用户的集合。

如果用户数量比较庞大，可以给用户分组，分好组以后可以给用户组分配权限，这样这个用户组下的每一个用户拥有的权限=用户个人拥有的权限+该用户组拥有的权限。以后加入更多的用户，就自动拥有了用户组的权限，不用再一一进行设置了。

角色组：角色组是角色的集合。

有时多个角色针对某一部分系统资源拥有相同的权限，如经理、技术人员、销售人员这些角色，对同一类文件拥有相同的权限，这时就可以为这些角色建立一个角色组，把权限赋予这个角色组，这样这些角色就都拥有了权限。

权限组：权限组是权限的集合。

权限之间有时是相关联的，这时就可以为这些关联的权限设置一个权限组，当授权时就可以把权限组赋予某个角色/角色组，就不需要再一一去设置了。如当我们视频通话时，需要同时具有相机和麦克风的权限。

三、角色定义

在了解完RBAC模型以后我们会发现，在RBAC模型中角色是关键。为了对许多拥有相似权限的用户进行分类管理，我们抽象出角色的概念。那么我们如何来定义角色呢？

角色是基于业务来定义，而不是依据行政关系。如双人复核类业务，用户A在一次业务过程中扮演操作员角色，用户B扮演复核员角色。而在下一次业务过程中，用户B扮演操作员角色，用户A扮演复核员角色。这样的角色定义完全是基于业务上的需要，而与用户A和B的行政关系没有任何关系。

我们在进行角色定义时，可能会对角色的颗粒度产生迷惑，不知道该范围大一些包含的内容多一些还是应该范围小一些包含的内容少一些。

如一个用户涉及A、B、C三项业务，那么我是应该定义一个角色完成A、B、C三项业务的范围还是应该定义两个角色分别完成A、B业务和C业务呢？甚至定义三个角色分别完成A业务、B业务和C业务呢？

这时有人可能会说取决于ABC三项业务的关联性，实际上这个问题与业务的关联性没有关系。因为如果是相关联的业务那么必然会一起授权不可分割，如果是不相关的业务但是所有用户都是一起使用，那么也应该一起授权。

那么我们怎么判断呢？其实上面的例子和问题是走入了一个本末倒置的误区，从业务来归类用户了，方向上反了。前面我们说过，角色是拥有相似权限的用户抽象。

所以梳理角色的时候分析用户本身就可以了，归类出每类有相似权限的用户然后抽象成一个个角色。

用户权限体系对于整个功能体系具有蝴蝶效应，一点点小的差异/差错到了最上层的功能和使用层面会放大很多倍。而且一旦需要修改会很麻烦，所以我们需要特别小心。

四、前端展现方式

如果一个用户有多个角色，那么在前端功能层面我们该如何处理呢？有两种方案：

1. 角色切换：当一个用户有多个角色时，前端仅展现当前角色的相关功能，用户需要切换角色去使用对应的功能。
2. 统一展现：当一个用户有多个角色时，前端展现该用户所有角色的功能的全集，用户不再需要切换角色。

那么我们在这两种方案之间，该如何选择呢？我们需要判断用户所拥有角色之间的关系。

一般来说，如果角色之间存在运行时互斥的情况，那么需要选择角色切换方案，如前面提到的家长和老师，一个用户不可能在同一时间既是家长角色又是老师角色，所以需要切换角色去使用对应的功能。

再比如求职者和招聘者，一个用户不可能同时使用求职者和招聘者的功能。除此以外，其他情况都可以选择统一展现方案。

这里需要我们注意一点，如果你的系统有很多功能，一个用户的运行时互斥角色只涉及到部分功能模块，那么角色切换可以只局限于局部，不必全局都进行角色切换。

五、建议

1. 依据现实情况建立

依据现实情况已经抽象形成的角色，最能贴合现实情况，能最大限度地满足现实需要。除此以外，使用现实情况中的角色定义符合普遍认知，避免“语言障碍”。

2. 最大化满足个性化需要

需要进行权限管理的系统，所涉及的业务特点、人员管理差异常常比较大，情况复杂，尽可能满足个性化配置可以兼容各种现实情况。

作者：厚厚（微信公众号：厚厚的语和文），多年互联网和传统企业的跨界产品经理。

本文由 @厚厚 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议