SaaS系统权限体系设计

Posted 2023-02-08 zero13_小葵司

权限系统是系统中链接用户与功能的关键桥梁，也是实际业务中组织角色及其职权的映射，不同的组织会需要不同的权限系统，但是作为SaaS我们需要考虑到灵活的配置、系统复杂度等综合情况。

权限情况是否能满足业务，是判断该系统价值度的一个重要标尺，如何在灵活与标准化、复杂度之间去平衡设计，就变得关键起来。

权限管理系统的设计中常遇到的问题有：

• 配置不规范，系统基础不稳，拓展性差；

• 配置不灵活，用户需求难满足，体验差；

• 配置太灵活，逻辑会复杂，实施成本高；

目录

• 基本要素
  • 主体
  • 客体
  • 行为
  • 机制
• 设计
  • 用户
  • 角色
  • 角色组、角色层级
  • 客体
  • 行为
  • 组织
• RESTFul接口设计与资源
• 数据权限
  • 数据客体的控制范围
    • obj_metadata

基本要素

主体

发起行为的一方，通常为用户（也可能是系统或机器人，未来我们进入CIE、RPA领域时，这件事可能是系统本身便是主体）

• 用户（组）：用户代表一个系统使用者，用户组代表一组规则打包在一起的用户，目前系统我们可以将用户组用户租户隔离，即用户会先有组。
• 角色（组）：角色及角色组会直接与权限产生关系，而角色组用于打包角色使配置更便捷，短期可暂不引入该概念。
  角色分为：功能角色、职责角色、数据角色
  角色组：组织、角色层级
• 标签（组）：通过一些标签或标签组进行权限控制，可以作为灵活的补充
• 其它：IP、设备类型、应用类型等

客体

行为的受体，内容的载体，一个主体操作的内容便是客体

• 资源：数据（行，列 - 需要业务系统能支持）
• 载体：菜单、页面、功能按钮、tab、推送消息
• 操作资源的条件：审批节点（根据资源状态将资源分配给不同主体），所属权（个人、部门、部门及下属、全部等）

行为

增删改查下载上传审批，是不是简单粗暴？

机制

机制涉及到角色与权限之间的关系，包括继承、互斥、授权、双向认证、共享、范围控制、先决条件等

• 继承：一个角色拥有其它一些角色的权限，如部门负责人的角色集成其部门所有角色，直接拥有该部门所有角色权限，也可通过角色组在这里使职责角色与功能角色不挂钩，但是常会有通过职责角色关联功能角色，使简化操作；
• 互斥：拥有该角色的用户，不可拥有另一个或多个特定角色，可以将这几个角色打包为一个组，标记该组内角色互斥，或直接为角色配置与哪些角色互斥，采用何种方案视具体情况而定；
• 授权：一个人可以将自己所具有的权限授予另一人，该授权范围不得大于授权人权限范围；
• 双向认证：主体携带了角色权限信息，而客体也标识了具体的角色权限信息，双向认证通过后方可进行后续操作；
• 共享：某用户可以将自己的角色权限共享给另一用户；
• 范围控制：一般用于数据权限控制，常见的有 仅可见自己的数据、可见部门的数据、可见下属的数据等，与组织架构结合比较常见；
• 先决条件：要获得某角色必须先获得另一个角色，通常为了严格控制会使要获得某上级角色，必须先获得其下级角色；

设计

用户

用户可以拥有：角色、角色组、组织

在较复杂组织中，我们可以将用户与角色组关联（见下一节角色组、角色层级、组织），角色组变相可以包含这个用户在组织内行使的所有职能，如财务部负责人，当用户获得该角色组时，便赋予了其组织架构角色以及其所对应的所有角色、权限，而当期岗位职责变更为HR负责人时，其失去财务部负责人这个角色组，获得HR负责人角色组，便直接实现了所有角色、权限的变更。

角色

角色是一组权限的组合，正如上一章提到，我们将角色再做细分为功能角色、数据角色、职责角色、其它角色（补充）

功能角色：我们最常见的角色，如菜单是否显示、某个按钮有没有、这个接口能否调用；

数据角色：定义一个角色对一组数据的访问权限，这会比功能权限控制复杂，因为必须要数据结构以及接口支持，如数据角色：自己门店指标任务数据，那么一个拥有该数据角色且属于该门店的用户，就能且只能查看其对应的门店指标任务数据，这需要指标任务数据暴露的接口能根据门店进行查询，接口识别到有数据权限控制时，校验数据权限，这里就有不止一种处理方式了，一种是接口定义查询我的门店任务，此时接口传参不带店铺ID，根据用户信息由系统自己查询店铺；还有一种是接口带店铺ID，此时识别到店铺ID为权限控制关键字段，便需要校验用户是否具有该店铺权限，没有便返回无对应权限；

职责角色：我们可以将职责角色集成多个功能角色、数据角色以及职责角色，并在命名上对业务友好，这会类似于角色组了；

角色组、角色层级

角色组：包含哪些角色；

角色层级：一个角色组其上级角色组与下级角色组；

组织架构：当角色层级形成时，其组织架构也就形成了，在角色层级之间我们需要去考虑是否有范围控制与先决条件；

NOTE：这里会涉及到角色权限以外的客体，如部门，部门是部门，是业务中实际存在的，而角色层级与组织架构某个角度是虚拟的，不要用实际的部门去强绑定这里提到的组织架构（当然也有单独维护组织架构而与角色权限无关的做法）。一个数据属于某个部门或多个部门，在数据权限上能否查看，即要看数据归属，也要看数据属性，但是外部访问都要通过接口调用，我们做系统的分层就使得我们的系统有了重新组织加工数据的能力，理论上数据怎么存是接口调用方不需要关注的。

客体

客体往往与前端息息相关，我们在做角色权限时，一定要考虑前端的集成实现，不然及时后端做了拦截，但是前端大开大合，或者修改起来代价很大，那么这也不是我们要的。

行为

基本操作：

审批流程：审批流程每一条都是一个独特的业务逻辑，其在业务节点中对于原有角色、权限、组织结构可能有关联也可能有特殊性，在这里我们一定不要用一套规则就绑死。

组织

组织是真实存在的部门及部门间的结构（扁平、层级等），不同的公司会有不同的组织架构设计，曾经看过一篇文章，叫100种组织架构设计，所以这个看似简单的东西，在不同的公司其实千差万别。

RESTFul接口设计与资源

角色与权限的设计指向的便是主体、客体、行为，而RESTFul的接口设计也是指向资源与操作行为的，某个角度两者能很好地契合，我们可以在管理平台（或统一权限中心维护数据），在网关缓存对应的客体与行为所需的权限，而登录用户请求时会携带主体信息，根据主体信息与接口控制匹配，实现对资源操作行为的控制。

数据权限

数据权限的控制会涉及到的客体便是数据，而对数据的权限控制，我们可以在两层来做：

• 接口层
• 数据访问层

当然这都需要我们对数据客体的设计，这里的设计还需要考虑不要因为权限控制而对原本的业务系统有大的影响，即有些业务数据的产生，不一定需要这么多的控制，或在数据产生及使用过程中，添加过多不必要的逻辑只会平白增加复杂度，没有必要。

但是数据也一定是有归属的，属于哪个组织哪个用户，如果没有这个归属信息，我们便无法知道该用户到底能不能基于范围操作数据。

标准数据体

GroupId	OrgId	Uid	data1	data2	dataxxx	creator	created	updated
归属租户ID	归属部门ID	归属用户ID				创建人	创建时间	更新时间

自定义数据体

标准数据体主要用于应对已相对固定的标准化数据，但是一套系统同样会面对一些新兴业务，如果我们采用一些低代码手段来实现这些业务，不会频繁新增新的库表来适配这些业务，因此我们需要系统能存在这些自定义数据体，而自定义数据体也需要进行数据权限的控制，因此我们该如何来设计这些自定义数据体呢？

GroupId	OrgId	UId	ObjId	key	value
归属租户ID	归属部门ID	归属用户ID

基于上面的考量，我们就在数据的上面增加一层保护网，让需要保护的通过该保护网，不需要保护的直接通过即可。

数据客体的控制范围

• 数据对象（这个数据我能不能看）
• 数据行（只能看我自己的，还是能看部门的，还是能看所有的）
• 数据列（能看到销售额，但是不能看成本）

最理想的情况当然是自由的组合，但是所有自由组合的背后都会有代价与复杂度。

我们的设计关键是数据数据权限中，该角色能访问哪些数据，因此会有一个数据资产的维护记录，比如我们称其为obj_metadata，数据资产便在这里进行管理，权限与数据资产的关系便基于此去建立。

obj_metadata

GroupId	ObjId	Col

关于几张表：

1. 用户
2. 用户与用户组
3. 角色
4. 角色组及角色层级（含相互关系）
5. 用户与角色关系
6. 用户与角色组关系
7. 权限
8. 角色与权限关系
9. 权限间关系

审批流：

1. 审批流通常与用户及用户组相关，具体视业务而定，但是经典的审批流系统中基本是基于此。