系统权限功能的设计

Posted 2023-04-20

参考技术A     几乎所有的管理后台都会涉及到权限的设计，权限控制是管理后台的重要功能，可以有效的提高系统的安全性，减少误操作、数据泄漏等风险的发生。但是，很多产品经理会对权限功能有一点害怕的心理，一方面是由于能参考的实例较少，权限管理算是一个“系统级”的基础功能，一般系统中只有管理员可以操作，不像其他功能可以通过去其他系统中试用体验，另一方面，对于权限功能普通用户无法操作使用，所以存在感较低，做好了也不会出彩，可没做好就会导致整个流程不通、产品崩溃。

一 RBAC 模型

    目前，接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。

1.角色的作用

如果没有角色的概念，直接用户对应权限，虽然会更加灵活，但是后台的数据表设计会变得复杂，操作成本也会很高，同时容错能力也会变得很差。

而引入“角色”概念后，用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性，同时整个设计的容错能力也提高了很多。

2.引入用户组

   一些大型的平台上，如果用户数量较大，新增角色时，需要为大量用户分配新的角色，工作量巨大，此时可以引入用户组的概念，将这些用户拉到同一个用户组中，然后对整个用户组进行角色的指定，这就大大减少了角色分配的工作量。

同理如果权限较多时也会存在一样的问题，对角色进行权限设置时也需要大量的操作，此时可以考虑引入权限组的概念，将关联性较强的权限大包成组赋予角色，从而减少赋值时的工作量，现实中权限组的使用相对较少，因为系统中的权限一般来讲是有限的。需要注意的是即使有用户组或权限组的存在，也可以允许用户或权限与角色直接关联，这个可以视具体业务情况而定。

下图所示为mac系统中运行添加用户组，并以用户组为单位配置权限。

3. 角色继承的RBAC模型

在一个业务场景中，如果角色需区分：设计主管、设计组长、设计成员，并且管理方式为向下兼容时，则需使用角色继承的RBAC模型。上层角色继承下层角色的全部权限，且可额外赋予权限。

此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图。

继承关系常常来源于公司团队的组织结构，此时常将角色与组织结构进行关联达到继承角色模型的效果。如下图所示的赵同学，其角色是“三级团队负责人”，与其并列的小组中有多个“三级团队负责人”的角色，但依附于左侧的组织结构树，各级负责人仅有查看和操作自己下属子节点的权限。

4. 限制的RBAC模型

在一个产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的。跟大家熟知的“不能既是‘运动员’又是‘裁判员’ ”一个道理。

因此，对于众多角色中的一组，只能是单选的关系，但多组角色之间可以共同存在。如下图中，一个用户可以既为设计师又为管理员，但在设计师角色组中仅能被赋予一个角色，在管理员角色组中也仅能被赋予一个角色。

此外，限制还有可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。

限制的模型不仅仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。

根据不同的业务需求，限制的形式很多。需要注意的是不能仅依赖后端限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错和沮丧。

三、权限的拆分与设计

通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？

这些都需要分析清楚才能进一步设计出完善的权限系统。

首先需要知道，一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。数据可被增删改查。

整体关系如下图所示：

因此，在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个操作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分操作和数据后，页面和流程仍能体验流畅。

保证初期设计支持后，配置权限时，还需要注意以下几点：

（1）确定是否支持前端配置

如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线。这种情况适用于公司内部系统等只有一个使用主体的系统。

如果需要自定义角色或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”。这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。

（2）以基本单元拆分，以业务逻辑配置

一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。

但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有“人员管理”的查看权限，管理员有操作权限，则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。

（3）页面权限优先于操作和数据权限

必须配置了页面模块权限后，才能配置当前页面模块下具体的操作权限，以及页面模块的数据展示权限。

（4）查看权限优先于增删改权限

正常情况下，一定要先能查看某个模块或操作，其它的增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置，或者配置其它权限时默认赋予查看权限。

（5）角色与权限的多种关系

角色与权限的关系不仅是单纯“是/否关系”，还包括以某种限制进行操作，和以某种程度访问数据。

例如在“人员管理”中：

数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；数据边界限制（上限等）：添加人员时不能超过20个等。数据字段：HR能查看人员列表中包括职级、薪资等字段，其它角色仅能查看姓名邮箱等字段；

（6）角色与权限的设计表达

在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。

正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达。将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

如下图所示：

四、需要注意的Tips

1. 隐形的admin

在可自定义角色和权限的系统中，一般需要预留一个admin角色来进行系统的初始配置，用于添加首批的业务人员和配置基本的角色。

有的系统中允许存在上帝视角的admin角色，则其可以作为“超级管理员”显示在角色配置的列表中。有的系统中不允许这种角色存在，则可将这种角色设置为隐形的状态，仅赋予维护系统的工作人员。

2. 初始权限的赋予

对于允许用户自行加入的系统，需要设定一至多个默认的角色，有时可以是仅有最基础权限的“游客”角色。

初始权限还可以与用户既有的某些数据字段进行关联，如添加用户时获取到用户的岗位为“设计师”，则直接赋予“设计师”角色的权限。

3. 人员管理中对自己的处理

在人员管理中，管理员角色处理自己时需要额外注意。因为如果修改或删除了自己角色后，可能导致系统没有管理角色，从而无法添加其他成员和正常运行。设计时可添加判断，当自己为唯一管理角色时，禁止编辑和删除。

4. 无页面权限的提示

虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示，避免用户认为系统bug。

最后

总结一下，整个权限系统设计就是定义各个节点和节点间关系的过程。

节点包括：

用户；用户组；角色；角色组；权限（页面、操作、数据）；权限组（页面、操作、数据）；

关系包括：

是/否关系；继承关系；限制关系（互斥、范围限制、边界限制、字段限制……）

权限设计系统——RBAC

权限设计系统——RBAC

​ 权限系统是针对与用户设计，不同的用户进入拥有不同的身份，而不同的身份则会导致他们能够使用到系统中的功能出现不同。这些功能即需要前端展示时的控制，也需要后端权限的校验。

1. RBAC

​ RBAC（Role-Based Access Control）是一套很成熟的权限设计模型。是一个基于角色所控制的系统，所谓角色，就是用户的身份，整个模型围绕着角色设计。

​ 一种常见的权限设计模型如下图：

​ 将用户和所对应的权限直接关联，这种将用户和权限直接关联的方式看起来很直接。一个用户可以拥有多个权限，而这些权限的信息都储存在用户权限表中，在小规模系统，或者说用户较少时比较便于管理，逐个用户授权，人说较多时，就显得有些麻烦，大部分的用户可能都是拥有者同样的权限，重复性极高。这个时候既可以引入角色。

​ 每一个普通员工有用的权限一定是一样的，部门管理者在权限上可能存在差异，而这一部分人往往是少数。设计以角色为核心的权限系统，可以减少数据库开销的同时，减少使用者的重复工作，这对于使用者是很友好的。RBAC的设计模型如下图：

2. 数据库设计

2.1 部门表(sys_dept，非必须)

​ 部门表主要是用来存放部门的基本信息。

字段	备注
dept_id	部门编号
dept_name	部门名称
pid	部门父id

2.2 用户表(sys_user)

​ 用户表主要用来存放用户的基本信息。

字段	备注
user_id	用户编号
username	用户名
password	密码
dept_id	所在部门编号

2.3 角色表(sys_role)

​ 角色表主要用来存放角色的基本信息。

字段	备注
role_id	角色编号
role_name	角色名称

2.4 权限表(sys_permission)

​ 权限表是用来存系统中包含的权限信息的。

字段	备注
per_id	权限编号
per_name	权限名称
per_nation	权限的标识符

2.5 用户角色表(sys_user_role)

​ 用户角色表是用来存放用户和角色的对应关系，理论上来说，用户和角色应该是一对一的，但是，在实际的生产环境中，一个用户往往有多个角色，即兼任。

字段	备注
user_id	用户编号
role_id	角色编号

2.6 角色权限表(sys_role_permission)

​ 角色权限表是用来存放角色和权限的对应关系，该表中，角色和权限应该是一对多的关系。

字段	备注
role_id	角色编号
per_id	权限编号

3. 拓展

​ 当然，一个权限系统一定不能只有已上几张表，为了实现菜单的动态化，需要补充三张表，补充后的结构如下：

3.1 菜单表

​ 菜单表是用来存放菜单的基本信息。

字段	备注
menu_id	菜单编号
menu_name	菜单名称
url	菜单所指向的地址
type	菜单的类型（包括目录、菜单以及按钮）
icon	菜单的图表
pid	菜单的父id

3.2 角色菜单表

​ 角色菜单表是用来存放角色所拥有的的菜单。

字段	备注
role_id	角色编号
menu_id	菜单编号

3.3 菜单权限表

​ 菜单权限表用来存放菜单的权限。为了能够控制菜单的动态显示、访问，所以给每一个菜单也设计了权限，这样看起来有些臃肿，一种简化方式是将菜单权限表省略，然后在菜单表中添加 permission 字段，代表改菜单所需要的的权限。

字段	备注
menu_id	菜单编号
per_id	权限编号