产品设计中基于角色的权限体系

限制角色
在一个产品或系统中，部分角色可 能是需要隔离的、不允许被同时赋 予一个人的。跟大家熟知的“不能 既是‘运动员’又是‘裁判员’ ” 一个道理。 因此，对于众多角色中的一组，只 能是单选的关系，但多组角色之间 可以共同存在。如下图中，一个用 户可以既为设计师又为管理员，但 在设计师角色组中仅能被赋予一个 角色，在管理员角色组中也仅能被 赋予一个角色。
在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个操作都最好使 用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分操作和数据后，页面和流程仍能体验流畅。保证初期设计支 持后，配置权限时，还需要注意以下几点：
确定是否支持前段配置
如果角色和权限相对固定，则一般将角色
Super
ADMIN
超级管理员
有的系统中允许存在上帝视 角的admin角色，则其可以 作为“超级管理员”显示在 角色配置的列表中。有的系 统中不允许这种角色存在， 则可将这种角色设置为隐形 的状态，仅赋予维护系统的 工作人员。
初始权限赋予
对于允许用户自行加入的系统，需要设定一至多个默认的 角色，有时可以是仅有最基础权限的“游客”角色。
团队；
•数据边界限制（上限等）：添加
人员时不能超过20个等。
•数据字段：HR能查看人员列表中
包括职级、薪资等字段，其它角色
仅能查看姓名邮箱等字段；
角色与权限的设计表达
6
在传达一个系统的权限设计规则时，
设计师常常习惯用主观最直接的方
式 表 达 想 法 ， 如 用 “ 当 …… 时 ，
就……”的句式来表达。但一个平台
中涉及的权限规则是非常多的，当
通篇以这样的形式描述时，表达对
象将很难理解。
正确的描述方式
更清晰的是基于开发的语 言，和技术模型的结果进 行表达。将各角色与权限 单元绘制成网格，每个交 叉点网格中描述该角色与 权限的数据关系和限制。
04
Admin
在可自定义角色和权限的系统 中，一般需要预留一个admin 角色来进行系统的初始配置， 用于添加首批的业务人员和配 置基本的角色。
基本单元拆分业务逻辑配置
页面权限先于操作和数据权限
可将每个对象的“增、删、改、查”各自
2
作为一个基本的权限单元。比方在“人员 管理”中，看人员列表、添加人员、删除
必须配置了页面模块权限后，才能配置当前
3
页面模块下具体的操作权限，以及页面模块 的数据展示权限
人员、编辑人员信息拆分为4个权限单元。
设计上，希望能尽量做到解耦和模块化。
但在业务层有些操作是一体的。不能拆开
的权限在“前端用户配置页面”中建议打
包成一个整体提供配置。例：如我们确定
在系统现有和未来业务中，仅为普通成员
有“人员管理”的查看权限，管理员有操
作权限，则可将“增、删、改”三个基本
权限单位合并为“操作”权限进行配置。
查看权限优先于增删改权限
4
正常情况下，一定要先能查看某个
关系包括
——是/否关系； ——继承关系； ——限制关系（互斥、范 围限制、边界限制、字段 限制……）； ——……
1
与权限的关系可以写在后台，改动时需要 后端变更且重新上线。这种情况适用于公
司内部系统等只有一个使用主体的系统。
如果需要自定义角色或者每个角色在不同
使用者的场景下有不同的权限，则需要将
角色的定义、角色与权限之间的配置体现
在“前端用户配置页面”。这种情况适用
于有频繁变动的自定义角色权限，和有租
户体系的系统。
03
多种角色
通 过 RBAC 模 型 已 经 能 够 很 好 的 搭 建起用户、角色与权限之间的关系 了。但具体是什么样的关系，以及 “权限”这个抽象的概念具体如何 规划？这些都需要分析清楚才能进 一步设计出完善的权限系统。首先 需要知道，一般产品的权限由页面、 操作和数据构成。页面与操作相互 关联，必须拥有页面权限，才能分 配该页面下对应的操作权限。数据 可被增删改查。
模块或操作，其它的增删改操作才
有意义。因此在设计时，应在获取
查看权限前限制其它权限的配置，
或者配置其它权限时默认赋予查看
权限。
角色与权限的多种关系
5
角色与权限的关系不仅是单纯“是
/否关系”，还包括以某种限制进
行操作，和以某种程度访问数据。
例如在“人员管理”中：
•数据范围：用户拥有查看人员列
表的权限，但仅能查看自己所在的
数量限制
此外，限制还有可能是 数量上的，比如一个产 品组中必须有且只有一 个管理员，不允许删除 或再分配管理员角色， 仅允许将负责人角色变 更。
多种角色
限制的模型不仅仅对分配过程产生 影响，有时即使拥有了多种角色， 因为不同的角色对同一个功能的使 用方式或数据会产生冲突，所以使 用时也需要进行限制。如左图所示 为同一时间仅允许以一个身份登录。 根据不同的业务需求，限制的形式 很多。需要注意的是不能仅依赖后 端限制，而是要在前端展示清晰的 规则和恰当的限制，避免用户出错 和沮丧。
02
用户和角色是多对一关系
即：一个用户只充当一种角色，一种角色可以有多个 用户担当
RBAC0模式
用户-角色-权限，最基础的RBAC模式
用户和角色是多对多关系
即：一个用户可同时充当好几种角色，一种角色可以 有多个用户担当
图一
如图1示，对于左边的用户-角色对应，每个人只能同时拥有一种角色，但是同一个角色里边，可能会含有多个用户（如：张 三和李四都是业务员）；而右边的用户-角色对应，是在左边的基础上，增加了一个用户可拥有多种角色的情况（如：王二 既是经理，也要负责财务的工作）
初始权限还可以与用户既有的某些数据字段进行关联，如 添加用户时获取到用户的岗位为“设计师”，则直接赋予 “设计师”角色的权限。
人员管理中对管理员自身的处理
在人员管理中，管理员角色处理自己时需要额外注意。 因为如果修改或删除了自己角色后，可能导致系统没有 管理角色，从而无法添加其他成员和正常运行。设计时 可添加判断，当自己为唯一管理角色时，禁止编辑和删 除。
01 02 03 04
01
RBAC模式
RBAC（基于角色的权限控制）模型的核心是在用户和权限之间引入了角色的概念。取消 了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地赋予用 户权限，从而达到用户和权限解耦的目的。设计师在进行设计时，常常会抽象出对产品有 诉求的多个角色，再依据角色的特性去梳理使用场景并设计。当角色之间的使用场景不冲 突，不需要隔离时，我们会综合考虑这些角色的使用场景来设计解决方案。比如：网易云 音乐同时为需要听歌和听电台的用户，提供所有的功能。当这些角色的使用场景完全不重 叠、流程对立时，我们会设计完全独立的两套系统，如滴滴的司机端和乘客端。
项目分析
一般公司的业务管理系 统，都有数据私密性的 要求：哪些人可以看到 哪些数据，哪些人不可 以看到哪些数据。这个 时候，我们就需要把这 些东西也考虑到你的权 限体系内了。
案例分析
公司业务部门的组织架构图，公司 要求你基于这个组织架构设计一个 业务管理系统，并要求系统需要满 足不同用户的数据私密性，比如： “张三”登录时，只能看到“张三” 负责的数据；“张三”的领导登录 时 ， 能 看 到 “ 团 队 A” 的 所 有 业 务 员负责的数据，但看不到其他团队 业务员负责的数据等等。我们可以 对其进行一些小改造后，即可达到 数据管控的目的。
RBAC0
RBAC1
基于RBAC0的优化， 增加了角色的分层 （即：子角色），子 角色可以继承父角色 的所有权限
基于RBAC0的另一种 优化，增加了对角色 的一些限制：角色互 斥、角色容量等
RBAC2
RBAC3
最复杂也是最全面的 RBAC 模 型 ， 它 在 RBAC0的基础上，将 RBAC1 和 RBAC2 中 的优化部分进行整合
解决方案
在“用户-角色-权限”的基础上，我们增加了用户与组织的关联关 系，组织决定了用户的数据可视权限。但要想真正达到这个效果， 我们还需要做2件事：
数据可视权限规则制定
角色继承
在一个业务场景中，如果角 色需区分：设计主管、设计 组长、设计成员，并且管理 方式为向下兼容时，则需使 用角色继承的RBAC模型。 上层角色继承下层角色的全 部权限，且可额外赋予权限。
用户
角色
权限
1.职能划分严谨
角色的权限调整不仅仅只影响单个用户， 而是会影响关联此角色的所有用户，管 理员下发/回收权限会更为严谨。
2.便于权限管理
无需对每一个用户都进行权限调整，既大幅 提升权限调整的效率，又降低漏调权限的概 率。
这 是 RBAC 的 初 始 形 态，也是最原始、最 简单的RBAC版本
选用多对一 系统的功能比较单一、使用人员较少、 岗位权限相对清晰且不会出现兼岗的 情况，这种情况也可以考虑用多对一 的权限体系。
选用多对多 一般系统尽量选择多对多模式，相对 复杂的权限体系最好选择多对多模式。
用户组
用户
角色
权限
在大型平台的应用上，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨 大，此时即可以引入用户组的概念。如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组， 基于这个组的对象进行角色和权限的赋予。同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将 使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的， 所以实际应用中对权限组的使用较少。
角色关系管理
此时除了对角色进行定义，还 需要管理角色间的关系，通过 关系来体现角色的层级关系， 从而达到继承权限的效果。角 色的继承关系主要有两种：树 形图和有向无环图。