Sun Java System Access Manager 7.1 管理指南

策略定义类型文档

一旦创建并配置了策略，它就会以 XML 形式存储于 Directory Server 中。在 Directory Server 中，XML 编码的数据存储在一个位置。尽管策略是使用 amAdmin.dtd（或控制台）进行定义和配置，但它实际上是作为基于 policy.dtd 的 XML 存储在 Directory Server 中。policy.dtd 包含从 amAdmin.dtd（无策略创建标记）中提取的策略元素标记。因此，“策略服务”从 Directory Server 加载策略时，它将根据 policy.dtd 分析 XML。只有在使用命令行创建策略时，才使用 amAdmin.dtd。本节介绍 policy.dtd 的结构。policy.dtd 存在于下列位置：

AccessManager-base/SUNWam/dtd (Solairs)
AccessManager-base/identity/dtd (Linux)
AccessManager-base/identity/dtd (HP-UX)
AccessManager-base\identity\dtd (Windows)

注 –

在本章中的余下部分将只给出 Solaris 目录信息。请注意，Linux、HP-UX 和 Windows 的目录结构不同。

Policy 元素

Policy 是根元素，它定义策略的权限或规则以及规则适用的对象或主题。它还定义策略是否是引用（指派）策略以及是否对该策略存在限制（或条件）。它可能包含一个或多个下列子元素： Rule、Conditions、Subjects、Referrals 或 response providers。所需 XML 属性是 name，它指定策略的名称。属性 referralPolicy 指明策略是否为引用策略；如果未定义，则它默认为常规策略。可选 XML 属性包括 name 和 description。

注 –

将策略标记为 referral 时，在策略评估期间将忽略主题和条件。相反，将策略标记为 normal 时，在策略评估期间将忽略所有“引用项”。

Rule 元素

Rule 元素定义策略的具体内容，可能包含三个子元素： ServiceName、ResourceName 或 AttributeValuePair。它定义已经为其创建策略的服务或应用程序的类型以及资源名称和对其执行的操作。定义规则时可不带任何操作；例如，引用策略就不含任何操作。

注 –

已定义的策略也可以不包括定义的 ResourceName 元素。

ServiceName 元素

ServiceName 元素定义策略所适用的服务名称。此元素表示服务类型。它不包含任何其他元素。其值与在服务的 XML 文件（基于 sms.dtd）中定义的完全一致。ServiceName 元素的 XML 服务属性是服务（取字符串的值）的名称。

ResourceName 元素

ResourceName 元素定义将要对其执行操作的对象。策略已经过专门配置以便保护此对象。它不包含任何其他元素。ResourceName 元素的 XML 属性是对象的名称。ResourceName 的示例可能是 Web 服务器上的 http://www.sunone.com:8080/images 或目录服务器上的 ldap://sunone.com:389/dc=example,dc=com。更具体的资源可为 salary://uid=jsmith,ou=people,dc=example,dc=com ，正在其上操作的对象为 John Smith 的工资信息。

AttributeValuePair 元素

AttributeValuePair 元素定义操作及其值。它被用作 Subject 元素、Referral 元素和Condition 元素的子元素。它包含 Attribute 和 Value 元素但没有 XML 服务属性。

Attribute 元素

Attribute 元素定义操作的名称。操作是针对资源所执行的操作或事件。POST 或 GET 是对 Web 服务器资源执行的操作，READ 或 SEARCH 是对目录服务器资源执行的操作。Attribute 元素必须与 Value 元素组对。Attribute 元素本身不包含其他元素。Attribute 元素的 XML 服务属性是操作的名称。

Value 元素

Value 元素定义操作值。 allow/deny 或 yes/no 是操作值的示例。其他操作值可以是布尔值、数字或字符串。该值在服务的 XML 文件（基于 sms.dtd）中定义。Value 不包含其他元素，也不包含 XML 服务属性。

注 –

拒绝规则始终优先于允许规则。例如，如果一个策略拒绝访问而另一个策略允许访问，则结果将为拒绝（假定两个策略的所有其他条件都满足）。建议谨慎使用拒绝策略，因为它们会导致潜在的冲突。如果采用显式拒绝规则，则通过不同主题（如角色和/或组成员资格）指定给某一用户的策略可能导致拒绝的访问。通常，策略定义过程应只使用允许规则。当未应用其他任何策略时，才可使用默认拒绝。

Subjects 元素

Subjects 子元素确定策略所适用的主体集合；根据组中的成员资格、角色所有权或个别用户选择该集合。它接受 Subject 子元素。可以定义的 XML 属性有：

name。它定义集合的名称。

description。它定义主题的说明。

includeType。当前未使用此项。

Subject 元素

Subject 子元素确定策略所适用的主体集合；该集合可从 Subject 元素所定义的集合中准确找出更具体的对象。成员资格可基于角色、组成员资格或仅仅基于个别用户的列表。它包含子元素AttributeValuePair 元素。所需 XML 属性是 type，它确定一个通用的对象集合，具体定义的主题从该集合中提取。其他 XML 属性包括定义集合名称的 name 和 includeType，后者规定集合是否如定义的那样，用于确定策略是否用于“不”属于该主题成员的用户。

注 –

定义了多个主题时，要使策略得以应用，至少要有一个主题应该应用于用户。将 includeType 设置为 false 来定义主题时，用户不应为应用策略的主题成员。

Referrals 元素

Referrals 子元素确定策略引用项的集合。它接受 Referral 子元素。定义该因素时可以使用的 XML 属性有定义集合名称的 name 和包含说明的 description。

Referral 元素

Referral 子元素确定特定的策略引用项。它接受子元素AttributeValuePair 元素。它必需的 XML 属性是 type，该属性确定一个通用的任务集合，具体定义的引用项从该集合中提取。它还可以包含定义集合名称的 name 属性。

Conditions 元素

Conditions 子元素标识策略限制（时间范围、验证级别等）集合。它必须包含一个或多个 Condition 子元素。定义该因素时可以使用的 XML 属性有定义集合名称的 name 和包含说明的 description。

注 –

Condition 元素是策略中的可选元素。

Condition 元素

Condition 子元素标识特定策略限制（时间范围、验证级别等）。它接受子元素AttributeValuePair 元素。它必需的 XML 属性是 type，该属性确定一个通用的限制集合，具体定义的条件从该集合中提取。它还可以包含定义集合名称的 name 属性。