一种高性能Hierarchical RBAC实现方案

背景

 

框图

 一种高性能Hierarchical RBAC实现方案

上图中,Role和被设置Permission的Resource都是可以有任意层级继承关系的。

 

举例

 

举一个网站的例子来说:

 

如果,User表示网站用户;Role表示角色;Resource表示所有可访问的URL;Permission是对每一个URL的某一个权限(如:查看,修改等)。

 

Role可以有任意层级继承关系,如:用户角色可以分为Normal User和Admin User,Admin User下又可以分为Super Admin、Content Admin、Support Admin等。

 

URL这种Resource也可以有任意层级继承关系的,如:对http://abc.com/A/A1/A11/A111.aspx这样一个链接,可以认为http://abc.com/A1是一个URL Resource,http://abc.com/A/A1/A11是他的一个子Resource,http://abc.com/A/A1/A11/A111.aspx又是http://abc.com/A/A1/A11的一个子Resource。

 

对某一个Role来说,他对某一个Resource – R1的具体的Permissions,等于关联到这个Role的Resource - R1及其所有父级Resource的Permissions的并集。

 

对于某一个User来说,他对某一个Resource的Permissions,等于他所属的所有Roles的Permissions的并集。

 

问题

 

各元素之间的关系容易理解,关键的难点在于,因为Role和Resource都可以是有无限层级继承关系的,如何保证权限信息验证具有较高的性能呢?当继承关系较复杂时,递归检测的性能无疑是不可接受的。

 

数据库表

 

User(ID,Name)

Role(ID,Name,ParentID,LeftIndex,RightIndex

UsersInRoles(UserID,RoleID)

Resource(ID,Name,ParentID,LeftIndex,RightIndex

PermissionsOfRole(PermissionsValue,ResourceID,RoleID)

 

这里简单起见,对于Permissions,使用一个二进制位表示一个具体的Permission。我们需要事先定义一个PermissionsValue的每一个二进制位表示的Permission。例如:如果PermissionsValue的二进制值为10101010,表示从低位到高位第2、4、6、8位所代表的权限的并集。

 

使用二进制位表示一个具体的Permission的好处是,处理Permissions的并操作可以转换为二进制的OR;缺点是,具体的Permission想不能特别多,因为多一个就意味着PermissionsValue的最大值大一个2的次方。8位二进制的最大值是2的8次方,这不算很大,但是,1000位二进制的最大值是2的1000次方,这就是个不可想象的巨大数字了。好在,一般来讲,具体的Permission项目不会特别多的。

 

该方案的关键,就在于Role和Resource表的LeftIndex和RightIndex这两个字段了,我们将使用这两个字段,在避免递归的情况下,实现较高性能的取某个继承节点的所有子元素或所有父元素的算法。

 

算法

 

我们以Role为例,首先Role表中有且只有一条记录存放所有Roles的顶层父节点(1,“Root Role”,1,2)。当他没有子节点时,其LeftIndex和RightIndex的值分别为1和2。当对其插入子节点时,LeftIndex和RightIndex的值需要做相应的调整,调整的规则如下(括号中为LeftIndex和RightIndex的值):

 一种高性能Hierarchical RBAC实现方案

按逆时针方向,大家能看出规则吗?

按照这个规则,我们可以如下获取某一个节点的所有字节点或所有父结点(使用伪SQL代码表示):

 

获取ID为3的Role节点的所有的子结点包括本身:

SELECT * FROM Role WHERE

LeftIndex >= (SELECT LeftIndex FROM Role WHERE ID = 3)

AND

RightIndex <= (SELECT RightIndex FROM Role WHERE ID = 3)

注:如果要不包括ID=3的节点本身,只需要用>和<代替>=和<=。

 

获取ID为5的Role节点的所有父节点包括本身:

SELECT * FROM Role WHERE

LeftIndex <= (SELECT LeftIndex FROM Role WHERE ID = 3)

AND

RightIndex >= (SELECT RightIndex FROM Role WHERE ID = 3)

注:如果要不包括ID=5的节点本身,只需要用>和<代替>=和<=。

 

大家可以根据上面的图验证一下算法的效果。完全不需要递归,只需要简单的判断LeftIndex和RightIndex就行,性能自然是非常好的。

 

我们甚至可以以非常简单的SQL语句获得某一个ID为2的User对ID为6的Resource的PermissionsValue:

 

DECLARE @PermissionsValue int;

SELECT @PermissionsValue = @PermissionsValue | PermissionsValue

FROM PermissionsOfRole WHERE

RoleID IN

(

SELECT ID FROM Role WHERE

LeftIndex >= (SELECT LeftIndex FROM Role WHERE ID IN

(SELECT RoleID FROM UsersInRoles WHERE UserID = 2))

AND

RightIndex <= (SELECT RightIndex FROM Role WHERE ID IN

(SELECT RoleID FROM UsersInRoles WHERE UserID = 2))

)

AND

ResourceID IN

(

SELECT ID FROM Resource WHERE

LeftIndex <= (SELECT LeftIndex FROM Resource WHERE ID = 6)

AND

RightIndex >= (SELECT RightIndex FROM Resource WHERE ID = 6)

);

SELECT @PermissionsValue;

上面的SQL虽然有不少嵌套的SELECT,但是,因为子查询基本上都是对主键字段的条件判断,LeftIndex和RightIndex我们也会加上索引,因此,实际上不会对性能造成太大影响。

 

OK,查询性能很好,不过这是以新建或修改Role和Resource的层级关系时的一定的性能损失为代价的。每次新增或修改Role或Resource的层级关系时,必须按照前面所述的规则重置所有节点的LeftIndex和RightIndex值。不过,一般情况下,由于Role和Resource的维护操作占系统整体操作的比例很小,几乎可以忽略,因此其性能损失也不是什么大问题。具体的重置所有节点LeftIndex和RightIndex值的伪代码我就不贴出来了,大家稍微花费几个脑细胞就能想出来了^-^

//结束

你可能感兴趣的:(rbac)