论坛首页 Java企业应用论坛

扩展RBAC用户角色权限设计方案

浏览 71194 次
该帖已经被评为良好帖
作者 正文
   发表时间:2011-04-01  
复杂,能否再进一步抽象呢,做个更通用一点的权限管理模块出来
0 请登录后投票
   发表时间:2011-06-27  
本来还挺明白的,看你的我糊涂了
0 请登录后投票
   发表时间:2011-06-27   最后修改:2011-06-27


 rongxh2010 写道

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)



角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个角色赋予该用户。 

 

当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)

在应用系统中,权限表现成什么?对功能模块的操作,对上传文件的删改,菜单的访问,甚至页面上某个按钮、某个图片的可见性控制,都可属于权限的范畴。有些权限设计,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性。(见下图)



请留意权限表中有一列“权限类型”,我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

 

这样设计的好处有二。其一,不需要区分哪些是权限操作,哪些是资源,(实际上,有时候也不好区分,如菜单,把它理解为资源呢还是功能模块权限呢?)。其二,方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串。

 

这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单,就得同时往这三个表中各插入一条记录。这样,可以不需要权限菜单关联表,让权限表与菜单表直接关联,此时,须在权限表中新增一列用来保存菜单的ID,权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

 

到这里,RBAC权限模型的扩展模型的完整设计图如下:



随着系统的日益庞大,为了方便管理,可引入角色组对角色进行分类管理,跟用户组不同,角色组不参与授权。例如:某电网系统的权限管理模块中,角色就是挂在区局下,而区局在这里可当作角色组,它不参于权限分配。另外,为方便上面各主表自身的管理与查找,可采用树型结构,如菜单树、功能树等,当然这些可不需要参于权限分配。

 

以上,是从基本的RBAC模型进行了扩展,具体的设计要根据项目业务的需要作调整。欢迎大家提出批评意见!


不是吧,猛一看以为是我自己的数据模型呢?我以为只有我的权限系统有“页面元素”这个概念呢。

--------------------------------------------

有时候需要单独为一个用户增加一两个权限的,这时候单独为这个用户设计一个“角色”,不值得,所以我设计的是:既可以通过角色为用户分配权限,也可以直接将权限分配给用户。

--------------------------------------------

我接触过的几个开发人员,都不明白为什么要直接给用户分配权限,但是在软件的实际应用中,如果完全基于“角色”为人员分配权限,你会 发现角色之间重复、冗余的权限很多,这样反复的定义多种多样的“角色”,还不如设计成可以直接为人员分配权限呢。

--------------------------------------------

权限管理基本上分为以下几个步骤:

1、定义权限-》定义角色-》为人员分配角色(或者直接分配权限),这是一个分配权限的过程;

--------------------------------------------

2、定义受保护资源-》为“受保护资源”指定授权权限,这是一个授权的过程;

--------------------------------------------

3、应用程序请求“受保护资源”-》“受保护资源”的授权权限与人员持有的权限进行匹配-》匹配成功,允许访问资源,匹配失败,不允许访问资源,这是一个认证的过程。

--------------------------------------------

上面这三个过程,是典型的“操作权限”的流程。

--------------------------------------------

关于“页面元素”的控制,目前多数权限管理系统,都是用“自定义权限标签”来控制页面元素的显示与否的。

我目前也是这样实现的,但是我一直认为:其实用“自定义权限标签”来控制页面元素的显示与否,跟直接在视图中使用程序逻辑判断,是一样的,并没有做到“灵活配置”,当权限编码改变,或者权限含义改变时,还是要去动页面的标签,所以跟写死没什么分别。

 

如果页面元素是通过服务端组装成json,或者别的格式的数据,然后返回到视图层进行渲染,这样的话,就可以做到“页面元素的权限灵活配置了”,可以通过数据库定义那些按钮对那些权限或角色进行显示。

 

“服务端组装视图层组件,返回视图层渲染”,这个模式虽然做到了“对页面元素的权限灵活配置”,但是牺牲掉了很多东西,比如加大了服务端的复杂度,使得页面的设计更加“程序员化”,而不是“美工化”等。

--------------------------------------------

 

至于最关键的“数据权限”,也就是人员对数据的读取深度的控制,是更为复杂的流程。

 

 

--------------------------------------------

对于“数据深度”的控制,我目前的做法是和业务结合的非常紧密,即:在读取数据的程序中,比如“列表”页,首先判断当前登陆者有没有“读取任意深度的权限”,如果有,就不做读取限制;如果没有,则判断当前登录人员是不是部门主管,如果是,则递归读取本部门下的所有数据,如果不是主管,则只读取自己的数据。

--------------------------------------------

“数据深度”的控制,细设计的话,应该可以更通用,更灵活,大家有什么更好的思路,可以讨论一下。

--------------------------------------------

我目前设计的是一个人员只能有一个“角色”,当然,如果设计成一个人员有多个“角色”,也不是很复杂的事情,在“用户表”和“角色表”之间增加一个“用户-角色映射表”就可以了,但是为了系统的简单起见,我把这种设计简化了。

--------------------------------------------

以下是我的“权限控制”的部分数据模型:

 

我目前比较关心的是:

1、数据权限(读取数据的深度)有什么更通用的设计?

2、页面元素的控制,除了使用“自定义权限标签”,或者“服务端组装视图层组件”两种方法,还有没有更好的设计?

有木有?有木有?牛人出来讨论下啊。

  • 大小: 143.3 KB
0 请登录后投票
   发表时间:2011-06-27   最后修改:2011-06-27
simplechinese 写道
楼上区分下功能权限和数据权限,楼主这里没涉及到数据权限


你说的“功能权限”,术语应该叫做“操作权限”。
权限控制通常分为操作权限和数据权限(读取数据的深度(多少)控制)。

数据深度的控制,一般是很难抽象出来,做到通用的,数据深度的控制,跟业务结合非常紧密。
要么是通过不同的权限来区分人员读取数据的深度,要么是在用一种程序中约定的(等于写死的)的标志,来区分不同人员的读取数据的深度。

所以权限之数据深度控制是比较难做到通用型的。
0 请登录后投票
   发表时间:2011-06-28  
vtrtbb 写道
实际复杂的是记录或者字段级别的权限设置,并不是页面端的控制

不知道对于记录级别的权限有什么好办法

举个最简单的例子,总经理看全部记录,部门经理部门,员工看自己 的三级权限,如何设置?



我也在考虑这样的问题 另外 页面端控制也很重要
0 请登录后投票
   发表时间:2011-07-04  
很一般般的RBAC就是第一级的那种稍微变通了下...
0 请登录后投票
   发表时间:2011-07-04  
数据权限理解不够,功能权限都在项目里遇到过,求达人出来科普一下
0 请登录后投票
   发表时间:2011-07-05  
向楼主提一个问题:如果要对一个文件目录进行增删改查子文件的权限进行设计,你怎么设计?
0 请登录后投票
   发表时间:2011-08-02  
认同楼主讲的大部分观点。从页面要素开始一些观点,我没有怎么看懂。

我觉得页面要素有些可以与功能级权限关联。比如:用户关联页面,按钮“添加用户”和添加用户权限挂钩;
添加用户页面的机构下拉框内容,显然有属于数据级权限了。
0 请登录后投票
   发表时间:2011-08-02  
我个人是开源访问控制(权限管理)Ralasafe中间件作者。数据级权限是Ralasafe的重点和拿手好戏。
Ralasafe使用策略对数据级权限进行描述;策略的管理设置由web管理段完成,不需要编写程序或者手工配置XML代码。

我对权限体系是这么划分的:
1,功能级权限(可以映射到菜单项,使用树形结构管理即可)
2,数据级权限

大多数据级权限应该与数据级权限挂钩,隶属关系。比如查询员工功能级权限,会有这样的数据级权限“不同用户能查询到哪些员工,控制到行列级”

对于有些页面要素,比如前面讲到的添加用户页面的机构下拉框内容,只有数据级权限,不需要设置功能级权限。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics