协同环境下基于角色的细粒度委托限制框架.doc

第1期刘伟等：协同环境下基于角色的细粒度委托限制框架91协同环境下基于角色的细粒度委托限制框架刘伟1,2，蔡嘉勇1,2，贺也平1（1. 中国科学院 软件研究所, 北京 100080；2.中国科学院 研究生院, 北京 100049）摘 要：提出了基于角色的细粒度委托限制框架，将角色分为对象角色和委托角色，实现细粒度的控制。分析了三类委托限制：时间限制、禁止限制和义务限制。针对不同类型定义相应限制规则，并用于描述条件委托和受控使用，条件委托要求满足条件后执行委托操作，防止非法扩散;受控使用约束委托权限，防止权限滥用。多个委托限制规则之间可能冲突，给出了时间复杂度为O(n2)的基于图论的一致性检测算法。关键词：计算机软件；协同；委托限制；基于角色的委托模型；冲突中图分类号：TP309 文献标识码：A 文章编号：1000-436X(2008)01-0083-09Role-based fine-grained delegation constraint framework in collaborative environmentsLIU Wei1,2, CAI Jia-yong1,2, HE Ye-ping1(1. Institute of Software, Chinese Academy of Sciences, Beijing 100080, China;2. Graduate School, Chinese Academy of Sciences, Beijing 100049, China)Abstract: A role-based delegation constraint method was introduced by separating role into two parts for fine-grained controlling. Three types of delegation constraints were analyzed, including temporal, prohibition and obligation. Using these constraints, conditional delegation and constrained usage was described. The former protected accepted delegation under certain conditions against diffuseness and abuse. The later constrained the usage of permission to avoid abuses of delegated permissions. An algorithm based on the graph theory for verifying the consistency of delegation constraints was presented, which had the time complexity of O(n2).Key words: computer software; collaboration; delegation constraint; role-based delegation model; conflict1 引言收稿日期：2006-07-13；修回日期：2007-08-10基金项目：“十五”国家科技攻关计划基金资助项目（2005BA113A01）；中国科学院研究生院创新资金资助项目Foundation Items: The Science-Technology Project of the National “Tenth Five-Year-Plan” of China (2005BA113A02); The Graduate Innovation Grant of Chinese Academy of Sciences随着分布式和网络的发展，越来越多的组织联合起来协同工作，这种趋势不但影响军事领域（例如联合军演），也涉及商业领域（例如合作研发）。协同需求不断增加，组织需要委托给协作方一定的访问权限以便信息共享。委托的基本思想是主动实体将权限赋予给其他实体，以便后者以前者的名义执行操作，其中主动实体称为委托者，其他实体称为被委托者。基于角色的访问控制（RBAC, role- based access control）1能够在大型组织中实施有效的授权,研究人员在其基础上引入委托的概念,提出基于角色的委托模型27（RBDM, role-based delegation model），支持委托者自主地委托角色或权限，为系统提供灵活的授权管理方式，减轻集中式管理的负担。另一方面，委托导致权限在多个实体间传递，权限滥用和非法扩散的可能性大大增加。针对安全问题，现有的模型重点研究如何对委托实施约束，主要采用2种方式：1）细化委托粒度，例如PBDM5定义可委托角色集合，限制允许委托的权限；2）控制委托范围，例如RDM20002定义先决条件，检查被委托者的资格，定义委托深度，限制委托路径。虽然上述方法解决了委托粒度、委托范围等限制问题，但仍然存在不足：首先，限制条件只检查被委托者的身份，没有考虑委托角色的内在属性；其次，限制条件的检查仅在委托操作之前进行，一旦委托操作执行，委托者失去控制委托权限的能力。因此，现有委托模型仍然面临以下安全威胁：1) 委托者可以随意地将重要权限委托给协作方，违反系统安全策略（例如职责隔离8）；2) 委托者无法控制委托权限的使用方式，可能造成权限滥用；3) 委托的安全主要由安全管理员负责，管理负担过重。为了有效管理和限制委托操作，本文提出协同环境下基于角色的细粒度委托限制框架。将RBAC中的角色分为对象角色和委托角色，前者用于访问控制，后者用于委托限制，实现细粒度控制。实施委托约束需要对委托限制分类，采用不同的规则描述相应类型的限制。分析3类委托限制：时间限制、禁止限制和义务限制。时间限制是委托的时序约束；禁止限制是委托不能违反的原则；义务限制是委托必须满足的要求。根据上述限制规则定义条件委托，委托操作必须满足所有委托条件后才能执行，解决第1类安全威胁；提出受控使用的概念，委托者增加规则，约束委托权限的使用方式，解决第2类安全威胁；管理员制定全局性策略，委托者定义自主性策略，共同管理委托操作，解决第3类安全威胁。多个限制规则之间可能存在冲突，给出时间复杂度为O(n2)的基于图论的一致性验证算法，有效地检测限制冲突。本文剩余部分的组织如下：第2节介绍工作基础；第3节介绍委托限制的分类；第4节描述委托限制框架和委托限制冲突检测算法，并给出框架的应用示例；第5节介绍相关工作并进行比较；第6节是结束语。2 工作基础根据委托内容不同，委托可以分为完全委托和部分委托。完全委托是用户将角色全部委托，早期的RBDM属于这种类型；部分委托是用户委托部分权限。文献5采用临时委托角色实现部分委托，本文统一使用角色作为委托的内容。委托是拥有权限的用户（委托者）将权限传递给其他用户（协作方）的过程。协作方可以使用委托的权限，也能够继续委托。现有的RBDM中，安全管理员集中划分允许委托的角色集合，在大型协同系统中需要委托的角色数量巨大，集中管理不适合灵活的临时委托角色方式，限制粒度较粗。增加委托角色DR描述委托限制，方便用户自主将部分权限委托给协作方。为了区别，原有RBAC的角色称为对象角色OR。定义1 RBAC模型中的角色表示为R=(OR, DR)，其中，其中,符号表示角色间的支配关系。被授予角色R的用户能够委托OR，但要求满足限制条件C，委托深度为。没有委托限制的角色表示为 ，其中表示没有限制条件，表示没有委托深度限制。委托深度为0表示用户不能委托角色R。这里假定拥有OR的用户才能委托角色R，单独委托OR，隐含委托，单独委托DR无效。为了描述委托限制，定义委托事件和委托谓词。定义2 委托事件delegateu_ru表示用户u将角色r委托给用户u的操作。委托谓词delegate(u,r,u,t)表示用户u在t时刻将角色r委托给用户u的状态。3 委托限制分类描述委托限制需要对其分类，针对不同的类型采取相应的描述方法。文献9,10总结3类RBAC模型的限制：禁止、义务和基数限制。文献11扩展增加时间限制。上述文献的限制范围仅限于RBAC模型，不涉及委托操作，而委托操作所导致的权限传递恰恰需要实施严格限制。参考这种分类方法，将委托限制（基数限制通过委托深度描述）分为：时间限制、禁止限制和义务限制。3.1 时间限制TRBAC12首次将时间概念引入RBAC模型，文献13全面描述了RBAC模型的时间约束。本文使用文献提出的周期时间表示时间范围，周期时间使用二元组表示，其中P是周期时刻集合，begin,end是时间间隔的范围。函数包含P中所有的时间间隔I，函数Sol(I,P)表示时刻集合。委托的时间限制表示委托操作执行的有效时间范围和持续的有效期限。委托操作执行必须在有效时间范围内，超出范围则操作失败。委托持续的时间受有效期限约束，超过期限后，系统自动撤销委托的角色。RBAC模型的时间限制包括周期限制和持续限制，分别表示操作有效的周期时间和持续时间。委托操作由用户自主进行，因此周期性限制并不适用。定义持续限制(tc)表达的规则是(I,P,)|D,Dx,E)，其中符号“|”表示替换项，方括号表示可选项。(I,P,)|D表示委托事件开始的有效时间，Dx表示委托事件的有效期限，E表示委托事件，时间限制规则的示例如表1所示。在时刻，委托事件E执行，有效持续间隔。表1委托时间限制示例限制规则限制1(01/01/2006,01/31/2006,all.Days+9.Hour8.Hours),4.Hours,delegateu_ru)限制2(WorkTime,3.Hours,delegateu_ru)限制3(2.Hours,delegateu_ru)表1中限制1的形式(I,P),Dx,E)，描述2006年10月中每天9点开始，持续8h，用户u将角色r委托给u1的操作有效，有效时间为4h。限制2的形式(D,Dx,E)，描述在工作时间内u委托r给u1的操作有效，有效时间为3h。限制3的形式(Dx,E)，描述在任意时间内u委托r给u1的操作都有效，有效时间为2h。3.2 禁止限制委托的禁止限制描述委托操作不能违反的限制，主要是满足职责隔离原则，防止用户随意地委托权限违反协同系统的安全策略。RBAC模型使用冲突关系描述职责隔离，包括3类：角色、权限和用户冲突。角色冲突描述角色间互斥关系，还可以细分为静态冲突r_SSoD和动态冲突r_DSoD。静态冲突的角色不能授予同一用户，动态冲突的角色不能在同一会话中激活。例如角色会计和出纳静态冲突，不能授予同一用户。用户冲突描述用户间的互斥关系，例如多个关键权限不能授予具有亲属关系的2个用户。权限冲突描述权限间的冲突关系，例如签署和支付支票属于互斥权限，不能授予同一用户或角色。委托者执行委托操作时不能违反权限冲突、用户冲突和静态角色冲突，被委托者使用委托角色时不能违反动态角色冲突。禁止限制PC是协同系统管理员制定的全局性限制。规则1 规则2 规则3 规则4规则5规则1描述委托角色不能与用户已有角色冲突，冲突角色不能委托给同一用户。规则2描述委托角色关联的权限不能与用户已有权限冲突。规则3描述冲突用户不能通过委托关联静态冲突角色。规则4描述冲突用户不能通过委托获得冲突权限。规则5描述具有动态冲突关系的角色不能在同一会话中激活。3.3 义务限制义务限制描述委托操作必须满足的规则，包括先决条件和后决条件。前者是委托操作之前必须满足的条件。后决条件是委托操作之后必须满足的义务，可以看成委托的后续操作。文献12定义触发器描述满足条件以后执行事件，但这种定义无法充分描述先决条件和后决条件，存在问题：首先，先决条件需要事件的执行，触发器只能描述操作的条件是否具备；其次，后决条件触发的事件是否执行、执行结果是否正确无法描述。本文扩展触发器定义，增加事件执行后的状态集合表示事件期望的执行结果。定义3 触发器的形式为 ，方括号表示可选项。触发器描述事件和谓词 满足后触发执行事件E，状态由谓词集合S描述。使用触发器表示先决条件 ，表示在t时刻委托条件满足后执行委托事件，系统状态集合是S(t)，包括委托事件完成后的状态谓词。后决条件的形式为 ，表示满足条件的委托谓词触发事件E，表示委托操作后需要继续执行的事件，描述操作完成后的状态集合。先决条件和后决条件的区别有2点：首先，触发的前提不同，先决条件的检查在委托事件之前，后决条件通过委托谓词触发，表示委托操作已经成功；其次，触发的结果不同，先决条件不再触发任何操作，后决条件触发事件约束委托角色的使用。4 基于角色的细粒度委托限制框架用户执行委托操作必须满足协同系统全局策略的要求，被委托者对委托权限能够执行2类操作，包括执行权限和继续委托。通过对委托限制的分析，在委托操作的不同阶段实施多种限制。在委托操作之前，委托者可以指定权限委托的条件；在委托操作完成后，委托者仍然希望能够约束委托权限的使用方式。相应地，将委托限制框架分为条件委托和受控使用。条件委托是委托操作在满足特定条件后才能执行；受控使用是协同方对委托权限的使用受到约束。受控使用规则形成受控使用规则库（ACRB），用户使用委托权限从ACRB中推导约束条件。委托限制框架中，委托角色的条件C分为委托条件CD和使用限制AC。定义4 如果R是规则，head(R)为返回逻辑蕴含的条件部分，body(R)为返回逻辑蕴含的结论部分，state(R)为返回规则的状态集合。根据上述定义可知body(pre)=，state(pc)=。4.1 条件委托时间限制描述委托操作执行的有效时间范围，禁止限制描述委托操作不能违反的全局性规则，义务限制中的先决条件描述委托操作之前必须满足的条件，以上三部分构成委托条件CD=TC, PC, PRE，其中TC是时间限制规则集合，PC是禁止限制规则集合，PRE是义务限制的先决条件集合。委托操作必须满足委托条件的要求，定义系统可接受的委托事件。定义5 给定委托事件delegateu_r u，其中委托角色，其中C=PC,PRE, AC。系统时刻t的状态集合是S(t)。委托事件被系统接受需要满足以下条件：1) ;2) ;3) ;4) 。条件1表示委托者u拥有角色r或更高级别的角色r，委托深度至少为1；条件2表示委托操作发生在时间限制的有效范围内；条件3表示如果当前状态集合中包含禁止限制规则的条件，则不能包含禁止限制规则的结论，即不能违反禁止限制；条件4表示当前状态中必须包含先决条件。可接受的委托表示委托事件能够被系统接受的基本条件，满足要求的委托限制才能加入ACRB。4.2 受控使用除了满足条件委托之外，委托者或管理员希望能够对委托权限的使用进行约束。例如使用时限和依赖关系等。虽然协作方通过委托操作获得角色资格，但可能由于不满足约束条件而无法激活。系统包含使用限制规则库ACRB约束委托权限的使用，使用限制规则AC=TC,PC,POST，其中TC是时间限制集合，PC是禁止限制集合，POST是义务限制的后决条件集合。委托权限的使用受时间限制的约束，时间到期后，委托的权限由系统自动撤销；这里的禁止限制主要描述动态冲突角色，动态冲突角色可以授予同一用户但不能同时激活；后决条件增加委托权限使用的条件，需要系统状态满足一定条件才能激活。时间限制是使用限制规则的基础，我们定义多个时间限制的关系。定义6 对于时间限制tcm和tcn，有效时间段分别为和 。如果 ，则tcm和tcn持续重合，重合时间为 ,。委托角色的使用受时间限制的约束，时间到期后，委托角色由系统自动撤销。委托谓词推导出协作方在时间限制集合TC定义的有效期限内使用被委托角色，表示为：委托谓词（t时刻）可推导在时间间隔内用户同委托角色关联。当被委托者激活委托角色之前，系统检查ACRB中的规则，如果时间超出委托的有效期限，激活操作无法成功。禁止限制规则描述全局性不能违反的条件，用户可以通过委托操作获得动态冲突角色，但不能在同一会话中激活。后决条件增加委托角色使用的条件，满足系统要求的后决条件规则加入ACRB中。4.2.1 委托限制规则的冲突后决条件表示执行委托操作后触发的事件，多个后决条件之间可能存在冲突，分为2种类型：1）多个委托操作的后决条件触发的事件冲突或无法同时满足，如例1所示；2）多个委托操作形成循环委托链，显然是没有意义的，而且容易导致委托操作语义的不一致性。例如Alice将D1角色委托给Bob，Bob将其委托给David，David最后将其委托给Alice。例1 Alice通过D1将access_cvs权限委托给Bob，要求立刻激活Auditor角色；Carol通过D2将audit权限委托给Alice，自己放弃该权限。2个委托操作的后决条件表示为假设2个委托操作满足委托条件要求，被系统接受，后决条件加入ACRB。当时刻t1=t2时，触发和 ，事件E1要求Carol激活Auditor，隐含状态Carol拥有权限audit；事件E2要求Carol不再拥有权限audit，E1和E2无法同时满足。文献10定义函数conf(E)表示E的冲突事件集合，例如enabler的冲突事件集合 ，即，表示冲突事件不能同时发生。函数conf(E)能够描述明确的冲突，但无法表示隐含冲突。冲突事件会导致冲突的状态，本文利用状态描述集合S(t)检测冲突。例1中， 表示post1要求激活Auditor，获得audit权限，表示post2要求Carol放弃audit权限。当t1=t2时，系统状态包含冲突。定义7 给定一个冲突事件集合 ，构造冲突状态集合 ，其中pi是ci对应的状态描述（事件对应一个或多个谓词），表示为。定理1 使用CE描述冲突关系属于使用PS描述冲突关系的子集。证明 要证明定理1就需要证明：对于任意一个冲突事件集合，都存在一个冲突状态描述集合，其中P=pi|ciC，pi是ci对应的状态描述。 p1, pnPS，pi是ci对应的谓词，且。4.2.2 委托限制冲突检测委托事件被系统接受后，委托限制规则被加入ACRB。新加入规则与ACRB中的原有规则可能存在冲突，一个有效的委托操作必须满足ACRB的一致性要求。定义8 设ACRB是受控使用委托规则库，如果ACRB中的规则包含循环关系或者运用ACRB中的规则能够推导出矛盾状态，则称ACRB是不一致的，否则称为是一致的。直接根据定义对ACRB的不一致进行判断是困难的，将ACRB中的规则用带标识的有向图表示，根据图的相关理论对ACRB的不一致进行判定相对比较简单。我们给出ACRB规则表示的有向图定义。定义9 设G(V,E)是ACRB表示的有向图，其中表示顶点的集合，表示边的集合，其中角色r和持续时间tc.D是边的标识，边的方向由委托者指向被委托者。ACRB用有向图表示后，其不一致性等价于2个条件：1）有向图中存在环，并且这个环中所有边标识时间集的交集是非空的，标识角色的交集是非空的；2）有向图中的顶点包含的状态集合包含冲突状态，并且指向该顶点的所有边标识时间集的交集是非空的。这个理论的正确性由以下定理保证。定理2 设G(V,E)是ACRB的标识有向图，如果G(V,E)包含环，且这个环所有边标识时间集的交集非空，标识的角色的交集非空，则ACRB是不一致的。如果顶点E的状态集合包含冲突，且指向该顶点的所有边标识时间集的交集非空，则ACRB是不一致的。ACRB的一致性判定问题转换成2个问题：判定其标识的有向图中是否存在环，并且环所有边标识时间集的交集非空，标识角色的交集非空；顶点的状态集合是否包含冲突，且指向该顶点的所有边标识时间集的交集非空。定理3 设G(V,E)是ACRB的标识有向图，G(V,E)中存在一个环，当且仅当存在G(V,E)的强连通分量L(N,J)。根据定义和定理给出基于图论的一致性验证算法。算法1 ACRB一致性验证算法输入：一个ACRB；输入：如果ACRB是一致的，返回true，否则返回false；user(V)=u1,u2,un包含顶点集合中的所有用户；in(v)=e1,e2,em包含指向顶点v的所有边。beginV=;E=;for each rule ac in ACRB do beginif delegatee(ac.post)user(E) thenV=V(delegatee(ac.post), state (ac.post) elsedelegatee(ac.post). status= delegatee(ac.post).statusstate(ac.post)if delegator(ac.post)user(E) then V=V(delegator(ac.post),)end/* 求G(V,E)的强连通分量，查找边标识时间集和角色交集非空的环 */=G(V,E)的所有强连通分量if L(N,J) and (jm,jnJ)toverlap(jm,jn) and thenreturn false/* 查看每个顶点是否包含冲突，且指向该顶点的所有边标识时间集的交集非空 */for each v in V dobeginif |in(v)|2 and (em,enin(v) toverlap(em,en) and status(v)S thenreturn falseendreturn true；end定理4 算法1的时间复杂度为O(n2)，其中n是ACRB所包含的用户数。根据上述定义和定理以及图的强连通算法时间复杂度理论，容易证明求有向图的强连通的时间复杂度是O(n2)，因此定理是正确的。4.3 委托框架应用示例下面给出在协同环境下委托框架应用的示例。例2 公司C和研究所I协同开发软件，I的用户Bob和David需要访问CVS服务器的权限access_cvs。用户Alice的角色为工程师Engineer，拥有访问CVS服务器的权限access_cvs，创建角色D1，将access_cvs授予D1，要求D1不能委托给C和I以外的用户，委托深度为3；用户Carol的角色为审计员Auditor，拥有执行审计的权限audit，创建角色D2，将audit授予D2，要求D2不能委托给I的用户。协同系统管理员定义的全局限制：1）委托操作只能在工作时间进行；2）权限access_cvs和audit不能由一个用户同时使用，确保正确审计访问CVS服务器的行为；3）委托access_cvs必须执行审计，委托audit则委托者放弃该权限，保证系统中只有一个用户执行审计操作。全局限制中限制1为时间限制；限制2为禁止限制，要求D1和D2动态冲突，禁止同时激活；限制3为义务限制，要求对D1和D2的委托操作后，执行后续事件。用户执行的委托操作如下：Alice从1月15日17点出差，将角色D1委托给Bob，有效期5天；Bob在每月20日将D1委托给David，要求Carol激活Auditor角色，有效期1天；David在1月20日下午16点到18点开会，将该权限委托给Alice，有效期2h。Carol将D2委托给Alice和David，并放弃该权限。具体的委托操作如图1所示。图1 协同环境下的委托限制示例上述委托限制转换为规则如下:,初始状态ACRB为空，操作O1和O2满足委托条件，对应的受控使用规则加入ACRB后保持一致性，委托操作成功。操作O3同样满足委托条件，将其受控使用规则加入ACRB，由于tc1,tc2,tc3持续重合 ，在该时间间隔内post1触发3次，ACRB构造的G(V,E)中顶点(Alice, SAlice)、(Bob, SBob)和(David, SDavid)之间存在环，形成循环的委托链，ACRB是不一致的，因此O3操作不成功。如果O4在内发生，在时刻，G(V,E)中的顶点(Alice, SAlice)的状态集合 包含冲突谓词，ACRB是不一致的，因此O4在该时间间隔内无法执行，但在剩余时刻O4能够操作成功。操作O5在任何时刻执行，系统检查发现不满足委托条件pre2，因此操作无法执行。5 相关工作研究人员提出了若干基于角色的委托模型27。RBDM02使用RBAC0模型元素实现用户到用户的委托，委托限制通过关系约束。随后的RBDM13扩充支持角色层次的委托，限制关系细分can-delegate的语义，实现角色层次的委托。文献4提出RDM2000模型，引入先决条件对委托进行限制，其中CR表示先决条件，N表示委托深度。限制(r,cr,n)表示用户可以委托角色r，满足先决条件cr，委托深度不能超过n。RBDM0/1和RDM2000模型中委托的单位是角色，Zhang等人提出PBDM5支持细粒度的权限委托。限制关系为 ，其中RR是普通角色，同RBDM0的初始角色含义相同，Pre_con是先决条件，P_range是委托范围，M是最大委托深度。ABDM7的用户和角色包含属性描述，只有满足属性要求的委托才能执行，委托限制分为： 和 ，分别增加属性描述DAE和获取能够接受TDR的用户集合Uee。CRDM6研究委托权限的使用限制，支持临时性和常规角色关联性委托限制，其中临时性主要表现在委托有效期限制、激活时间限制、使用次数限制；常规角色关联性表现为常规角色依赖限制，确保委托角色的激活满足特定的常规角色激活状态。由于CRDM以PBDM0为基础，基于扁平角色，不支持角色继承和角色委托传播限制。总结上述模型，除CRDM外，所有模型的限制关系都是扩展can- delegate关系，加入不同约束条件，但都无法有效约束委托权限的使用，而这正是本文的重要内容。文献14使用Prolog语言描述RBDM0，通过规则推导检测定义的静态与动态职责隔离和委托行为的冲突，文献15使用Alloy语言描述RBAC的管理和委托，解决其中存在的冲突。上述工作使用特定语言描述委托操作，并解决与RBAC其他元素的冲突问题，但并不区分系统的全局策略和用户的自主策略。与其相比，本文工作与具体策略描述语言无关，冲突检测不依赖特定语言实现，例如RCL20009更适合描述委托限制规则，且灵活度更好。研究工作1618侧重于RBAC系统实际应用中的委托限制。文献16提出基于用户的委托框架，将权限细化为对象权限和委托权限，并定义条件委托。文献17分析协同环境下的委托限制，使用常规表达限制委托树的大小，构造委托树的时候允许委托者调整限制。文献18描述安全工作流管理系统的条件委托，包含3方面的条件：时间、工作负载、任务属性。实施过程中产生四类限制：授权限制、委托条件、角色激活限制和工作流依赖需求。与本文相比，上述工作没有分析委托操作中常用的时间限制，而且无法限制委托权限的使用方式。6 结束语分布式和网络环境的发展提出了协同工作的需求。为了实现信息共享，研究人员提出若干基于角色的委托模型。使用这些模型协同系统能够减轻管理负担，满足权限传递的要求。另一方面，委托也带来安全威胁，需要进行有效地限制和管理。本文提出协同环境下基于角色的细粒度委托限制框架，将角色分为对象角色和委托角色，分别用于访问控制和委托限制；分析3类委托限制：时间限制、禁止限制和义务限制。委托限制框架中包括条件委托和受控使用，条件委托是在满足条件后委托才能执行，防止权限扩散；受控使用是委托者对委托权限的使用增加约束，防止权限滥用。多个委托限制之间可能存在冲突，提出基于图论的一致性检测算法，有效检测委托限制冲突。参考文献：1SANDHU R, COYNE E, FEINSTEIN H, et al. Role-based access control modelsJ. Computer, 1996, 29(2): 38-47.2BARKA E, SANDHU R. A role-based delegation model and some extensionsA. Proceedings of 23rd National Information Systems Security ConferenceC. Baltimore, USA, 2000.168-177.3BARKA E, SANDHU R. Role-based delegation model/hierarchical roles (RBDM1)A. Proceedings of the 20th Annual Computer Security Applications ConferenceC. Tucson, Arizona, USA, IEEE Computer Society, 2004. 396-404.4ZHANG L H, AHN G J, CHU B T. A rule-based framework for role-based delegationA. Proceedings of 6th ACM Symposium on Access Control Models and TechnologiesC. Chantilly, 2001. 153-162.5ZHANG X W, O H S, SANDHU R. PBDM: a flexible delegation model in RBACA. Proceedings of the 8th ACM Symposium on Access Control Models and TechnologiesC. Como, 2003. 149-157.6徐震, 李斓, 冯登国. 基于角色的受限委托模型J. 软件学报, 2005, 16(5): 970-978.XU Z, LI L, FENG D G. A constrained role-based delegation modeJ. Journal of Software, 2005, 16(5): 970-978.7YE C X, WU Z F, FU Y Q. An attribute-based delegation model and its extensionJ. Journal of Research and Practice in Information Technology, 2006, 38(1): 3-16.8JOSHI J, SHAFIQ B, GHAFOOR A, BERTINO E. Dependencies and separation of duty constraints in GTRBACA. Proceedings of the 8th ACM Symposium on Access Control Models and TechnologiesC. New York, 2003. 51-64.9AHN G J, SANDHU R. Role-based authorization constraints specificationJ. ACM Transactions on Information and System Security, 2000, 3(4):207-226.10AHN G J. Specification and classification of role-based authorization policiesA. Proceedings of the 12th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative EnterprisesC. 2003. 202-208.11董光宇, 卿斯汉, 刘克龙. 带时间特性的角色授权约束J. 软件学报, 2002, 13(8): 1521-1527. DONG G Y, QING S H, LIU K L. Role-based authorization constraint with tim