如何设计数据库表实现完整的RBAC(基于角色权限控制)

来源：http://hi.baidu.com/seamcker/blog/item/efcdad58f9cd3cdd9d82042f.html

RBAC(基于角色的权限控制)是一个老话题了，但是这两天我试图设计一套表结构实现完整的RBAC时，发现存在很多困难。

我说的完整的RBAC，是指支持角色树形结构和角色分组。具体来说，应当包含如下权限控制需求：

父级角色可以访问甚至是修改其子级的数据，包含直接子级直到最终子级。
角色可以访问其所在组的数据。
父级角色可以访问其所有子级(从直接子级到最终子级)所在组的数据。
而具体到我的系统中，还应当有如下需求。

兼容多种数据库产品。只能用简单的表，视图，存储过程和函数等实现。
同时兼容单条数据处理和批量数据处理的需求。
且不论这些具体需求，RBAC的基本表应当如下四个：

roleList表，记录所有的角色和角色组。
roleId: PK, 角色/组的ID，全局唯一，不区分角色和组。
roleName:角色/组的名称。
roleType: R - 角色，G - 组
rolePermission表，记录每一个角色/组对每一个对象的权限。
permissionID: PK, 无特定意义。
role: 角色/组的ID。
object: 对象的ID。
permission: 权限标识，如读，写，删等。
roleRelationship表，记录角色/组之间的关系。
relationId: PK, 无特定意义。
superiorRole: 父角色/组的ID。
role:子角色，子组，成员角色，成员组的ID。
relationship: 关系标识，可在如下设置集中选取一个。
PG标识：P - 父子关系，G - 组/成员关系。
PPGG标识：在PG集上，再加三种：PP - 间接父级关系，GG - 组内组关系，CG - parentRole是组，childRole的子角色或间接子角色是其成员，或其子组(含间接子组）的成员
objectList表，记录所有的对象。
objectId: PK，对象ID，全局唯一。
objectName: 对象名称。
... ...

分析上述表结构，不难发现，问题的关键在于从rolePermission表中读取数据时，如何限定角色/组的范围.

方案一

如果角色和组的总量不大，比如在100以内，采用PPGG标识关系，读取数据时是最快的。这个时候的SQL只需要一个输入参数?roleId：

SELECT object FROM rolePermission p left join roleRelationship r on p.role = r.role WHERE p.role = ?roleId or r.superiorRole = ?roleId. (尚未验证SQL的正确性)

但是，这个方案是以极度冗余roleRelationship表的数据为代价的，比如有100个角色，那么roleRelationship中将会有100 * 100 ＝10,000条记录。而在每次调整角色和R角色组的时候，就要在roleRelationship中一次增加或删除100条记录。这个开销是比较大的。

方案二

只标识PG，查询时接收的输入参数为一个完整的相关角色列表?roleList。

SELECT object FROM rolePermission WHERE role in (?roleList)

在系统运行时，这个?roleList通常可以从role hierarchy cache中取到，比较方便。这个方案的主要问题有二：

1）如果?roleList过长，使用in判断性能会很差。

2）在有些情况下，如报表查询和系统外查询时，取得roleList不太方便。

方案三

只标识PG，但使用如下三个数据库函数来判断角色/组之间的关系。

boolean isChild(role, parentRole) - 如role为parentRole的子，返回true。
boolean isDescendant(role, ancestorRole) - 如role为ancestorRole的子或间接子级，返回true。
boolean isMember(role, group) - 如role为group的成员或子组的成员，返回true。
boolean descendantIsMember(role, group) - 如role的子或间接子级为group的成员，返回true。
boolean isBelong(role, super) - 如role为super的子，间接子，成员或间接员，或者role的子(含间接子)是super的成员或子组成员，返回true。
在查询时，也只需要接收一个?roleId：SELECT object FROM rolePemission WHERE isBelong(?roleId, role)

如何写出高性能的数据库函数是实现这个方法的关键。

上述方法仅是理论分析，我倾向于方案二。

终于想到新的方案了。

方案四，

结合方案一和方案二，在roleRelationship中，对前两级(也可以是三级或四级)角色，保存其所有的下级角色和组。这样，如果以前两级角色查询数据，就使用方案一，如果以第三级及以下的角色查询数据，就使用方案二。

仍以100个角色为例，每个角色要保存三个关系：一级主管角色，二级主管角色，直接主管角色，最多有300条数据。

每往角色组中加一个角色，也需要加入三条数据：角色本身，一级主管角色，二级主管角色。

但往角色组中加一个子组，需要加入的数据量就大一些：子组本身，子组所有角色，子组所有角色的一级主管角色和二级主管角色。如在多个子组中发现同一角色，可重复保存，但应在表中附加说明是由哪个子组导入的。这样在删除子组时就可以有选择性的删除。

但重复子组的情况就比较麻烦，还有等考虑。假充有组g01,g11,g12,g21。g01包含g11和g12，g11和g12分别包含g21。从 g01中删除g11时，如何判断g21的去留?看来还是应当在维护时判断应不应当删除。

如何设计数据库表实现完整的RBAC(基于角色权限控制)相关推荐

RBAC、控制权限设计、权限表设计基于角色权限控制和基于资源权限控制的区别优劣
RBAC.控制权限设计.权限表设计基于角色权限控制和基于资源权限控制的区别优劣一.介绍二.基于角色的权限设计三.基于资源的权限设计四.主体.资源.权限关系图主体.资源.权限相关的数据模型 ...
ThinkPHP的RBAC（基于角色权限控制）详解
ThinkPHP的RBAC(基于角色权限控制)详解一.什么是RBAC 基于角色的访问控制(Role-Based Access Control)作为传统访问控制(自主访问,强制访问)的有前景的代替受到 ...
RBAC用户角色权限设计方案
RBAC用户角色权限设计方案转自http://www.cnblogs.com/zwq194/archive/2011/03/07/1974821.html RBAC(Role-Based Acces ...
RBAC用户角色权限设计方案(转)
RBAC用户角色权限设计方案 RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限 ...
扩展RBAC用户角色权限设计方案（转载）
扩展RBAC用户角色权限设计方案来源:https://www.cnblogs.com/zwq194/archive/2011/03/07/1974821.html https://blog.csdn ...
错误:在keystone中无法找到默认角色user_Kubernetes RBAC角色权限控制
摘选:https://i4t.com/4448.html 在Kubernetes中所有的API对象都保存在ETCD里,可是,对这些API对象的操作,却一定是通过访问kube-apiserver实现的. ...
java的string访问某个元素_架构师必懂的——RBAC基于角色的访问权限设计
RBAC 是基于角色的访问控制(Role-Based Access Control )在 RBAC 中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限.这就极大地简化了权限的管理.这 ...
RBAC(基于角色的权限访问控制)
第一节.RBAC简介英文全称(Role-Based Access Control) 中文全称:基于角色的权限访问控制 rbac: 一种数据库设计思想,根据设计数据库设计方案,完成项目的权限控制. 经 ...
RBAC 基于角色的访问控制
RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用 ...

如何设计数据库表实现完整的RBAC(基于角色权限控制)

如何设计数据库表实现完整的RBAC(基于角色权限控制)相关推荐

最新文章

热门文章