MASA Auth - 从用户的角度看整体设计

用户

在系统里，用户是一个核心概念。它代表了一个人的唯一身份标识，除了与角色、团队、组织架构等有关，甚至还会影响到在同一个界面不同的用户操作流程与显示内容都会发生变化，再复杂一点的话，或许在同一个系统内的一个用户进入到不同产品后的身份也会变化

用户与角色

用户可以拥有一个或多个角色，让角色作为权限组，将一组或多组权限间接的分配给用户

用户与团队

用户可以在多个团队中，每个团队可以拥有一个或多个角色，将一组或多组权限通过角色与团队关联，并赋予团队内的成员

团队内成员可以是内部的，也可以是外部的。通过统一的用户表作为人的唯一身份标识。再通过 Employee 和 ThirdPartyUser 区分用户身份属性。

用户与组织架构

用户可以被指定在组织架构的某一个节点中

但组织架构是一个虚拟的树形结构，它归属于业务，所以没有与权限直接关联

除此之外，组织架构有时候很难表示角色继承关系。在同一个组织架构节点中的不同成员常常会具有不同的角色，且上下级关系也未必会作为上下级节点紧贴在一起。有部分公司上下级之间可能隔了几个层级

组织架构在我们早期定义中是与权限关联且没有团队这个概念的。但实际上项目制在很多公司内部都存在，以项目制运行时，人员的权限和虚拟组织关系会频繁变化。导致常常要在组织架构调整和大量个人权限微调上做抉择，为了彻底解决这种割裂的行为。我们把组织架构看作虚拟的树形结构来描述每个人的部门归属权，同时采用团队的方式解决项目制下人员频繁进出和四处作战而引发的权限变更问题

用户与权限

用户除了拥有角色以外，可能还存在个别特殊业务下需要临时性授予或禁用部分权限

虽然与 RBAC2 有一点冲突，但事实上这样的场景的确存在，比如即将离职的财务需要临时收回付款功能，这里明显要违背互斥原则，在设计上我们的选择是扩展权限的优先级高于角色内包含的权限。这样可以通过对冲达到收回部分敏感权限的功能

用户类型

用户有三种类型：终端用户，员工，驻场员工

举个例子：

• A 是公司员工，拥有内部权限。同时也是公司产品的终端用户

• B 是驻场员工，拥有部分内部权限。同时也是公司产品的终端用户

用户权限优先级

用户的权限应该具有一定的优先级，来解决同一个业务下多个权限同时生效时系统该选择激活哪一个

我们将采用以下规则：

1. 超级管理员/管理员

2. 超级管理员为系统管理员，管理员为指定项目的管理员

3. 用户的扩展配置权限

4. 用户的角色权限

5. 用户的角色权限冲突时，拒绝优先级高于允许，低于用户的扩展配置权限

6. 团队的默认角色权限

7. 团队中的父级角色权限

8. 将来在团队支持上下级关系后，当前用户没有被分配到权限，且当前团队存在父级时将向上递归查找距离最近的默认角色来获得权限列表

用户权限类型

用户的权限类型大概分为四类

• 菜单：是否可以通过菜单访问某个页面

• 页面元素：是否可以对页面内的元素进行操作，如按钮。页面元素需要挂在菜单下

• 数据：是否显示指定字段。数据需要挂在菜单下

• 数据与页面元素类似，但与页面元素之间相互独立

• API：是否可以访问指定 API。API 一般需要挂在菜单或页面元素下，如有需要也可以挂在数据下

权限层级

总结

至此，我们从一个用户的角度将角色和权限，前端与后端都串联了起来。但到目前为止还是概念的梳理阶段，做好一个权限中心很难。每个团队有自己的管理方式，如何在不同的团队需求中摘取到共同点把主线串联起来，既能满足绝大部分场景需求又留有扩展余地仍然需要时间去验证。

（本文章不代表最终设计）

参考：

https://uxdesign.cc/design-permissions-for-a-saas-app-db6c1825f20e

开源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Utils：https://github.com/masastack/MASA.Utils

MASA.EShop：https://github.com/masalabs/MASA.EShop

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们