权限系统设计

权限系统(1)--基本模式

在系统中发生的事情，抽象的说都是某个主体(subject)在某个资源(resource)上执行了某个操作(operation)。
subject --[operation]--> resource
所谓权限管理，就是在这条信息传递路径中加上一些限制性控制。
主体试图去做的 limited by 系统允许主体去做的 = 主体实际做的。
可以看到，权限控制基本对应于filter模式。subject试图去做的事情应该由业务逻辑决定，因而应该编码在业务系统中。

先考虑最粗粒度的控制策略，控制点加在subject处，即无论从事何种操作，针对何种资源，我们首先需要确认subject是受控的。只有通过认证的用户才能使用系统功能，这就是authentication。boolean isAllowed subject)
稍微复杂一些，控制可以施加在subject和operation的边界处（此时并不知道具体进行何种操作），称为模块访问控制，即只有某些用户才能访问特定模块。isAllowed(subject, operation set)
第三级控制直接施加在operation上，即操作访问控制。operation知道resource和subject（但它尚没有关于resource的细节知识)，我们能够采取的权限机制是bool isAllowed(subject, operation, resource), 返回true允许操作，返回false则不允许操作。

最简单的情况下，subject与resource之间的访问控制关系是静态的，可以直接写成一个权限控制矩阵

for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1


isAllowed(subjectA, resourceA)恒等于true

如果多个operation的权限控制都可以通过这种方式来表示，则多个权限控制矩阵可以叠加在一起

for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11

当subject和resource的种类很多时，权限控制矩阵急剧膨胀，它的条目数是N*M。很显然，我们需要进行矩阵分解。这也是最基本的控制手段之一: 在系统中增加一个瓶颈，或者说寻找到隐含的结构。
subject_resource = subject_role * role_resource
这样系统权限配置条目的数量为 N*R + R*M, 如果R的数目远小于subject和resource，则实现简化。这称为RBAC(role based access control)，它的一个额外好处是权限系统的部分描述可以独立于subject存在，即在系统中没有任何用户的时候，通过角色仍然可以表达部分权限信息。可以说角色是subject在权限系统中的代理(分解)。

有时候引入一个瓶颈还不过瘾，有人引入组的概念，与role串联，
subject_resource = subject_group_role * role_resource
或着group与role并联,
subject_resource = subject_group * group_resource

与role稍有不同，一般情况下group的业务含义更加明显，可能对应于组织结构等。将组织机构明确引入权限体系，有的时候比较方便，但对于权限系统自身的稳定性而言，未见得有什么太大的好处。并联模式有些多余，串联模式又过于复杂，细节调整困难，特别是多条控制路径造成的冲突情况。一般情况下，我不提倡将group引入权限控制中。

比操作控制更加深入的控制就是数据控制了，此时需要对于resource的比较全面的知识。虽然表面上，仍然是
boolean isAllowed(subject, operation, resource)，但控制函数需要知道resource的细节。例如行级控制(row-level)或者列级控制(column-level)的实现。因为我们一般情况下不可能将每一个条目都建模为独立的resource，而只能是存在一个整体描述，例如所有密级为绝密的文档。在witrix平台中，数据控制主要通过数据源的filter来实现，因为查询条件（数据的定位条件)已经被对象化为Query类，所以我们可以在合适的地方自由的追加权限控制条件。

以上的讨论中，权限控制都是根据某些静态描述信息来进行的，但现实世界是多变的。最简单的，当subject从事不同业务时，对应于同一组资源，也可能对应的权限控制并不同(在witrix平台中,对应于IDataSource的模式切换)。更复杂一些, 在不同的时刻, 我们需要根据其他附加信息来作出是否允许操作的判断, 即此时我们权限设置的不仅仅是一些静态的描述信息, 而是一个完整的控制函数, 这就是所谓的工作流权限控制,一种动态权限控制.

权限系统(2)--operation

权限控制可以看作一个filter模式的应用, 这也符合AOP思想的应用条件。在一个简化的图象中，我们只需要将一个判别函数 isAllowed(subject, operation, resource)插入到所有安全敏感的函数调用之前就可以了。虽然概念上很完美，具体实现的时候仍然有一些细节上的问题。基本的困难在于很难在最细的粒度上指定权限控制规则（连续的？动态的？可扩展的？），因而我们只能在一些关键处指定权限规则，或者设置一些整体性的权限策略，然后通过特定的推理来推导出细粒度的权限规则，这就引出结构的问题。我们需要能够对权限控制策略进行有效的描述（控制策略的结构），并且决定如何与程序结构相结合。subject, operation和resource为了支持推理，都可能需要分化出复杂的结构，而不再是简单的原子性的概念。而在与程序结构结合这一方面，虽然AOP使得我们可以扩展任何函数，但这种扩展需要依赖于cutpoint处所能得到的信息，因而权限控制的有效实施也非常依赖于功能函数本身良好的设计。有的时候因为需要对结构有过于明确的假定，权限控制的实现不得不牺牲一定的通用性。

下面我们将分别讨论一下operation, subject和resource的结构分解的问题。首先是operation。
说到推理结构，让人最先想起的就是决策树，树形结构，在面向对象语言中可以对应于继承。金字塔式的树形结构也正是在现实世界中我们应用最多的控制结构。通过层层分解，operation的结构可以组织为一棵树,
应用程序 ==> 各个子系统 ==> 每个子系统的功能模块 ==> 子功能模块
==> 每个模块的功能点(具有明确的业务含义) ==> 每个功能点对应的访问函数(程序实现中的结构)
一个常见的需求是根据权限配置决定系统菜单树的显示，一般控制用户只能看到自己有权操作的功能模块和功能按钮。这种需求的解决方法是非常直接的。首先，在后台建立子系统到功能模块，功能模块到功能点以及功能点到实现函数之间的映射表（如果程序组织具有严格规范，这甚至可以通过自动搜集得到）。然后，在权限配置时建立用户与功能点之间的关联。此时，通过一个视图，我们就可以搜集到用户对哪些功能模块具有访问权限的信息。

为了控制菜单树的显示，witrix平台中的SiteMap采用如下策略：
1. 如果用户对某个子功能具有操作权限，则所有父菜单项都缺省可用
2. 如果用户对某个功能具有操作权限，并且标记为cascade，则所有子菜单项都自动缺省可用
3. 如果明确指定功能不可用，则该菜单及子菜单都强制不可用
4. 如果明确指定功能对所有人可用，则不验证权限，所有子菜单自动缺省可用
4. 强制设定覆盖缺省值
5. 不可用的菜单缺省不可见
6. 明确标记为可见的菜单即使不可用也可见
7. 父菜单可见子菜单才可见
我们通过预计算来综合考虑这些相互影响的控制策略。尽量将推导运算预先完成也是解决性能问题的不二法门。

在witrix平台中，每一次网络访问的url都符合jsplet框架所要求的对象调用格式，需要指定objectName和objectEvent参数，这就对应于功能点的访问函数。访问控制点集中在objectManager并且访问格式是标准的。使用spring等AOP方式实现细粒度访问控制，困难似乎在于不容易引入外部配置信息（例如功能点信息等），而且控制点所对应的对象函数格式也不统一，因而多数需要在细粒度上一一指定。

权限系统(3)-- subject

权限控制中，subject可能不会简单的对应于userId, 而是包含一系列的security token或certificate, 例如用户登陆地址，登陆时间等。一般情况下，这些信息在权限系统中的使用都是很直接的，不会造成什么问题。
subject域中最重要的结构是user和role的分离，可以在不存在user的情况下，为role指定权限。有人进一步定义了userGroup的概念，可以为userGroup指定role，而user从其所属的group继承role的设置。一般情况下，我不提倡在权限系统中引入userGroup的概念。这其中最重要的原因就是它会造成多条权限信息传递途径，从而产生一种路径依赖, 并可能出现信息冲突的情况。一般user与group的关联具有明确的业务含义，因而不能随意取消。如果我们希望对user拥有的权限进行细调，除去user从group继承的某个不应该拥有的权限，解决的方法很有可能是所谓的负权限，即某个权限条目描述的是不能做某某事。负权限会造成各个权限设置之间的互相影响，造成必须尝试所有权限规则才能作出判断的困境，引出对额外的消歧策略的需求，这些都极大的限制了系统的可扩展性。在允许负权限的环境中，管理员将无法直接断定某个权限设置的最终影响，他必须在头脑中完成所有的权限运算之后才能理解某用户最终拥有的实际权限，如果发现权限设置冲突，管理员可能需要多次尝试才能找到合适方案。这种配置时的推理需求可能会增加配置管理的难度，造成微妙的安全漏洞，而且负权限导致的全局关联也降低了权限系统的稳定性。我更倾向于将group作为权限设置时的一种辅助标记手段，系统中只记录用户最终拥有的角色，即相当于记录用户通过group拥有权限的推导完成的结果, 如果需要权限细调，我们直接在用户拥有的角色列表上直接进行。当然，如果实现的复杂一些，权限系统对外暴露的接口仍然可以模拟为能够指定userGroup的权限。
推理在面向对象语言中最明显的表现是继承，所以有些人将subject域中的推理直接等价于role之间的继承问题，这未必是最好的选择。继承可以形成非常复杂的推理关系，但是可能过于复杂了（特别是直接使用sql语句无法实现树形推理查询）。按照级列理论，从不相关发展到下一阶段是出现简单的序关系，即我们可以说subject出现级别上的差异，高级别subject将自动具有低级别的权限。一种选择是定义roleRank,规定高级别role自动具有低级别role的权限，但考虑到user与role的两分结构，我们也可以同时定义userRank和roleRank,规定高级别user自动具有低级别的role，而role之间不具有推理关系。在面向对象领域中，我们已经证实了完全采用继承来组织对象关系会导致系统的不稳定，所以我倾向于第二种选择，即将role看作某种类似于interface的东西，一种权限的切片。为了进一步限制这种推导关系，我们可以定义所谓的安全域的概念. security domain, 规定推导只能在一定的域中才能进行。
select user.userId, role.roleId
from user, role
where user.userRank > role.roleRank
and user.domain = role.domain

将权限控制一般需要施加在最细的粒度上，这在复杂的系统中可能过于理想化了。复杂的情况下我们需要进行局部化设计，即进行某些敏感操作之前进行一系列复杂的权限校验工作。当完成这些工作之后，进入某个security zone, 在其中进行操作就不再需要校验了。
总的来说，权限系统采用非常复杂的结构效果未必理想。很多时候只是个管理模式的问题，应该尽量通过重新设计权限空间的结构来加以规避。不过在一些非常复杂的权限控制环境下，也许简单的描述信息确实很难有效的表达权限策略（虽然我从未遇到过），此时尝试一下规则引擎可能比在权限系统中强行塞入越来越多的约束要好的多

权限系统(4)--resource

权限管理中进行数据访问控制，其基本模式如下
operation target = selector(resource)
selector = user selector + auth filter
这里需要对resource的结构，以及选择算子的显式建模。selector必须允许权限系统追加filter，例如
IDataSource包中所使用的Query对象。
sql语言的表达能力有限, 作为选择算子来使用有时需要resource作一些结构上的调整，增加一些冗余的字段。例如表达一段时间内的利率，我们需要使用from_date和to_date两个字段来进行描述，其中to_date的值与下一条记录的from_date相同。
value from_date to_date
0.01 2003-01-01 2003-05-01
0.012 2003-05-01 2004-01-01

如果表达一条航线中的多个阶段，我们可能会在每条记录中增加起始站和终点站两个字段。
更重要的一个常见需求是树形结构在关系数据库中的表达。为了能够直接操纵一个分支下的所有记录，在层次固定的情况下，我们可能会增加多个分类字段，例如数据仓库中的层次维度。在层次数目不确定的情况下，我们将不得不使用层次码或者类似于url的其他方案，通过layer_code like '01.01.%' 之类的语句实现分支选择。为了限制选择的深度，我们可能还需要layer_level字段。基于层次码和层次数，我们可以建立多种选择算子，例如包含所有直接子节点，包含自身及所有父节点等等。
http://www.dbazine.com/oracle/or-articles/tropashko4

权限系统(5)--动态性

动态权限最简单的一个表现是时限性，subject只在某个时间段内具有某种权限。这只需要在user和role的映射中，或者role自身的属性中增加startTime和expireTime即可。

更复杂的动态性一般与流程控制相关，此时权限控制应该由工作流系统完成，而不是在数据上增加越来越多的权限标记。在witrix平台中，使用tpl模板技术来定制权限设置。
http://canonical.blogdriver.com/canonical/658364.html

 

基于 RBAC 模型的权限管理系统的设计和实现

裴辉东 梁云风

（ 1. 山东省烟台海颐软件股份有限公司；2山东省烟台东方电子信息产业股份有限公司）

 

摘要： 提出了基于RBAC模型的权限管理 系统的 设计和实现方案。介绍了采用的J2EE架构的多层体系结构设计，阐述了基于角色的访问控制RBAC模型的设计思想 ，并讨论了权限管理系统的核心面向对象设计模型，以及权限访问、权限控制和权限存储机制等关键技术。

关键词： 权限管 理系统；角色；访问控制；RBAC模型；J2EE；LDAP

 

0 引言

管理信息系统是一个复杂的人机交互系统，其中每个具体环节都可能受到安全威胁。构建强健的权限管理系统，保证管理信息系统的安全性是十分重要的。权限管理系统是管理信息系统中可代码重用性最高的模块之一。任何多用户的系统都不可避免的涉及到相同的权限需求，都需要解决实体鉴别、数据保密性、数据完整性、防抵赖和访问控制等安全服务 (据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访问方式。用户登录时调用权限管理系统的用户鉴别服务，如果验证成功，调用权限计算服务，并返回权限关系表，以HashMap的方式存放到登录用户的全局Session中；如果没有全局的Session或者过期，则被导向到登录页面，重新获取权限。

b.直接URL资源采用基于CL访问方式进行的访问控制。如果用户直接输入URL地址访问页面，有两种方法控制访问：1.通过权限标签读取CL进行控制；2.采取Filter模式，进行权限控制，如果没有权限，则重定向到登录页面。

5 权限控制机制

权限所要控制的资源类别是根据应用系统的需要而定义的，具有的语义和控制规则也是应用系统提供的，对于权限管理系统来说是透明的，权限将不同应用系统的资源和操作统一对待。应用系统调用权限管理系统所获得的权限关系表，也是需要应用系统来解释的。按此设计，权限管理系统的通用性较强，权限的控制机制则由应用系统负责处理。

由于应用系统的权限控制与特定的技术环境有关，以基于 J2EE架 构的应用系统为例来说明，系统 主要的展示组件是JSP页面， 采用标记库和权限控制组件共同来实现。

a. 权限标识：利用标签来标识不同级别资源，页面权限标签将标识页面对象。

b. 权限注册：遍历JSP页面上的权限控制标签，读取JSP的控制权限。通过权限注册组件将JSP页面上的权限控制对象以及规则注册到权限管理信息系统中。

c. 权限控制：应用系统用户登录系统时，从权限管理系统获得权限关系表之后，一方面，权限标签控制页面展示；另一方面，利用权限控制组件在业务逻辑中进行相应的权限 控制 ， 尤其是和业务逻辑紧密联系的控制对象实例的权限控制。

6 权限存储机制

权限管理系统采用了两种可选的存储机制：LDAP（Lightweight Directory Access Protocol）目录服务数据库和关系型数据库。存储用户信息、组织结构、角色、操作、访问模式等信息。

其中，目录服务系统基于LDAP标准，具有广泛的数据整合和共享能力。元目录（Meta-Directory）功能允许快速、简洁的与企业现存基础结构进行集成，解决基于传统RDBMS等用户数据库与LDAP用户数据库的同步问题。

7 结语

本文论述了 一种基于RBAC模型的权限管理系统的 实现技术方案。该 权限管理系统 已成功应用于系统的设计和开发实践，与应用系统具有很好的集成。实践表明，采用 基于RBAC模型的权限具有以下优势：权限分配 直观、容易理解，便于使用；扩展性好，支持岗位、权限多变的需求；分级权限适合分层的组织结构形式；重用性强。

 

参考文献

1. 段云所（著）（Duan Yunsuo）。信息安全概论。北京:高等教育出版社（Beijing：Publishing House of Higher Education），2003

2. Kevin Duffey Vikram Goyal Ted Husted著。JSP站点设计编程指南（Professional JSP Site Design）。北京：电子工业出版社（Beijing：Publishing House of Electronics Industry），2002