1797人阅读
SHARE（19）
基本上搞过it的都知道权限控制其实是很麻烦的一件事情，但是不难理解。在我学习rbac之前，对权限的理解基本上就是权限分配给角色，角色又分配给用户组，然后用户可以属于用户组之类的。一些企业级应用可能会有更复杂的情况，比如A部门的员工甲，就分配A角色给甲；若甲在B部门兼职，那就不是简单的把B角色分配给甲，兼职还是有区别的；rbac也只是一种模式而已，看下面的标准介绍：
（，美国国家标准与技术研究院，）标准模型由个部件模型组成，这个部件模型分别是：
·基本模型（）；
·角色分级模型（，含，）；
·角色限制模型（，含，即和）；
·统一模型（）。
先从rbac0开始，上图：
此图从右往左分析
1、先看ob对象，也就是我们需要操作的对象，可以是用户本身，可以是角色本身，也可以是任何需要做权限控制的实体或虚拟的数据；
2、然后是op操作，操作不是权限，操作 +　对象　＝　权限，应该这样理解
拿windows的文件来举例，那么ob就是文件，op就是 读、写、执行等，而权限 可以理解成 ob 和 op的笛卡尔乘积；例如 &对文件的读权限、对文件的写权限等
3、prms权限，就是图中的大红圈，这个就不用解释了；role角色、user用户 & 这2个也很好理解
4、session这个比较难理解，现在我们假设没有session这个环节，其实权限控制也基本成型；
从分配上理解，prms可以分配给多个role，role可以有多个prms，role可以分配给多个user，user可以有多个role；
这样涉及到一个问题，当用户登录系统后，它具有的权限怎么计算呢？当然是先找这个用户有多少个角色，然后通过角色找总共有多少个权限，这样得到的一个权限的集合，这个集合就代表这个用户登录系统后的权限；
但是有的系统不是这么考虑的，rbac也不是这么考虑的；例如oracle，使用过的人应该知道，我们用sqlplus登录oracle时，需要选择此次登录，是用sysdba还是normal，这其实是对角色的一种选择；如果你选择以normal方式登录，那sysdba部分的权限就没有；那是不是sysdba部分的权限没有分配给用户呢？其实也不是
所以可以这样理解，所有分配给用户的权限是一个大的集合，而且是处于未激活状态，每次用户登录系统的时候，有选择的激活一部分的权限，作为此次登录系统的权限集合；
那如何做到这点，看rbac0的图，就是session；session是关联用户与角色的，每次用户登录，就会激活一个session，这个session对应的角色下的权限，就是此次用户登录系统的权限集合；
我个人理解，对于一些小的系统，比如一个简单的新闻发布网站，想用rbac来做权限控制，或者是自己想写一个简单的rbac小框架，可以考虑去除session的rbac0模式；
然后要注意ob对象这个数据库存储的设计，例如ob代表系统中注册的用户，有2000人，从理论上讲，用户的操作有 &读、修改、删除、新增，如果要分配的话，那所有用户都对自己的个人信息有 读、修改 权限，那就有 2000对象 x 读、修改操作 = 4000个权限，然后分配给2000个角色，这2000个角色又单独分配给对应的2000个用户，这样就变的非常的麻烦；
而且，管理员有所有用户的 读、修改 操作权限，那每新增一个用户，都要把这个用户 维护到 ob中，再产生prms，再分配给管理员，这样也非常的麻烦；
如果哪个系统需要这么完整细微的权限控制，那麻烦是必须的，如果简单的系统，例如用户只有 普通用户 和 管理员 2种，那完全没有必要弄的那么复杂；
我个人理解，rbac模式只是给出一个思路，具体实现是可以灵活多变的；
比如ob，我可以把“所有用户”作为一个ob，然后 对此ob的操作权限分配给管理员，这样就不怕动态新增用户的时候，需要维护权限表；
再如，我加上潜规则，在用户查看自己的信息、或修改自己的信息时，可以不经过rbac的权限校验，直接查看；当然，你要理解，这个潜规则，就不是rbac层面的东西了，应该是业务层面的东西；
再举个例子，用户新增单据的权限，限制用户只能最多新增10张单据，那这种权限在rbac中如何配置如何体现？
好吧，我只能告诉你，没有办法。rbac做的仅仅是 &有 或者 没有 &这个权限；至于 什么情况下有，是次数限制 &还是 &时间段限制，这些都不是rbac关心的，这些是业务层逻辑关心的。
好吧，说多了，来看看rbac1，上图：
rbac0 和 rbac1之前的差别在rh角色继承，这个继承和oop中类的继承很相似；不多解释，看看官方点的说明
角色间的继承关系可分为一般（）继承关系和受限（）继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则增加了职责关系的分离，进一步要求角色继承关系是一个树结构。一般继承的和受限继承的两者的区别在于：前者是图；而后者可以有多个父节点但只能有一个子节点，是一个反向树结构。
再看看rbac2，上图：
rbac2是在rbac0 的基础上（注意不是rbac1的基础上），加上了更多的限制，这种限制在某些机构可能会需要；
举个例子：出纳角色 &和 &会计角色，不允许分配给同一个人；这个需求就只能通过rbac2模式中的约束来实现；或者 保洁角色 和 公司管理员角色 &不能同时分配给一个用户（这基本上不会有人分配错吧！）
约束的作用是实现责任分离，就是用户相互之间的权限与责任，不要太多的重叠在一起，免得出麻烦
rbac2中的约束，分2种；
1、静态责任分离：就是我刚刚举的例子，不允许某些角色同时分配给一个用户；
2、动态责任分离：这就是要先理解session了；首先允许把互斥的2个角色分配给一个用户，突破了静态责任分离的限制；但是，不允许session同时激活2个互斥的角色，好吧，同样是实现了责任分离，不过这个被定义为动态的而已；
好了，最后终于要给大家介绍最牛x的rbac3，一句话：不解释，rbac1+rbac2=rbac3
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：490764次
积分：5719
积分：5719
排名：第3559名
原创：100篇
转载：80篇
评论：107条
(1)(1)(2)(3)(4)(4)(13)(1)(5)(3)(13)(8)(6)(19)(8)(3)(2)(1)(5)(4)(3)(3)(14)(5)(5)(16)(5)(6)(2)(3)(1)(2)(2)(9)(1)(2)人人网 - 抱歉
哦，抱歉，好像看不到了
现在你可以:
看看其它好友写了什么
北京千橡网景科技发展有限公司：
文网文[号··京公网安备号·甲测资字
文化部监督电子邮箱：wlwh@··
文明办网文明上网举报电话： 举报邮箱：&&&&&&&&&&&&温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(5263)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_086068',
blogTitle:'RBAC模型（1）',
blogAbstract:'一、
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}基于RBAC的权限管理系统的实现
> 基于RBAC的权限管理系统的实现
基于RBAC的权限管理系统的实现
0 引 言本文引用地址：
　　在许多的实际应用中，不只是要求用户简单地进行注册登录，还要求不同类别的用户对资源有不同的操作权限。目前，权限管理系统也是重复开发率最高的模块之一。在企业中，不同的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只满足自身系统的权限管理需要，无论在数据存储、权限访问和权限控制机制等方面都可能不一样，这种不一致性存在如下弊端：
　　(1)系统管理员需要维护多套权限管理系统，重复劳动；
　　(2)用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证；
　　(3)由于权限管理系统的设计不同，概念解释不同，采用的技术有差异，权限管理系统之间的集成存在问题，实现单点登录难度十分大，也给企业构建企业门户带来困难。
　　采用统一的安全管理设计思想，规范化设计和先进的技术架构体系，构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统，使得权限管理系统真正成为权限控制的核心，在维护系统安全方面发挥重要的作用，是十分必要的。
　　本文介绍一种基于角色的访问控制(role-based policies access control)模型的权限管理系统的设计和实现，系统采用基于.NFT Framework 2.0架构技术实现，并讨论了应用系统如何进行权限的访问和控制。
1 的基本思想
　　企业环境中的访问控制策略一般有3种：自主型访问控制方法、强制型访问控制方法和基于危色的访问控制方法()。其中，自主式太弱，强制式太强，二者工作最大，不便于管理。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其最著的2大特征是：(1)减小授权管理的复杂性，降低管理开销；(2)灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
　　美国国家标准与技术研究院(the national institute of standards and technology，NIST)标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0(core RBAC)、角色分级模型RBAC1(hierarchal RBAC)、角色限制模型RBAC2(constraint RBAC)和统一模型RBAC3(combines RBAC)。RBAC0模型如图1所示。
　　(1)RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中，包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色，而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
　　(2)RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系最一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
　　(3)RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
　　(4)RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。
　　事实上，RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组，也就是&Who对What(Which)进行How的操作&。这点我们在后面的描述中来详细讨论。
2采用.NET Framework 2.0架构设计
　　采用.NET Framework 2.0企业平台架构构建权限管理系统。NET Framework 2.0集成了先进的软件体系架构思想，具有采用多层分布式应用模型、基于组件并能重用组件、统一完全模型和灵活的事务处理控制等特点。而且在需要的时候，可以与Windows Server 2003的Active Directory进行无缝连接，直接通过Active Directory管理用户帐户。
　　系统逻辑上分为四层：表现层、业务层、数据访问层和数据层。
　　(1)表现层主要负责人机交互。可以使系统管理员通过Web浏览器访问。
　　(2)业务层提供业务服务，包括业务数据和业务逻辑，集中了系统业务处理。
　　(3)数据访问层主要负责数据的访问，如数据的增加、修改、删除和查找等。
　　(4)数据层主要负责数据的存储、组织和管理。数据层使用了 SQL Server 2000或SQL Server 2005来实现。
3核心对象模型设计
　　根据RBAC模型的权限设计思想，建立权限管理系统的数据库模型，如图2所示。
　　根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型，如图3所示。
　　由于RBAC解决的就是Who、What、How的问题，通过图3来做一个详细的描述：
　　Who：权限的拥用者或主体(User、Group、Role、Actor)。
　　What：权限针对的对象或资源(Resource)，资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。资源应该是一个树形结构。
　　How：具体的权限(Privilege，正向授权与负向授权)，这个权限是绑定在特定的对象上的。比如说教师测评系统新闻的发布权限，叫做&部门新闻发布权限&。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。权限，包括系统定义权限和用户自定义权限，用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理权限包含前两种权限)。
　　Operator：操作。表明对What的How操作。也就是Privilege+Resource的集合；
　　Role：角色，一定数量的权限的集合，是粗粒度和细粒度(业务逻辑)的接口。一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。Role的继承通过Group来体现，所以不考虑Role的继承关系。但是Role可以与相关的Group相关联，便于授权。
　　Group：用户组，权限分配的单位与载体，直接映射组织关系。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的ParentGroup是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否&同组&。
　　User：纯粹的用户，与权限分离，只能通过Role去关联相应的权限。
　　该模型中主要的关系有：分配资源操作RA(resource assignment)、分配角色权限PA(privi-lege assignment)、分配用户组角色GA(group as-signment)描述如下：
　　(1)分配资源访问RA：实现资源和操作之间的关联关系映射。
　　(2)分配角色权限PA：实现操作和角色之间的关联关系映射。
　　(3)分配用户组角色GA：实现用户组和角色之间的关联关系映射。 权限管理系统的操作模式主要分为以下3个步骤：
　　(1)创造资源、权限：用户创建一个资源(Re-source)的实例的时候指定相关的权限以及权限分配。比如学生测评只能创建者有修改的权限，同Group的人员只能拥有查看的权限。
　　(2)分配权限：系统管理员指定相关资源(Re-source)的权限分配，创建Role，创建Group，给Role分配权限，给Group分配User，给Group赋予某个Role等等。
　　(3)使用权限：User使用管理员分配的角色去使用相应的系统功能。
4权限访问机制
　　权限管理系统服务器端：提供集中管理权限的服务，负责提供用户的鉴别、用户信息、用户组信息，以及权限关系表的计算，如图4所示。
　　系统根据用户、用户组、角色、操作、访问方式和资源对象之间的关联关系，同时考虑权限的正负向授予，计算出用户的最小权限。在业务逻辑层使用SecuirtyManager.GetPower()方法实现此服务。采用代理Proxy模式，集中控制来自应用系统的所要访问的权限计算服务，并返回权限关系表，即二元组{ResouceId，OperationId}。
　　在表现层：可以通过访问能力表CL和访问控制表ACL两种可选的访问方式访问权限管理系统。以基于.NET Framework的教师测评系统为例，说明访问过程：
　　(1)首先采用基于表单的验证。考虑到需要鉴别的实体是用户，采用基于ACL访问方式。用户登录时调用权限管理系统的用户鉴别服务，如果验证成功，调用权限计算服务，并返回权限关系表，以HashTable的方式存放到登录用户的全局Session中；如果没有全局的Session或者过期，则被导向到登录页面，重新获取权限。
　　(2)直接URL资源采用基于CL访问方式进行的访问控制。如果用户直接输入URL地址访问页面，有两种方法控制访问：1．通过权限标签读取CL进行控制；2．采取页面载人判断权限模式，进行权限控制，如果没有权限，则重定向到登录页面。
5权限控制机制
　　由于应用系统的权限控制与特定的技术环境有关，以基于.NET Framework 2.0架构的教师测评系统为例来说明，系统主要的展示组件是aspx页面，采用标记和权限控制组件共同来实现。
　　(1)权限标识：利用页面标签来标识该页面上所有的权限访问控制对象。
　　(2)权限控制：应用系统用户登录系统时，从权限管理中获得权限关系表之后，一方面，权限标签控制页面展示；另一方面，利用权限控制组件在业务逻辑中进行相应的权限控制，尤其是和业务逻辑紧密联系的控制对象实例的权限控制。
6权限数据存储机制
　　权限管理采用了关系型数据库SQL Server2000或SQL Server 2005用来存储用户信息、用户组信息、角色、操作、权限等信息。
　　本文论述了一种基于RBAC的权限管理系统的实现技术方案。该权限管理系统已成功应用于教师测评系统的设计和开发实践，与教师测评系统具有很好的集成。实践表明，采用基于RBAC模型的权限管理系统具有以下优势：由于角色／权限之间的变化比角色／用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销；而且能够灵活地支持应用系统的安全策略，并对应用系统的变化有很大的伸缩性；在操作上，权限分配直观、容易理解，便于使用；分级权限适合分层的用户级形式；重用性强。
分享给小伙伴们：
我来说两句……
最新技术贴
微信公众号二
微信公众号一RBAC模型的权限管理系统的设计和实现-五星文库
免费文档下载
RBAC模型的权限管理系统的设计和实现
导读：RBAC模型的权限管理系统的设计和实现，管理信息系统是一个复杂的人机交互系统，构建强健的权限管理系统，保证管理信息系统的安全性是十分重要的，权限管理系统是管理信息系统中可代码重用性最高的模块之一，任何多用户的系统都不可避免的涉及到相同的权限需求，访问控制服务要求系统根据操作者已经设定的操作权限，权限管理系统也是重复开发率最高的模块之一，不同的应用系统都拥有一套独立的权限管理系统，每套权限管理系
RBAC模型的权限管理系统的设计和实现
管理信息系统是一个复杂的人机交互系统，其中每个具体环节都可能受到安全威胁。构建强健的权限管理系统，保证管理信息系统的安全性是十分重要的。权限管理系统是管理信息系统中可代码重用性最高的模块之一。任何多用户的系统都不可避免的涉及到相同的权限需求，都需要解决实体鉴别、数据保密性、数据完整性、防抵赖和访问控制等安全服务(据ISO7498-2)。例如，访问控制服务要求系统根据操作者已经设定的操作权限，控制操作者可以访问哪些资源，以及确定对资源如何进行操作。 目前，权限管理系统也是重复开发率最高的模块之一。在企业中，不同的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只满足自身系统的权限管理需要，无论在数据存储、权限访问和权限控制机制等方面都可能不一样，这种不一致性存在如下弊端：
a) 系统管理员需要维护多套权限管理系统，重复劳动。
b) 用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证。
c) 由于权限管理系统的设计不同，概念解释不同，采用的技术有差异，权限管理系统之间的集成存在问题，实现单点登录难度十分大，也给企业构建企业门户带来困难。
采用统一的安全管理设计思想，规范化设计和先进的技术架构体系，构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统，使得权限管理系统真正成为权限控制的核心，在维护系统安全方面发挥重要的作用，是十分必要的。
本文介绍一种基于角色的访问控制RBAC（Role-Based policies Access Control）模型的权限管理系统的设计和实现，系统采用基于J2EE架构技术实现。并以讨论了应用系统如何进行权限的访问和控制。
1 采用J2EE架构设计
采用J2EE企业平台架构构建权限管理系统。J2EE架构集成了先进的软件体系架构思想，具有采用多层分布式应用模型、基于组件并能重用组件、统一完全模型和灵活的事务处理控制等特点。 系统逻辑上分为四层：客户层、Web层、业务层和资源层。
a) 客户层主要负责人机交互。可以使系统管理员通过Web浏览器访问，也可以提供不同业务系统的API、Web Service调用。
b) Web层封装了用来提供通过Web访问本系统的客户端的表示层逻辑的服务。
c) 业务层提供业务服务，包括业务数据和业务逻辑，集中了系统业务处理。主要的业务管理模块包括组织机构管理、用户管理、资源管理、权限管理和访问控制几个部分。
d) 资源层主要负责数据的存储、组织和管理等。资源层提供了两种实现方式：大型关系型数据库（如ORACLE）和LDAP（Light Directory Access Protocol，轻量级目录访问协议）目录服务器（如微软的活动目录）。
2 RBAC模型
访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么[1]。
企业环境中的访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，二者工作量大，不便于管理[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销；2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）[1]。RBAC0模型如图1所示。
图1 RBAC0模型
a) RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、
角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。 b) RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继
承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
c) RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,
以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
d) RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。
3核心对象模型设计
根 据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型。如图2所示。
对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：
图2 权限管理系统核心类图
a .控制对象：是系统所要保护的资源（Resource），可以被访问的对象。资源的定义需要注意以下两个问题：
1.资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。
2.这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑：
一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。
例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。
另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。
b.权限：对受保护的资源操作的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略（Access Strategy）和资源类别相关，不同的资源类别可能采用不同的访问模式（Access Mode）。例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个
数据集的可修改访问模式就包含了可查询访问模式。
c.用户：是权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。
d.用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。
e.角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。
f.操作：完成资源的类别和访问策略之间的绑定。
g.分配角色权限PA：实现操作和角色之间的关联关系映射。
h.分配用户角色UA：实现用户和角色之间的关联关系映射。
该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。
4 权限访问机制
权限管理系统端：提供集中管理权限的服务，负责提供用户的鉴别、用户信息、组织结构信息,以及权限关系表的计算。如图3所示。
图3 权限的访问示意图
Fig.3 Privilege invoke
系统根据用户，角色、操作、访问策略和控制对象之间的关联关系，同时考虑权限的正负向授予，计算出用户的最小权限。在业务逻辑层采用Session Bean实现此服务，也可以发布成Web Service。采用代理Proxy模式，集中控制来自应用系统的所要访问的权限计算服务，并返回权限关系表，即二元组{ObjectId，OperatorId}。
应用系统端：可以通过访问能力表CL和访问控制表ACL两种可选的访问方式访问权限管理系统。 以基于J2EE框架的应用系统为例，说明访问过程：
a.首先采用基于表单的验证，利用Servlet方式集中处理登录请求[2]。考虑到需要鉴别的实体是用户，采用基于ACL访问方式。用户登录时调用权限管理系统的用户鉴别服务，如果验证成功，调
包含总结汇报、IT计算机、旅游景点、外语学习、党团工作、人文社科、出国留学以及RBAC模型的权限管理系统的设计和实现等内容。本文共2页
相关内容搜索