RBAC应用最为广泛的权限管理模型，核心的三要素是：账户、角色、权限，但并不仅仅局限于这三个核心要素，基于企业规模、用户规模、运维复杂度，RBCA其实是有很多的变种。从理论角度，有所谓的RBAC0、RBAC1、RBAC2、RBAC3等变种，这里就不讲这些理论，大家一搜就能明白，我按照演化的思路去看下RBAC的变化。
1、基本的RBAC模型
RBAC的核心就是在用户和权限中间增加角色这一层级，提升了权限体系的扩展性。取消了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地赋予用户权限，从而达到用户和权限解耦的目的。
如果没有角色的概念，系统中每加入一个用户，就需要为这个用户配置一遍权限，下图是wiki中直接为用户权限管理方式，可以看出管理成本巨大。
而引入“角色”概念后，如下图即是RBAC模型中最基本的模型：用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。
此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性。
2、提升账户赋权的灵活性：引入岗位概念的RBAC模型
在大型平台的应用上，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入岗位的概念，岗位是多个角色的合集。如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，基于岗位的对象进行角色和权限的赋予。
再次验证了，提升产品的扩展性和灵活性，增加一层就好。
3、提升权限运维的便捷性：引入权限组概念的RBAC模型
同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的，所以实际应用中对权限组的使用较少。
4、集团型企业组织数据的隔离：引入组织的RBAC模型
通过角色所绑定的组织，来决定账户能访问的数据范围，这也是2B类ERP所采用的方法。
附：RBAC在维基百科的模型
多组织访问能力
上图的角色和组织是一对一，也就是一个角色只能访问一个组织，想要访问其他组织，就得切换新的角色，用户体验不好。
Oracle EBS有一个很好地功能就是多组织（MO，Multi Org），通过一些配置，可以选择角色是单组织或是多组织，如果是多组织，这个角色在不用切换的情况下就能访问多个组织的数据。
附：多年前，画的Oracle EBS职责与组织的关系脑图。
6、进一步扩展，员工和账户的关联
很好理解，账户不一定代表员工，可能是一个虚拟的账号，对于大型企业有精细化管理的要求，需要把账号和HR中的员工进行关联，那就可以再增加一层员工。
7、权限的拆分与设计
通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了，但具体权限其实还没有展开。对于一般的系统，权限包括：页面权限、操作权限、数据权限
但具体是什么样的关系，以及“权限”这个抽象的概念具体如何规划？这些都需要分析清楚才能进一步设计出完善的权限系统。首先需要知道，一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。数据可被增删改查。
整体关系如下图所示：
示例
参考
NITST Model For Role-Based Access Control
