RBAC权限设计模型（精选7篇）
RBAC权限设计模型 篇1
0 引言
随着企业信息管理系统的逐渐发展,数据权限的需求日益增加,在一个企业信息管理系统里,可能涉及到多类用户,每类用户对应着不同的数据访问范围。RBAC并不能很好的满足复杂的数据权限控制的需求。本文在RBAC模型的基础之上,提出了一个加强数据权限管理的数据权限模型,满足对复杂数据权限控制的需求。
1 基于角色的权限控制模型
RBAC的核心思想是将权限与角色联系起来,在系统中根据应用的需要为不同的工作岗位创建相应的角色,同时根据用户职责指派合适的角色,用户通过指派的角色获得相应的权限,实现对文件的访问。也就是说,传统的访问控制是直接将访问主体(发出访问操作,有存取要求的主动方)和客体(被调用的程序或欲存取的数据访问)相联系,而RBAC在中间加入角色,通过角色沟通主体和客体,角色的目的就是为了隔离用户和权限。角色作为一个用户与权限的代理层,解耦了权限和用户的关系,所有的授权应该给予角色而不是直接给用户,从而实现了用户与访问权限的逻辑分离。1996年,Sandhu发布了RBAC96的RBAC通用模型族。文献[5]介绍了一些基于角色系统的开发框架。图1显示了通用模型族中最通用的模型。
用户和角色之间是多对多的关系,一个用户可以被赋予若干角色,一个角色也可以被赋予若干个具体用户。同样角色和权限之间也是多对多的关系,一个角色可以具有多项权限,一个权限也可以赋予多个不同的角色。某系统的操作用户,可以通过他所具有的角色的权限来判断其可访问的系统资源和对系统资源可以进行的操作,这就是RBAC最基本的工作原理。
RBAC的描述如下:
u:User用户;
r:Role角色;
p:privilege权限。
此时,如果某个用户u对某个业务对象o具有的权限记为P(u,o),则有如下关系:
P(u,o)=Pr(r(u),o)
其中,Pr(r(u),o)是通过用户u所赋予的角色r对业务对象o的权限。
大型企业系统一般功能庞大复杂,不同身份和岗位的用户对系统模块功能的使用权限不同。这种基于角色的权限控制模型可以直接将企业组织结构映射到信息系统中,使得对用户权限的管理更加直观、方便和统一,在很大程度上简化了权限管理工作。
2 基于RBAC的数据权限模型
2.1 模型设计
在企业应用系统中,由于用户量大、用户层次结构复杂、业务对象庞杂,权限涉及到比较复杂的功能权限和数据权限,其中功能权限可以是一个按钮或者链接,而数据权限则是对不同层次用户的不同数据范围的限制,假设功能权限的数量为m,数据权限的数量为n,在RBAC模型中,对于完全的权限管理需要有m*n种权限关系,在大型的企业信息管理系统中,随着功能数量的增加,角色权限的配置非常庞大而复杂,并且一旦需要改变数据权限的类型数量,将需要对权限表做较大的调整,因此不具有良好的可扩展性。
针对上述问题,本文在角色的权限控制模型的基础之上,设计了一个新的数据权限模型如图2所示。
数据权限模型将权限划分为功能权限和数据权限,对功能权限和数据权限分别设置不同的角色,分别为数据角色和功能角色。为用户不仅需要赋予功能角色,同时也需要赋予数据角色。用户需要访问一个模块时,不仅要取得该模块对应的功能角色的权限,还要取得该模块对应的数据角色的数据权限,才可以访问该模块功能下的数据。
模型中将角色分为了类型角色,用户与角色关系变为了用户功能角色的关系和用户与数据角色的关系,虽然对用户角色赋予的工作量增加了,但是解耦了角色与功能权限、数据权限之间的关系,使得完全权限集仅需要包含m+n个权限即可。假设数据权限类型数量增加为n+x,则完全权限集只需增加为m+n+x即可,而RBAC模型中完全权限集所对应的m*(n+x)=m*n+m*x,同理,当功能权限增加为m+x时,完全权限集也仅增加为m+n+x,而RBAC模型中完全权限集所对应的(m+x)*n=m*n+n*x。这使得数据权限模型随着系统数据权限的变更具有更少的变动,具有更好的可扩展性,减少了功能权限和数据权限的增加为角色权限维护带来的大量的增改工作。在实际操作中,也可以使用户的角色赋予更加清晰,达到更为简洁的角色权限控制。
2.2 模型实现
数据权限模型的权限控制系统采用普遍的三层架构,包括表示层、业务层和数据层。其中数据层是由数据库系统组成,权限管理则以数据库作为基础来进行。数据库的设计结构如图3所示。
用户通过“用户-功能角色”和“用户-数据角色”建立起动态的对应关系,功能角色与“功能角色-模块-按键”建立动态的对应关系,数据角色则与“数据角色-模块-数据范围”建立动态的对应关系,通过这种动态的对应关系可以更简便的建立用户与功能权限和数据权限之间的对应关系。
用户授权的实现通过共九个部分实现,包括用户管理、模块管理、模块按键管理、模块数据范围管理、功能角色管理、数据角色管理、功能角色模块按键对应表管理、数据角色模块数据范围对应表管理、用户功能角色和数据角色分配管理。
其中模块按键和模块数据范围的实际应用中随着系统模块的增减而改变,维护量仅随着系统模块的增减以及数据权限范围的变化而线性变化。而用户授权部分由用户管理、功能角色管理、数据角色管理和用户功能角色和数据角色分配管理实现,根据实际需求,为用户需要访问的菜单模块和此菜单模块下访问的数据范围分配角色,可以实现方便快捷的实现权限管理。
具体的系统实现流程为:页面模块读入时,根据用户ID获取用户的功能权限和数据权限,根据功能角色判断用户对该页面模块的访问权限,获取通过后,判断该用户的数据权限,并将数据权限键值存储到Session中,在用户使用按键时,判断根据Session中的数据权限范围,将其注入到SQL查询语句中,此时只需要将一定的范围限制语句作为一个封装的方法加入到SQL语句中,即可实现对数据访问范围的控制,当用户在该模块下的数据权限范围发生变化时,只需在改变用户在该模块下的数据权限范围,并不需要改变数据访问层的代码。如果系统需要修改数据权限范围,只需改变对数据权限限制语句所封装的方法,即可实现对数据权限的修改,有效的减少数据访问层代码的修改。
此数据权限模型可以广泛适用于大型企业管理系统中的权限管理,特别适合于类似于具有省、市、部门、个人多级数据权限控制范围需求的应用系统权限管理,可以灵活的增加不同层次范围的数据控制需求,对于后期的用户角色权限授权管理比较方便。
3 结束语
权限管理是企业应用系统中重要组成部分,权限管理的技术和策略对系统的信息安全影响很大。数据权限的管理属于权限管理的一个重要组成部分,是影响系统的信息安全的重要因素。针对于传统的RBAC模型存在的数据权限管理方面的不足,本文提出的一种基于RBAC的数据权限模型的设计与实现方法,是在RBAC96模型理论基础上提出,并在实际应用中进行了验证,满足了数据权限和功能权限双重控制的需求,降低了权限管理和维护的复杂性。对开发类似的多组织层次的应用系统管理功能模块具有一定的参考价值。
参考文献
[1]王延彬,许林英,杨海琛.OA系统中基于角色的用户权限管理[J].微处理机.2008.
[2]肖军模,刘军,周海刚.网络信息安全[M].北京:机械工业出版社.2003.
[3]周文峰,尤军考,何基香.基于RBAC模型的权限管理系统设计与实现[J].微计算机信息.2006.
[4]Sandhu R S,Coyne E J,Feinstein H L,et al.Role-based AccessControl Models[J].IEEE Computer.1996.
[5]Epstein P,Sandhu R.Towards A UML Based Approach toRole Engineering[C]//Proceedings of the 4th ACM Workshopon Role-based Access Control.[S.l.]:AVM Press.1999.
RBAC权限设计模型 篇2
网络信息系统的每个具体环节都可能受到安全威胁,它是一个复杂的人机交互系统。目前网络信息系统安全存在的关键问题是:缺乏集中统一的用户身份认证机制,用户身份认证是建立安全应用系统的第一道防线,各种业务系统的用户身份认证方式多样化,用户登录不同的业务系统可能采取不同的登录方式,造成管理员对用户的管理分散和不便;缺乏集中统一的资源访问授权机制,各种业务系统对于资源的授权方式不同,缺乏集中的资源访问授权,使管理员对于配置细粒度资源访问以及授权费时费力。
为了保证网络信息系统的安全,我们需要构建强健的权限管理,任何多用户的系统都不可避免的涉及到相同的权限需求,都需要解决实体鉴别、数据保密性、数据完整性、防抵赖和访问控制等安全服务。权限管理系统是网络信息系统中可代码重用性最高的模块之一。所以在网络信息系统安全要求中,应以权限管理作为设计与实现的重点。
采用统一的安全管理设计思想,规范化设计和先进的技术架构体系,构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统,使得权限管理系统真正成为权限控制的核心,在维护系统安全方面发挥重要的作用,是十分必要的。
本文介绍一种基于角色的访问控制RBAC(Role-Based policies Access Control)模型的权限管理系统的设计和实现,系统采用基于DNA架构技术实现。
1 DNA架构[1]
采用Windows DNA构建权限管理系统。Windows DNA架构集成了先进的软件体系架构思想,具有采用多层分布式应用模型、基于组件并能重用组件、统一完全模型和灵活的事务处理控制等特点。
系统逻辑上分为三层:表示层、业务层和数据层。表示层负责人机交互;业务层提供业务管理,主要包括用户管理、权限管理和访问控制等。数据层主要负责数据的存储、组织和管理等。
2 权限模型设计
实现权限管理,就是对人员及其可以访问的数据和可以进行的操作进行归类,在此基础上进行必要的访问和修改控制。系统由于针对的行业和使用者的不同,在权限的设置和管理上又有不同的要求。在实现过程中考虑到易用性、灵活性、安全性和可扩充性的要求,借鉴Windows NT的用户管理模式;按等级划分权限;提供数据库字段一级的访问控制等原则。
2.1 RBAC模型[23]
访问控制策略一般有三种:自主型访问控制(DAC)、强制型访问控制(MAC)和基于角色的访问控制(RBAC)。自主式太弱,强制式太强,二者工作量大,不便于管理。基于角色的访问控制是目前公认的解决统一资源访问控制的有效方法。其优点是:减小授权管理的复杂性,降低管理开销;灵活的安全策略,有很大的伸缩性。
2.2 核心对象模型[4]
根据RBAC模型的权限设计思想,建立权限管理的核心对象模型,模型的基本元素主要有:用户(Users)、角色(Role)、访问模式(Access Mode)、控制对象(Control Object)和操作(Operator)等。主要的关系有:分配角色权限PA(Permission Assignment)、分配用户角色UA(Users Assignment)。各元素及关系描述如图1。
2.3 权限访问机制
权限管理:提供集中管理权限的服务,负责提供用户的验证、角色信息、权限关系表的验证。如图2所示。
系统根据用户、角色、操作、访问策略和控制对象之间的关联关系,同时考虑权限的正负向授予,计算出用户的最小权限。在业务逻辑层采用Session Bean实现此服务,也可以发布成Web Service。采用代理Proxy模式,集中控制来自应用系统的所要访问的权限计算服务,并返回权限关系表。应用系统端通过访问能力表CL和访问控制表ACL两种可选的访问方式访问权限管理系统。
2.4 权限控制机制
权限所要控制的资源类别是根据应用系统的需要而定义的,控制规则也是应用系统提供的,对于权限管理系统来说是透明的,权限将不同应用系统的资源和操作统一对待。应用系统调用权限管理系统所获得的权限关系表,也是需要应用系统来解释的。按此设计,权限管理系统的通用性较强,权限的控制机制由应用系统负责处理。
权限限制施加于单个或多个角色之间,用来表达权限的执行是有条件的。每个角色需遵守最小特权集和职责分离原则,另外角色的权限可以继承。
为了实现这种权限访问控制,建立用于权限管理的数据表,用以存放模块信息、角色、授给角色的权限、授给用户的权限和用户的角色等。
角色权限表存放了所有角色的ID、角色名、角色权限信息。每个角色ID唯一确定一种角色。每一种角色被分配相应的权限。权限字段存储的是权限ID的集合。该表把具体的许可对象与能够操作它们的角色绑定在一起,是实现用户权限定制的关键。角色与权限是双向多对多的关系。
2.5 权限存储
权限管理采用目录服务数据库。目录服务系统基于LDAP(Lightweight Directory Access Protocol)标准,具有广泛的数据整合和共享能力。存储用户信息、角色、操作、访问模式等信息。它允许用户根据需要使用ACI(一般称为ACL或访问控制列表)控制对数据读和写的权限。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及对其他对数据进行访问控制,这些都由LDAP目录服务器完成,不用考虑在客户端的应用程序是否要进行安全检查。
3 角色权限分配与管理
安全访问控制必须要识别和确认应用系统的用户。为了防止对系统的任意访问,该系统采用用户名和密码验证登录用户的身份,以确定登录用户是否被允许访问系统资源。用户身份被确认后,进入系统,应用系统把从用户表提取的用户ID发送给角色管理模块,角色管理模块通过角色表获得赋予用户的角色。应用系统把系统管理员角色发送给权限模块,权限模块通过权限表使得拥有某角色的用户获得相应的权限,同时使得不同角色的用户在相同的应用系统中获得不同的操作权限,避免了越权操作。
角色权限管理:一是权限的分配策略,二是权限的操作。在权限的操作过程中首先选取要操作的权限,如授权、修改、浏览等。然后判断是实体权限还是功能权限,再把权限分配给角色。如果角色获得的权限是功能权限则实现系统功能;如果是实体权限,则选择实体对象。同时某用户获得该角色,对实体对象进行权限操作,直至权限管理完成。
功能权限主要是对前台窗口中的控件字段的管理,实体权限是对后台数据库的基本表和基本列表的管理,这种设计解决三层体系结构涉及的安全问题。
4 结束语
本文论述了一种基于RBAC模型的权限管理系统的实现技术方案。实践应用表明,采用基于RBAC模型的权限具有以下优势:适合分层的组织结构形式;扩展性好,支持权限多变的需求;重用性强;权限分配直观、容易理解,便于使用。该权限管理系统已成功应用于学籍管理系统的设计和开发实践。
摘要：本文提出了基于RBAC模型的权限管理的设计和实现方案,讨论了权限管理为核心的面向对象设计模型,以及权限访问和权限控制等技术。
关键词：角色,访问控制,RBAC模型
参考文献
[1]Dino Esposito等著,程永敬,董启雄等翻译.ASP数据访问高级编程[M].机械工业出版社,2007.
[2]常彦德.基于角色的访问控制技术研究进展[J].计算机与现代化,2011,(12).
[3]俞诗鹏.基于角色访问控制的理论与应用研究[D].北京大学硕士学位论文,2003,5.
RBAC权限设计模型 篇3
关键词：软件即服务,基于角色访问控制,访问控制,模型
0 引言
Saa S系统可以定义为“将软件部署为服务并通过Interne进行访问”的系统,是单实例、多用户体系结构、基于Internet访问的系统。系统中每个环节都可能受到安全威胁。为了确保系统中数据的安全性、一致性、完整性,使客户能够放心地将具有重要性、机密性的商业数据交给Saa S服务提供商进行管理和控制,在开发一个Saa S系统的过程中,作为Saa S系统的重要组成部分———权限管理模块变得尤为重要。本文在研究基于角色的访问控制(RBAC)模型的基础上,提出了Saa S系统的一种权限管理模型。
1 RBAC模型研究
访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体(用户、进程、服务等)对访问客体(文件、系统等)的访问权限,从而使计算机系统在合法范围内使用;决定用户能做什么,也决定代表一定用户利益的程序能做什么。企业环境中的访问控制策略一般有三种:自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法。其中,自主式太弱,强制式太强,二者工作量大,不便于管理。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其基本原理是在用户和访问权限之间加入角色这一层,实现用户和权限的分离,用户只有通过激活角色才能获得访问权限,提高了防护的力度。同时通过角色对权限分组,大大简化了用户权限分配表,间接地实现了对用户的分组,提高了权限分配的效率。而且加入角色层后,访问控制机制更接近真实世界中的职业分配,便于权限管理,提高了灵活度。其显著的两大特征是:(1)减小授权管理的复杂性,降低管理开销;(2)灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性。美国国家标准与技术研究院NIST(The National Institute of Standards and Technology)标准RBAC模型由四个部件模型组成,这四个部件模型分别是基本模型RBAC0(Core RBAC)、角色分级模型RBAC1(Hierarchal RBAC)、角色限制模型RBAC2(Constraint RBAC)和统一模型RBAC3(Combines RBAC)[1]。RBAC0模型如图1所示。
RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户(USERS)、角色(ROLES)、目标(OBS)、操作(OPS)、许可权(PRMS)五个基本数据元素,权限被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
RBAC1引入角色间的继承关系,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
RBAC3包含了RBAC1和RBAC2,既提供了角色间的继承关系,又提供了责任分离关系。
通过上面对RBAC模型的研究,在RBAC模型中,访问控制都与角色相关,系统权限控制都通过角色来实现,权限粒度不够细化,权限层次不够清晰,不能很好地区分系统功能操作控制与系统数据访问控制。基于这些问题的考虑,提出了一种新型的权限管理模型———基于RBAC的分层控制模型。
2 Saa S系统的权限模型
随着社会的不断发展、竞争的不断加剧、社会分工的不断细化、企业之间的合作不断加强、业务的灵活性不断增强,企业对系统数据的安全性要求越来越高,原有基于单一角色的粗放式系统权限管理模式已不能满足现在用户的需要,需要对系统权限管理进行细化,实行更精细化的管理。根据对Saa S系统的分析了解,运用分层控制的思想对Saa S系统的权限管理实施多层访问控制,能够确保系统的安全性和数据访问的灵活性。分层控制的思想是基于RBAC模型的权限设计思想,对RBAC模型进行了部分改良和扩展。把Saa S系统的权限管理模型划分为系统许可证权限管理、系统功能操作控制管理、系统数据访问控制管理三个层次;引入许可证、岗位、组织机构(部门、小组、虚拟团队)等数据实体,并定义岗位与用户、用户与不同组织机构等实体之间的关系。其总体模型如图2所示。
Saa S系统权限管理模型包含的基本元素主要有:用户、小组、角色、资源、操作、岗位、许可证、虚拟团队、部门、组织、权限。主要的关系有:分配角色权限、分配用户角色、分配用户岗位、分配组织许可证、分配权限操作、分配操作资源、分配小组到不同组织机构。其形式化描述可以从系统许可控制、系统功能操作控制、系统数据访问控制三个层次对其进行描述。
2.1 系统许可证控制
定义1许可证许可证一般分为用户许可证和功能许可证。用户许可证控制访问系统的用户数,功能许可证控制访问功能模块的用户数。
定义2分配组织许可证实现组织和许可证之间多对多的关系。即一个组织可以拥有多个许可证,一个许可证可以分配给多个组织。
2.2 功能操作控制
功能操作控制层主要表示用户对系统功能和系统资源两个层面的访问控制。用户可以访问哪些系统功能,怎样访问这些功能;用户可以操作哪些系统资源,怎样操作这些资源。系统功能的访问控制和系统资源的访问控制最终反映到对系统页面的控制。一个用户拥有怎样的页面访问权限也就具有相应的系统功能及系统资源访问权限。操作控制层主要涉及到数据实体:用户、角色、权限、操作、资源;数据实体关系:用户角色分配、角色权限分配、权限操作、操作资源等。其模型如图3所示。
定义3资源是系统所要保护的,可以被访问的对象。
定义4角色角色对应于某一特定的工作岗位,是一组可执行任务的集合。在视图层面的控制,表现为角色的赋予,不同角色具有不同的功能视图。用户根据被赋予的角色个性化地使用系统。系统用户看到的页面视图范围为该用户所具有的所有角色所定义的视图的总和。其关系图如图4所示。
定义5权限权限是对计算机系统中的一个或多个数据对象进行某种方式访问的许可权,是数据操作任务访问数据资源的接口。权限分配的单位与载体,用来定义用户执行各种功能的权限。同时,还用于控制用户看到的各种页面布局和选项卡。
定义6用户是权限的拥有者或主体。用户和权限实现分离,通过授权管理进行绑定。
定义7操作完成资源的类别和访问策略之间的绑定。
定义8会话一个会话是一个用户对多个角色的映射,当用户激活了部分或全部他被授予的角色时,他就建立了一个会话,用户实际上可以执行的任务是在这次会话期间被激活的角色的任务集。
定义9分配角色权限(PA)权限配置表示权限和角色之间多对多的分配关系,即一个角色可以被授予多个权限,一个权限可以分配给多个角色。
定义10分配用户角色(UA)分配用户表示用户和角色之间多对多的分配关系,即一个用户可以被授予多个角色,一个角色可以分配给多个用户。
定义11分配权限操作分配权限操作表示权限与操作之间多对多的分配关系,即一个权限可以包含多个操作,一个操作可以分配给多个权限。
定义12分配操作资源分配操作资源表示操作与资源之间多对多的分配关系,即一个操作可以对应多个资源,一个资源可以分配给多个操作。
2.3 数据访问控制
现代企业内部之间的协作不断加强,企业之间的合作越来越紧密,根据不同的业务活动需要,在企业部门内部、企业部门之间、企业之间设立了不同的小组、虚拟组织等工作组织形式,有些组织中的员工虽然具有相同的功能操作权限,但具有不同的数据访问权限,这需要系统对数据访问进行严格、灵活的控制,数据访问控制层能很好地解决这些问题。数据访问控制层主要是对系统数据访问进行控制,控制系统数据的访问权限及数据的共享权限。不同级别用户群体具有不同的数据访问权限;不同机构用户群体具有不同的数据共享权限。其模型如图5所示。
定义13岗位是一个企业的某个部门的职位(相当于在部门下有相同职能的员工的集合),它隶属于某个具体的部门,并且可以有一个或多个员工在岗位上任职。一般情况是一人一岗,同时提供一人多岗的功能,以完成权限在数据层面的灵活控制。一个系统用户如果有两个岗位,那么他只能看到当前岗位下的数据,通过岗位切换,可以达到查看所属其它岗位下的数据信息。另外岗位有上下级关系,上级可以查看下级的数据,下级不能访问上级的数据,平级之间不能互相访问。其关系图如图6所示。
定义14用户是权限的拥有者或主体。用户和权限实现分离,通过授权管理进行绑定。
定义15组织机构根据不同用户属性划分的用户群体。在一个企业内部可以划分为部门、小组等不同组织形式;在企业之间可以划分为小组、虚拟团队等不同组织形式。一个部门可以划分多个小组,一个小组可以包含多个用户;部门跟用户存在一对多的关系,用户小组跟用户存在多对多的关系。组织机构与用户之间的关系具有多样性、灵活性,根据不同的业务活动需要可以进行细化。
定义16分配用户岗位表示用户与岗位之间多对多的分配关系,即一个用户可以拥有多个岗位,一个岗位可以分配给多个用户。
3 结束语
本文论述了一种基于RBAC模型的Saa S系统权限管理模型的研究。该权限管理模型已成功应用于系统的设计和开发实践,与应用系统具有很好的集成。实践表明,采用基于RBAC模型的新系统权限管理模型表现出以下优点:(1)采用分层思想实现权限管理,有利于权限控制与管理。(2)权限分配直观、容易理解,便于使用。(3)扩展性好,支持岗位、权限多变的需求。(4)通过资源的细分,为系统提供了不同粒度的权限控制。特别是将权限粒度控制到页面一级,并通过不同用户到不同页面的映射,可以实现用户界面的定制,实现了更大的灵活性。
RBAC权限设计模型 篇4
1 权限分配过程
通过RPMI模型中角色规格证书和角色分配证书及实现角色-资源-操作、角色-角色-权限分配矩阵, 实现了用户-角色的指派、角色-权限的分配、角色层次、角色代理, 支持最小特权原则、静态约束及动态约束, 对角色私有权限的保护及灵活的代理也提供了较好的支持[1]。
1.1 角色-资源/角色-操作/权限的分配 (RSOP处理)
角色-权限的分配在RPMI系统实现中有两种方式, 一种是角色-资源-操作的分配, 另一种是角色-角色-权限的分配, 两种分配方式在统一的RSOP处理中实现。角色的层次继承及私有权限的保护也在这里得到实现。
定义四元组RSOP= (R角色, S资源, O操作, P权限) :
(1) 角色- (资源-操作) 的分配:
assignRS (r, Pr) ={r∈R|Pr= (O→S) }:对角色集合R中的任意元r都有它的权限是作用在资源S上的O操作;
(2) 角色- (角色-权限) 的分配:
assignRR (r, Pr) ={r∈R|PrPRi, i=1, …, n}:对于角色集合R中元素r由于R被授予拥有其它角色R2, R3, …, Ri的全部或部分特权, 因此r也同时拥有权限Pr1, Pr2, …;
(3) 角色-角色的完全继承:
r∈R1, R1≥R2则Pr∈ (Pr1∪Pr2) (≥表示继承关系) ;
(4) 角色-角色的部分继承:
r∈R1, R1≥R2则Pr part of (Pr1∪Pr2) 并且去掉要保护的私有权限。
对于 (3) 角色A完全继承角色B, 将不对角色B的特权作选择, 默认全部继承;对于 (4) 角色A不继承角色B的私有权限, 将对Pr2集合进行选择, 根据策略, 去掉要保护的私有权限, 这样角色B的私有权限将不被角色A继承。 (3) 、 (4) 实质上是 (2) 的特殊情况。在进行角色-角色的分配中, 系统将自动监测是否有角色冲突发生。
分配结束后, 所得结果存入一个三维矩阵中, 送交“角色分析处理”模块。“角色分析处理”提取矩阵中R角色, 这将作为角色规格证书中的角色;对矩阵中对象O、权限P, 根据OID号的分类, 对角色和权限排序 (实践证明这有利于提高“特权验证者”的验证效率) , 这将作为角色规格证书中的属性。角色规格证书通过AA私钥签名, 发布到LDAP中。
1.2 角色代理
在X.509中规定只有SOA和AA有权发布证书, 对权限的代理主要通过证书扩展项pathLenConstraints和delegatedNameConstrai nts分别从路径空间和命名空间上作了限制。我们没有完全遵照这个限制, 或者说根本没作代理空间的限制, 用户之间可以自由代理其所拥有的权限, 但通过以下3条规则来保证系统的安全:
(1) 用户需要将它的角色或特权授予他人, 需先产生授权申请;
(2) 只有AA有权颁发证书;
(3) 发生代理时必须有安全管理员的参与。
代理是通过RSOP处理辅助实现的, 这也是RSOP的一个特色, 不但各级安全管理员可以使用, 个人用户也可以使用, 只是根据其PKC不同来授予不同的使用范围, 也就是说他可以管理的只是他个人拥有的角色、特权和资源。通过选择要代理出去的角色/特权, 生成信息交换文件, 并用其私钥签名, 送交SOA/AA。安全管理员根据策略检查许可后, 签发新的角色分配证书, 实现角色的委托代理, 同时将信息交换文件备案。虽然, 在分布式环境中, 如果用户可以在没有安全管理员的参与下就可将自己的角色/权限代理出去在某些场合很适用, 也确实可以做到根据预设策略, 例如只要验证签名正确和权限是在代理范围内, 就可由系统自动签发新的角色分配证书得到实现。但这里强调指出, 用户进行角色代理不能没有安全管理员的参与, 否则将产生严重安全漏洞。
用户-角色的分配[2]。用户-角色的分配通过二维矩阵 (X, Y) 来完成, 这里x为用户, y为角色。系统自动监测静态责权分离原则的实施。模型中动态责权分离在“特权验证者”中实施。在为角色分配权限时, 有的复杂的角色的权限就是其他几个角色的权限的和, 我们在做角色规范证书时, 就不一一列举此角色的权限了, 就只列举出他的角色组合就可以了。例如:角色Y他的权限就是由角色X, 角色Z, 角色W三者的权限简单相加组成, 那么我们就在角色Y的角色规范证书的属性列中写上角色X、Z、W就可以了。不用写上他们的具体权限, 简化了角色规范证书, 便于权限的管理。
最小特权原则。在每个受保护的资源处都有一个“特权验证者”, 此模块在系统初始化时加载, 装入所需角色/权限的OID。当有资源访问事件发生时, “特权验证者”只需查询角色证书中有无这些OID即可。OID可以是角色也可以是特权。这样, 一方面实现了最小权限规则, 同时保护了用户的权限不被滥用。
2 属性证书的签发过程
属性证书的签发流程:用户输入登陆信息, 若不合法, 则再输入, 合法, 就把用户请求属性证书所需要的信息如角色、资源、权限等写入请求文件中, 并用自己的私钥进行签名, 形成属性证书请求文件, 把请求文件送给AA签名之前, 要验证AA的合法性, 特别是验证AA的私钥的合法性, 若AA的私钥是合法的, 那么就验证AC请求文件的合法性, 如果也合法, 就初始化AC请求文件, 并设置证书中的各项参数, 最后用前向安全数字签名方法使用AA的私钥签发AC, 用户申请的AC就这样生成了[3]。
3 结语
本文详细介绍了RPMI系统中两个关键部分:“权限分配过程”、“属性证书签发过程”的实现。通过RPMI模型中角色规格证书和角色分配证书及实现角色-资源-操作、角色-角色-权限分配矩阵实现了权限分配, 在证书签发过程中使用前向安全数字签名签发属性证书, 整体提升RPMI系统性能。
参考文献
[1]谭强, 黄蕾.PMI原理及实现初探.计算机工程, 2002, 28 (8) :187.
[2]张大江, 钱华林.一个利用教学证书实现的RBAC模型[J].小型微型计算机系统, 2001, 22 (8) :936-939.
RBAC权限设计模型 篇5
1.1 RBAC0
在RBAC0中抽象出了角色的概念,角色是权限的集合,权限就是对系统资源的操作许可。
在模型中,一个用户可以拥有多个角色,当然一个角色也可以同时分配给多个用户,当用户拥有了某个角色,那么就拥有了该角色的权限。用户拥有的不同角色会在不同的操作中激活,但无论用户拥有多少个角色,在一次会话过程中只激活若干角色,在某一个特定时刻只激活一个角色。
1.2 RBAC1
RBAC1对RBAC0中角色的概念进行了扩展,为角色增添了优先级的概念,因此在RBAC1模型中角色可能有优先级或继承,此时的角色是一个树形结构。
RBAC1模型的这种角色的继承关系符合现实生活的实际,如总经理角色比普通员工的角色级别更高,则总经理角色拥有比普通员工更多的权限。
1.3 RBAC2
RBAC2是在RBAC0的基础上扩展的,而不是在RBA-C1的基础上进行扩展的,在用户和角色间建立约束。约束是指用户和角色间建立的约束关系,如那些具有互斥关系的角色不能被授权给同一个用户。在为用户分配多个角色时,角色之间权限可能有冲突,即可能会拥有互斥的权限。
1.4 RBAC3
RBAC3是对RBAC1和RBAC2的整合,综合了两者的功能和优点。
2 OA系统中的权限管理模型
在RBAC权限模型中,是基于角色进行授权的。这种授权的机制很好,但有时候却不太符合国内企业的实际情况,特别是某些企业的管理不太规范的情况下。在实际项目中,不仅仅对角色授权,还要支持直接对用户单独授权。当然对用户的授权可以通过创建一个不存在的角色通过对角色的授权来实现,但用户往往不太赞同,也就是不太习惯虚拟角色,同时会造成角色迅速膨胀,就出现了针对用户进行授权的需求,在实际操作中也往往采用直接对用户进行授权。这样一来,就需要对RBAC再次进行扩展来满足需要。
在系统的开发中,就采用了针对角色授权和针对用户授权相结合的方式来进行,系统的授权模型如图1所示。
在OA系统的开发中,根据用户需求,得到如图1所示的权限管理模型,图1中各实体简单介绍如下:
(1)ACL:访问控制列表,是权限管理模块的核心,一条ACL定义了一条权限,即对某一个模块所具备的权限。(2)Permission:权限,共分为Create、Read、Update、Delete四种。(3)Module:系统资源模块,即将系统功能划分为一个一个的模块,每一个模块对于一个名字、编号和访问该模块的URL地址。(4)Role:角色,也就是该角色有哪些权限,即包含了几条ACL记录。(5)UserRoles:为了授权的方便,将不同的角色划分为一条UserRoles记录,包含了不同角色的权限。(6)User:用户,为了满足企业需求,可直接对用户授权,既可通过ACL直接授权,也可通过UserRoles授权。
3 管理模型在OA系统中的应用
为了使用图1所示的权限管理模型实现对系统权限的灵活管理,首先要对系统中的资源模块进行划分和定义。这里的资源模块指系统中各种功能模块、数据、操作等等,是主体能访问的各种对象。由于对象的机密情况及所属单位的不同,能对操作的用户也不相同。
在进行该模块开发时首先要进行的就是进行对象的定义。对象的定义可分为以下几个部分,分别是功能模块定义、界面元素控制和数据信息控制。
在实现时是对系统功能结构图中的每一小功能模块作为一个系统对象,对访问权限划分为CRUD,如:
可以根据需要对系统的每个功能模块进行划分,这样就可以把对每一个子功能的操作定义成一条权限,从而形成系统的权限集合。
然后根据企业需要进行角色的定义,之后对角色进行授权,也就是包含哪些权限。这里的权限,就是对上述系统功能模块的访问权限,也就是哪些角色对系统中的哪些功能模块具有哪些权利(CRUD)。基于角色的访问控制方法就是用角色来充当用户行使权限的中介,对角色进行授权,角色的权限分配给用户,这样,用户与角色之间以及角色与权限之间就形成了两个多对多的关系,即一个用户可以拥有多个角色,一个角色也可以供多个用户使用。即如果某个用户拥有角色M的同时还拥有N的角色,即双重甚至多重角色,那么在默认的情况下,系统会为该用户分配角色M和角色N拥有的所有权限,权限为两个角色的权限的合集。因此在为用户分配权限之前应该首先创建角色,通过角色为用户授权。
最后是对企业人员进行角色的划分,根据事先定义的权限,这些人员都属于某一个或几个角色,这样该人员就具备了这些角色所具有的权限,也就是可以使用系统中的哪些功能了。需要注意的是,如果某个用户具有多个角色,而这些角色的权限有可能出现冲突,这时该怎么办?解决办法是为不同的角色定义优先级,并且优先级各不相同,当权限发生冲突时,以高优先级的角色所定义的权限为准。
4 结束语
基于RBAC的权限管理机制具有通用性,可推广到较复杂的应用系统,特别是对权限管理要求严格的应用系统。
摘要：分析了传统的RBAC权限管理模型,并根据国内企业的需求和特点,在RBAC的基础上设计了更灵活的权限管理机制,很好的满足了企业的需求。
关键词：基于角色的权限管理,办公自动化,权限管理模型
参考文献
[1]余文森,张正秋,章志明,等.基于角色的访问控制模型中私有权限问题的研究[J].成都:计算机应用研究,2004,21(4):50-51.
[2]黎川,周定康,熊娟.数字校园中基于角色的访问控制[J].南昌:计算机与现代化,2009(4):32-33.
RBAC权限设计模型 篇6
在各种基于J2EE的应用开发中, 以认证授权为基本操作的权限控制子系统是不可缺少的部分, 而且在模块化的系统开发中, 一个基本前提就是权限控制子系统对各业务逻辑系统透明, 简单说就是业务逻辑系统中不应包含权限控制的语句。因此构建一个通用的、便携性强的、便于配置和管理的真正贴近开发实际的安全控制架构尤为重要。
2. Acegi架构的不足
轻量级J2EE框架Spring的出现, 无疑为应用的便携性铺平了道路, 通过IoC和AOP等核心技术的使用, 使得POJO取代EJB成为程序的主角, 开发者可以为POJO业务对象提供声明式的事务管理和其他横切性的企业级服务。而构建在它上的Acegi秉承了这一极为重要的优势, 成为了J2EE安全领域事实上的标准。但在实际的应用开发中, Acegi也存在着一些不能满足实际应用的地方:
其一、Acegi给出的基于XML文件授权信息的配置策略, 显然不符合实际的应用环境, 在大多数应用中权限往往是动态变化的, 管理员可能随时需要配置、维护和修改权限信息。而采用XML文件作为受保护资源的授权信息的载体, 显然无法满足这一基本需求。
其二、Acegi提供的基于RDBMS的用户权限控制模型虽然适合一些小规模, 低复杂度的使能应用, 但对错综复杂的安全需求缺乏统一的支持, 需要进一步引入更为复杂、适用面更加广泛的权限控制模型。
3. 在Acegi中引入RBAC的利弊分析
面向角色的访问控制 (RBAC) 模型实现了用户与访问权限的逻辑分离, 减少了授权管理的复杂性, 降低了管理开销和管理复杂度。但在实际的J2EE应用的设计与开发中, 是否采用基本的RBAC权限管理模型仍需要根据实际需求做出取舍, 以求达到系统复杂度和效率的平衡。
比如在对Acegi权限管理的改进和扩展中, 我们虽然可以考虑直接把标准的基于RBAC的权限管理数据模型引入Acegi中, 但对大多数基于Web的应用来说, 这却不一定是最好的解决方案, 原因如下:
权限校验复杂。在大多数Web应用中, 系统主要关注的是对Web资源和业务方法的保护, 当客户发出对Web资源的访问请求时, 这样的请求在很多时候非常频繁, 采用RBAC权限管理模型系统在进行权限校验时需要不断的遍历和递归, 对系统性能的负面影响显而易见。
对领域对象的权限控制实现起来也比较低效。比如在笔者参与开发过的一个基于Web的内容管理系统 (Content Management System, CMS) 中, 员工可以创建信息栏目, 这时他就是该栏目的所有者, 拥有对该栏目的一切权力, 而RBAC模型无法直接对用户进行授权, 必须通过角色, 这无疑是低效的。
4. 在Acegi中RBAC模型的改进
因此, 这里提出一种折中的权限管理方案。把对Web资源和业务方法的保护同对领域对象的保护隔离开来, 采用不同的数据模型。具体如下所示:
(1) 对Web资源和业务方法的保护采用简化的RBAC模型
因为在绝大多数应用中, 对Web资源和业务方法而言, 操作只有“访问”一种情况, 所以在RBAC模型中去掉operations表, 直接把资源同角色联系起来。数据管理模型如图1所示:
这样, 不但提高了系统权限校验的效率, 而且使得每张表的容量比起RBAC模型来明显减少, 使得我们可以把它们整体放入缓存中, 进一步减少了授权操作的时间, 加快了系统的响应速度。
(2) 对领域对象的保护采用ACL模型
ACL模型是操作系统普遍采用安全控制模型。从领域对象的角度而言, 每个领域对象都有各自的访问控制列表 (ACL) , 各个ACL可能持有若干个访问控制项 (ACE) , ACE真正给出了操控当前领域对象的具体权限信息。该模型的E-R图如图2所示:
借助于这一在操作系统中普遍使用的ACL模型, 不但模型本身更容易理解, 而且可以直接对用户或角色授权, 这对领域对象的保护提供了极大的灵活性。
5. 结束语
本文在基于对Acegi的研究的基础上, 通过对Acegi进行改进扩展, 在构建一个通用性好的、便于配置和管理的安全控制架构方面做了一定的尝试。
摘要：本文在对Acegi中引入RBAC模型的利弊分析基础上, 提出了在Acegi中采用一种折衷的权限管理方案。该方案把对Web资源和业务方法的保护同对领域对象的保护隔离开来, 采用不同的访问控制模型。
关键词：Acegi,认证, 授权,RBAC
参考文献
[1]Rod Johnson.Professional Java development with the springframework[M].USA:Wiley Publishing, 2005.
RBAC权限设计模型 篇7
企业采购管理系统采用了三层架构的客户/服务器体系结构, 使的各用户能够通过互联网随时随地对系统进行应用, 而这同时对系统的安全性和健壮性提出了更高的要求。系统应有严密的数据验证和身份认证, 保证数据的准确和安全, 同时还需要有详细的权限划分, 以配合企业采购系统的实际管理制度和采购流程管理控制。基于角色的访问控制RBAC (Role-Based Access Control) 授权模型, 访问控制策略体现在RBAC模型里是用户-角色、角色-权限和角色-角色之间的关系。采用RBAC的最大好处在于将用户和其具有的权限分离开来, 管理员可以将用户的授权和权限的划分进行分别处理, 通过给角色授予权限, 给用户分配角色来实现用户的授权操作。这降低了管理和维护用户权限的复杂度和数据库的存储开销, 增加了系统的可靠性和安全性, 能够较好的防止非法用户的入侵和合法用户的非法操作造成的数据破坏。
1 RBAC模型的基本思想
1.1 RBAC模式介绍
RBAC的基本思想是在用户和访问权限之间引入角色的概念, 将用户和角色联系起来, 通过对角色的授权来控制用户对系统资源的访问。
角色是访问权限的集合, 用户通过赋予不同的角色获得角色所拥有的访问权限。一个用户可拥有多个角色, 一个角色可授权给多个用户;一个角色可包含多个权限, 一个权限可被多个角色包含。用户通过角色享有权限, 它不直接与权限相关联, 权限对存取对象的操作许可是通过角色实现的。
1.2 基本RBAC模型
基本RBAC定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中, 包含用户users (USERS) 、角色roles (ROLES) 、目标objects (OBS) 、操作operations (OPS) 、许可权permissions (PRMS) 五个基本数据元素, 此模型指明用户、角色、访问权限和会话之间的关系。每个角色至少具备一个权限, 每个用户至少扮演一个角色;可以对两个完全不同的角色分配完全相同的访问权限;会话由用户控制, 一个用户可以创建会话并激活多个用户角色, 从而获取相应的访问权限, 用户可以在会话中更改激活角色, 并且用户可以主动结束一个会话。
权限:对受保护的资源操作的访问许可 (Access Permission) , 是绑定在特定的资源实例上的。对应地, 访问策略 (Access Strategy) 和资源类别相关, 不同的资源类别可能采用不同的访问模式 (Access Mode) 。例如, 页面具有能打开、不能打开的访问模式, 按钮具有可用、不可用的访问模式, 文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如, 某个数据集的可修改访问模式就包含了可查询访问模式。
用户:是权限的拥有者或主体。用户和权限实现分离, 通过授权管理进行绑定。
用户组:一组用户的集合。在业务逻辑的判断中, 可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念, 主要实现用户 (个人的身份) 的方式。
角色:权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如, 科长角色同时具有科长角色、科内不同业务人员角色。
操作:完成资源的类别和访问策略之间的绑定。
分配角色权限PA:实现操作和角色之间的关联关系映射。
分配用户角色UA:实现用户和角色之间的关联关系映射。
2 采购管理系统分析
2.1 采购管理系统总体主流程介绍及明细功能需求分析
通过对企业的实际调研, 并对其需求进行分析, 确定本系统的主流程如下:
需求计划录入—需求计划确认—编制采购计划—报批采购计划—审批采购计划—下达采购计划—编制询价书—发出询价书—报价—报价揭示—编制合同申请—合同申请计划员审批—合同申请领导审批—编制合同—合同归档
基于主流程的分析及根据具体的需求确定采购管理系统的主要功能模块如表1。
2.2 系统角色分析
表1系统需求明细
为了降低管理与维护成本, 对系统访问权限实施动态管理, 简化和规范授权操作, 确保对系统资源的正确和安全访问, 建立相应的安全体系模型实现根据角色来访问控制的机理, 则需要理清使用该管理系统的用户类别。根据用户的职责不同, 可以分为以下角色:
计划员:拥有需求计划管理 (需求计划录入、未确认需求计划查询) 、采购计划管理 (编制采购计划、计划报批、计划下达、计划修改与删除) 、审核管理 (合同申请计划审批) 的管理权限。
部门领导:拥有审核管理 (采购计划审批、合同审批) 的管理权限。
采购员:拥有询价报价管理 (编制询价书、报价揭示、询价书查询) 、合同管理 (编制合同申请、合同申请查询、查询合同) 的管理权限。
系统管理员:拥有除供应商的公开求购及定向询价书报价两项功能以外的所有管理权限。
供应商:拥有公开求购及定向询价书报价的权限。
3 采购管理系统中权限管理具体设计
3.1 系统的运行机理
从系统的安全管理角度出发, 系统的所有用户必须为能合法使用信息系统的员工, 包括系统管理员和普通用户, 系统管理员可以添加、修改和删除用户, 还可以对普通用户的角色和权限进行分配。普通用户则只能在系统管理员的授权下才能进行相关的业务操作。另外系统总体设计并实现各个功能模块和角色的设置, 并将各模块的描述信息存入功能模块信息表中, 把各角色的权限信息放在角色信息表中。
当用户登陆时首先判断用户名与密码, 错误则给出出错信息。如正确, 进一步去用户角色关系表中读取出属于该用户的角色信息列表, 如果列表为空, 表示该用户无权访问管理系统, 给出出错信息, 不予登录。进入系统后用户调用应用。权限控制模块使用应用的标识和用户的角色列表, 在数据库中查询角色与应用的关系。若确定该角色有访问该应用的权限则进入下一步, 否则提示无权访问。
3.2 权限管理的数据模型设计
数据库的建立是整个系统开发过程中一个最重要的环节。数据库结构设计的好坏将直接影响到整个系统的效率和功能的实现, 本系统的权限设计如图4所示。
在权限设计中使用了五张表, 具体设置请参见图5
1) 系统用户表 (SYS_USERS) :记录系统中所有用户的详细情况。
2) 角色信息表 (SYS_USER_ROLE) :记录系统中所有可供分配的角色。具体的角色安排在第二节中已经具体分析。
3) 用户角色表 (SYS_USER_ROLE) :记录用户与角色之间的对应关系。
4) 菜单角色表 (SYS_MENU_ROLE) :用于记录各角色对应的菜单功能。
5) 菜单信息表 (SYS_MENUS) :用于记录各菜单的详细信息。
4 结束语
本文在分析了企业采购系统具体需求上, 在用户权限方面论述了一种基于RBAC模型的企业管理系统的实现技术方案。该权限管理模型已成功应用于系统的设计和开发。实践表明, 采用基于RBAC模型的权限具有以下优势:权限分配直观、容易理解, 简单易用, 便于使用;扩展性好, 支持权限多变的需求;分级权限适合分层的组织结构形式;可重用性强。
摘要：该文从企业的实际需求出发, 分析和总结了企业采购管理系统对用户管理和权限控制的具体需求, 采用了基于角色的权限管理模型来解决在系统中可能存在的各个角色所能拥有的权限问题, 并对该系统的权限管理模型数据表和功能模块进行了设计。
关键词：RBAC,权限管理,采购管理系统
参考文献
[1]李丽琳.基于角色的用户权限管理在养猪场信息化平台中的应用[J].电脑编程技巧与维护, 2011 (3) .
[2]齐斌.基于角色的权限管理模型在大学生创新性项目管理系统中的研究与应用[J].软件导刊, 2011 (3) .