网易UEDC – 蒋蕊遥 ：文章结合自己的几次权限设计经历，提供一些所谓的经验套路，希望各位设计师从此微笑迎接权限需求。
一、令人头疼的权限设计
设计师在进行设计时，常常会抽象出对产品有诉求的多个角色，再依据角色的特性去梳理使用场景并设计。
当角色之间的使用场景不冲突，不需要隔离时，我们会综合考虑这些角色的使用场景来设计解决方案。比如：网易云音乐同时为需要听歌和听电台的用户，提供所有的功能。
当这些角色的使用场景完全不重叠、流程对立时，我们会设计完全独立的两套系统，如滴滴的司机端和乘客端。
但除了以上两种情况，在大多数 B 端产品中，基于流程公正性、信息安全性等因素考虑，各个角色的使用场景是部分通用，部分隔离的，这时候就需要引入「权限系统」了。
设计师有时会对角色权限系统有一丝畏难情绪。
- 一方面因为角色权限系统的配置作为一个非常后台的管理功能，在竞品调研过程中很难通过上帝视角去解剖其中逻辑，自己琢磨又较难透彻；
- 另一方面对于角色权限系统，做好了并不能代表设计能力有多优秀，但一旦没做好就会导致整个流程不通、产品崩溃。所以设计师常对权限系统望而却步。
以下就笔者的几次权限设计经历，提供一些所谓的经验套路。
二、基于技术模型进行设计-RBAC模型
进行设计前，最好能够理解技术模型。在业界接受度较高的功能权限模型是 RBAC（Role-Based Access Control）模型，其基本理念是将「角色」这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。以下就模型与设计相关的几点做一下简单介绍。
1. 基本的RBAC模型
如果没有角色的概念，系统中每加入一个用户，就需要为这个用户配置一遍权限，下图是 wiki 中直接为用户权限管理方式，可以看出管理成本巨大。
而引入「角色」概念后，如下图即是 RBAC 模型中最基本的模型：用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。
此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性。
2. 引入用户组概念的RBAC模型
在大型平台的应用上，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入用户组的概念。如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，基于这个组的对象进行角色和权限的赋予。
同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的，所以实际应用中对权限组的使用较少。
下图所示为 mac 系统中运行添加用户组，并以用户组为单位配置权限。
需要注意的是即使有用户组或权限组的存在，也可以允许用户或权限与角色直接关联，这个可以视具体业务情况而定。
3. 角色继承的RBAC模型
在一个业务场景中，如果角色需区分：设计主管、设计组长、设计成员，并且管理方式为向下兼容时，则需使用角色继承的 RBAC 模型。上层角色继承下层角色的全部权限，且可额外赋予权限。
此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图。
继承关系常常来源于公司团队的组织结构，此时常将角色与组织结构进行关联达到继承角色模型的效果。如下图所示的赵同学，其角色是「三级团队负责人」，与其并列的小组中有多个「三级团队负责人」的角色，但依附于左侧的组织结构树，各级负责人仅有查看和操作自己下属子节点的权限。
4. 限制的RBAC模型
在一个产品或系统中，部分角色可能是需要隔离的、不允许被同时赋予一个人的。跟大家熟知的不能既是「运动员」又是「裁判员」一个道理。
因此，对于众多角色中的一组，只能是单选的关系，但多组角色之间可以共同存在。如下图中，一个用户可以既为设计师又为管理员，但在设计师角色组中仅能被赋予一个角色，在管理员角色组中也仅能被赋予一个角色。
此外，限制还有可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。
限制的模型不仅仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。
根据不同的业务需求，限制的形式很多。需要注意的是不能仅依赖后端限制，而是要在前端展示清晰的规则和恰当的限制，避免用户出错和沮丧。
三、权限的拆分与设计
通过 RBAC 模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系，以及「权限」这个抽象的概念具体如何规划？
这些都需要分析清楚才能进一步设计出完善的权限系统。
首先需要知道，一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。数据可被增删改查。
整体关系如下图所示：
因此，在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个操作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分操作和数据后，页面和流程仍能体验流畅。
保证初期设计支持后，配置权限时，还需要注意以下几点：
1. 确定是否支持前端配置
如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线。这种情况适用于公司内部系统等只有一个使用主体的系统。
如果需要自定义角色或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在「前端用户配置页面」。这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。
2. 以基本单元拆分，以业务逻辑配置
一般可将每个对象的「增、删、改、查」各自作为一个基本的权限单元。打个比方，在「人员管理」中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。
但是在业务层面有些操作却是一体的。这些不能拆开的权限在「前端用户配置页面」中建议打包成一个整体提供配置。例如：如果我们确定在系统的现有和未来业务中，仅分为普通成员有「人员管理」的查看权限，管理员有操作权限，则可将「增、删、改」三个基本权限单位合并为「操作」权限进行配置。
3. 页面权限优先于操作和数据权限
必须配置了页面模块权限后，才能配置当前页面模块下具体的操作权限，以及页面模块的数据展示权限。
4. 查看权限优先于增删改权限
正常情况下，一定要先能查看某个模块或操作，其它的增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置，或者配置其它权限时默认赋予查看权限。
5. 角色与权限的多种关系
角色与权限的关系不仅是单纯「是/否关系」，还包括以某种限制进行操作，和以某种程度访问数据。
例如在「人员管理」中：
- 数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；
- 数据边界限制（上限等）：添加人员时