权限管理设计总结

权限设置一定要根据具体情况进行设计，不要千篇一律，更不要化简为繁，像继承，多角色等，目前我们公司没有，一个用户只有一个角色，管理起来很方便；而数据权限又是完全独立一套设计，基本思路也大差不差的！

权限系统设计的需求背景

业务流程复杂化：

随着业务越来越复杂，之前一个订单只需要一名销售跟进，现在却需要五个销售协同完成一个订单的流程（每个销售负责其中一个流程）；此时我们就可以通过权限系统，分别赋予五个销售处理各自流程的权限（比如销售A只有录入意向订单的权限，销售B只有补充客户信息的权限，等等），这样每个销售都只能看到流转至自己手上的信息，将复杂的流程简单化。

信息敏感：

也就是数据敏感，当同级部门不止一个时，便会在同一公司内产生竞争关系。例如，销售1组辛苦挖掘的用户数据并不想被销售2组看到；权限系统可以设置不同部门的数据彼此独立，即便是各组组长也无法互看对方数据。

操作安全，权责明确：

在一个大型系统中，一个误操作产生的后果可能是非常严重的；权限系统的存在最大程度上避免了这些，只要是界面上出现的功能，都是可以操作或不会产生严重后果的。

页面简洁：

如果系统没有进行权限管理，那么每个帐号登录后看到的界面都是一样的，充斥着各种与自己无关的，冗余的信息，甚至还需要专门培训，花费巨大的成本去学习；经过权限系统的管理，每个帐号登陆后只能看到和自己有关的信息，可以更快速地理解自己工作范围内的业务。

权限系统的基本构成

权限系统主要由三个要素构成：帐号，角色，权限。

帐号是登录系统的唯一身份识别，一个账号代表一个用户。由自己注册或系统管理员统一注册分配。

角色，为账号批量分配权限。在一个系统中，不可能为每个帐号订制权限，所以给同一类帐号赋予一个“角色”，以达到批量分配权限的目的。

权限又分为操作权限，页面权限和数据权限。其中操作权限指的是用户可以进行的操作，例如是否可以新增、删除、编辑等。页面权限指的是可以看到的页面。数据权限指的是可以查看数据的范围。

权限设计思路

在此直接引用网易里的一篇文章，讲解的非常详细，原网址

设计师在进行设计时，常常会抽象出对产品有诉求的多个角色，再依据角色的特性去梳理使用场景并设计。

当角色之间的使用场景不冲突，不需要隔离时，我们会综合考虑这些角色的使用场景来设计解决方案：比如网易云音乐同时为需要听歌和听电台的用户提供所有的功能；

当这些角色的使用场景完全不重叠、流程对立时，我们会设计完全独立的两套系统，如滴滴的司机端和乘客端；

但除了以上两种情况，在大多数B端产品中，基于流程公正性、信息安全性等因素考虑，各个角色的使用场景是部分通用，部分隔离的，这时候就需要引入“权限系统”了。

基于技术模型进行设计-RBAC模型

在业界接受度较高的功能权限模型是RBAC（Role-Based Access Control）模型，其基本理念是将“角色”这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。

1. 基本的RBAC模型

如果没有角色的概念，系统中每加入一个用户，就需要为这个用户配置一遍权限，下图是wiki中直接为用户权限管理方式，可以看出管理成本巨大。

而引入“角色”概念后，如下图即是RBAC模型中最基本的模型：用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。

此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性。

2. 引入用户组概念的RBAC模型

在大型平台的应用上，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入用户组的概念：如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，基于这个组的对象进行角色和权限的赋予。

同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的，所以实际应用中对权限组的使用较少。

3. 角色继承的RBAC模型

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

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

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

4. 限制的RBAC模型

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

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

 

 权限的拆分与设计

通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？这些都需要分析清楚才能进一步设计出完善的权限系统。

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

 

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

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

1. 确定是否支持前端配置

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

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

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

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

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

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

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

4. 查看权限优先于增删改权限

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

5. 角色与权限的多种关系

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

• 数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；

• 数据边界限制（上限等）：添加人员时不能超过20个等。

• 数据字段：HR能查看人员列表中包括职级、薪资等字段；其它角色仅能查看姓名邮箱等字段；

6. 角色与权限的设计表达

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

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

最后注意事项和节点

1. 隐形的admin

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

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

2. 初始权限的赋予

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

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

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

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

4. 无页面权限的提示

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

5.节点包括：

• 用户

• 用户组

• 角色

• 角色组

• 权限（页面、操作、数据）

• 权限组（页面、操作、数据）

关系包括：

• 是/否关系

• 继承关系

• 限制关系（互斥、范围限制、边界限制、字段限制……）

• ……