角色权限设计

角色权限设计

• • 一 ·RBAC模型
  • 1.基本的RBAC模型
  • 2.引入用户组概念的RBAC模型
  • 3. 角色继承的RBAC模型
  • 4. 限制的RBAC模型
  • 二·权限的拆分与设计
  • 三·需要注意的Tips
  • 四·通用权限控制系统示例

 

一 ·RBAC模型

1.基本的RBAC模型

RBAC(Role-Base Access Control,基于角色的访问控制)，就是用户通过角色和权限进行关联。简单的说，一个用户拥有多个角色，一个角色拥有多个权限。这样，就构成“用户-角色-权限”的授权模型。在这个模型中，用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。

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

在大型平台的应用上，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入用户组的概念。如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，基于这个组的对象进行角色和权限的赋予。
同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的，所以实际应用中对权限组的使用较少。

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。

四·通用权限控制系统示例

1.人员不复杂、中小型企业

2.人员组织复杂、大型的系统