注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

我的博客

等闲识得东风面,万紫千红总是春!

 
 
 

日志

 
 

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

2009-02-19 11:54:22|  分类: 数据库 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
版权声明:原创作品,如需转载,请与作者联系。否则将追究法律责任。
RBAC(基于角色的权限控制)是一个老话题了,但是这两天我试图设计一套表结构实现完整的RBAC时,发现存在很多困难。
我说的完整的RBAC,是指支持角色树形结构和角色分组。具体来说,应当包含如下权限控制需求:
  1. 父级角色可以访问甚至是修改其子级的数据,包含直接子级直到最终子级。
  2. 角色可以访问其所在组的数据。
  3. 父级角色可以访问其所有子级(从直接子级到最终子级)所在组的数据。
而具体到我的系统中,还应当有如下需求。
  1. 兼容多种数据库产品。只能用简单的表,视图,存储过程和函数等实现。
  2. 同时兼容单条数据处理和批量数据处理的需求。
且不论这些具体需求,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的去留?看来还是应当在维护时判断应不应当删除。

本文出自 “威尔金的IT博客,51CTO” 博客,转载请与作者联系!

本文出自 51CTO.COM技术博客
  评论这张
 
阅读(677)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017