A Brief Introduction to XACML

一个XACML的简介

摘要：

本文对XACML进行一个简要的介绍。如需对XACML作更多的了解，请访问OASIS的XACML技术委员会网站。

简要的说，XACML是一个通用的访问控制策略定义语言。XACML提供一套语法（使用XML定义）来管理对系统资源的访问。

A Brief Introduction to XACML

XACML简介

XACML是一个OASIS标准。该标准是一个描述（访问控制）策略语言，同时也是一个描述访问控制判断请求/应答（request/response）的语言。当然，都是使用XML。策略描述语言用于定义通用的访问控制需求，包括若干标准扩展点来定义新的功能、数据类型、组合逻辑等。（访问控制判断）请求/应答描述语言使得你可以构成一个问询（query）来判断是否一个动作（action）被允许执行，并对结果进行解释。访问请求通常包括关于请求是否被允许的问题，这个问题中包括四个参数：Permit，Deny，Indeterminate（错误发生或需要的参数值不可用，无法进行判断）和Not Applicable（该请求无法被该服务器回应）

典型的机制是这样：当有人试图执行一项资源上的动作时。就会发出一个请求到事实上保护该资源（可能是一个文件系统或Web服务器）的那个装置，该装置被称为PEP（Policy Enforcement Point，策略强制执行点）。PEP会根据请求者的属性、请求资源、动作以及其它的附属信息来构成一个请求（request）。然后PEP会将该请求发送到PDP（Policy Decision Point，策略判断点）。PDP会查阅请求以及一些关于该请求的（访问控制）策略信息，并最终回答该访问是否被承认合法。这个回答返回到PEP，由PEP来对请求者作允许或拒绝的回答。注意：PEP和PDP可能被包容在同一个应用呈现中，也可能被分布到不同的服务中。除了作为一个请求/应答和策略描述语言以外，XACML同时也提供其它一些关系描述：如：根据一个请求定位其对应访问控制策略，以及根据这个请求和其对应策略回答是或否等。

业界有很多类似的应用定义语言来完成这类任务。但XACML有几点优势：

• XACML是标准。标准通过了大量专家和使用者审查，开发者不再需要每次都重新考虑，也不需要在费心考虑在设计一个定义语言所需要的诸多因素。另外，当XACML越是被大量部署，开发者越是能轻松的通过标准语言来与其它应用系统协作交互。
• XACML是通用的。这意味着可以在大多数环境中使用，而不只是在一些特殊的环境中或对特殊的资源可以使用。一个访问控制策略编写后，可以被很多不同类型的应用程序使用。当使用一个较通用的语言来实现时，访问控制策略的管理也变得简单了。
• XACML是分布式的。这意味着一个访问控制策略可以被编写为引用其它任意位置的其它策略。其带来的好处就是可以由不同的用户或组各自管理策略中各自业务范围内、或专业领域内的子策略并最终合并为总策略，而不是集中管理一个集成的访问控制策略。由XACML来处理如何正确的合并不同的子策略判断结果，并作出统一的访问控制。
• XACML是强大的。因为由若干基于基本语言的扩展方法，所以对多环境考虑已经不再必要。标准语言已经可以支持广泛的数据类型、功能、和合并不同策略判断结果的规则。另外，已经有若干标准小组致力于开发扩展和能力描述（extensions and profiles）来使得XACML可以与其它诸如SAML和LDAP之类的标准协调工作。这使得XACML可以得到更广泛的应用。

为了展示这些特征如何很好的相互配合，接下来是一个关于XACML访问控制策略的讨论，并演示该语言的若干标准特性。注意，XACML是一个很丰富的语言，所以在本文中只有很少的特性被展示。可以通过浏览“定义文档”来了解更多的关于XACML特性的信息。

Top-Level Constructs: Policy and PolicySet

顶层结构：Policy and PolicySet（策略和策略集）

所有的XACML访问控制策略的根是Policy或PolicySet。一个PolicySet是一个可以容纳其它Policy或PolicySet的容器，可以通过其引用到非本地的Policy或PolicySet。一个Policy表现为一个单一访问控制策略的引用，它通过一套规则（Rule）来表现。每一个XACML访问控制策略文档都在其XML标签根部包含了唯一的一个Policy或PolicySet。

因为一个Policy或PolicySet可以包含多个策略或规则。因为这些策略或规则会有不同的访问控制判断结果决定，所以XACML需要一个协调判断结果的方法。这在XACML中是通过一套合并算法（Combining Algorithms）来实现。每个算法表示一种不同的合并多判断结果到单一判断结果的方法。XACML有“策略合并算法/ Policy Combining Algorithms”（PolicySet采用）和“规则合并算法/ Rule Combining Algorithms”(Policy采用)。这当中的一个例子是“Deny Overrides Algorithm”，代表无论其它策略判断结果如何，只要其中有一个策略或规则判断返回结果Deny，则最终判断结果定为Deny。这些合并算法可以用于构建复杂的策略。在已有的7种标准的合并算法以外，你可以构造自己的合并算法来满足你的需求。

Targets and Rules

目标和规则

XACML PDP要做的一部分工作是根据一个请求找到对应的策略。为了实现这一点，XACML提供另一个被称为Target的特性。一个Target基本上来说是一套简化了的在一个请求中Policy、PolicySet、Rule必须遇到的关于主题（Subject）、动作（Action）、资源（Resource）的条件限制。这些条件限制都使用布尔判断（将在下一节作阐述）来比较一个请求中的参数值和一个Target里面的条件对应值。如果一个Target中的所有的条件都符合，该请求就被关联到相应的Policy、PolicySet、Rule上。作为一种检查策略适用性的方法，Target的信息中还有一种方法进行策略索引。这在当需要在同一Target中存储多种策略并且需要快速的审阅这些策略以选择最合适策略时非常有用。例如，一个Policy可能包含一个只适用于某一特定服务的Target时。当一个要求访问该服务的请求发生时，PDP就知道到哪儿去找适合判断该请求的策略。因为策略被基于他们的Target的限制条件进行了索引。注意，Target也可以定义为适用于所有的请求。

一旦Policy被找到并被用于验证一个请求，其规则（Rule）即发生作用。Policy可以容纳任意数量的Rule，这些Rule中包含一个XACML策略的核心逻辑。绝大多数的Rule表现为一个条件布尔判断。当前条件为真时，“规则的结果/ Rule‘s Effect”（一个根据规则判断的Permit或Deny的结果）即被返回。条件的判断结果也可以为一个错误（也即“不明确/Indeterminate”）或该条件不适用于判断请求（即“不适合/NotApplicable”）。一个条件可以非常复杂，如：由一系列嵌套的非布尔判断的函数或属性来判断。

Attributes, Attribute Values, and Functions

属性，属性值和函数

XACML运行时处理的是属性。属性是已知类型的值，可能包括属性定义者的标识或定义日期时间。特定的，属性是Subject、Resource、Action或访问请求发生的环境的特征值。一个用户名称、访问间歇、试图访问的文件、访问日期等都可能成为属性值。当一个请求从PEP被发送到PDP时，该请求被构成属性扩展集，并被用于与策略中的属性值进行比较，并最终产生访问控制结果。

Policy以两种机制来解析来自请求或其它来源（其它Policy）中的属性值：AttributeDesignator和AttributeSelector。AttributeDesignator让策略定义以一个名称和类型来定义属性，同时可以提供一个发布者（issuer）可选项。然后PDP就在请求中寻找该属性的值，或判断该属性值是否在请求中可以被找到。一共有4种指示者（designator），分别对应请求中的4种类型的属性：Subject, Resource, Action, and Environment。因为Subject属性可以被拆分到不同的目录中，SubjectAttributeDesignators也可以定义目录来查询之。AttributeSelectors使得一个策略根据XPath query的形式查询一个属性值。只要提供一个数据类型和XPath表达式，就可以解析请求文档中的属性值。

AttributeDesignator和AttributeSelector都可以返回多值（因为可能存在一个请求匹配多条件的情况），所以XACML提供一个特殊的属性叫“Bag”，Bag是一个无序的集合，并且允许重复。通常designator和selector都返回bag，甚至当只有单值返回时也是以bag返回。当没有匹配项是返回空的bag。当然，designator和selector可以设置一个标记，当这一情况发生时产生一个错误。

当属性值Bag被获取时，需要通过某种方法对其进行比较以获得预期的访问控制许可决定。这一功能被一个强大的系统函数集实现。函数集可以在以任何属性值组合为参数运作，并可返回系统支持的任何类型的属性值。函数集还支持嵌套，所以使用函数的结果调用另外的函数，这样的分级嵌套可以任意复杂。二次开发的函数可以提供更加丰富的语言来表达访问条件限制。

在构建这样分级嵌套函数集需要注意的一点是有些函数是被定义为与特定数据类型一起作用（如：string和integer等）。为了处理这一问题，XACML定义了一套标准的构成类型唯一函数（[type]-one-and-only函数），使用在这些函数，如果在Bag中只有一个值时，函数接受Bag中的特殊类型值并返回单一值，或当Bag中无值或多值时报错。这是一个Condition中最普遍的一类函数。Target中并不需要[type]-one-and-only函数，因为PDP会自动的将匹配函数对应到bag的每个元素中。

Putting it Together: An Example Policy

一个Policy例子

以下是一个使用上面讨论的特征的Policy的例子。其Target规定Policy只对那些对“SampleServer”服务发出访问请求的request发生作用。其Policy有一个带Target的Rule，需由“login”动作和一个Condition引发。该Condition适用于当Subject尝试在9:00am到5:00pm之间“login”时。注意，这个荔枝可以被扩展为包括不同动作的其它Rule。当第一个Rule不被适用时，一个缺省Rule返回Deny结果。（Rule是按顺序作用的）

Beegee：

常常想也许感兴趣的朋友可以聚在一起，设立一个开源项目研究实现相关的模型。但似乎国内朋友的热情不足，多为了完成公司的一个项目或毕业论文才投入某个领域其中，而后便又不再有更多投入。其实我自己又何尝不是这样呢？想到这里，感叹不已，于是费力将自己近日所读一文翻译成中文。希望可以此在网上吸引高人在不忍心后的指点一二，或是拉络到一帮志同道合的菜鸟一同谈论。罢了。

原文http://blog.csdn.net/beegee/article/details/105935