2年前转到SaaS部门之后期间断断续续做着权限相关的业务，这篇文章主要回顾下过往的设计以及其原因和利弊。
不过因为是线上业务，会省略掉很多细节以及账号体系和权益相关得部分，只讨论权限相关。
本文也不会涉及到技术层面的实现仅讨论设计。
SaaS和一些内部系统/2C业务的权限最大不同点是他是天然多租户的。
用户之上会有一层组织(Organization)的概念，组织只拥有所有权限的子集（取决于组织购买的服务），并且组织可以自行管理部分权限。
省略了部门，群组等等概念的简化图：
增加了组织概念：
刚接手的这块的时候发现因为历史原因设计得比较粗糙。
整个权限系统只有两个表：权限定义 和 组织权限关系。
默认情况下组织内的所有用户都能获得分配给组织的权限，需要区分对待管理员和用户的权限都是在代码中进行硬编码，手动去除对应权限。
当时的功能：
组织权限分配 - ACL
组织内用户权限分配 - 硬编码
这个模型严重限制了售卖策略和商家的灵活度，在系统中存在大量的硬编码为了某个业务去修改权限的关系。
后续在这一版上勉强引入了组织内角色分配的功能，但因为业务设计过于简单，没法支撑后续的操作，最后决定重构。
这中间经历了两次模型的调整和服务的变更。
第一次想做和业务无关之后其他业务可复用的模型，基于RBAC构造了角色，角色"用户"关系，角色权限关系；为了覆盖ACL场景构建了"用户"权限关系；为了多个业务方接入定义了domain，并且权限，"用户"的定义和角色都和domain挂钩。
对外提供的RBAC接口本质上是ACL，"用户"分配角色，角色内权限变更会引起"用户"和权限关系的变化。
至于为什么要这么设计，因为考虑到了一个分配角色后能手工修改用户权限的场景，初步评估这个场景是有必要的。
为了保证"用户"分配了多个角色后，如果存在同样的权限点不会因为之后取消某个角色被全部取消了引入了refCount。
此时就存在了一个可以直接使用的ACL(obj_access_relation)和外观看上去是RBAC（但其本质还是ACL）的基础设施。
设置了两个domain，针对组织依旧使用ACL，针对组织内的分配场景使用RBAC。
增加权限定义概念在这之前要说明的是在设计时，组织中存在了一个管理员的概念，他不是某个角色，而是类似于组织creator的概念，其权限等同于组织的权限并且仅有一个，他的定义是为了简化组织的管理，作为了这个组织的用户层面映射。
权限定义这一概念的引入是为了应对组织内分配关系。
因为现在存在了组织和用户两个维度，分配关系最简单的场景下会有几种：
权限用于售卖，组织需要分配，用户需要分配；
权限用于售卖，组织需要分配，用户自动获得；
权限用于售卖，组织需要分配，用户不能获得；（仅管理员使用）
权限用于管理用户，组织自动获得，用户需要分配；
权限用于管理用户，组织自动获得，用户自动获得。(这个场景就不要用权限了）
权限用于管理用户，组织自动获得，用户不能获得；（仅管理员使用）
对于权限组织
权限定义内有两个维度： 组织分配关系（默认获得，需要分配），用户分配关系（默认获得组织的，需要分配，无法获得）
经过实践这一套不是特别方便：
不同domain需要定义不同的权限，但这个场景两个domain下的权限其实是一致的；
过于业务独立，一些业务场景自定义的东西难以插入其中，比如业务额外定义的权限定义表。
后续为了更好支持SaaS的权限系统把这套基础设施复制到了SaaS权限内，这套基础设施依旧留着给其他业务发光发热。
到这一步的权限系统有如下几个特性：
组织权限可通过权限定义和分配获得，组织下存在一个管理者其权限等同于组织权限；
组织内用户权限通过权限定义和角色分配获得，并且约束用户权限不能大于组织（防止组织的某个权限过期后其用户还能继续使用）；
存在系统预设的系统角色，出现条件为组织存在其角色依赖的权限；
组织可对其拥有的且定义为用户可分配的权限组装自定义角色分配给用户。
针对用户的高级功能。