SaaS权限设计总结

2年前转到SaaS部门之后期间断断续续做着权限相关的业务，这篇文章主要回顾下过往的设计以及其原因和利弊。

不过因为是线上业务，会省略掉很多细节以及账号体系和权益相关得部分，只讨论权限相关。

本文也不会涉及到技术层面的实现仅讨论设计。

原初的混沌

SaaS和一些内部系统/2C业务的权限最大不同点是他是天然多租户的。

用户之上会有一层组织(Organization)的概念，组织只拥有所有权限的子集（取决于组织购买的服务），并且组织可以自行管理部分权限。

省略了部门，群组等等概念的简化图：

增加了组织概念：

刚接手的这块的时候发现因为历史原因设计得比较粗糙。

整个权限系统只有两个表：权限定义 和 组织权限关系。



默认情况下组织内的所有用户都能获得分配给组织的权限，需要区分对待管理员和用户的权限都是在代码中进行硬编码，手动去除对应权限。

当时的功能：

• 组织权限分配 - ACL
• 组织内用户权限分配 - 硬编码

这个模型严重限制了售卖策略和商家的灵活度，在系统中存在大量的硬编码为了某个业务去修改权限的关系。

后续在这一版上勉强引入了组织内角色分配的功能，但因为业务设计过于简单，没法支撑后续的操作，最后决定重构。

业务场景驱动

这中间经历了两次模型的调整和服务的变更。

第一次想做和业务无关之后其他业务可复用的模型，基于RBAC构造了角色，角色"用户"关系，角色权限关系；为了覆盖ACL场景构建了"用户"权限关系；为了多个业务方接入定义了domain，并且权限，"用户"的定义和角色都和domain挂钩。

对外提供的RBAC接口本质上是ACL，"用户"分配角色，角色内权限变更会引起"用户"和权限关系的变化。

至于为什么要这么设计，因为考虑到了一个分配角色后能手工修改用户权限的场景，初步评估这个场景是有必要的。

为了保证"用户"分配了多个角色后，如果存在同样的权限点不会因为之后取消某个角色被全部取消了引入了refCount。



此时就存在了一个可以直接使用的ACL(obj_access_relation)和外观看上去是RBAC（但其本质还是ACL）的基础设施。

设置了两个domain，针对组织依旧使用ACL，针对组织内的分配场景使用RBAC。

增加权限定义概念

在这之前要说明的是在设计时，组织中存在了一个管理员的概念，他不是某个角色，而是类似于组织creator的概念，其权限等同于组织的权限并且仅有一个，他的定义是为了简化组织的管理，作为了这个组织的用户层面映射。

权限定义这一概念的引入是为了应对组织内分配关系。

因为现在存在了组织和用户两个维度，分配关系最简单的场景下会有几种：

1. 权限用于售卖，组织需要分配，用户需要分配；
2. 权限用于售卖，组织需要分配，用户自动获得；
3. 权限用于售卖，组织需要分配，用户不能获得；（仅管理员使用）
4. 权限用于管理用户，组织自动获得，用户需要分配；
5. 权限用于管理用户，组织自动获得，用户自动获得。(这个场景就不要用权限了）
6. 权限用于管理用户，组织自动获得，用户不能获得；（仅管理员使用）
   
   对于权限组织

权限定义内有两个维度： 组织分配关系（默认获得，需要分配），用户分配关系（默认获得组织的，需要分配，无法获得）

---

经过实践这一套不是特别方便：

1. 不同domain需要定义不同的权限，但这个场景两个domain下的权限其实是一致的；
2. 过于业务独立，一些业务场景自定义的东西难以插入其中，比如业务额外定义的权限定义表。

后续为了更好支持SaaS的权限系统把这套基础设施复制到了SaaS权限内，这套基础设施依旧留着给其他业务发光发热。

到这一步的权限系统有如下几个特性：

1. 组织权限可通过权限定义和分配获得，组织下存在一个管理者其权限等同于组织权限；
2. 组织内用户权限通过权限定义和角色分配获得，并且约束用户权限不能大于组织（防止组织的某个权限过期后其用户还能继续使用）；
3. 存在系统预设的系统角色，出现条件为组织存在其角色依赖的权限；
4. 组织可对其拥有的且定义为用户可分配的权限组装自定义角色分配给用户。

针对用户的高级功能。

上述特性中有提到用户权限不能大于组织，这其实仅仅是针对组织域。

如果针对用户层面贩卖高级功能，就不能被这一层限制。

于是又引入了另一个域，其和组织域是正交的，双方不存在逻辑层面上的关系。

也就是 管理员通过VIP获得的权限不会影响到组织权限，用户通过VIP获得的权限不受到组织权限约束。

更多KA定制场景

做SaaS有一点比较困难的是KA需求，作为最重要的一批客户，提供了大量现金流。KA的定制需求不能被忽略。

在迭代中增加了不少定制场景并泛化使用。

比如：

• 组织层面的权限定义，为了应对客户嫌角色分配麻烦，可以组织内开关某个权限；
• VIP继承组织权限设计，为了应对客户在大量购买某VIP分配之后不想重复分配角色；
• 权限自动赋予某些部门下用户

等等

这些问题的共同点就是分配行为的繁琐。

之前引入的权限定义本身就是在组织分配层面解决这个问题，有了一些ABAC的特征。

在这些KA需求的迭代中也增加了更多subject attribute，例如组织ID，VIP类型，以及之后的更多拓展。

基于分配给用户和解耦用户直接分配的ACL和RBAC模型在这些领域都不能很好发挥，因为他们的作用前提是发生了分配关系，为了满足更多的KA场景以及系统本身迭代会引入更多的ABAC元素。

之后的规划

现在线上运行的这一套系统已经和整个商业链路打通，客户的服务购买/续期/增购会有一部分反应到权限系统中，新的功能需要商业化也都会统一接入其中，权限也从最开始的百来个发展到近千个。

但当前系统的不足也很明显，整套体系的架构比较杂乱。

• 最开始做的伪RBAC那一套最后实践没有对应的场景，而且容易发生不一致的问题，需要在系统层面移除掉（但ACL本身保留）；
• ABAC实现零散且混乱，这一套要需要体系化重写；
• 系统需要泛化到2C场景，打通2B和2C的商业化链路；
• 缺失了数据权限控制（object），但这一套应该不会和当前权限这一套做在一起，两者的业务对象相差有点多（一个是组织用户和功能，一个是用户和各类数据）。

Written with StackEdit.