中财网flashget手机版:XACML入门
来源：百度文库 编辑：中财网 时间：2024/05/10 07:01:24
时间：2004-03-23
作者：Phil Griffin
浏览次数： 1990
本文关键字：XACML, OASIS, 策略 文章工具
推荐给朋友
打印文章
OASIS批准了一种新的标记语言，它承诺可以使策略管理和访问决策标准化。 2003年2月，可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）获得了批准，成为了一个OASIS标准。 XACML定义了一种通用的用于保护资源的策略语言和一种访问决策语言。
概述
每个企业都需要保护由雇员、合作伙伴、顾客访问的资源。 例如， 在当今的企业中，基于浏览器对聚合资源(web页、应用、服务，等等)的门户的访问是很典型的。为了获取资源，客户端将请求发送到服务器，但在服务器将资源返回之前，必须确定请求者是否被授权使用该资源，这就是XACML的适用之处。
。
XACML提供了一种策略语言，这种策略语言允许管理员定义访问控制需求，以便获取所需的应用资源。 语言和模式支持包括数据类型、函数和允许定义复杂 (或简单)规则组合逻辑。 XACML还包括一种访问决策语言，用于描述对资源的运行时请求。当确定了保护资源的策略之后，函数会将请求中的属性与包含在策略规则中的属性进行比较，最终生成一个许可或拒绝决策。
关键概念
当客户端向服务器提出资源请求时， 可执行授权控制访问的实体叫做策略执行点（Policy Enforcement Point）。为了执行授权的策略， 这个实体将规范化描述策略信息点（ Policy Information Point）的请求者的属性，并向策略决定点（Policy Decision Point）委托授权决定。可用的策略位于策略存储器中，并由策略决定点评估出来，然后返回授权决定。 利用这条信息， 策略执行点可以向客户端做出适当的反应。
定义策略
管理员可以用XACML语言制定策略。 关键的高层元素是聚合了其他PolicySet或Policy元素的PolicySet。Policy元素主要由 Target、Rule 和 Obligation元素构成，在策略决定点做出评估，以生成和访问决策。
由于可能发现多项策略对于访问决策来说都是可用的 (并且由于单个策略可以包含多个Rules)， 那么可以使用组合算法（Combining Algorithms）来将多个结果协调成单个决策。标准组合算法被定义为Deny-Overrides、Permit-Overrides、First Applicable和 Only-One Applicable 等。
Target元素用于将被请求的资源关联到一个可用的Policy上。 它包含了请求的Subject、Resource或Action必须符合Policy Set、Policy或 Rule的条件，以便资源更适用。 Target包括一个内置的方案，用于有效的索引/查找策略。
Rules提供了在一个Policy中测试相关属性的条件。 可以使用任何数量的Rule元素，每一个Rule元素都可以产生一个真或者假的结果。将这些结果进行综合便产生了对该Policy的单一决策，可以是Permit、Deny、Indeterminate或者NotApplicable决策。
Policy 属性
属性提供了既代表一个资源请求者，也代表Policy的条件谓词的典型值。 当描述请求者时， 属性可以包括发布日期和时间、发布者标识，并且还可以选择包含访问请求的Subject、Environment、Resource和Action元素 。
Attribute Designator元素用于根据指定属性的名字、类型和发布者而从请求中获取属性值。SubjectAttributeDesignator、ResourceAttributeDesignator、ActionAttributeDesignator和EnvironmentAttributeDesignator 均从请求的各个元素中获取属性。AttributeSelector元素用于查找使用XPATH查询的请求属性。由于查询能返回属性集合 (所有的相同的原语类型)，它们放在一个Bag里。Functions用于比较包含在一个Bag里的属性。
聚到一起
下面的例子由试图访问服务器资源以便执行部署操作的浏览器客户端组成。服务器策略执行点实体收到了客户的Http 请求，作为回应，策略执行点将XACML 请求写成公式 (使用策略信息点实体的服务) ，包括：1) 客户端所属的用户组的描述; 2) 客户试图访问的URL 资源;3) 客户端试图对资源执行的操作(重新部署)。
DataType="http://www.w3.org/2001/XMLSchema#string"
Issuer="admin@bea.com">
Deployer
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
http://bea.com/deploy/control.html
DataType="http://www.w3.org/2001/XMLSchema#string">
redeploy
寻找并评估策略
下一步， 调用策略决定点实体的服务来查找一个可用的策略，评估它，并返回一个到策略执行点的访问决策。 在本例中，由于Target 元素评估为真，基于Subject、Resource和 Action元素匹配，一个名叫“DeployerPolicy”的策略被决定应用于 Request。
“DeployerPolicy” 只有单个需要评估的Rule，。 如果Rule评估成功， 它将返回一个“Permit” 决策。 Rule中的第一项评估，就是把所有相匹配的Request的Subject、Resource和 Action(“重新部署”)与另一个Target 元素相比较。因此，Condition 被评估。 Condition使用一个SubjectAttributeDesignator来获取Request中所包含的“group” 属性的属性值，并且将其与所匹配的 Policy AttributeValue ("Deployer")相比较。
最终结果是从Policy评估返回的Permit，并返回到策略执行点。
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
http://bea.com/deploy/control.html
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>
redeploy
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/>
AttributeId="group"/>
Deployer
采用时的障碍
在任何系统中，特别是企业级系统中，性能都是一个很关键的因素。随着程序员使用XML不断地变得容易，仍然涉及到很多开销(处理时间和内存)。根据访问决策的粒度，这种障碍可能会变得明显。例如，单个客户端 Http 请求要求呈现一个聚集了许多种资源的门户页面，这种请求也许需要许多访问决策。如果利用XACML来处理这种场景，就会产生许多Request，因为每一个Request可能只包含单个Action元素。这样，收集所有访问决策所花费的处理时间和延迟是令人无法接受的。
第二个潜在的障碍可能是XACML与现有引擎的集成。 一些企业和安全产品供应商都有规则引擎，该引擎用于授权决策中。为了获得成功，XACML必须提供一种与现有引擎集成的简单方法，也许需要通过对Rule元素的评估来调用本地实现。
结束语
在安全策略和访问决策方面，XACML在标准化语言方面迈出了重要一步。这种语言的可扩展性将为多数企业和安全产品供应商提供了克服所有语言缺点的能力。 但是，XACML绝不是一种适用于所有访问决策需求的解决方案，各企业必须根据自己的独特需求来仔细评估，寻找合适的解决办法。
作者：Phil Griffin
浏览次数： 1990
本文关键字：XACML, OASIS, 策略 文章工具
推荐给朋友 打印文章OASIS批准了一种新的标记语言，它承诺可以使策略管理和访问决策标准化。 2003年2月，可扩展访问控制标记语言（Extensible Access Control Markup Language，XACML）获得了批准，成为了一个OASIS标准。 XACML定义了一种通用的用于保护资源的策略语言和一种访问决策语言。
概述
每个企业都需要保护由雇员、合作伙伴、顾客访问的资源。 例如， 在当今的企业中，基于浏览器对聚合资源(web页、应用、服务，等等)的门户的访问是很典型的。为了获取资源，客户端将请求发送到服务器，但在服务器将资源返回之前，必须确定请求者是否被授权使用该资源，这就是XACML的适用之处。
。
XACML提供了一种策略语言，这种策略语言允许管理员定义访问控制需求，以便获取所需的应用资源。 语言和模式支持包括数据类型、函数和允许定义复杂 (或简单)规则组合逻辑。 XACML还包括一种访问决策语言，用于描述对资源的运行时请求。当确定了保护资源的策略之后，函数会将请求中的属性与包含在策略规则中的属性进行比较，最终生成一个许可或拒绝决策。
关键概念
当客户端向服务器提出资源请求时， 可执行授权控制访问的实体叫做策略执行点（Policy Enforcement Point）。为了执行授权的策略， 这个实体将规范化描述策略信息点（ Policy Information Point）的请求者的属性，并向策略决定点（Policy Decision Point）委托授权决定。可用的策略位于策略存储器中，并由策略决定点评估出来，然后返回授权决定。 利用这条信息， 策略执行点可以向客户端做出适当的反应。
定义策略
管理员可以用XACML语言制定策略。 关键的高层元素是聚合了其他PolicySet或Policy元素的PolicySet。Policy元素主要由 Target、Rule 和 Obligation元素构成，在策略决定点做出评估，以生成和访问决策。
由于可能发现多项策略对于访问决策来说都是可用的 (并且由于单个策略可以包含多个Rules)， 那么可以使用组合算法（Combining Algorithms）来将多个结果协调成单个决策。标准组合算法被定义为Deny-Overrides、Permit-Overrides、First Applicable和 Only-One Applicable 等。
Target元素用于将被请求的资源关联到一个可用的Policy上。 它包含了请求的Subject、Resource或Action必须符合Policy Set、Policy或 Rule的条件，以便资源更适用。 Target包括一个内置的方案，用于有效的索引/查找策略。
Rules提供了在一个Policy中测试相关属性的条件。 可以使用任何数量的Rule元素，每一个Rule元素都可以产生一个真或者假的结果。将这些结果进行综合便产生了对该Policy的单一决策，可以是Permit、Deny、Indeterminate或者NotApplicable决策。
Policy 属性
属性提供了既代表一个资源请求者，也代表Policy的条件谓词的典型值。 当描述请求者时， 属性可以包括发布日期和时间、发布者标识，并且还可以选择包含访问请求的Subject、Environment、Resource和Action元素 。
Attribute Designator元素用于根据指定属性的名字、类型和发布者而从请求中获取属性值。SubjectAttributeDesignator、ResourceAttributeDesignator、ActionAttributeDesignator和EnvironmentAttributeDesignator 均从请求的各个元素中获取属性。AttributeSelector元素用于查找使用XPATH查询的请求属性。由于查询能返回属性集合 (所有的相同的原语类型)，它们放在一个Bag里。Functions用于比较包含在一个Bag里的属性。
聚到一起
下面的例子由试图访问服务器资源以便执行部署操作的浏览器客户端组成。服务器策略执行点实体收到了客户的Http 请求，作为回应，策略执行点将XACML 请求写成公式 (使用策略信息点实体的服务) ，包括：1) 客户端所属的用户组的描述; 2) 客户试图访问的URL 资源;3) 客户端试图对资源执行的操作(重新部署)。
Issuer="admin@bea.com">
寻找并评估策略
下一步， 调用策略决定点实体的服务来查找一个可用的策略，评估它，并返回一个到策略执行点的访问决策。 在本例中，由于Target 元素评估为真，基于Subject、Resource和 Action元素匹配，一个名叫“DeployerPolicy”的策略被决定应用于 Request。
“DeployerPolicy” 只有单个需要评估的Rule，。 如果Rule评估成功， 它将返回一个“Permit” 决策。 Rule中的第一项评估，就是把所有相匹配的Request的Subject、Resource和 Action(“重新部署”)与另一个Target 元素相比较。因此，Condition 被评估。 Condition使用一个SubjectAttributeDesignator来获取Request中所包含的“group” 属性的属性值，并且将其与所匹配的 Policy AttributeValue ("Deployer")相比较。
最终结果是从Policy评估返回的Permit，并返回到策略执行点。
http://bea.com/deploy/control.html
采用时的障碍
在任何系统中，特别是企业级系统中，性能都是一个很关键的因素。随着程序员使用XML不断地变得容易，仍然涉及到很多开销(处理时间和内存)。根据访问决策的粒度，这种障碍可能会变得明显。例如，单个客户端 Http 请求要求呈现一个聚集了许多种资源的门户页面，这种请求也许需要许多访问决策。如果利用XACML来处理这种场景，就会产生许多Request，因为每一个Request可能只包含单个Action元素。这样，收集所有访问决策所花费的处理时间和延迟是令人无法接受的。
第二个潜在的障碍可能是XACML与现有引擎的集成。 一些企业和安全产品供应商都有规则引擎，该引擎用于授权决策中。为了获得成功，XACML必须提供一种与现有引擎集成的简单方法，也许需要通过对Rule元素的评估来调用本地实现。
结束语
在安全策略和访问决策方面，XACML在标准化语言方面迈出了重要一步。这种语言的可扩展性将为多数企业和安全产品供应商提供了克服所有语言缺点的能力。 但是，XACML绝不是一种适用于所有访问决策需求的解决方案，各企业必须根据自己的独特需求来仔细评估，寻找合适的解决办法。