上述特性中有提到用户权限不能大于组织，这其实仅仅是针对组织域。
如果针对用户层面贩卖高级功能，就不能被这一层限制。
于是又引入了另一个域，其和组织域是正交的，双方不存在逻辑层面上的关系。
也就是 管理员通过VIP获得的权限不会影响到组织权限，用户通过VIP获得的权限不受到组织权限约束。
做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.