一种多层次优化的策略评估引擎的建立方法及其实施方法

摘要

本发明公开了一种多层次优化的策略评估引擎的建立方法及其实施方法，属于信息安全领域。本发明首先对策略评估引擎策略库内的访问控制规则进行精化；然后建立判定结果缓存机制、属性缓存机制和策略缓存机制，得到该引擎；其实施方法为：该引擎根据访问请求的主体标识和会话标识在判定结果缓存中查找相同访问请求的判定结果；如果有则将其作为本次访问请求的判定结果返回；如果没有则在属性缓存中检索主体标识相应的属性缓存，然后将资源标识和动作标识组成权限原语，获取该权限原语的主体属性列表，并用主体属性依次在属性缓存中匹配检索；引擎将首次适用的主体属性所附带的判定类型返回。本发明可降低通信损耗，提高策略匹配的速度和准确率。

说明书

技术领域

本发明属于信息安全中的授权策略判定领域，具体涉及一种多层次优化的策略评估引擎的建立方法及其实施方法。

背景技术

访问控制标记语言XACML(The eXtensible Access Control Markup Language)已逐渐成为多个企业应用和商业产品实现安全授权功能的实际标准。分布式资源共享、Web服务、域间协作等新兴业务需要制定大量的XACML策略条目对资源进行细粒度访问控制，但随着策略规模和策略语义复杂性的上升，策略评估效率已成为制约系统可用性的关键瓶颈。

在OASIS组织制定XACML标准后不久，Sun公司即推出其策略评估系统原型SunXACML，其通过策略检索模块接口和属性检索模块接口实现对访问请求的判定评估，用户可以自定义模块接口的具体实现，其后出现的多种访问判定系统大多采用了这种模式或该模式的改进方案。虽然该引擎给出一个比较完整的访问控制功能体系结构，但其没有进一步考虑策略检索和属性检索对评估引擎带来的效率影响，只采用穷举遍历策略库的方式处理访问请求。另有一些简单的实验型判定引擎(例如XACML.NET、Parthenon XACML)仅支持简单的策略逐条匹配方式，在策略检索和辅助功能部件方面缺乏实用性和延展性。系统环境单一的小规模策略应用场景下，逐条匹配对策略检索效率并没有显著影响，但在大规模策略集成应用中，对访问请求真正实施影响的几条策略可能分布在数以千计甚至万计的策略条目中，穷举匹配的模式会严重降低系统检索有效策略的概率.

有一些系统为了应对企业级的策略处理规模，采用了部分有针对性的引擎优化技术。JBoss XACML在Sun XACML基础上实现了一次上层封装，提供灵活的策略加载方式和引擎启动方式，但没有改善策略检索匹配模式以解决评估效率问题。Melcoe PDP针对XACML策略载体的特点，将策略文件存储在XML Native数据库中，利用Native数据库对XML的专有处理技术提高判定引擎的策略匹配速度，并使用属性约束列表进一步缩减策略检索空间，但其优化方案依赖专有数据库自身的技术特点。XACMLight提供了Web服务模式的策略判定和策略管理，其专注于评估引擎的远程服务调用，没有对策略匹配过程做特别优化。AXESCON XACML强化评估引擎中的策略载入和策略缓存功能，考虑了策略引用和多策略匹配问题，但其采用的匹配逻辑仍然按照XACML嵌套结构逐层进行，没有在匹配逻辑优化和高效索引结构方面更进一步。

在策略索引方面比较有成效的工作有专利号：ZL 200810119404.7，发明名称：“一种XACML策略规则检测方法”的研究，其技术方案中给出了对XACML策略规则冲突检测的预定位，以及在给定冲突消解算法的情况下对规则冗余的判定；另外比较有成效的工作是Enterprise XACML系统，其根据策略目标中包含的属性标记建立策略索引结构，在一定程度上缩减了策略检索空间，但策略目标和访问请求中可能包含多个属性标记，从而造成策略重复索引和多次匹配，另外其索引结构没有考虑规则目标的匹配优化问题。Xengine系统采用的优化思想不同于大多数判定引擎，该方案将XACML策略规则转译为数字区间规则，把嵌套递归式描述结构转化为扁平结构，采用“首次适用”合并算法避免规则的遍历匹配。虽然数字区间匹配的效率高于策略字符串匹配，但引擎需要动态生成大量的辅助运算数据结构，其额外的规则转译运算量不能忽视，另外数字区间规则并不能完全支持XACML的复杂描述能力。

大多数现有策略评估引擎所采用的优化方案提升评估效率的能力有限，原因在于XACML复杂的嵌套递归结构增加了优化工作的难度；性能测试涵盖的引擎系统不够丰富，缺乏从技术原理角度对各引擎的专有技术差异进行比较分析。

发明内容

本发明的目的之一在于克服现有技术中存在的问题，提供一种多层次优化的策略评估引擎(Multi-Level Optimization Based Evaluation Engine，MLOBEE)的建立方法及其实施方法。

本发明的技术方案为：

一种多层次优化的策略评估引擎的建立方法，其步骤为：

1)冗余判定模块对策略评估引擎策略库内的访问控制规则进行冗余判定；

2)规则精化模块删除策略库中冗余的访问控制规则后调整访问控制规则的顺序，进行规则精化；

3)缓存机制建立模块建立判定结果缓存机制、属性缓存机制和策略缓存机制；其中，

所述判定结果缓存机制为：主体标识会话标识、会话标识资源访问结果的二层映射模式，

所述属性缓存机制为：主体标识和属性标识列表组成第一层映射，每个属性标识对映一个属性值列表组成第二层映射，

所述策略缓存机制包括两阶段索引：第一阶段索引根据每个资源属性条目进行策略分类，将和某个资源属性相关的所有策略组成一个策略列表；第二阶段索引以访问控制规则目标的权限原语为键值，将其所在访问控制规则中的主体属性添加到权限原语指向的主体属性列表，建立权限原语和主体属性列表的映射关系。

进一步的，所述策略库内的策略类型包括：permit-overrides类型、deny-overrides类型、first-applicable类型；采用permit-overrides评估合并算法对permit-overrides类型策略内的规则进行冗余判定；采用deny-overrides评估合并算法对deny-overrides类型策略内的规则进行冗余判定；采用first-applicable评估合并算法对first-applicable类型策略内的规则进行冗余判定。

进一步的，所述调整访问控制规则的顺序的方法为：将permit-overrides类型策略内permit类型访问控制规则置于deny类型访问控制规则之前；将deny-overrides类型策略内deny类型访问控制规则置于permit类型访问控制规则之前；对于first-applicable类型策略内的访问控制规则不调整。

进一步的，所述主体标识包括主体ID及其所在域；每个所述主体标识对应一个所述会话标识，每个所述会话标识对应一个资源访问结果列表。

进一步的，所述属性标识内附加一时间戳，用于记录属性标识最新加载时间。

进一步的，所述第一阶段索引的建立方法为：首先从策略目标中提取资源属性条目作为索引主键，每个主键指向一个策略列表；然后策略加载时，将每条策略添加到其包含资源属性所指向的策略列表中，形成哈希表。

进一步的，设定所述策略列表内的策略针对相同资源属性条目索引的权限，对于存在层次关系的资源属性，将所有上层资源的策略都自动适用其蕴含的下层资源。

进一步的，所述第二阶段索引的建立方法为：首先按访问控制规则精化后的顺序，依次从每条规则的目标元素中提取资源属性子集与动作属性子集的笛卡儿积，形成权限原语集合；然后依次将权限原语所在目标元素内的主体属性分别组成主体属性列表，主体属性列表中的每个主体属性都附带所在规则的类型；最后以权限原语为索引建立权限原语到主体属性列表的映射结构，形成哈希表。

进一步的，所述策略列表中只存放策略标识，其指向内存中唯一的策略实体。

一种多层次优化的策略评估引擎的实施方法，其步骤为：

1)策略评估引擎根据访问请求的主体标识和会话标识在判定结果缓存中检索，查找是否存在相同访问请求的判定结果；所述访问请求包括：主体标识、资源标识和动作标识；

2)如果判定结果缓存中存在相应的判定结果，则策略评估引擎将其作为本次访问请求的判定结果返回；

3)如果判定结果缓存中没有相应的判定结果，则在属性缓存中检索主体标识相应的属性缓存，如果存在，进行步骤4)，如果没有则通过检索主体标识的属性信息并存入属性缓存中，然后进行步骤4)；

4)将访问请求中的资源标识和动作标识组成权限原语，通过第二阶段索引获取该权限原语的主体属性列表，并根据列表中的主体属性依次在属性缓存中匹配检索；

5)策略评估引擎将首次适用的主体属性所附带的判定类型返回。

进一步的，如果应用场景为多策略组合，则所述策略评估引擎根据本次访问请求的资源信息进行策略分类，将和某个资源属性相关的所有策略组成一个策略列表。

进一步的，所述主体信息、的取值是单一属性值或是包含多个值的属性集合；所述资源信息的取值是单一属性值或是包含多个值的属性集合；所述动作信息的取值是单一属性值或是包含多个值的属性集合。

具体来说，本发明技术方案包括下列几个重要方面：

第一部分策略库的访问控制规则精化：

1)冗余访问控制规则定义

冗余访问控制规则假设用户发出的访问请求记为req(sub，res，ac)。其中sub、res和ac分别代表访问相关的主体信息、资源信息和动作信息，其取值可以是单一属性值或是包含多个值的属性集合。若访问控制规则R适用于req(sub，res，ac)，则记为R|＝req(sub，res，ac)。当R_i|＝req(sub，res，ac)成立时，R_j|＝req(sub，res，ac)必然成立，反之不一定，则称R_j覆盖R_i，记为此时删除R_i后并不影响引擎的判定结果，称R_i是冗余访问控制规则。

2)策略库中的每一条策略均包含有若干条访问控制规则，同时每一策略中均附带评估合并算法类型，下面为冗余判定模块针对每种策略类型的冗余判定规则。

a)permit-overrides评估合并算法下冗余判定规则

规则1  若且R_j.effect＝permit(即R_j为permit类型规则)，则R_i是冗余访问控制规则。

规则2  若且R_j.effect＝deny：当R_i.effect＝deny时，R_i是冗余规则；当R_i.effect＝permit时，R_i不是冗余访问控制规则。R.effect表示判断类型，其取值为permit或deny。

b)deny-overrides评估合并算法下冗余判定规则

规则3  若且R_j.effect＝deny，则R_i是冗余访问控制规则。

规则4  若且R_j.effect＝permit：当R_i.effect＝permit时，R_i是冗余访问控制规则；当R_i.effect＝deny时，R_i不是冗余访问控制规则。

c)first-applicable评估合并算法下冗余判定规则

规则R_i在策略中的位置顺序记为seq(R_i)：

规则5  若且R_i.effect＝R_j.effect，则R_i是冗余访问控制规则。

规则6  若且R_i.effect≠R_j.effect(即两条规则的判断类型冲突)：当seq(R_j)＜seq(R_i)时，R_i是冗余访问控制规则；当seq(R_i)＜seq(R_j)时，R_i不是冗余访问控制规则。

3)访问控制规则精化及其相关定义

规则精化(Rule refining)设策略容器的规则集为RS，规则精化模块根据其评估合并算法α，运行策略处理流程process_refine^α，获得RS的一个子集$>{\mathrm{RS}}^{\prime }\subseteq \mathrm{RS}.$>对于任何访问请求req来说，RS′和RS的判定评估结果保持不变，则称RS′是RS在α算法下的规则求精，称过程process_refine^α为规则精化。

process_refine^permit首先根据评估合并算法对RS：{R₁，R₂，...，R_n}进行冗余分析并删除其中的冗余访问控制规则，若为permit-overrides，则把所有permit类型规则置于deny类型规则之前，变为且|RS′|＝n′≤n。同理，deny-overrides下的处理流程类似，即first-applicable下根据算法逻辑不能对规则顺序作出调整。

第二部分缓存机制建立模块建立多级缓存机制：

1)判定结果缓存

判定结果缓存(Result cache)是加速评估过程最直接的缓存优化机制，即把用户之前的访问结果进行保存，当再次访问时，不必触发属性检索和策略匹配等造成系统响应延迟的复杂流程。用户在访问期内可以激活多个访问会话，在同一会话内可以访问多条具体资源并具有不同的判定结果，因此判定结果缓存应按照主体标识会话标识、会话标识资源访问结果二层映射模式构建。图1是判定结果缓存结构示意图，主体标识Principal由主体ID和其所在域Domain组成，可区分域内/域外主体；每个主体标识对映一个会话标识(Session ID)列表，保存该主体激活的所有访问会话；每个Session ID对映一个资源访问结果列表，保存用户在该会话内访问的具体资源ResID和相应的判定结果Result。Resultcache的设计目标是尽可能减少相同访问路径引起评估引擎重复运算，作为MLOBEE系统的一级缓存，其前端直接面对访问量频繁的用户并发操作请求，后端要考虑授权策略和属性信息的变更问题，因此应将缓存空间控制在一定规模并制定均衡的缓存有效期。缓存中具体的匹配条目是ResID|Result对，Result的结构形如“read:permit”。Result还可以通过“read:exception”和“read:error”等结构记录判定异常、判定无效等信息，使评估引擎预先识别垃圾请求和无效请求，从而提高抵御恶意DoS攻击的能力，减轻评估引擎的处理负担。

2)属性缓存

属性检索是评估引擎完成策略匹配的必要环节，用户属性的完整程度直接影响策略匹配的成功率。一般的评估引擎可以支持两种最通用的属性传递技术：“push”模式和“pull”模式。若采用“push”模式，用户将自身相关属性和请求资源一起发送给评估引擎进行判定，这种方式的优点是简化策略判定实施过程，缺点是增加用户的访问负担，属性可信性较低；若采用“pull”模式，评估引擎根据策略匹配具体需要对属性库进行实时检索，这种方式的优点是可信第三方管理的属性安全级别高，缺点是增加了判定引擎通讯交互负担。MLOBEE的属性缓存(Attribute cache)机制采取折衷方案，用户访问时无需提供自身属性，系统在实施策略匹配前首先检索Attribute cache，若没有检索结果则表示该用户是首次发出访问请求，然后通过属性断言服务检索用户属性信息并存入Attribute cache，后继的访问判定过程直接在属性缓存中对该用户属性进行快速检索。如图2所示，属性缓存同样采用二层映射模式，主体标识Principal和属性标识AttrName列表组成第一层映射，每个AttrName对映一个属性值列表ValueList组成第二层映射。某些主体属性在系统运行期间变更相对频繁，属性缓存为每个属性标识AttrName附加一个时间戳Time stamp用来记录其最新加载时间，通过比较时间戳和缓存有效期，定期动态更新过期属性值。Attribute cache既免除了用户携带大数据量属性信息访问的负担，又规避了频繁远程属性检索的延迟，为策略判定提供基于本地的高效属性查询代理。

3)策略缓存

XACML策略结构的复杂性导致评估引擎必须对从策略树根节点到叶子节点路径上的所有Target进行遍历式匹配运算，缺乏高效策略索引和匹配逻辑致使每条访问请求都要触发检索大量策略条目和规则条目。XACML策略主要有两种模式：(1)多策略组合多管理方对共同拥有的资源制定个性化的安全策略，策略组合体现为多条Policy组合为一个PolicySet；(2)多规则组合组织内制定针对多个用户和多种资源的安全策略，策略组合体现为多条Rule组合为一个Policy。MLOBEE系统针对上述应用特点，通过两阶段索引技术实现策略缓存机制(Policy cache)。

第一阶段索引针对多策略组合，考虑到安全策略的实施最终要落实到资源信息的保护，首先从策略目标中提取资源属性条目res作为索引主键，每个主键指向一个策略列表policyList。策略加载时，将每条策略添加到其包含资源属性所指向的策略列表中，形成哈希表HashTable(res，policyList)，称此为MLOBEE策略缓存的第一阶段索引。第一阶段索引借鉴了策略目标的交集计算方法，策略列表内的策略都包含针对相同res索引的权限定义，另外对于存在层次关系的资源属性，所有上层资源的策略都自动适用其蕴含的下层资源。通过这种资源定位方式，评估引擎可以在不进行完全匹配的情况下，迅速缩减实际评估的策略规模。

第二阶段索引针对策略内多个规则的目标元素，其目标是通过访问请求中提取的部分信息快速定位一个较为精确的检索子集，且该检索子集为扁平式结构，其内部信息描述简单，检索代价的上限即对子集中所有元素进行匹配所需的耗时，该过程完成后即给出明确评估结果。首先按规则精化后的规则顺序，依次从每条规则的目标元素中提取资源属性子集与动作属性子集的笛卡儿积，其逻辑表达式为$>\mathrm{PerUnit}=(T\arg \mathrm{et}.\mathrm{res})\otimes (T\arg \mathrm{et}.\mathrm{ac}),$>称perAtom(res，ac)∈PerUnit为权限原语；然后依次将perAtom(res，ac)∈PerUnit所在目标元素内的主体属性分别组成主体属性表subList，subList中的每个主体属性都附带所在规则的effect，形如subAttr^effect；以权限原语为索引建立perAtom到主体属性表的映射结构，形如哈希表HashTable(perAtom，subList)，称此为策略缓存的第二阶段索引。该索引改变了策略内以规则为单位的嵌套式组织结构，形成以权限原语为索引的扁平式描述结构，将策略内的规则匹配逻辑统一为首次适用匹配逻辑。图3是针对图4实现的策略缓存示意图，为了避免策略实体在缓存中重复加载，策略列表中只存放策略标识，其指向内存中唯一的策略实体，权限单元中的属性值用其在策略定义中的数字下标表示，下面详细说明第二阶段索引建立过程。

策略P1内的四条规则目标简化表示为：

T₁＝{[sub₁，sub₂]，[res₁，res₂]，[ac₁，ac₂]}^d、T₂＝{[sub₂，sub₃]，[res₃]，[ac₃]}^p、

T₃＝{[sub₃，sub₄]，[res₃，res₅]，[ac₄]}^d、T₄＝{[sub₄]，[res₄，res₆]，[ac₄]}^p；

策略P2内的四条规则目标简化表示为：

T₅＝{[sub₂，sub₄]，[res₁，res₂]，[ac₁，ac₄]}^p、T₆＝{[sub₄，sub₅]，[res₂，res₃]，[ac₂，ac₃，ac₄]}^d、

T₇＝{[sub₄]，[res₂]，[ac₁，ac₃]}^p、T₈＝{[sub₂]，[res₁]，[ac₁]}^p。

P1的规则合并算法是Permit-Overrides，因此规则精化流程后的规则排列顺序将变为R2→R4→R1→R3，即seq(R₂)＜seq(R₄)＜seq(R₁)＜seq(R₃)。因此首先从T₂中提取$>\mathrm{PerUnit}=\left({\mathrm{res}}_3\right)\otimes \left({\mathrm{ac}}_3\right),$>其中仅包含一条权限原语perAtom＝(res₃，ac₃)，将$>\mathrm{perAtom}({\mathrm{res}}_3,{\mathrm{ac}}_3)\leftrightarrow \mathrm{subList}({\mathrm{sub}}_2^p,{\mathrm{sub}}_3^p)$>添加到第二阶段索引中。然后依次针对T₄、T₁、T₃建立索引项。策略P2的规则精化后的顺序为R6→R5→R7→R8，其缓存建立过程需要注意几个问题：首先，经过规则冗余分析，规则R8针对R5是冗余规则，因此规则精化过程将其删除，策略缓存初始化不再导入该规则；其次，T₅∩T₆＝{[sub₄]，[res₂]，[ac₄]}且考虑到规则评估合并算法是Deny-Overrides，可推得R5中sub₄：{res₂，ac₄}^p相对R6中sub₄：{res₂，ac₄}^d是无效的权限表达，因此在权限原语perAtom(res₂，ac₄)对映的subList中只包含sub₄^d，不再添加sub₄^p条目；再有，虽然R7不是冗余规则，但其拆分出的权限sub₄：{res₂，ac₁}^p已被R5所涵盖，且权限sub₄：{res₂，ac₃}^p相对R6是无效表达，所以R7是无效规则，其导入过程不触发实际的索引添加操作。

将以上过程归纳得出两阶段索引策略缓存应遵循的完整创建规则：

规则7第一阶段索引根据每个资源属性条目进行策略分类，将和某个资源属性相关的所有策略组成一个策略列表，即第一阶段索引中的属性资源条目res全部取自于策略目标pol.Target，若策略目标中省略了对资源属性的约束，则默认该策略适用所有资源条目；下层资源属性指向的策略列表自动添加上层资源属性策略列表中的策略。

规则8第二阶段索引从规则目标的资源属性子集与动作属性子集的笛卡尔积中拆分权限原语perAtom(res，ac)为键值，将其所在规则中的主体属性添加到权限原语指向的主体属性列表subList，建立perAtom(res，ac)和subList的映射关系，subList中主体属性元素都附带其所在规则的effect，形如sub^effect。

规则9针对同一策略内的规则R_i和R_j，若seq(T_i)＜seq(T_j)且perAtom(res，ac)∈PerUnit_i∧perAtom(res，ac)∈PerUnit_j，则对Tj中权限原语建立索引时，不再重复建立perAtom(res，ac)索引项，而是把T_j主体属性子集subSet_i中的元素直接添加到该原语先前已建立的subList中。

规则10若{sub，res，ac}∈T_i∩T_j：当effect_i＝effect_j时，在perAtom(res，ac)相应subList中添加sub的操作只进行一次；当effect_i≠effect_j时，根据规则评估合并算法的优先匹配类型prefer-effect(permit或deny)，只把sub^{prefer-effect}添加到subList中。

第三部分MLOBEE系统：

根据XACML标准中提出的数据流框架，实现一个完整的访问控制系统通常需要策略执行点、策略决策点、策略信息点、策略管理点等功能部件。据此，MLOBEE系统除了实现策略评估相关的核心功能以外，还提供完整的访问授权支撑平台。如图5所示，其主要功能部件包括：策略管理服务部件(Policy Management Service，PMS)、策略决策服务部件(Policy Decision Service，PDS)、策略持久化服务部件(Policy Persistence Service，PPS)和属性断言服务部件(Attribute Assertion Service，AAS)。

PMS提供一个集中式的图形化策略管理平台，其主要负责策略操作、规则冗余分析及规则精化。策略操作涉及策略的创建、修改、删除和更新等；规则冗余分析根据规则评估合并算法，检测不产生实际判定影响的冗余规则；规则精化根据冗余分析结果与合并算法类型缩减策略规模并调整规则顺序，实现策略匹配的前期优化。PMS针对XACML基于属性的描述框架，支持属性层次分析以及各种访问控制模型的策略定义(基于身份访问控制、基于格的访问控制、基于角色访问控制等)。另外，管理平台通过策略持久化服务远程调用获取策略信息并转化为自身应用的策略实体。

PDS是MLOBEE系统的核心部件，多极缓存机制以及策略缓存中的两阶段策略索引都在该模块内实现。上下文处理器将具体的用户资源请求过程抽取为XACML请求发送到评估引擎，将返回的判定结果装配为XACML应答；评估引擎利用缓存管理器中的多级缓存对当前请求进行策略匹配和访问判定，其中包含了判定结果缓存、属性缓存以及策略缓存，还提供有效期感知器监测缓存生命周期。

PPS负责实现策略持久化存储并支持多种策略存储方式。持久化管理器负责整个持久化服务的全局系统配置，可动态加载和注销多个策略库；策略库提供者必须通过策略库注册组件登记才能被持久化管理器识别；具体的策略库提供者可以是数据库、LDAP服务器、文件系统等。

AAS提供属性断言发布服务，为策略匹配提供必要的属性检索功能。属性请求处理器响应来自PDS的属性检索请求，将查询到的属性以标准格式返回(例如SAML断言或属性证书)；AAS除支持管理域内属性查询外，还支持外域用户的属性检索；通过属性推理引擎和推理规则对域外属性进行域内属性的等价推导。

本发明的积极效果为：

本发明从技术原理角度分析了策略判定引擎的多层次优化技术。策略判定引擎可以通过本发明的方法精简原始策略库，缩减策略规模和调整规则顺序，降低和其它功能部件的通信损耗，提高策略匹配的速度和准确率。

附图说明

图1判定结果缓存结构示意图

图2属性缓存结构示意图

图3策略缓存结构示意图

图4XACML策略示例

图5MLOBEE系统

图6MLOBEE判定时序流程图

具体实施方式

图6给出MLOBEE评估引擎完成一次完整判定的时序流程。设定用户发出请求req(principal，res，ac)，其中principal是用户自身标识，res是要访问资源，ac是访问动作。PDS中的上下文处理器ContextHandler将请求转换为XACMLRequest(principal，res，ac)，评估引擎EvaluationEngine对XACMLRequest进行处理，根据用户的principal和此次会话标识Session ID在Result Cache检索是否有关于(res，ac)的判定结果。若Result Cache中存在判定结果，引擎直接将其封装为XACMLResponse返回；若没有检索到判定结果，引擎首先判断属性缓存中是否有principal的相关属性，principal首次访问资源时，需要通过属性断言服务AAS检索并更新Attribute Cache。若用户来自外域，还需要推导其在本域的等价属性。若系统的访问控制规则都汇总为一个XACML策略中，根据perAtom(res，ac)获取subList并将主体属性subAttr∈subList按顺序依次在属性缓存中匹配，首次适用的subAttr所附带的effect类型即为该策略的评估结果；若应用场景为多策略组合，引擎根据res在策略缓存中进行第一阶段索引匹配，获取策略列表policyList，针对其中的每条策略，实施第二阶段索引。多策略组合情况下会应用策略评估合并算法：若某条策略的评估结果符合算法的优先匹配逻辑，则直接返回该结果；若不符合优先匹配逻辑，则评估引擎继续对policyList中后继策略进行评估，最终评估结果经过上下文处理器返回用户。

附录：冗余判定规则证明

permit-overrides算法下：

规则1  若且R_j.effect＝permit，则R_i是冗余规则。

证明：对于R_i适用的任意访问请求req(sub，res，ac)，因为可得R_j|＝req(sub，res，ac)。若R_i.effect＝permit，则与R_j.effect重复，删除R_i不影响整个策略的最终判定结果，证得R_i是冗余规则；若R_i.effect＝deny，因为策略采用permit-overrides算法，R_i对req(sub，res，ac)的判定结果被Rj屏蔽，删除R_i不影响整个策略的最终判定结果，证得R_i是冗余规则。□

规则2  若且R_j.effect＝deny：当R_i.effect＝deny时，R_i是冗余规则；当R_i.effect＝permit时，R_i不是冗余规则。

证明；对于R_i适用的任意访问请求req(sub，res，ac)，因为可得R_j|＝req(sub，res，ac)。若R_i.effect＝deny，则与R_j.effect重复，删除R_i不影响整个策略的最终判定结果，证得R_i是冗余规则；若R_i.effect＝permit，因为策略采用permit-overrides算法，R_i对req(sub，res，ac)的判定结果为permit，R_j无法屏蔽此结果，删除R_i将影响整个策略对req(sub，res，ac)的最终判定结果，证得R_i不是冗余规则。□

规则3～规则6的证明方法与规则1和规则2的证明方法类似，证明从略。