test

Sun Java System Access Manager 7 2005Q4 管理指南

第 8 章 管理策略

本章介绍 Sun Java™ System Access Manager 的“策略管理”功能。Access Manager 的“策略管理”功能使顶级管理员或顶级策略管理员能够查看、创建、删除和修改可在所有领域中使用的特定服务的策略。 它还为领域管理员、子领域管理员或策略管理员提供了一种在领域级别查看、创建、删除和修改策略的方法。

本章包括以下内容：

概述

策略定义了若干规则，这些规则将指定对某一组织受保护资源的访问权限。企业拥有各种需要进行保护、管理和监视的资源、应用程序和服务。“策略”通过定义用户对给定的资源进行操作的时间和方式，从而控制对这些资源的访问权限和使用方式。策略定义了特定负责人的资源。

注 –

负责人可以是个人、公司、角色或组等具有某种身份的任何对象。 有关详细信息，请参阅 Java™ 2 Platform Standard Edition Javadoc。

单个策略能定义二进制或非二进制的决策。二进制决策为 yes/no、true/ false 或 allow/deny。 非二进制决策代表某个属性的值。例如，邮件服务可能包含一个 mailboxQuota 属性，其中为每个用户都设置了最大存储量的值。通常说来，配置策略可以定义某负责人在什么条件下可以对什么资源执行什么操作。

策略管理功能

“策略管理”功能提供了用于创建和管理策略的策略服务。策略服务允许管理员定义、修改、授予、撤消和删除权限，以保护 Access Manager 部署内部的资源。通常，策略服务包括一个数据存储库、一个允许创建、管理和评估策略的界面库以及一个策略执行程序或策略代理。默认情况下，Access Manager 使用 Sun Java Enterprise System Directory Server 进行数据存储，并提供用于策略评估和策略服务自定义的 Java 和 C API（有关详细信息，请参阅 《Sun Java System Access Manager 7 2005Q4 Developer’s Guide》）。它也允许管理员将 Access Manager 控制台用于策略管理。Access Manager 提供了一种启用策略的服务 －“URL 策略代理”服务，该服务使用可下载策略代理执行策略。

URL 策略代理服务

安装时，Access Manager 会提供“URL 策略代理”服务来定义策略以保护 HTTP URL。 该服务允许管理员通过策略强制程序或策略代理来创建和管理策略。

策略代理

“策略代理”是存储企业资源的服务器的“策略强制点”(PEP)。策略代理独立于 Access Manager 而被安装在一个 Web 服务器上，当用户向位于受保护 Web 服务器上的 Web 资源发出请求时，此代理将起到附加授权步骤的作用。此授权是对资源执行的任何用户授权请求的补充。该代理可保护 Web 服务器，而资源反过来又会受到授权插件的保护。

例如，受远程安装的 Access Manager 保护的人力资源 Web 服务器上可能会安装某一代理。此代理可防止无适当策略的人员查看保密的工资信息或其他敏感数据。策略由 Access Manager 管理员定义，存储在 Access Manager 部署中，并由策略代理使用，以允许或拒绝用户对远程 Web 服务器内容的访问权。

最新的“Access Manager 策略代理”可以从“Sun Microsystems 下载中心”下载。

有关安装和管理策略代理的详细信息，可在 《Sun Java System Access Manager Policy Agent 2.2 User’s Guide》中找到。

注 –

策略评估不会按特定顺序进行，尽管在对其进行评估时，如果一个操作值评估结果为 deny，也不再对后续策略进行评估，除非在“策略配置”服务中启用“拒绝决策时继续评估”属性。

Access Manager 策略代理仅在 Web URL（http://... 或 https//...）上执行决策。但是，可以使用 Java 和 C Policy Evaluation API 编写代理，以在其他资源上强制执行策略。

此外，还需要将“策略配置服务”中的“资源比较器”属性由其默认配置更改为：

serviceType=Name_of_LDAPService |class=com.sun.identity.policy.plugins.SuffixResourceName|wildcard=*

|delimiter=,|caseSensitive=false

或者，提供类似于 LDAPResourceName 的实现以实现 com.sun.identity.policy.interfaces.ResourceName 并相应地配置“资源比较器”也可达到目的。

策略代理过程

当 Web 浏览器向驻留于策略代理所保护的服务器中的 URL 发出请求后，即开始受保护 Web 资源的过程。服务器中已安装的策略代理会截取请求并检查现有的验证凭证（会话标记）。

如果代理已截取请求并验证了现有的会话标记，随后将发生以下过程。

  1. 如果会话标记有效，则允许或拒绝用户的访问。如果会话标记无效，则用户将被重定向到“验证服务”，如下列各步骤所述。

    假设代理截取了某一请求，而对于该请求不存在任何现有会话标记，则代理将用户重定向到登录页面，即使用不同验证方法保护资源也是如此。

  2. 正确验证用户凭证后，代理会向定义用于连接到 Access Manager 内部服务的 URL 的“命名服务”发布请求。

  3. 如果资源与在代理处配置的非执行列表匹配，则允许访问。

  4. “命名服务”返回策略服务、会话服务和日志记录服务的定位器。

  5. 代理将请求发送到“策略服务”以获取适用于用户的策略决策。

  6. 是允许用户访问还是拒绝用户访问，需根据当前访问资源的策略决策而定。如果对策略决策的建议指示出不同的验证级别或验证机制，代理会将请求重定向到“验证服务”，直到所有条件都经过验证为止。

策略类型

有两种类型的策略可以使用 Access Manager 进行配置：

标准策略

在 Access Manager 中，用于定义访问权限的策略被称为标准策略。标准策略由规则、主题、条件和响应提供者组成。

规则

一条规则包含一个资源、一项或多项操作以及一个值。每个操作均可拥有一个或多个值。

注 –

可以不使用某些服务的资源来定义操作。

主题

主题定义策略所影响的用户或用户集合（例如，一个组或某个特定角色的拥有者）。主题将被分配给策略。主题的常规规则是：只有当用户至少是策略中的其中一个主题的成员时，才能够应用策略。默认主题包括：

AM 身份主题

在“领域主题”选项卡下创建和管理的身份可作为主体的值进行添加。

Access Manager 角色

任意 LDAP 角色均可作为该主题的值进行添加。“LDAP 角色”是使用 Directory Server 角色功能的任意角色定义。这些角色具有通过 Directory Server 角色定义授权的对象类。可以在“策略配置服务”中修改“LDAP 角色搜索”过滤器以缩小范围并提高性能。

验证的用户

任何拥有有效 SSO 令牌的用户均为该主题的成员。 所有通过验证的用户都是此“主题”的成员，即使他们已经通过其他组织（而不是定义策略的组织）的验证。如果资源拥有者要开放一些资源（为其他组织的用户所管理的资源）的访问权时，这将非常有用。

LDAP 组

任意 LDAP 组成员均可作为该主题的值进行添加。

LDAP 角色

任意 LDAP 角色均可作为该主题的值进行添加。“LDAP 角色”是使用 Directory Server 角色功能的任意角色定义。这些角色具有通过 Directory Server 角色定义授权的对象类。可以在“策略配置服务”中修改“LDAP 角色搜索”过滤器以缩小范围并提高性能。

LDAP 用户

任意 LDAP 用户均可作为该主题的值进行添加。

组织

任意组织成员均为该主题的成员

Web 服务客户机

有效值为本地 JKS 密钥库中的可信赖证书（对应于可信赖 WSC 证书）的 DN。 此主题取决于“Liberty Web 服务框架”，并且只能由“Liberty 服务提供者”用来对 WSC 进行授权。 如果 SSO 令牌中包含的负责人的 DN 与此主题的任意选定值匹配，则由该 SSO 令牌标识的 Web 服务客户机 (WSC) 是此主题的成员。

请确保将此“主题”添加到策略之前，您已经创建了密钥库。 您可以从以下位置找到有关设置密钥库的信息：

AccessManager-base /SUNWam/samples/saml/xmlsig/keytool.html

Access Manager 角色与 LDAP 角色

Access Manager 角色是由 Access Manager 创建的。这些角色所具有的对象类由 Access Manager 进行授权。LDAP 角色是使用 Directory Server 角色功能的任意角色定义。这些角色具有通过 Directory Server 角色定义授权的对象类。所有 Access Manager 角色均可被用作 Directory Server 角色。但是，Directory Server 角色并不一定都是 Access Manager 角色。可通过配置策略配置服务从现有目录利用 LDAP 角色。 Access Manager 角色只能通过所属的“Access Manager 策略服务”进行访问。可以在“策略配置服务”中修改“LDAP 角色搜索”过滤器以缩小范围并提高性能。

嵌套角色

嵌套角色可作为策略定义主题中的“LDAP 角色”正确评估。

条件

您可以使用“条件”定义策略的限制条件。例如，为某个薪金应用程序定义策略时，可以为该操作定义一个条件，限定只能在特定的时间内访问该应用程序。另外，您还可以定义另一种条件，限定只有当请求是来自指定的一组 IP 地址或公司内部网时才允许执行该操作。

此外，条件还可以用于配置同一个域的不同 URI 上的不同策略。例如，http://org.example.com/hr/*jsp 只能由 org.example.net 在 9 AM 到 5 PM 之间进行访问，而 http://org.example.com/finance/*.jsp 可以由 org.example2.net 在 5 AM 到 11 PM 之间进行访问。同时使用“IP 条件”和“时间条件”就可以实现这一目的。 将规则的资源指定为 http://org.example.com/hr/*.jsp，策略将应用到 http://org.example.com/hr 下的所有 JSP 文件，包括子目录中的 JSP 文件。

注 –

候选、规则、资源、主题、条件、操作和值等术语分别对应 policy.dtd 中的 Referral、Rule、ResourceName、Subject、Condition、Attribute 和 Value。

可以添加的默认条件是：

验证级别

如果用户的验证级别大于或等于条件中设置的验证级别，则应用该策略。

此属性指明验证的信任级别。

可以使用验证级别条件来指定领域中已注册的验证模块级别之外的级别。当对已通过其他领域验证的用户应用某个策略时，这将非常有用。

对于“LE 验证”，如果用户的验证级别低于或等于条件中设置的验证级别，则应用该策略。可以使用验证级别条件来指定领域中已注册的验证模块级别之外的级别。当对已通过其他领域验证的用户应用某个策略时，这将非常有用。

验证模式

从下拉菜单中选择条件的验证模式。 这些验证模式即为在领域的核心验证服务中定义的验证模块。

IP 地址

基于“IP 地址”的范围设置此条件。 您可以定义的字段包括：

  • 起始/结束 IP 地址 — 指定 IP 地址范围。

  • DNS 名称 — 指定 DNS 名称。此字段可以是全限定主机名，也可以是采用以下格式之一的字符串：

    domainname

    *.domainname

会话

基于用户的会话数据设置此条件。您可以修改的字段包括：

  • 最长会话时间 — 指定在发起会话时，策略可应用的最长持续时间。

  • 终止会话 — 如果选择该字段，当会话时间超过在“最长会话时间”字段中定义的最长允许时间时，系统将终止该用户会话。

    可使用该条件保护敏感资源以使其仅在验证后的有限时间内可用。

会话属性

根据用户的 Access Manager 会话中设置的属性值决定策略是否适用于请求。在策略评估期间，仅当用户会话的每个属性值均符合条件中的定义时，条件才会返回 true。对于在条件中定义了多个值的属性，令牌只要具有条件的属性中列出的一个值就足够了。例如，可使用该条件来应用基于外部库属性的策略。 验证后期插件可设置基于外部属性的会话属性。

时间

基于时间限制设置此条件。这些字段包括：

  • 起始/结束日期 — 指定日期范围。

  • 时间 — 指定一天内的时间范围。

  • 天数 — 指定表示天数的范围。

  • 时区 — 指定一个标准的或自定义的时区。自定义的时区只能是可由 Java 识别的时区 ID（例如，PST）。如果未指定值，默认值为 Access Manager JVM 中设置的时区。

响应提供者

响应提供者是提供基于策略的响应属性的插件。响应提供者属性与策略决策一起发送到 PEP。 Access Manager 包括一个实现，IDResponseProvider。该版本的 Access Manager 不支持自定义的响应提供者。 代理和 PEP 通常会将这些响应属性作为标题传递给应用程序。 应用程序通常会使用这些属性来自定义应用程序页面（如门户页面）。

策略建议

如果根据条件判定策略不适用，该条件可能会产生建议消息，指明策略不适用于请求的原因。这些建议消息在策略决策内传播到“策略强制点”。“策略强制点”可以检索此建议并采取适当的行动，例如将用户重定向回验证机制以进行更高级别的验证。 如果策略适用，系统在针对建议采取适当的操作后可能会提示用户进行更高级别的验证，用户或许可以访问资源。

可从以下类中找到更多信息：

com.sun.identity.policy.ConditionDecision.getAdvices()

如果条件不满足，则只有 AuthLevelCondiiton 和 AuthSchemeCondition 提供建议。

AuthLevelCondition 建议与下列关键字相关： 

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_LEVEL_CONDITION_ADVICE

AuthSchemeCondition 建议与下列关键字相关：

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_SCHEME_CONDITION_ADVICE

自定义的条件也可以提供建议。但是，“Access Manager 策略代理”只对“验证级别建议”和“验证模式建议”做出响应。 可以编写自定义的代理来理解和响应更多建议，也可以扩展现有的 Access Manager 代理来理解和响应更多建议。有关详细信息，参见《Sun Java System Access Manager Policy Agent 2.2 User’s Guide》。

候选策略

管理员可能需要将一个领域的策略定义和决策委托给另一个领域。 （另外，还可以将资源的策略决策委托给其他策略产品）。 候选策略控制着对策略创建和评估的委托授权。该策略由一个或多个规则或一个或多个候选项组成。

规则

规则定义策略定义和评估相关的资源。

候选项

候选组织定义当前与策略评估相关的组织。默认情况下，有两种候选项类型：对等领域和子领域。 它们分别代表同级领域和子级领域。 有关详细信息，请参阅为对等领域和子领域创建策略 。

注 –

相关领域只能为那些已相关的资源（或子资源）定义或评估策略 。但是，该限制并不适用于顶层领域。

策略定义类型文档

一旦创建并配置了策略，它就会以 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)
注 –

在本章中的余下部分将只给出 Solaris 目录信息。请注意 Linux 的目录结构有所不同。

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 属性。

添加“已启用策略服务”

只有当服务模式拥有配置到 sms.dtd 的 <Policy> 元素时才可定义给定服务的资源策略。

默认情况下，Access Manager 会提供“URL 策略代理”服务 ( iPlanetAMWebAgentService)。 此服务在位于以下目录的 XML 文件中定义：

/etc/opt/SUNWam/config/xml/

但是，您可以向 Access Manager 添加附加的策略服务。一旦创建了策略服务，就可以通过 amadmin 命令行实用程序把它添加到 Access Manager。

Procedure添加新的已启用策略服务

步骤

  1. 在基于 sms.dtd 的 XML 文件里开发新的策略服务。Access Manager 提供两个策略服务 XML 文件，用户可能希望将其用作新策略服务文件的基础：

    amWebAgent.xml - 这是默认“URL 策略代理”服务的 XML 文件。它位于 /etc/opt/SUNWam/config/xml/。

    SampleWebService.xml - 这是位于 AccessManager-base/samples/policy 的范例策略服务文件。

  2. 将该 XML 文件保存到您将从中加载新策略服务的目录。例如：


    /config/xml/newPolicyService.xml

  3. 用 amadmin 命令行实用程序加载新策略服务。例如：


    AccessManager-base/SUNWam/bin/amadmin
    --runasdn “uid=amAdmin,ou=People,default_org,
root_suffix
    --password password
    --schema /config/xml/newPolicyService.xml

  4. 加载新策略服务后，可通过 Access Manager 控制台或使用 amadmin 加载新策略来制定策略定义的规则。

创建策略

您可以通过“策略 API”和 Access Manager 控制台创建、修改和删除策略，并通过 amadmin 命令行工具创建和删除策略。 您也可以使用 amadmin 实用程序获取和列出 XML 格式的策略。 本节重点介绍如何通过 amadmin 命令行实用程序和 Access Manager 控制台创建策略。有关“策略 API”的详细信息，请参阅《Sun Java System Access Manager 7 2005Q4 Developer’s Guide》。

策略通常使用 XML 文件创建，再通过命令行实用程序 amadmin 添加到 Access Manager，然后使用 Access Manager 控制台进行管理（尽管策略可通过控制台创建）。 这是因为不能直接使用 amadmin 修改策略。要修改策略，必须先从 Access Manager 中删除该策略，然后使用 amadmin 添加已修改的策略。

通常情况下，策略是在领域（或子领域）级别创建以在整个领域树中使用的。

Procedure使用 amadmin 创建策略

步骤

  1. 创建基于 amadmin.dtd 的策略 XML 文件。该文件位于以下目录中：

    AccessManager-base /SUNWam/dtd

  2. 策略 XML 文件生成之后，便可使用以下命令加载它： 


    AccessManager-base/SUNWam/bin/amadmin
--runasdn "uid=amAdmin,ou=People,default_org,
root_suffix"
--password password
--data policy.xml

    要同时添加多个策略，请将这些策略放在一个 XML 文件中，而不是在每个 XML 文件中放一个策略。如果一连串使用多个 XML 文件装入策略，则可能会损坏内部策略索引，并且某些策略可能不会参与策略评估。

    通过 amadmin 创建策略时，确保验证模块在创建验证模式条件时已注册到领域；创建领域、LDAP 组、LDAP 角色和 LDAP 用户主题时存在相应的 LDAP 对象领域、组、角色和用户；创建 IdentityServerRoles 主题时存在 Access Manager 角色；以及创建子领域或对等领域候选项时存在相关领域。

    请注意，SubrealmReferral、PeerRealmReferral、Realm 主题、IdentityServerRoles 主题、LDAPGroups 主题、 LDAPRoles 主题和 LDAPUsers 主题中的值元素的文本中需要完整 DN。

Procedure使用 Access Manager 控制台创建标准策略

步骤

  1. 选择要为其创建策略的领域。

  2. 单击“策略”选项卡。

  3. 在“策略”列表中单击“新建策略”。

  4. 为策略添加名称和说明。

  5. 如果您希望激活此策略，请在“活动”属性里选中“是”。

  6. 此时，您不必为标准策略定义所有字段。您可以在创建策略之后再添加规则、主题、条件和响应提供者等内容。有关详细信息，请参见管理策略。

  7. 单击“创建”。

Procedure使用 Access Manager 控制台创建候选策略

步骤

  1. 选择要为其创建策略的领域。

  2. 在“策略”选项卡中单击“新建候选项”。

  3. 为策略添加名称和说明。

  4. 如果您希望激活此策略，请在“活动”属性里选中“是”。

  5. 此时，您不必为候选策略定义所有字段。 您可以在创建策略之后再添加规则、候选项等内容。有关详细信息，请参阅管理策略。

  6. 单击“创建”。

为对等领域和子领域创建策略

要为对等领域或子领域创建策略，必须首先在父领域（或其他对等领域）中创建候选策略。 候选策略的规则定义中必须包含子领域所管理的资源前缀。 一旦在父领域（或其他对等领域）中创建了候选策略，便可在子领域（或对等领域）创建标准策略。

在本示例中，o=isp 是父领域，o=example.com 是管理 http://www.example.com 的资源和子资源的子领域。

Procedure为子领域创建策略

步骤

  1. 在 o=isp 中创建候选策略。有关候选策略的信息，请参阅修改候选策略过程。

    候选策略必须将 http://www.example.com 定义为规则中的资源，并且必须包含一个以 example.com 作为候选项中的值的 SubRealmReferral。

  2. 找到子领域 example.com。

  3. 既然资源是通过 isp 引用 example.com，就可以为资源 http://www.example.com，或任何以 http://www.example.com 开头的资源创建标准策略。

    要为 example.com 所管理的其他资源定义策略，必须在 o= isp 上创建其他候选策略。

管理策略

一旦创建了标准或候选策略并将其添加到 Access Manager，您就可以使用 Access Manager 控制台通过修改规则、主题、条件和候选项来管理策略。

修改标准策略

通过“策略”选项卡，可以修改定义访问权限的标准策略。 您可以定义和配置多个规则、主题、条件和资源比较器。 本节列出并介绍相关操作步骤。

Procedure在标准策略中添加或修改规则

步骤

  1. 如果已创建了策略，请单击要为其添加规则的策略的名称。否则，请参阅使用 Access Manager 控制台创建标准策略 。

  2. 在“规则”菜单中单击“新建”。

  3. 为规则选择以下任一默认服务类型。 如果策略可用的服务较多时，您看到的列表可能会比较长：

    搜索服务

    为搜索服务查询定义授权操作并通过指定资源的 Web 服务客户机修改调用的协议。

    Liberty 个人配置文件服务

    为“Liberty 个人配置文件”服务查询定义授权操作并通过指定资源的 Web 服务客户机修改调用的协议。

    URL 策略代理

    为策略强制提供“URL 策略代理”服务。该服务允许管理员通过策略强制程序或策略代理来创建和管理策略。

  4. 单击“下一步”。

  5. 输入规则的名称及其资源名称。

    目前，“策略代理”只支持 http:// 和 https:// 资源，不支持代替主机名的 IP 地址。

    主机、端口和资源名称都支持通配符。 例如：


    http*://*:*/*.html

    对于“URL 策略代理”服务，如果未输入端口号，则 http:// 的默认端口号是 80，https:// 的默认端口号是 443。

  6. 为规则选择操作。如果您使用的是“URL 策略代理”服务，则可以选择以下选项：

    • GET

    • POST

  7. 选择操作值。

    • Allow — 允许您访问与规则中定义的资源相匹配的资源。

    • Deny — 拒绝您访问与规则中定义的资源相匹配的资源。

    • 拒绝规则始终优先于允许规则。 例如，如果某种给定的资源存在两个策略，一个拒绝访问而另一个允许访问，结果为拒绝访问（假定两个策略的条件都满足）。建议谨慎使用拒绝策略，因为它们会导致策略间的潜在冲突。策略定义过程应只使用允许规则。 如果没有适用于资源的策略，则自动拒绝访问。

      当采用了显式拒绝规则时，即使一个或多个策略允许访问，通过多个不同主题（如角色和/或组成员资格）指定给给定用户的策略可能仍然会导致对资源的拒绝访问。 例如，如果应用于“员工”角色的资源的策略为拒绝策略，而应用于“经理”角色的同一资源的策略为允许策略，则被分配了“员工”和“经理”两个角色的用户的策略决策将为拒绝。

      解决此问题的一个方法是使用条件插件来设计策略。在上述情况下，将拒绝策略应用于通过“员工”角色验证的用户并将允许策略应用于通过“经理”角色验证的用户的“角色条件”可以帮助区分两种策略。 另一个方法是使用 authentication level 条件，其中“经理”角色在更高验证级别进行验证。

  8. 单击“完成”。

Procedure在标准策略中添加或修改主题

步骤

  1. 如果已创建了策略，请单击要为其添加主题的策略的名称。如果尚未创建策略，请参阅使用 Access Manager 控制台创建标准策略 。

  2. 在“主题”列表中单击“新建”。

  3. 选择以下任一默认主题类型。有关主题类型的说明，请参阅主题

  4. 单击“下一步”。

  5. 输入主题的名称。

  6. 选择或取消选择“排除”字段。

    如果未选择该字段（默认），策略将应用到属于该主题的成员的身份。如果选择该字段，策略将应用到不属于该主题的成员的身份。

    如果策略中存在多个主题，则当身份属于至少一个主题的成员时，策略将应用到该身份。

  7. 执行搜索以显示要添加到主题的身份。此步骤不适用于“验证的用户”主题或“Web 服务客户机”主题。

    默认 (*) 搜索模式将显示所有条目。

  8. 选择要为主题添加的各个身份，或单击“全部添加”一次添加所有身份。单击“添加”将这些身份移至“选定”列表中。 此步骤不适用于“验证的用户”主题。

  9. 单击“完成”。

  10. 要从策略中移除主题，请选择相应主题并单击“删除”。 您可以通过单击主题名称来编辑任何主题定义。

Procedure将条件添加到标准策略

步骤

  1. 如果已创建了策略，请单击要为其添加条件的策略的名称。如果尚未创建策略，请参阅使用 Access Manager 控制台创建标准策略

  2. 在“条件”列表中单击“新建”。

  3. 选择条件类型，然后单击“下一步”。

  4. 定义条件类型字段。有关条件类型的说明，请参阅条件。

  5. 单击“完成”。

Procedure将响应提供者添加到标准策略

步骤

  1. 如果已创建了策略，请单击要为其添加响应提供者的策略的名称。如果尚未创建策略，请参阅使用 Access Manager 控制台创建标准策略 。

  2. 在“响应提供者”列表中单击“新建”。

  3. 输入响应提供者的名称。

  4. 定义以下值：

    StaticAttribute

    该响应属性的名称和值在实例 IDResponseProvider 中定义并在策略中存储。

    DynamicAttribute

    应首先在相应领域的“策略配置服务”中定义此处所选择的响应属性。定义的属性名称应与已配置数据存储库中已有的属性名称相同。有关如何定义属性的详细信息，参见 Access Manager 联机帮助中的“策略配置”属性定义。

  5. 单击“完成”。

  6. 要从策略中删除响应提供者，请选择相应主题，然后单击“删除”。您可以通过单击响应提供者名称来编辑任何响应提供者的定义。

修改候选策略

可将领域的策略定义和决策委托给使用候选策略的不同领域。 自定义候选项可用于从任意策略目标点获取策略决策。 一旦创建了候选策略，便可添加或修改相关的规则、候选项和资源提供者。

Procedure在候选策略中添加或修改规则

步骤

  1. 如果已创建了策略，请单击要为其添加规则的策略的名称。否则，请参阅使用 Access Manager 控制台创建候选策略 。

  2. 在“规则”列表中单击“新建”。

  3. 为规则选择以下任一默认服务类型。 如果策略可用的服务较多时，您看到的列表可能会比较长：

    搜索服务

    为搜索服务查询定义授权操作并通过指定资源的 Web 服务客户机修改调用的协议。

    Liberty 个人配置文件服务

    为“Liberty 个人配置文件”服务查询定义授权操作并通过指定资源的 Web 服务客户机修改调用的协议。

    URL 策略代理

    为策略强制提供“URL 策略代理”服务。该服务允许管理员通过策略强制程序或策略代理来创建和管理策略。

  4. 单击“下一步”。

  5. 输入规则的名称及其资源名称。

    目前，“策略代理”只支持 http:// 和 https:// 资源，不支持代替主机名的 IP 地址。

    资源名称、端口号和协议都支持通配符。例如：


    http://*:*/*.html

    对于“URL 策略代理”服务，如果未输入端口号，则 http:// 的默认端口号是 80，https:// 的默认端口号是 443。

    如果将资源定义为 http://host*:*.，即可允许对安装在特定计算机上的所有服务器的资源进行管理。此外，还可以定义以下资源，以授予管理员对该组织中所有服务的组织权限： 


    http://*.subdomain.domain.topleveldomain

  6. 单击“完成”。

Procedure在策略中添加或修改候选项

步骤

  1. 如果已经创建了策略，请单击要为其添加响应提供者的策略的名称。如果尚未创建策略，请参阅使用 Access Manager 控制台创建候选策略 。

  2. 在“规则”列表中单击“新建”。

  3. 选择“服务类型”。

  4. 在“规则”字段中定义资源。这些字段包括：

    候选项— 显示当前候选项类型。

    名称— 输入候选项的名称。

    资源名称— 输入资源的名称。

    过滤器— 指定将显示在“值”字段中的组织名称的过滤器。 默认情况下，该字段将显示所有组织名称。

    值 — 选择该候选项的组织名称。

  5. 单击“完成”。

    要从策略中移除候选项，请选择该候选项，然后单击“删除”。

    您可以通过单击候选项名称旁边的“编辑”链接来编辑任何候选项定义。

Procedure将响应提供者添加到候选策略

步骤

  1. 如果已创建了策略，请单击要为其添加响应提供者的策略的名称。如果尚未创建策略，请参阅使用 Access Manager 控制台创建标准策略 。

  2. 在“响应提供者”列表中单击“新建”。

  3. 输入响应提供者的名称。

  4. 定义以下值：

    StaticAttribute

    该响应属性的名称和值在实例 IDResponseProvider 中定义并在策略中存储。

    DynamicAttribute

    该响应属性只有名称是在策略的实例 IDResponseProvider 中选定。在策略评估期间，根据用户身份请求从 IDRepostitories 读取属性值。

  5. 单击“完成”。

  6. 要从策略中移除响应提供者，请选择相应主题，然后单击“删除”。您可以通过单击响应提供者名称来编辑任何响应提供者的定义。

策略配置服务

“策略配置”服务用于通过 Access Manager 控制台为每个组织配置与策略相关的属性。 也可以定义资源名称实现和与 Access Manager 策略框架一同使用的 Directory Server 数据存储库。 在“策略配置服务”中指定的 Directory Server 用于 LDAP 用户、LDAP 组、LDAP 角色以及组织策略主题的成员资格评估。

主题结果的生存时间

为了提高策略评估的性能，成员资格评估将被缓存一段时间，具体时间长短如“策略配置”服务中的“主题结果的生存时间”属性定义。 在达到“主题结果的生存时间”属性中所定义的时间之前，将持续使用这些缓存的成员资格决策。在此之后的成员资格评估用于反映目录中用户的当前状态。

动态属性

这些是所允许的动态属性名称，它们显示在列表中，并且可通过选择它们来定义策略响应提供者的动态属性。所定义的名称需与数据系统信息库中定义的属性名称相同。

amldapuser 定义

amldapuser 是默认情况下安装“策略配置”服务中指定的 Directory Server 期间创建的用户。 如有必要，管理员或领域的策略管理员可以对其进行更改。

添加策略配置服务

创建领域时，将为领域自动设置“策略配置”服务属性。 但是，必要时也可修改属性。

基于资源的验证

某些组织需要高级验证方案，其中用户将根据他们尝试要访问的资源用特定模块进行验证。基于资源的验证是 Access Manager 的一项功能，该功能要求用户必须通过用于保护资源的特定验证模块而非默认验证模块进行验证。 此功能仅适用于首次用户验证。

注 –

该功能与会话升级中所描述的基于资源的验证不同。后者不具有任何限制。

限制

基于资源的验证包含以下限制：

Procedure配置基于资源的验证

一旦安装了 Access Manager 和策略代理，便可对基于资源的验证进行配置。 要执行此操作，需要将 Access Manager 指向网关 servlet。

步骤

  1. 打开 AMAgent.properties。

    AMAgent.properties 可在 /etc/opt//SUNWam/agents/config/ 中找到（在 Solaris 环境中）。

  2. 注释掉以下行：

    #com.sun.am.policy.am.loginURL = http://Access Manager_server_host.domain_name:port/amserver/UI/Login。

  3. 将以下行添加到 文件：

    com.sun.am.policy.am.loginURL = http://AccessManager_host.domain_name:port/amserver/gateway

    注 –

    网关 servlet 是使用“策略评估 API”开发的，可使用它来编写用于完成基于资源的验证的自定义机制。《Sun Java System Access Manager 7 2005Q4 Developer’s Guide》中的第 6  章 “Using the Policy APIs”一书中的第 6 章，“Using the Policy APIs”。

  4. 重新启动代理。