后台产品设计系列：单系统与多系统的用户权限设计（五）

2018-11-10 09:56:00

上篇，给大家介绍了后台产品比较通用的五个原型设计要点，此篇，笔者将介绍后台产品另一个通用设计——用户权限设计。

由于保密、体验、安全等多种因素，用户权限设计成为每个后台产品的必备功能。那么作为产品经理，面对不同复杂度的系统，又该如何来做呢？
目前，用户权限设计最主流的方式是基于RBAC模型的用户、角色、权限的设计，这种基于角色的权限设计能够非常灵活、高效，并应对更多场景的需求。不过，虽然理论基础一样，单系统的用户权限与多系统的用户权限在实际产品设计中，却存在较大差异。
本篇，笔者将分享基于RBAC模型的单系统权限设计和在此基础上拓展的多系统权限设计。

一、RBAC模型概述

1. RBAC是什么

RBAC模型：Role-Based Access Control，基于角色的访问控制。
名称有点拗口，具体怎么理解呢？
重点就是这个角色。举个栗子：小王是名财务，能够审批报销单和发工资。在这个场景里，“小王”就是“用户”，“财务”就是“角色”，“审批报销单和发工资”就是“权限”，在没有引入“角色”前，权限都是直接指给用户的，就是“小王能够审批报销单和发工资”，那么这里就有问题了。

到底什么样的人才能审批报销单和发工资呢？我们需要做一个归类，比如把这一批人归为财务，把那一批人归为领导亲戚，就是把拥有同样权限的人设定一个“角色”，进行归类。
如果没有角色，那么拥有同样权限的人就得每个都配一遍，有人员流动时又要再配一次，很麻烦。引入“角色”后，我们把权限指派给“角色”，这样在配权限时，只需要将“用户”关联上角色就可以了。

通过下图连线条数就可以看出哪种方式更简单：

整个RBAC的核心就是这个。那么根据这套模型功能的复杂程度不同，由简单到复杂又可以分为RBAC-0、RBAC-1、RBAC-2、RBAC-3四个层级。

2. RBAC的四大模型

RBAC-0

RBAC-0是最基础的，就是在用户与角色、角色与权限间建立关系，每种关系均为多对多。
RBAC-1

RBAC-1是在RBAC-0的基础上，增加了继承关系。就是一个角色只能有另一角色的部分权限，这个角色的权限大小受另一角色权限影响。例如：财务主管有三个权限，那么财务专员的权限一定要小于主管的权限，所以上班就不能扯犊子，只能主管可以。
如果财务主管有需求，我们还应在角色权限配置页面，给财务主管自己配置财务专员的的权限，由财务主管自由设置财务专员的用户是谁、权限有哪些，哪天主管自己一个人扯得无聊，就可以自己偷偷在配置页面给专员也开个“上班扯犊子”权限，然后两个人就可以愉快的互扯了，扯完了再自己手动关掉，美滋滋。
RBAC-2

从上面的例子中，我们可以看到，如果用户、角色、权限完全自由，随意配置，会存在很大风险，领导小舅子既当财务主管，又当老板秘书，财政大权和老板行程全被掌控。于是，老板就规定：任何一个人，“财务主管”与“老板秘书”两个角色只能二选一。
这种权限模式就是我们的RBAC-2，在用户、角色、权限三者间增加各种限制条件，例如每个用户角色最多两种：一个用户不能同时拥有某两个有关联的角色；一个用户同时只能以一种角色身份登录等等。
RBAC-3
RBAC-3是RBAC-1与RBAC-2的结合，就是既有继承关系，又有限制条件，基础都一样。
介绍完理论基础，再来分享这套理论在单系统与多系统中的应用

二、单系统的权限设计

当我们针对一个单一系统做权限设计时，我们需要在系统中将用户、角色、权限三个实体都管理起来，设计对应的配置页面。

1. 用户管理

用户管理模块，主要功能是将此系统用户进行管理，一般而言，系统中需要做用户信息维护的，用户数都比较小，所以不用做太多其他功能，只需维护几个简单字段就可以了。
对于如何创建用户这个问题，需区分不同场景。如果是公司内部使用的系统，不需要做注册功能，直接在系统中由管理员手动新增用户，而用户的账号密码既可按某一指定规则自动生成，也可以手动录入。
根据需求，可选择是否开放用户登录后修改自己密码的权限；而如果是To B的产品，则需要设计注册功能，供免费注册体验等，而注册的用户，则默认为管理员角色，然后由注册用户自己添加其他使用者。

2. 角色管理

角色作为用户与权限的中间方，无法独立存在。角色的定义是完全基于业务需求来确定的，很多时候角色容易与公司组织架构中的职位混淆，然后在角色定义时总想着与公司各职位保持一致。但其实这种强行一致是没有必要的，业务需要定义什么角色，就定义那个角色就好，职位和角色可能有对应关系，但并不相同，也许称呼一样，但分属不同实体管理。

3. 权限管理

按用途来分，权限可以分为数据权限和操作权限。
（1）数据权限
数据权限是指用户是否能够看到某些数据。主要应用在数据有保密要求，或数据量大，需按用户或角色来进行区分时。例如：财务主管在后台可以看到公司所有人的工资流水，但普通员工只能看到自己的工资流水。
在这里，有的同学或许认为，既然我们的权限是跟角色关联，为什么“查看工资流水”这个权限精确到每个用户了呢？
其实这就是RBAC-2的一种，权限与角色关联后增加了限制条件，不过这种限制条件无法在页面上灵活配置。
数据权限的颗粒度由粗到细可以分为菜单级、栏目级、字段级，一般配置页面都可以灵活操作。
（2）操作权限
操作权限是指用户是否能够操作对应按钮。需要先有数据权限，才有操作权限，所以需要增加系统自动校验：

选择了操作权限，就默认勾选了查看（数据）权限；
取消了数据权限，就自动取消了操作权限

以上就是我们做单系统的权限设计分享的内容。在多系统的权限设计中，虽然理论基础一样，但因为涉及到多个系统，所以产生了很多其他问题，需要另外解决。

三、多系统的权限设计

1. 多系统权限设计场景

场景一：多个子系统共属于同一母系统，同时每个子系统已微服务化，代码不耦合；
场景二：多系统各自独立，每个系统都要做用户权限设计，用户都是同一批人，例如都是公司所有员工，这种场景在大公司经常可见。

2. 两种场景下产生的问题

场景一：
Q1：既然每个子系统已分离，那么是针对母系统做一个权限管理模块还是每个子系统分别做一个？如果是针对母系统来做，就意味着这个模块需要跟每个子系统对接，而如果每个子系统做一个，业务上用户、角色会有重复，会导致资源浪费，并让母系统不再像一个整体的产品。
场景二：
Q1：多个系统，用户重合时，用户信息在一处管理还是多处管理？
Q2：一个角色多个系统要用，是否也可以统一管理？例如：项目经理，在不同的系统中，均有此角色，是否可以复用？
Q3：有的角色下的用户能否无需配置，跟职位挂钩，用户入职时录入的用户管理系统就自动在对应系统有了角色？

3. 解决方案

无论是单系统还是多系统，用户权限设计都是围绕用户、角色、权限三者间的关系展开的，只是在多系统中，需要增加考虑的是这三者分别在哪里配置及是否需要跟其他信息关联的问题。
场景一
Q1：针对母系统做一个权限管理模块，一方面对外，母系统才是一个产品，另一方面能节约资源。但是因为子系统间的解耦，我们做的这个权限管理模块也要当做一个小的子系统来做，然后与其他子系统做对接，如果架构组不因此单独给资源，可以做到其中一个子系统中，通过这个子系统控制其他子系统的用户权限。
场景二
Q1：所有用户信息在一处维护。建立一个第三方系统——用户管理系统，单独管理用户信息，跟其他各个系统对接，而角色和权限由各个系统自己管理。这种做法的好处不仅可以节省资源，还可以保证数据的一致性，同时需要引入用户组的概念。用户组可以是同一岗位的用户集合，也可以自定义同一类人的集合，这样在关联用户时，就可以批量操作。
Q2：如果一个角色多个系统共用，是不需要有一个类似用户管理系统那种单独的管理系统的，因为角色无法独立存在，角色必须依赖权限，而权限一定是在各个系统中独自管理，即使共用角色有一个统一管理的地方，在各个系统仍需管理，所以没有这个必要。
Q3：在管理用户时，可以增加“职位”的信息管理，由原来的“用户——角色——权限”变为“用户——职位——角色——权限”，将“职位”与“角色”直接关联，“用户”与“角色”就可以通过“职位”间接关联，每次有新员工入职时，设置好其职位，那么各个系统的角色也就确定了，快速方便。