RBAC

Role Based Access Contorl.

基于角色的权限控制

数据权限

目前是准备使用组group来表示用户的归属的

机构如何组织

• 1.有严格层级的组织关系。

  假设组是有层级关系的，并且组的层级数目是固定的，比如说最多只能有3级，并且人员必须有一个对应的三级组，那么我们每在操作一个功能的时候产生的数据，可以归属到这个三级组上。 每个用户在使用的时候，查看下他拥有哪些组的数据权限，将这些组拼接到查询数据的语句中，就可以通过数据权限来控制查询了。

  group1	-subgroup1		-subsubgroup1
  -subgroup2
  -subsubgroup2

  • 这种情况存在的问题是，很多时候，严格层级的组织关系并不能很好的形容我们的团队。我们需要更灵活的组织关系来描述我们的团队。

• 2.无严格层级的组织关系。

  假设组是没有层级的，也没有层级数据限制，只是我们通过定义组的包含关系来确定这些组之间的上下级关系（但是并不是说一个下级只能有一个直属上级）。甚至这种情况都不需要定义组的上下级关系，只需要将不同的用户包含在不同的组之中即可（有点类似linux中的group）。

  • 这种情况存在的问题是，我们如何跟这些组匹配上下级关系？

数据和组如何关联

• 以上两种情况都会遇到一个问题，那就是，我们在页面上操作一个功能的时候，我们如何确定这个功能产生的数据归属于那个组呢？

  • 我们可以采用，在每个功能中，每个用户（或者每个角色）对应一个组。在保存数据的时候，根据用户编码、功能代码可以查询出对应的组织代码，将这个组织代码和数据关联起来。 （存在的问题是如果用户编码、功能代码联合对应组织代码，这样需要配置的数据太多；如果角色代码、功能代码联合对应组织代码，在操作功能的时候，用户是唯一的，但是用户可能拥有多个角色，需要我们识别出使用哪个角色。）
  • 或者另外一种思路，数据必然是由唯一的功能代码产生，也必然是由唯一的用户进行操作产生。我们可以将功能代码和用户代码联合起来暂时称作“数据产生源”，我们将“数据产生源”挂在不同的组中，挂有“数据产生源”的组就有访问这个数据的访问权限。 如果觉得每个功能每个用户配置一个组太麻烦的话，可以给每个用户配置一个组，这个组表示这个用户产生的数据的数据访问权限。

  当然上述关于数据和组如何关联的设想都是比较简陋的，还需要再次完善。