Spiga

基于角色-功能-资源的权限控制模型的设计与实现-引子

2006-11-21 15:10 by 冰戈, 8483 visits, 网摘, 收藏, 编辑

摘要

本文在RBAC基本思想的基础上,增加资源权限的概念,设计了在企业应用系统中用户权限控制的一种具体的简单实现方法。

关键字 用户权限控制

名词解释

资源权限:资源指的是纳入企业应用的一切需要管理的信息实体,如进销存系统中的进货订单;资源权限则是系统将要在这些资源的基础上进行的访问使用权限的控制;

引言

企业应用系统对安全问题有较高的要求,传统的访问控制方法DAC(Discretionary Access Control,自主访问控制模型)、MAC(Mandatory Access Control,强制访问控制模型)难以满足复杂的企业环境需求。因此,NIST(National Institute of Standards and Technology,美国国家标准化和技术委员会)于上世纪90年代初提出了基于角色的访问控制方法,实现了用户与访问权限的逻辑分离,更符合企业的用户、组织、数据和应用特征。

本文将首先介绍RBAC(Role Based Access Control)的基本思想,在此基础上,给出企业应用系统中实现R-F-RBAC(Role-Function-Resource Based Access Control,基于角色-功能-资源的权限控制)的一种具体方法。

RBAC的基本思想可简单地用图1来表示,即把整个访问控制过程分成两步:访问权限与角色相关联,角色再与用户关联,从而实现了用户与访问权限的逻辑分离。


 

由于RBAC实现了用户与访问权限的逻辑分离,因此它极大的方便了权限管理。例如,如果一个用户的职位发生变化,只要将用户当前的角色去掉,加入代表新职务或新任务的角色即可,角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多,并且委派用户到角色不需要很多技术,可以由行政管理人员来执行,而配置权限到角色的工作比较复杂,需要一定的技术,可以由专门的技术人员来承担,但是不给他们委派用户的权限,这与现实中情况正好一致。

而R-F-RBAC的设计思路是在RBAC基础上的一个发展,引入了资源的概念。何所谓资源,大体来说可以是纳入系统管理的信息,在技术实现层面可以是一张表、一条或一列记录、甚至可以是表的一个单元格。在实践使用中,一些高安全级别额的企业应用,仅仅将权限控制到功能是不够的,要求能控制某些用户只能操作到指定的系统内容。

案例分析

这里我们用一个简单的应用模型实例对R-F-RBAC进行深入分析,即给某企业应用假设一个安全级别较高的合同管理子模块,这个模块涉及如下元素:

·合同文件:根据业务要求分为三个等级(项目级、部门级、公司级);

·具体功能:根据实际功能要求分为草拟、上报、会签、批核;

·操作角色:根据公司行政职位设置有项目经理、部门经理、总经理;

·操作人员:公司的内部人员A项目经理张三、甲部门经理李四、总经理王二;

系统的安全需求为A项目经理张三只能草拟并上报仅限于A项目的项目级别合同文件,甲部门经理李四只能草拟、上报、会签率属于甲部门下的项目级或部门级的合同文件,而总经理王二则有权任意操作整个公司的三个级别的合同文件,可将此模型归纳为如下表格:

人员

角色

功能

资源

王二

总经理

草拟、上报、会签、批核

三个级别的合同文件

李四

部门经理

草拟、上报、会签

甲部门下的项目级或部门级的合同文件

张三

项目经理

草拟、上报

仅限于A项目的项目级别合同文件

解决方案

为此我们要设计如下几张关键的数据表:

·用户表:           记录用户的相关信息,UserID作为唯一的用户标识;

·角色表:           记录角色的相关信息,RoleID作为唯一的角色标识;

·模块及功能表:记录模块相关信息及模块的相关功能,分为主子关系表;

·资源表:            记录系统中的所有需要高安全控制的资源信息,其中ResTable是资源对应的数据表名(如合同信息表),ResTerm则是给定该资源的条件(如甲部门下的项目级或部门级的合同文件)用于限定数据提取范围;

由于本文提到的R-F-RBAC的设计思路均考虑用户可以授予多角色,因此我们需要建立用户-角色对应表,用来记录某用户可能对应的若干角色信息,同样需要建立的是角色-功能对应表和角色-资源对应表,以彻底剥离用户与权限访问间的关系;

数据库关系图(仅涉及关键字段)如下:

 

程序实现

代码实现应分为三大部分:

·权限数据维护:该部分主要实现用户、角色、功能、资源等基础信息的维护,给系统管理员一个便利的操作接口;

·权限数据处理:指的是在程序内部实现权限调用接口,如根据调用者提供的模块及用户的信息给出应该提供可操作数据和功能;

·权限数据引用:在UI层具体的处理用户对应的组合权限,如根据得到的功能权限信息控制UI上按钮、菜单等功能元素的显隐活可用性,或根据得到的资源权限条件组合提数条件以达到某些用户只能操作到指定的系统内容的控制级别;

附:引言部分关于RBAC的基本思想的阐述文字来源于http://www.infosecurity.org.cn/article/pki/accessctrl/23637.html ,在此对原作者表示感谢!
0
0
(请您对文章做出评价)
« 上一篇:Microsoft AJAX Library的beta2版发布
» 下一篇:请dudu注意 : 发现园子的一个bug
Add your comment

37 条回复

  1. #1楼 NoProg[未注册用户]2006-11-21 15:44
    文章中有些概念有误,资源本身就是RBAC中的概念,没有R-F-RBAC之说,RBAC分0、1、2三级标准,涵盖范围远不止角色、资源这些。
      回复  引用    
  2. #2楼[楼主] 冰戈      2006-11-21 16:18
    资源本身就是RBAC中的概念,的确是,只不过是我在这突出来写罢了
      回复  引用  查看    
  3. #3楼 菌哥      2006-11-21 16:47
    既然写通用版,建议和ASP.NET2.0的Membership结合起来,写个Provider,那还是不错的
      回复  引用  查看    
  4. #4楼 jiekengxu      2006-11-21 17:28
    这种设计角色很多啊,系统管理员对角色的分布是很头痛的,我以前就出现客户提出这样的问题
      回复  引用  查看    
  5. #5楼[楼主] 冰戈      2006-11-21 17:38
    @jiekengxu
    是呢,易用性本来就是大问题
      回复  引用  查看    
  6. #6楼 Ryan Gene      2006-11-21 21:42
    这种权限控制简单了点吧?
      回复  引用  查看    
  7. #7楼 管理制度[未注册用户]2006-11-22 03:27
    不错,学习一下
      回复  引用    
  8. #8楼[楼主] 冰戈      2006-11-22 09:05
    @Ryan Gene
    请您提出宝贵意见
      回复  引用  查看    
  9. #9楼 gyf19[未注册用户]2006-11-22 10:05
    一个用户可以很多角色呀!!为什么T_User_Role都是主键?
      回复  引用    
  10. #10楼 NET人生      2006-11-22 10:27
    不错,希望楼主继续努力
      回复  引用  查看    
  11. #11楼 Amnoh      2006-11-22 10:40
    T_User_Role中还可以加点东西,
    比如“取得角色时间”,可以知道一个用户何时取得该角色的,这在某引动时候会有用处,更有用的一个是,可以加入“过期时间”,特别地,如果我们只是给一个用户临时赋予一个角色权限时,这个字段就很有用处了
      回复  引用  查看    
  12. #12楼 simonw      2006-11-22 10:54
    权限继承, 权责分离, 资源分类, 操作分类, user-group等因素也应该考虑进去, 越说越多了...
      回复  引用  查看    
  13. #13楼 omnislash      2006-11-22 13:19
    为什么我看到的权限设计的方案全用数据库表来表示的?
      回复  引用  查看    
  14. #14楼[楼主] 冰戈      2006-11-22 13:33
    @simonw,omnislash
    这仅仅是个引子,你们提到的都要考虑进去的,所以说要提建议嘛,详细的设计实现方案会相继推出
      回复  引用  查看    
  15. #15楼 Justin      2006-11-24 15:47
    期待成品~
      回复  引用  查看    
  16. #16楼 Justin      2006-11-24 15:47
    期待成品~
      回复  引用  查看    
  17. #17楼 皇帝的新装      2006-11-30 21:50
    能解决动态增加权限的问题吗?
      回复  引用  查看    
  18. #18楼 Kim Taehee      2006-12-01 09:15
    我其实也设计过一个权限模型,你的这个在现实生活中有许多地方需要改进的,比如文档,或者其它一些比较难以简单描述的资源。如何管理动态的权限分配都是需要搂主考虑的,其实你的这个方案行不行把它套用到一个现实的项目中检验检验,看看你就知道了!RBAC不错,但是也如楼主所讲,只是讲到了一个核心的模型设计思路,成功与否要靠你的细节处理,并且你的模型应该是针对某些类型,某些行业可能更实际一点,一个通用的权限模型是只能到你讲的这一步的,除非你能遍历所有的权限需求。我能说得就是楼主的思路绝对没有错,要想设计好,需要更多的了解需求,积累经验!这个问题本不难,讲的多了,考虑的多了也就成了一个难点。
    希望作者坚持下去我们共同讨论。
      回复  引用  查看    
  19. #19楼 Terry Sun      2006-12-07 14:28
    @冰戈
    你提供的网址打不开,请确认是否正确,谢谢
      回复  引用  查看    
  20. #20楼 心田[未注册用户]2006-12-27 17:05
    使用角色分别关联到资源和功能,其实功能是不是就是操作的概念啊?怎么进行控制呀?好像普通的权限系统只是将资源和操作放在一起组成权限进行控制的。
      回复  引用    
  21. #21楼 bbo[未注册用户]2009-08-05 09:54
    @心田
    我感觉,T_Module这个关系可以去掉,你在这里好像没有体现出来它的作用呀
      回复  引用    
  22. #22楼 java1995[未注册用户]2009-12-19 00:36
    不错,现在我的也是用的这样的。用的struts-menu来控制菜单
      回复  引用