关于实现方案的简单记录

通过关于RBAC实现的方案记录-上，我们了解到了RBAC的一些基础知识，下面是实际使用中的一些案例情况。

1. 简单模式

在常见的平台中，一般会内置超级管理员角色以及admin/root的账号，默认拥有一些或者全部的权限。
同时还会内置限制，只有超级管理员才能创建角色、给角色授权，其他的角色是无权操作这些的。
对于这种情况，使用的就是RBAC0的模型，有以下特点：

  1. 只有超级管理员可以创建角色、授权角色；
  2. 所有角色都是平级，修改授权时，不会对其他角色造成影响；

2. 级联模式

对于级联模式，使用的就是RBAC1的模型，对角色进行分层，使得角色之间有继承关系。
它的特点如下：

  1. 创建角色时，需要选父级角色；
  2. 对上级角色的授权进行修改时，主要是删减，会影响到子角色，需要自动对齐；

此时根据业务需求，就可以满足：

  1. 允许超级管理员操作角色和权限；
  2. 也允许将角色操作下放至其他角色，进行数据权限限制；
  3. 超级管理员修改角色A的权限时，权限自动收敛，所以A的子角色自动变化；

如果同时将角色和权限的操作下放至其他角色，可能会出现的情况如下：

  1. 角色A添加了一个权限，是否允许超级管理员将其分配给其他角色；
  2. 角色A修改了一个权限的配置，会影响到其他平级等角色，不安全；

所以，一般情况下不会使用这种完全下放的权限管理，实际应用中还是超级管理员一个人操作这些模块的居多。

3.数据隔离

在工作中，我遇到的需求如下：

平台需要给集团A准备好角色，集团A给子公司的管理员授权之后，子公司X自己可以创建角色、权限等，子公司之间是互相隔离。

对于这种必须授权的情况，一般可以通过数据权限隔离，达到效果，即：

  1. 权限授予之后，角色A只能看到它数据权限范围内的数据，它的操作不影响其他角色；
  2. 超级管理员只管理功能权限，其他权限它不关注；

一般的数据隔离都是通过组织架构来区分，也就是给数据标记上属于什么组织，然后通过组织树型关系，每个组织只能看到自己以及自己的子组织的数据。
同时角色创建时，也需要赋予组织属性，就可以实现登录后根据登录者的角色所属组织，进行查询时的数据权限过滤。

其他

本次记录属于日记形式，如有变化，后续再更新~