自定义RBAC（2）

　　您好，我是湘王，这是我的头条号「湘王说」，欢迎您来，欢迎您再来～
　　上一次把DAC、MAC、PBAC这三个都一口气介绍完了，本想一口气把RBAC也说完。想了想，饭还是要一口口吃，一次吃太多会消化不良，所以现在再来说下RBAC。
　　本来在RBAC和PBAC之间还有一个ABAC，就是Attribute-Based Access Control，基于属性的权限控制，它是通过动态计算一个或一组属性来是否满足某种条件来进行授权判断（可以编写简单的逻辑），比如＂允许所有住的远的员工有10分钟的弹性打卡时间＂，这就是典型的ABAC，但业务系统不是考勤打卡，这种权限管理方式确实足够强大灵活，但却极其复杂，而且设计难、门槛高、应用少，所以除了在一些大的商用考勤系统中使用之外，几乎再也没有什么露脸的机会。因此这里也就不多说了。
　　所谓RBAC，是Role-Based Access Control的缩写，意思是基于角色的访问控制。这是迄今为止最为普及的权限设计模型：每个用户关联一个或多个角色，每个角色关联一个或多个权限，从而省去了每新增一个用户就要关联一遍所有权限的麻烦。
　　RBAC有几种扩展模式：
　　1、RBAC0：最基础的用户-角色-权限
　　2、RBAC1：增加角色继承特性
　　3、RBAC2：增加职责分离（互斥与约束）特性
　　4、RBAC3：增加组织、职位、用户组、对对象的控制特性
　　下面来一个个地看。
　　RBAC0：用户-角色-权限
　　RBAC0是最简单的一种权限系统，初创公司和少于100人的小公司，用这个差不多已经足够了。
　　接下来，
　　RBAC1 = RBAC0 + 角色继承
　　角色继承的意思并不是面向对象编程OOP的概念，而是角色所具备的权限的一种叠加的概念。它有两种继承方式：
　　1、一般继承：允许角色多重继承，即角色D既具有角色A，又具有角色B和C的权限，例如开发部经理，既有开发、测试、运维，可能还具有一定的产品、业务权限；
　　2、受限继承：角色只能单一继承，即角色C能且只能具有角色A或角色B的权限，例如对于一个财务部门的员工来说，会计或出纳的权限，只能二选一。
　　再接着，
　　RBAC2 = RBAC1 + 职责分离
　　职责分离意味着：
　　1、角色互斥：互斥角色是指各自权限互相制约的两个角色，同一用户只能分配到一组互斥角色集合中至多一个角色。比如财务部的用户就不能同时拥有会计和审核员这两个角色；
　　2、基数约束：用户可拥有的角色数量受限，角色被分配的用户数量受限，角色对应的权限数量也受限；
　　3、先决条件：用户在获得角色A的同时，必须先获得角色B。
　　通过增加config表来定义职责分离逻辑，业务代码读取config配置实现职责分离。
　　最后，
　　RBAC3 = RBAC2 + 用户组/组织机构
　　1、用户组：当用户基数增大，角色类型增多时，可能会有一部分人具有相同的属性。比如外卖送餐部门人数众多，如果一个个地授权，会非常麻烦。但是如果给这些员工创建一个用户组，员工加入用户组后，即可自动获取该用户组的所有角色，退出用户组，同时也撤销了用户组下的所有角色，无须再一个个手动管理；
　　2、组织机构：另一种分类方式，是通过将组织与角色进行关联，实现类似用户组的功能；
　　3、用户组-组织机构混合式：通过用户组实现对角色的整合，然后再按照组织机构的不同范围来查看数据。
　　RBAC3的应用就像这样：
　　到这里，RBAC的概念算是都讲完了，接下来，就该代码上场了。
　　感谢您的大驾光临！咨询技术、产品、运营和管理相关问题，请关注后留言。欢迎骚扰，不胜荣幸～
　　我在头条