可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）和下一代访问控制（Next Generation Access Control，NGAC）是两种截然不同的基于属性的访问控制（Attribute-based Access Control，ABAC）标准。虽然它们的目标都是提供一种标准化的方式来表达和执行各种类型的访问控制策略，以满足各种数据服务上的多样化策略的需要，但这两个标准在描述和实施访问控制策略的方式上有明显的差异。
本文介绍了XACML和NGAC的标准规范，然后分别从5个方面对它们进行了比较，目的是帮助ABAC用户和供应商在解决未来数据服务的策略实施需求时，能够做出明智、正确的选择。
关键词：访问控制；访问控制机制；访问控制模型；访问控制策略；基于属性的访问控制；授权；可扩展访问控制标记语言；下一代访问控制；特权
第一部分
ABAC概况和XACML规范
壹
ABAC的发展概况
几十年来，控制和管理对敏感数据的访问一直是一个颇具挑战性的任务。基于属性（Attribute）的访问控制（ABAC）代表了逻辑访问控制发展的最新里程碑，它提供了一种基于属性的方法来适应广泛、多样的访问控制策略，并简化了访问控制管理。
大多数访问控制方法都是基于发起访问（例如读取文件）请求的用户的身份来实现的，要么直接基于用户身份为其分配相应的能力（Capability），要么通过预定义的属性类型（例如分配给用户的角色或组）来间接授权。因为需要将能力直接与用户或其属性相关联，这些访问控制系统的建设和管理往往很麻烦。
此外，请求用户的身份、组和角色通常也不足以表示实际的访问控制策略。另一种方法是用属性来表示策略，并根据用户和资源的任意属性，以及可选的环境属性来授予或拒绝用户的请求，这种访问控制方法通常称为基于属性的访问控制（ABAC），也是XACML和NGAC的固有特性。
ABAC引擎的访问控制逻辑根据请求用户、资源和环境的指派（Assign）属性以及用这些属性表示的策略来计算策略决策，如图1所示。
图1 ABAC的基本概念
有两种方法来定义ABAC策略。最常见的方法是通过逻辑表达式来定义授权策略，逻辑表达式由属性值和逻辑运算符（例如，AND，OR，≥，≠）组成。例如：
can_access(u，a，o)→ Role(u)=”doctor” AND Ward(u) = Ward(o) AND (a=read OR a=write)
定义了：对于任何用户u和客体o，只要u具有doctor角色，且u和o的病房信息相同，且当前操作为read或write，则都允许u对o执行操作a。
XACML 、ABAC𝞪和HGABAC（基于层次组和属性的访问控制）所定义的策略规范语言都属于这种表达方式。
第二种策略的定义方法是枚举所有相关的关系配置。NGAC和LaBAC（基于标签的访问控制）属于这一类。例如，NGAC通过使用（uai，arsi，oai）形式的关系组合来指定策略，意为：用户属性uai中的用户拥有对客体属性oai中的客体在访问权限集arsi中的访问权限。
XACML和NGAC都是ABAC标准，用于为用户的数据服务环境引入便利的安全策略框架。一般来说，数据服务是为用户提供数据的消费、操纵、管理和共享的应用程序，如员工考勤报告、工资单处理、公司日历和健康福利管理等应用程序，这些应用都需要访问控制的保护。XACML和NGAC为应用程序提供了一个通用的访问控制工具，大大减轻了企业在安全管理中面临的互操作性和可用性挑战。具体的做法是，从每个应用的操作环境中删除其实现访问控制的功能组件，所有相应的访问控制逻辑由一组提供访问决策功能的公共访问控制模块来实现，这些模块通过集中的策略和属性存储库来支持这些应用程序。
从访问控制的角度来看，数据服务在概念上可以被视为具有表示/逻辑层和操作环境层的应用程序，其不同层次由相应的功能和接口来描述。表示层为用户提供了一个数据接口和方法，用于创建、显示和更改数据。表示层不执行存储、检索或更改存储数据状态的操作，也不执行更改数据访问状态的操作（例如，读取、写入/保存、创建和删除文件、提交、批准、调度），而是向操作环境层发出执行这些操作的请求。操作环境实现操作例程以执行访问请求，并提供访问控制以确保操作例程的执行受策略保护。
访问控制机制由多个逻辑组件组成，它们相互协同以实现受策略保护的数据访问。这些组件包括访问控制数据（用于表达访问控制策略和属性），以及用于捕获访问请求和针对这些请求计算和执行访问决策的一组函数。大多数操作环境以不同的方式实现访问控制，每个环境都有不同的控制范围（例如用户、资源），每个环境都涉及不同的操作方式（例如读取、发送、批准、选择）和数据类型（例如文件、消息、工作项、记录）。
这种异质性带来了许多管理和策略执行方面的挑战。在管理访问策略和属性时，管理员不得不处理大量的安全域。即使能在不同的操作环境中进行适当的协调，全局控制也很难可视化和实施运行。此外，由于操作环境以不同的方式实现访问控制，因此很难跨操作环境来交换和共享访问控制数据。XACML和NGAC试图通过创建一种通用的、集中的方式来表达所有访问控制数据（策略和属性）和计算策略决策（针对应用程序表示层的访问请求），从而缓解这些挑战。
2014年，NIST发布了SP 800-162《基于属性的访问控制（ABAC）定义和思考》。发布该文档有两个目的，首先，它为联邦机构提供了ABAC的权威定义及其功能组件的描述。SP 800-162将ABAC视为一种机制，包括4个功能层次：执行、决策、访问控制数据和管理。第二，考虑到ABAC不同实现方法的潜力，SP 800-162强调了选择ABAC进行部署的几个考虑因素。这些考虑因素涉及操作效率、属性和策略管理、支持的策略范围和类型以及对行政审查和资源发现的支持等。基于这些方面，本报告对XACML和NGAC进行了分析和比较，还比较了它们在支持访问控制功能与专有操作环境分离方面的能力，但并不打算为XACML或NGAC提供实现规范。
1
XACML
2003年，随着面向服务体系结构（SOA）的出现，结构化信息标准促进组织（OASIS）发布了一个名为XACML的规范，提出了许多后来被认为是ABAC的元素。XACML在其授权过程中采用了三个组件：
◆ XACML策略语言。采用规则、策略和策略集的形式来定义访问控制要求，策略要素包括主体（用户）、资源、动作（操作）和环境属性，以及一组用于策略/规则组合的算法。
◆ XACML请求/响应协议。用于查询决策引擎，该引擎根据策略评估主体的访问请求，并在响应时返回访问决策。
◆ XACML参考体系结构。用于部署软件模块以支持策略和属性，并基于策略和属性计算和执行访问控制决策。
XACML是最早出现的ABAC标准，当前版本是2013年发布的XACML 3.0，在其发展过程中，它得到了研究人员和供应商的广泛关注和认可。与较新的、仍处于初级阶段的NGAC标准（最早的一部分内容发布于2013年，其他部分仍在开发中）相比，XACML已经被很多系统采用，许多开源和专有实现都涵盖了其标准组件。
尽管无法一一讨论各种XACML产品，但Sun XACML开源框架非常值得一提，因为它开创性地实现了XACML框架的所有组件，进而验证了XACML标准的可行性，并对后续的XACML产品产生了较大影响。Sun XACML不仅是企业应用和研究性项目中使用最广泛的访问决策引擎，许多其他开源和专有XACML解决方案也都以Sun XACML作为基础开发库。
2
NGAC
2003年，NIST启动了一个称为策略机（Policy Machine）的项目，以寻求一个标准化的ABAC机制，允许在ABAC策略的表达和执行中通过更改一组固定的数据元素和关系，来实现灵活的授权过程。
如今，策略机已经从一个概念发展到正式规范，再发展到受临时专利保护的NGAC和GitHub开源的参考实现。作为NGAC中的一个重要组成部分，策略机与美国国家标准协会/国际信息技术标准委员会（ANSI/INCITS）一系列以“下一代访问控制”（NGAC）为题的标准化工作保持一致，并为其提供支持。除了表达和实施各种各样的访问控制策略，NGAC设施还可用于实现各种数据服务的关键安全组件，并为数据服务实施基于任务定制的访问控制策略。NGAC标准化工作已经并将继续在以下三个子项目下进行：
◆ Project 2193–D：NGAC–实施要求、协议和API定义
◆ Project 2194–D：NGAC–功能体系架构
◆ Project 2195–D：NGAC–通用操作和抽象数据结构
NGAC初始标准发布于2013年，现在可以从ANSI标准库获取，名为INCITS 499–NGAC功能体系架构（NGAC–FA）。不过，现在正在根据2195-D项目的经验和2193-D项目的反馈，进行一些相关的标准更新工作。
目前，Project 2195–D的标准已获得批准，可从ANSI标准库获取，名为INCITS 526–NGAC通用操作和抽象数据结构（NGAC-GOADS）。
在三个NGAC项目中，Project 2193-D项目最不成熟，其提议的实施方法和支撑材料预计将在2016年夏末提交完毕（注：该报告的发布日期为2016.10）。
随着策略机规范、NGAC GitHub开源发行版的推出，以及NGAC（旨在与策略机规范保持一致）作为国家标准的出现，商业和学术机构正在努力开发相关产品。目前，至少有一个NGAC的实现已经完成商业化部署，用于支持某云解决方案提供商为生命科学的临床研究提供的内部应用程序。这个访问决策引擎可能是第一个活动的、在生产环境中使用的策略机/NGAC实现，目前用于保护用户的一些临床试验数据。在不久的将来，该公司的其余产品（它们管理着世界上绝大部分的临床试验数据）将与该访问决策服务集成。策略机/NGAC实现的很大一部分已经开放源码。
3
XACML和NGAC的项目起源
在企业IT体系结构的不同组件中指定和实施安全策略（尤其是访问控制策略），使维护、修改和展示企业范围内合规性的代价变得非常昂贵。开发XACML是为了满足访问控制对通用的策略表达语言的需求，以便在各种信息系统组件中管理所有策略元素的执行。该标准的第一个版本XACML 1.0由OASIS于2003年发布，当前版本是XACML 3.0，OASIS于2013年1月批准了该版本。
由于XACML规范缺少对其包含的策略的访问控制模型，因此它需要一个额外的策略管理模型，XACML 3.0中的管理和委托概要（版本1.0）是一个满足该需求的规范。因为只有当多个人具有能够创建策略的管理权限时，策略背景下的管理（注：指受策略保护的管理操作）才有实际意义，并且由于这些操作总是来自更高层的权威实体（例如，集中式管理员），因此XACML的委托概要自然应该具有策略委托的功能，并且支持创建委托链。
发展NGAC的动机是不同的。虽然研究人员、安全从业者和策略制定者已经制定了各种各样的访问控制策略来解决现实世界中的安全问题，但这些策略中只有非常小的一部分可以通过现有技术执行，而能够被所有机制执行的策略就更少了。NGAC的研究目的是设计一个通用的访问控制框架，通过策略的配置来表达和实施任意的、特定组织的、基于属性的访问控制策略。NGAC从一组基本的、可重用的数据抽象和功能出发，为访问控制提供了一个全新的视角，这些抽象和功能支持常见的和已实现的访问控制策略，以及通用策略的组合，甚至那些尚不存在访问控制机制的策略。
策略和属性（包括委托）的管理从一开始就被视为NGAC框架的一部分。2003年首次开发的策略机是体现上述原则的概念验证系统，随后的迭代改进了策略的多样性和授权的表达能力。出于规范策略机访问控制模型和策略评估过程的需要，为了鼓励策略机的大规模应用，开发了NGAC。
尽管XACML和NGAC有不同的起源和动机，但它们具有共同的主题，都是基于与用户、操作或资源相关联的属性来进行授权。因此，XACML和NGAC都是基于ABAC模型的访问控制框架。然而，在XACML中，授权是用包含属性值的逻辑表达式表示的，而在NGAC中，授权是通过枚举包含属性值的关系来表示的。
目前，XACML和NGAC都适用于各种应用程序环境，例如文件系统，以及具有Web服务或RESTful API的分布式应用程序。
贰
XACML规范
XACML为ABAC实现定义了一种策略规范语言和参考体系结构。该标准包含用于表示请求、策略、属性和函数的语法和语义，这些请求、策略、属性和函数用于计算决策和执行策略，以响应主体对资源的访问请求。
为了简洁易读，本节对XACML规范进行了概述，旨在突出XACML的基本特性，因此内容可能并不完整。在某些特殊情况下，XACML的细节和术语被替换为本文的术语，以简化表述。
1
策略与属性
XACML访问请求由主体（Subject，通常指发出请求的用户）属性、资源（Resource，请求访问的对象）属性、操作（Action，对资源执行的操作）属性和环境（Environment）属性组成。
XACML属性以“名-值”对的形式定义，其中属性值可以是不同类型（例如integer、string）。属性名/ID表示与主体、资源、操作或环境相关联的属性或特征。例如，在医疗情况下，主体属性Role可能具有doctor、intern和admissions nurse等值，其值的类型均为string。主体和资源实例使用一组“名-值”对来指定它们各自的属性。例如，医疗策略中使用的主体属性可能包括：Role=“doctor”、Role=“consultant”、Ward=“pediatrics”、SubjectName=“smith”；环境属性：Time=“12:11”；和资源属性：resource-id=“medical-records”WardLocation=“pediatrics”，Patient=“johnson”。
尽管XACML不需要任何命名属性的约定，但前缀Subject、Resource和Env分别用于命名主体、资源和环境属性，以增强可读性。
主体和资源属性存储在各自的存储库中，并在访问请求时和计算决策之前通过策略信息点（PIP）进行检索。XACML将操作形式化定义为请求的一部分，其属性值包括read，write，submit和approve等操作。
环境属性通常需要借助能够检测和报告环境数据的系统传感器，并且与通过管理手段创建的主体和资源属性有些不同。环境属性不是主体或资源的特性，而是与访问请求发生时的操作环境或上下文环境相关的可测量特征。这些环境特征与主体和资源无关，可能包括当前时间、一周中的某一天或威胁级别。
本文档使用A()的函数形式来表示属性值的计算结果，其参数可以是主体、资源、操作或环境。例如A(e)，其中e是环境，可能等于09:00（时间）或low（威胁级别）；A(s)，其中s是主体，可能等于smith（姓名）和doctor（角色）。使用元组来表示主体、资源或环境所拥有的多个属性。例如，A(s1)=<smith，doctor>，其中第一个属性对应于主体s1的名称，第二个属性对应于主体s1所拥有的角色。
如图2所示，XACML访问策略被组织为策略集（PolicySet）形式，策略集由策略和其他策略集（可选）组成，而策略由规则（Rule）组成。策略和策略集存储在策略检索点（PRP）中。因为并非所有的规则、策略或策略集都与给定的请求相关，所以XACML引入了一个“目标（Target）”的概念。一个目标定义了一个简单的布尔条件，如果属性满足该条件（计算结果为真），则由策略决策点（PDP）确定继续进行后续计算。如果没有目标与请求匹配，则PDP计算的决策结果为“不适用（NotApplicable）”。
图2 XACML策略的构造结构
与目标相似，规则也包含一组布尔条件（Condition），如果计算结果为True，则触发效用动作（Permit或Deny）的执行。如果某个规则的目标条件计算结果为True，但该规则的条件由于任何原因而无法计算，则该规则的效果是不确定的。与目标的（匹配）条件相比，规则或策略的条件通常更复杂，并且可以包括涉及用于比较属性值的逻辑运算符（例如，“greaterthan-equal”、“less-than”、“string-equal”）的函数。条件可用于表示访问控制关系（例如，医生只能查看其负责的病房中患者的病历）或属性值的计算（例如，sum(x,y) lessthan-equal:250）。
为了提高互操作性，所有属性都具有已知的数据类型，并且所有使用这些属性的函数也都有适当的类型。尽管这些标准数据类型和函数已经可以支持灵活的策略表达式，但XACML仍然进一步定义了数据类型和函数的扩展规范。
2
组合算法
因为一个策略可能包含多个规则，而一个策略集也可能包含多个策略或规则集，每个规则、策略或策略集可能产生不同的决策结果，包括允许（Permit）、拒绝（Deny）、不适用（NotApplicable）或不确定（Indeterminate）。XACML通过一系列组合算法来协调这些可能冲突的单个决策，每个算法代表一种将多个局部决策合并成单个全局决策的方法。AXCML定义的标准组合算法，包括：
◆ 拒绝覆盖（Deny-override）。如果任何决策评估为拒绝，或没有决策评估为允许，则合并结果为拒绝。如果所有决策都评估为允许，那么合并结果就是允许。
◆ 允许覆盖（Permit-override）。如果任何决策评估为允许，则合并结果为允许，否则合并结果为拒绝。
◆ 首项适用（First-applicable）。按评估项在组合列表的顺序，将第一项的决策结果（允许、拒绝或不确定）作为合并结果。
◆ 唯一适用（Only-one-applicable）。如果合并列表中只有一个决策适用，则以该决策的结果作为合并结果，如果有多个决策适用，则合并结果为不确定。
在策略中的规则和策略集中的策略上应用组合算法后，获得PDP的最终决策结果。组合算法可用于构建日益复杂的策略。例如，假设仅当聚合（最终）决策为Permit时，PDP才允许主体请求，则“允许覆盖”算法的本质是针对Permit的“OR”操作（只需存在一个结果为Permit的决策），“拒绝覆盖”的本质是针对Permit的“AND”操作（所有决策都必须为Permit）。
除了标准的组合算法集之外，XACML还包括一个标准的扩展机制，可以用来定义其他算法。
3
职责和建议
XACML包含了职责（Obligation）和建议（Advice）的概念。规则、策略或策略集中指定的职责（可选）是PDP向PEP发出的指令，说明在允许（或拒绝）访问请求之前（或之后）PEP必须执行的操作。
建议与职责类似，唯一的区别是建议可以被PEP忽略。
例子：
◆ 如果Alice被拒绝访问文档X：通过电子邮件通知她的经理，Alice试图访问文档X。
◆ 如果拒绝用户访问文件：通知用户拒绝其访问的原因。
◆ 如果准许用户查看文档X：在传输文档前，为其添加水印。
最典型的职责是在批准访问请求后，审记和记录用户的访问事件。
应该注意的是，执行职责或建议指令的功能超出了XACML的能力，通常需要由特定应用的PEP实现和执行。
4
策略示例
下面给出两个XACML策略的规范示例。为了保持与XACML相同的语义，使用了相同的元素名，但是为了增强可读性，策略和规则采用了伪代码（而不是准确的XACML语法）定义。附录C中包含了第一个策略（策略1）的标准XACML格式。
策略1适用于“医生或实习生对病历的所有读写操作”（即策略的目标），包括三个规则。因此，当具有“doctor”或“intern”角色的主体发出读取或写入“medical-records””资源的请求时，该策略被视为“适用”。
这些规则没有对目标的细化，而是描述了允许医生或实习生对病历进行读写请求的条件。如果分配给医生或实习生的病房与患者所在的病房不同，规则1将拒绝任何访问请求（read或write）。规则2明确拒绝实习生在任何情况下的write访问请求。规则3在特殊情况（病人处于危重状态）下，允许“doctor”对病历进行读写访问，而不管规则1的条件是否满足。由于该策略的目的是在这些特殊情况下允许访问，因此使用了“允许覆盖”的策略组合算法，如果只有规则1或规则2中所述的条件适用，则仍然拒绝访问（注：规则1或2适用时，它们都产生Deny的决策）。
<Policy PolicyId=“Policy 1”rule combing algorithm=“permit overrides”>
// Doctor Access to Medical Records//
<Target>
/* :Attribute-Category :Attribute ID :Attribute Value */
:access-subject :Role :doctor
:access-subject :Role :intern
:resource :Resource-id :medical-records
:action :Action-id :read
:action :Action-id :write
</Target>
<Rule RuleId= “Rule 1” Effect= “Deny”>
<Condition>
Function: string-not-equal
/* :Attribute-Category :Attribute ID */
:access-subject :WardAssignment
:resource :WardLocation
</Condition>
</Rule>
<Rule RuleId=“Rule 2” Effect = “Deny”>
<Condition>
Function: and
Function: string-equal
/* :Attribute-Category :Attribute ID :Attribute Value */
:access-subject :Role :intern
Function: string-equal
/* :Attribute-Category : Attribute ID :Attribute Value */
:action : Action-id :write
</Condition>
</Rule>
<Rule RuleId=“Rule 3” Effect=“Permit”>
<Condition>
Function: and
Function: string-equal
/* :Attribute-Category :Attribute ID :Attribute Value */
:access-subject :Role :doctor
Function: string-equal
/* :Attribute-Category :Attribute ID :Attribute Value */
:resource :PatientStatus :critical
</Condition>
</Rule>
</Policy>
策略和属性指派一起定义了授权状态。表1通过指定属性名和值来定义策略1的授权状态。
表1. 策略1的属性名称和值以及授权状态
| 主体属性和值域 | Role = {doctor, intern} WardAssignment = {ward1, ward2} |
| 资源属性和值域 | Resource-id = {medical-records} WardLocation = {ward1, ward2} PatientStatus = {critical} |
| 操作属性和值域 | Action-id = {read (r), write (w)} |
| 系统中，两个主体 (s3, s4) 和三个资源 (r5, r6, r7)的属性指派 | A(s3) = <doctor, ward2>, A(s4) = <intern, ward1>, A(r5) = <medical-records, ward2>, A(r6) = <medical-records, ward1>, A(r7) = <critical> |
| 授权状态 | (s3, r, r5), (s3, w, r5), (s3, r, r7), (s3, w, r7), (s4, r, r6) |
策略2适用于“国税局代理和审计师获取纳税申报表”（策略的目标），包含两条规则。当角色为“IRS代理或审计员”的用户通过写请求访问资源“纳税申报表”时，此策略为“适用策略”。这些规则没有对目标细化，但规定了允许IRS代理人或审计员向纳税申报表记录执行写操作的条件。如果访问时间（环境变量）在上午8点到下午6点之间，规则1将允许适用的访问请求。如果IRS代理人或审计员试图写他自己的纳税申报表，即使规则1中的条件满足，规则2也将拒绝该请求。由于该策略的目的是防止国税局雇员更改自己的纳税申报表，因此使用了“拒绝覆盖”的组合算法，但若规则2的条件不满足，仍将允许访问。
<Policy PolicyId = “Policy 2” rule-combining-algorithm=”deny-overrides”>
// IRS Agent and Auditor Access to Tax Returns //
<Target>
/* :Attribute-Category : Attribute ID : Attribute Value */
:access-subject :Role :IRS-agent
:access-subject :Role :auditor
:resource :Resource-id :tax-returns
:action :Action-id :write
</Target>
<Rule RuleId = “Rule 1” Effect=”Permit”>
<Condition>
Function: and
/* :Attribute-Category : Attribute ID : Attribute Value
:environment : Time : ≥ 08:00
:environment : Time : ≤ 18:00
</Condition>
</Rule>
<Rule RuleId = “Rule 2” Effect=”Deny”>
<Condition>
Function: string-equal
/* :Attribute-Category :Attribute ID
: access-subject :SubjectName
: resource :Resource-owner
</Condition>
</Rule>
</Policy>
5
访问请求与响应
XACML规范了访问请求和决策响应的数据传输格式，称为XACML上下文。请求和响应格式代表了PDP与PEP之间的标准接口。如果PEP没有在XACML上下文中生成访问请求，那么PEP和PDP之间就需要一个上下文处理器。该处理器将特定应用环境的请求（来自PEP）转换为XACML上下文请求，然后提交给PDP，还要将从PDP接收的XACML上下文响应转换为特定应用环境的响应，然后再转发给PEP。
请求上下文由一个或多个与策略元素（主体、资源、操作和环境）相关联的属性组成。例如，如果IRS代理Smith请求在上午9:30写入Brown的报税表，XACML访问请求将携带主体属性Subject-id和Role（属性值分别为“Smith”和“IRS代理”），资源属性resource-id和resource-owner（属性值分别为“Tax-returns”和“Brown”），操作Action-id（值为“write”），环境属性time（值为“09:30”）。该访问请求的XACML代码如下。
<Request>
<Subject>
<Attribute AttributeId=”access-subject;Subject-id”>
<AttributeValue>smith</AttributeValue>
<Attribute AttributeId=”access-subject;Role”>
<AttributeValue>IRS-agent</AttributeValue>
</Subject>
<Resource>
<Attribute AttributeId=”resource;Resource-id”>
<AttributeValue>tax-returns</AttributeValue>
<Attribute AttributeId=”resource:Resource-owner”>
<AttributeValue>brown</AttributeValue>
</Resource>
<Action>
<Attribute AttributeId=”action;Action-id”>
<AttributeValue>write</AttributeValue>
</Action>
<Environment>
<Attribute AttributeId=”environment;time”>
<AttributeValue>09:30</AttributeValue>
</Environment>
</Request>
策略2（3.4节）适用于此请求，因为其目标包括角色为“IRS代理或审计员”以“写”模式访问“资源税申报表”的任何主体。该策略的规则1指定了允许访问的时间区间，规则2拒绝了访问主体与资源所有者相同（IRS代理或审计员访问其自己的纳税申报表）的访问请求。
响应上下文包含一个或多个从PDP获得的、与访问请求对应的评估结果，如决策、状态、职责或建议（可选）。如上所述，决策结果包括：允许、拒绝、不适用或不确定（在发生错误的情况下）。状态用于返回与错误相关的信息（可选）。对适用的策略或策略集，响应还可以选择性地包括一个或多个义务或建议。
如果根据策略2来评估上述请求，则其XML编码的响应如下：
<Response>
<Result>
<Decision>Permit</Decision>
<Status>
<StatusCode Value=”status:ok”/>
</Status>
</Result>
</Response>
6
委托
到目前为止，前面讨论的XACML策略都是由单个授权机构创建和修改的访问策略。单一授权机构（例如集中式管理员）被认为是可信的，这些访问策略也不需要携带“颁发者（Issuer）”信息。基于信任的语义，这些策略所属的类型或类可以称为“可信的访问策略”。但是在没有任何其他类型策略的情况下，XACML策略库中的策略都被简单称为“访问策略”。可信策略的优点是可以被PDP直接用于计算决策。
为了能够通过委托（从集中式管理员/单一授权机构到下级管理员（被委托的机构））来创建策略，XACML引入了一种新的策略（称为管理策略）。这种策略能够指定多个授权机构，用于：（A）创建访问策略，或（b）创建一个或多个管理策略来指定更多的下级授权机构。这种指定的授权机构称为受托方，受托方所拥有权限的域称为情境（Situation）。这种策略管理能力要求XACML能够规范委托策略的定义，从而产生了委托链（由一个或多个管理策略组成，并以访问策略终结）。
管理策略所引入的委托和情境两个概念被封装在它的目标中。因此，管理策略中的目标在内容和语义上与访问策略中的目标不同。“委托”可以被认为是一种与主体类型相同的属性类别，代表被授予创建访问策略（完结委托链）或管理策略（添加到委托链）权限的实体。情境通过指定特权域来限制该权威机构的“领地”范围，特权域用主体、资源和操作的属性组合来表示。如果受托方创建了一个策略，为其特权域所覆盖的资源授予访问权限，则这种策略的类型为非可信访问策略。非可信访问策略与访问策略（在没有委托策略的策略存储库中）很容易区别开来，因为前者应该始终有一个颁发者。另外，如果受托方决定在该特权域的范围内行使进一步委托的权利（而不是行使创建访问策略的权利），则他创建的管理策略被称为非可信管理策略。
这样，在支持委托的XACML策略存储库中，存在4种子类型的策略：
●（可信）访问策略
● 非可信访问策略
● 可信管理策略
● 非可信管理策略
根（Root）或委托策略（即委托链）的起点是管理策略的一个子类，称为可信管理策略。可信管理策略是由创建（可信）访问策略的同一机构创建的，因此，可信管理策略也没有颁发者标记，因为它总是由可信的集中式管理员创建。
回顾一下，管理策略是通过一系列授权，将创建访问策略的权利直接或间接地委托给多个机构。因此，可信管理策略授予受托方创建非可信管理策略或非可信访问策略的权限。因此，委托链必须从可信管理策略开始，以非可信访问策略结束，中间选择性地包括一个或多个非可信管理策略。新创建的非可信管理策略或非可信访问策略的情境是可信管理策略的情境的子集（特权范围相同或更小）。此外，非可信管理策略或非可信访问策略包括一个颁发者标记（其值与受托方相同）。所有这些策略至少有一个规则具有“允许”或“拒绝”效用。
6.1
委托链示例
如前所述，委托链的起点是可信管理策略，它的目标中存在一个受托方（下级管理员）和一个情境（下级管理员可以授权或进一步委托的特权域）。在图3示例中，可信管理策略将“Smith”指定为下级管理员，将“Situation1”指定为特权域，Smith可以在其上对资源的访问授权或执行进一步的委托。
图3 XACML委托链（从下到上）的示例
回想一下，非可信管理策略也有一个受托方（其指定的下级）和与该受托方关联的特权域。此外，非可信管理策略还应具有颁发者标记，该标记的值必须与某些管理策略中的受托方标记的值一致。只有创建非可信管理策略的受托方才会成为颁发者标记。在图3中，一个由Smith发布的非可信管理策略（在上面讨论的可信管理策略的授权下），指定Jones作为受托方（下级管理员），关联的特权域是“Situation2”。特权域“Situation2”的范围必须是特权域“Situation1”（在上面讨论的可信管理策略的中指定）的子集。
就像下级管理员Smith一样，其委托方Jones可以对其特权域中指定的资源行使进一步的委托权或访问授权。如果Jones对其特权域内的资源行使访问授权（与Smith不同），则她将创建的访问策略将是非可信访问策略。在图3中，Jones发布了一个非可信访问策略（在Smith授予她的权限下），访问权限的范围被指定为“Situation3”。这个作用域必须是Smith委托给她的特权域（Situation2）的子集。
XACML策略存储库中的委托策略（形成委托链）数量相对较少。大多数策略是由单个授权机构创建的（可信）访问策略，如图3所示。
6.2
委托链中的访问请求处理
在没有任何委托链的情况下，系统中的所有访问策略都是（可信）访问策略。在这些情况下，如果PDP能够将请求中的属性与访问策略的目标相匹配，则该访问策略就被视为适用的策略，并自动作为参与策略包含在相关的策略组合算法中（因为该策略是可信的）。在存在一个或多个委托链的情况下，PDP可以发现匹配目标（相对于访问请求）来自非可信访问策略中。由于它被指定为非可信访问策略，因此只有在验证策略颁发者（非可信访问策略始终具有颁发者标记）的权威性后，PDP才会考虑将其包含在策略组合算法中。
权威性验证通过查找导向可信管理策略的委托链来完成，该委托链在指向可信管理策略的路径中可能包含0个或多个非可信管理策略。当策略被视为图中的节点时，查找委托链的过程转化为在该图中查找/构造一条从非可信访问策略节点到可信管理策略节点的路径。为了构造图中的每个边，PDP（使用XACML上下文处理器）构造了一个管理请求，如图3所示。
管理请求的结构与访问请求相同，但除了基本的属性类别（访问主体、资源和操作）之外，它还使用两个额外的属性类别，即委托（delegate）和决策信息（decision-info）。如果策略Px恰好是一个适用的（匹配的）非可信访问策略，则使用以下方法从策略Px生成管理请求，以便构造一条到策略Py的边：
使用上述属性构造出来的管理请求将按照策略Py的目标进行评估。如果评估结果为“允许”，则在策略Px和Py之间构造一条边。总体逻辑是验证策略Px的发布具有合法性，为此，应该存在一个策略，其“委托”设置为Px的策略颁发者。如果该策略是Py，则表示策略Px是在策略Py授权的基础上发布。然后，从策略Py开始构造边，直到找到到达可信管理策略的边。
选择适用策略以纳入委托链组合算法的过程如图4所示。假设对于一个访问请求，匹配的目标可以在三个非可信访问策略P31、P32和P33中找到。如果可以构造（通过一条边或多条边）从每一个策略到可信管理策略的路径（从而验证每个策略的发布合法性），则这些策略都可以成为适用策略（因此可以包括在相关的组合算法中）。在图4中，可以从策略P31和P32构建这样的路径。从策略P31出发，此路径经过非可信管理策略P21到达可信管理策略P11。从策略P32开始，此路径经过非可信管理策略P22到可信管理策略P12。但是，非可信访问策略P33不存在这样的路径。因此，在计算最终访问决策的组合算法中，将仅使用策略P31和P32，而策略P33将被丢弃（由于无法验证其权威性）。
图4 利用授权链进行策略评估
下面是一个更具体的示例，说明了如何使用委托链来选择适用的策略，这些策略用于组合算法以获得最终的访问决策。该示例给出了一个策略集，该策略集由4个策略组成：
◆ 策略P1：可信管理策略，授予John（受托人）为“任何具有医生角色的用户读取病历”的情境创建策略的权限。
◆ 策略P2：由John在P1授权下发布的非可信管理策略，授予Jessica（受托人）为“任何具有医生角色的用户读取病历”的情境创建策略的权限。由于P1的受托人与P2的策略颁发者匹配，并且策略P1和P2的情境相同，发布策略P2的权限显然来自策略P1。因此P1和P2形成一个委托链。
◆ 策略P3：Jeff发布的非可信访问策略，授权Carol能够读取病历。
◆ 策略P4：Jessica发布的非可信访问策略，使Carol能够读取病例。由于P2的受托人与P4的策略颁发者匹配，并且策略P2和P4的情境相同，发布策略P4的权限显然来自策略P2。因此P2和P4形成了一个委托链。
上述4个策略的伪代码形式如下：
<Policy Set>
<Policy P1> /* Trusted Administrative Policy */
<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
:access-subject :role :doctor
:resource :resource-id :medical-records
:action :action-id :read
:delegate :subject-id :john
</Target>
<Rule R1>
Effect: PERMIT
</Rule R1>
</Policy P1>
<Policy P2> /* Untrusted Administrative Policy */
<Policy Issuer> john </Policy Issuer>
<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
:access-subject :role :doctor
:resource :resource-id :medical-records
:action :action-id :read
:delegate :subject-id :jessica
</Target>
<Rule R2>
Effect: PERMIT
</Rule R2>
</Policy P2>
<Policy P3> /* Untrusted Access Policy */
<Policy Issuer> Jeff </Policy Issuer>
<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
:access-subject :subject-id :carol
:resource :resource-id :medical-records
:action :action-id :read
</Target>
<Rule R3>
Effect: PERMIT
</Rule R3>
</Policy P3>
<Policy P4> /* Untrusted Access Policy */
<Policy Issuer> Jessica </Policy Issuer>
<Target> /*:Attribute-Category :Attribute ID :Attribute Value */
:access-subject :subject-id :carol
:resource :resource-id :medical-records
:action :action-id :read
</Target>
<Rule R4>
Effect: PERMIT
</Rule R4>
</Policy P4>
<Policy Set>
通过将一个策略中的情境和受托人与另一个策略中的情境和策略颁发者匹配起来，可以看出P1、P2和P4形成了一个委托链，P3不属于任何委派链。鉴于上述委托结构，考虑如何解决下列访问请求REQ1。
<Request REQ1>
<Attributes> /* :Attribute-Category : Attribute ID : Attribute Value */
:access-subject :subject-id :carol
:access-subject :role :doctor
:resource :resource-id :medical-records
:action :action-id :read
</Attributes>
</Request REQ1>
通过将请求REQ1中的属性（及值）与策略集中策略目标的属性（及值）匹配，可以发现只有策略P3和P4直接匹配，因为策略P1和P2包含委托属性。由于策略P3和P4都是非可信访问策略，因此必须通过发送管理请求来验证它们各自的合法性。由于策略P3不属于任何委托链，因此无法验证其合法性。然而，策略P4的合法性可以通过委托链P1、P2、P4来验证。
用于创建访问策略的PAP接口也可用于创建支持委托所需的其他策略，包括非可信访问策略、可信管理策略和非可信管理策略。在支持委托的系统中，至少需要两类策略管理员，第一种是有权创建访问策略的系统管理员，第二种是被授权创建非可信管理策略或非可信访问策略的委托管理员，而这些非可信策略应符合当前策略存储库中任何可信管理策略授权的情境（或其子集）。
7
XACML体系架构
XACML参考体系结构定义了必要的功能组件（如图5所示），以实现其策略的实施。其授权过程包含7个步骤，并依赖于4个功能层：执行、决策、访问控制数据和管理。
PDP（负责计算针对主体请求的策略决策）是整个系统架构的核心。访问请求（从PEP发往PDP）和策略决策（从PDP发往PEP）均通过标准化的请求和响应语言表达。PEP作为与其应用程序紧密耦合的操作环境组件来实现。PEP可能不能以XACML语法生成请求，也不能处理与XACML语法兼容的授权响应。为了将本地格式（与操作环境相关）的访问请求转换为XACML访问请求（或将XACML中的PDP响应转换为本地格式），XACML体系结构包括一个上下文处理器。上下文处理器还为访问请求上下文提供其他属性值（可以从PIP检索）。在图5中，上下文处理器没有显式地用组件表示，因为它被认为是PEP或PDP的一个组成部分。
请求由从PIP中提取的属性组成，这些属性至少应满足目标匹配的需要。PIP虽然被表示为一个逻辑存储库，但实际上它也可以包含多个物理存储库。在计算决策时，PDP查询存储在PRP中的策略，如果请求的属性不足以进行规则和策略评估，PDP可以请求上下文处理器在PIP中搜索其他属性。存储在PIP和PRP中的信息和数据共同组成了访问控制数据并定义了当前授权状态。
图5 XACML参考体系结构
策略管理点（如PAP1）使用XACML策略语言来创建存储在PRP中的访问控制数据，包括策略规则、作为策略容器的策略集以及规则/策略组合算法等。PRP可以存储可信或非可信策略。尽管没有包括在XACML参考体系结构中，第2策略管理点（PAP2）用于创建和管理存储在PIP中的访问控制数据。PAP2实现了创建和管理属性（名称和值）所必需的管理例程。资源访问点（RAP）用于对资源执行操作。在PDP返回许可决策的情况下，PEP向RAP发出命令以执行对资源内容的操作。如图5中的虚线框所示，与PEP一样，RAP也运行在应用程序的操作环境中，独立于PDP及其支持组件。PDP及其支持组件通常以集中式授权服务器的模块形式实现，集中式授权服务器可以为多种类型的操作提供授权服务。
扫一扫
770
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
