用户角色权限设计

最近做B端项目遇到的关于用户角色权限的问题，该类问题也是做B端产品必须要吃透的知识点，它是整个系统的基础底层设计，也是核心。在项目开发阶段，是开发人员需要优先开发的功能点，因为其他核心业务功能点都会围绕着角色、权限进行展开。

什么是用户角色权限设计？

在一个较为复杂的系统中，每个用户(帐号)经常会扮演一个或多个角色，不同的角色拥有不同的权限。这样就可以明确用户在系统中能做什么，简单来说就是什么样的用户，什么事情可以做，什么事情不可以做。其意义在于，让管理员能够基于系统的安全规则和业务场景的策略对非管理员用户的权限进行控制；对于非管理员用户来讲，角色权限的设计可以降低操作风险，让自己仅专注自己的工作范围。

ACL模型

ACL模型（Access Control List），该模型的核心机制是“资源”，每一项资源都有一个列表，每个列表都对应着哪些用户可以操作该资源。

应用到角色权限设计中，我们可以把“资源”理解为权限。那么，在ACL权限模型中，就有了用户和权限两大要素。这是一个最为基础的角色权限设计，围绕着【用户 – 权限】两个维度进行，需要为每一个用户单独配置权限，同时，也有可能一个用户拥有多个权限的情况。

该模型适用于用户体量较小，系统功能简单，用户直接对应到具体的功能点即可。

RBAC模型

RBAC模型（ Role-Based Access Control ）， 基于角色的权限访问控制。该模型的核心思想是新增角色概念，每一个角色对应相关的权限，然后将角色赋予到具体的用户。此时，角色充当了一个中间介质，也可以理解为“桥”，使得用户与权限的配置更加灵活便利。

与ACL模型相比，该模型的优点是，不必每次新增用户的时候都为其分配权限，只需给新增用户赋予相应的角色即可。

RBAC0模型：用户、角色、权限多对多关系

在RBAC0模型中，可以赋予每个用户多个角色，也可以给每个角色配置多个权限，即用户、角色、权限多对多关系。需要说明的是，原则理论上是这样，但在实际应用中一般不会出现这么“混乱”的情况，否则就会新增太多麻烦。

回归现实。在实际业务场景中，公司会安排一人多岗的情况，此时一个人扮演多个角色，拥有多个权限是真实存在的。当时有人提议新增角色，把两个角色的权限融合成一个角色。那么，就造成了系统中角色冗余，权限分布模糊，无形中就增加了使用的复杂度。

RBAC1模型：基于RBAC0添加角色等级

在RBAC0模型的基础上，RBAC1新增了角色等级这个概念，角色之间存在上下级的关系。等级不同，权限也不同。角色等级低，所配置的权限也就越少，高等级包含所有低等级的权限，通过这种方式可以实现颗粒度更细的角色权限管理。

Tips：换个角度来理解，RBAC1的模型也可以说是一种角色权限继承的概念。子角色继承了父角色的权限，但是子角色的权限一定是要少于父角色的权限。

RBAC2模型：基于RBAC0添加角色限制规则

没有规则，不成方圆。在RBAC2模型中，角色配置权限，用户赋予角色，都需要遵循一些限制规则。这些常见的规则包括：

① 角色互斥：一个用户只能赋予一组互斥角色中的一个角色。例，申请相关角色和审批相关角色，用户只能被赋予其中一个角色，不应该是自己的申请自己去审批，这是矛盾的。应用到系统中，该规则可以体现出职责分离的作用。

② 基数约束：a、单个角色的用户数限制，如，超级管理员只能有一个；b、单个用户赋予的角色数限制；c、单个角色所配置的权限数量限制。

③ 先决条件：角色等级的条件限制，在RBAC1的基础上做限制规则，想要获得高级权限，必须要拥有限制范围内的低级权限。

实际项目中用户角色权限设计流程

1、整理权限

本质上来讲，权限就是用户能够访问到资源，这里的资源可以是一个页面、一个菜单、一个操作按钮、一条数据信息。对权限进行分类整理，可分为：页面权限、操作权限、数据权限。

页面权限主要是对用户的导航/菜单进行控制；

操作权限则是控制菜单下的功能按钮；

数据权限较为灵活，平台系统的业务差异决定了数据权限的划分方式，但一般来讲可根据组织进行划分，如系统中的区域范围、组织结构、项目类别等等。落地到每一个用户上，就实现了同一页面不同的用户看到的数据信息不一样。

Tips：上述数据权限中提到的“组织”，实际就是将有同类数据权限诉求的用户进行归类整理，也可以理解为分组。如，部门就是非常典型的一个分组思想，A部门只能看到A部门及其子部门的数据信息，B部门只能看到B部门的数据信息，它看不到A部门的数据信息。

2、整理角色

整理角色，可根据公司的组织架构和业务架构来进行整理。

根据公司组织架构整理，实际就是根据岗位进行划分角色，在这种情况下，岗位和实际工作职责有着很密切的关系。该整理方式适合大多数系统，也是较为简便的一种角色划分。

根据业务架构整理，需要弄清楚各个角色在整个系统的业务流程，他们分别需要做什么操作，完成什么任务。该整理方式适合系统中较为特殊的角色划分，如某项工作任务需要特定的人来完成，那么就可以根据工作任务的情况来整理出角色。

Tips：超级管理员这个角色概念是每个系统中必须安排的，用于对整个系统进行初始配置，管理维护。（我更喜欢将超级管理员定义为一种角色概念，它并不能算是一个角色，更多的是承载了系统中一个全面的配置。它也可以不叫超级管理员，可以叫管理员，也可以叫系统维护员，等等。因为它只是系统中必不可少的一个功能模块。）

在一些复杂的系统中，还会存在一些固定且通用的角色类型。如何理解？就是这类角色可以有，也可以没有；如果有，那就是锦上添花，如果没有，系统照样可以正常使用。

基础角色：拥有较为基础通用的权限，适用于刚刚注册的新人用户，后续可根据情况对角色进行升级。

临时角色：角色拥有时效性，适用于使用系统的临时用户，如外援用户、跨部门协作等等。

Tips：为方便角色管理，建议添加一个角色黑白名单。向上，可以给角色拓展权限；向下，可以控制角色权限。

3、用户、角色、权限连接方法

用户赋予相应的角色，这一点很好理解，在系统中每一个用户会充当一个或者多个角色去完成某项工作任务。这一步完成后，我们可以将用户和角色视为一个整体。然后再去分析，用户(角色)在什么页面完成某项任务，这一步可以确定所需的页面权限。往下走，完成某项任务，用户(角色)需要做什么，此时就会产生行为，那么就会牵引出所需的操作权限。

通过此方法进行穷举，我们可以整理出用户(角色)所需的权限，并且形成对应的连接关系。

总结

在中后台系统设计中，权限模块关注度并不是那么高，产品设计者更加注重业务模块的设计。在较为复杂的系统中，权限模块可以有条不紊的管理好用户，并对其任务进行分工，减少操作风险；对于管理者来讲，也能更好的管理。

RBAC模型是权限设计的核心思想，实际项目中会出现非常复杂的场景，但万变不离其宗，结合具体需求进行分析即可。