Sun Java System Access Manager 7.1 管理指南

第 1 部分访问控制

这是《Sun Java System Access Manager^TM 7.1 管理指南》的第一部分。 “访问控制”界面提供了一种创建和管理验证和授权服务的途径，从而保护和控制基于领域的资源。当企业用户请求信息时，Access Manager 会验证用户身份并授权用户访问其所请求的特定资源。本部分包含以下各章：

第 1 章 Access Manager 控制台

Access Manager 控制台是一个 Web 界面，它允许拥有不同访问级别的管理员（包括做其他事情）创建领域和组织、在这些领域中创建或删除用户，以及建立可保护和限制领域资源访问的强制策略。此外，管理员还可以查看和终止当前用户会话以及管理它们的联合配置（创建、删除和修改验证域和提供商）。另一方面，不拥有管理权限的用户可以管理个人信息（姓名、电子邮件地址、电话号码等）、更改他们的密码、订阅和取消订阅组以及查看他们的角色。 Access Manager 控制台拥有两个基本视图：

管理视图

拥有管理角色的用户通过 Access Manager 进行验证时，默认视图为“管理视图”。在该视图中，管理员可以执行与 Access Manager 相关的大多数管理任务。Access Manager 可以在两种不同模式（“领域”模式和“传统”模式）下进行安装。每种模式均拥有其各自的控制台。有关“领域模式”和“传统模式”的详细信息，参见《Sun Java System Access Manager 7.1 Technical Overview》。

注 –

如果在“领域模式”下安装 Access Manager 7.1，则无法回到“传统模式”。如果在“传统模式”下安装 Access Manager，则可以通过使用 amadmin 命令更改为“领域模式”。有关详细信息，参见 Access Manager 管理参考中的“Changing from Legacy Mode to Realm Mode”。

领域模式控制台

领域模式中的管理控制台使管理员能够管理基于领域的访问控制、默认服务配置、Web 服务以及联合。要访问管理员登录屏幕，请在浏览器中使用以下地址语法：

protocol://servername /amserver/UI/Login

protocol 可以为 http 或 https，具体取决于您的部署。

图 1–1 领域模式管理视图

传统模式控制台

“传统模式”控制台是基于 Access Manager 6.3 体系结构的。此传统 Access Manager 体系结构使用 Sun Java System Directory Server 自带的 LDAP 目录信息树 (DIT)。在“传统模式”下，用户信息和访问控制信息均存储于 LDAP 组织中。选择“传统模式”时，LDAP 组织等同于访问控制领域。领域信息集成在 LDAP 组织内。在“传统模式”下，“目录管理”选项卡可在基于 Access Manager 的身份管理中使用。

要访问管理员登录屏幕，请在浏览器中使用以下地址语法：

protocol://servername /amserver/console

protocol 可以为 http 或 https，取决于您的部署。

图 1–2 传统模式管理视图

传统模式 6.3 控制台

Access Manager 6.3 的某些功能在 Access Manager 7.1 控制台中不可用。因此，管理员可以通过 7.1 传统部署登录到 6.3 控制台。在将 Access Manager 建立在 Sun Java System Portal Server 或其他需要将 Sun Java System Directory Server 用作中心身份库的 Sun Java System 通信产品上的情况下，通常会使用此控制台。其他功能（如“委托管理”和“服务类”）只能通过此控制台进行访问。

注 –

请勿交换使用 6.3 传统模式控制台和 7.1 传统模式控制台。

要访问 6.3 控制台，请在浏览器中使用以下地址语法：

protocol://servername /amconsole

protocol 可以为 http 或 https，取决于您的部署。

图 1–3 基于传统 6.3 的控制台

用户概要文件视图

当尚未指定管理角色的用户向 Access Manager 进行验证时，默认视图为用户自己的“用户概要文件”视图。在“领域模式”或“传统模式”下均可访问“用户概要文件”视图。要访问该视图，用户必须在“登录”页面中输入自己的用户名和密码。

用户可以在该视图中修改用户的个人配置文件所特有的属性值。其中包括（但不限于）姓名、家庭地址和密码。“用户概要文件视图”中显示的属性可以扩展。

图 1–4 用户概要文件视图

第 2 章管理领域

访问控制领域是可以与用户或用户组关联的一组验证属性和授权策略。领域数据存储于专有信息树中，该信息树由 Access Manager 在您指定的数据存储库中创建。Access Manager 框架在 Access Manager 信息树中聚集了每个领域所包含的策略和属性。默认情况下，Access Manager 会将 Access Manager 信息树作为特殊分支插入到 Sun Java Enterprise System Directory Server 中，但用户数据除外。您可以在使用任何 LDAPv3 数据库的同时使用访问控制领域。

有关领域的详细信息，参见《Sun Java System Access Manager 7.1 Technical Overview》。

在“领域”选项卡中，可以为访问控制配置以下属性：

创建和管理领域

本节说明了如何创建和管理领域。

创建新的领域

从“访问控制”选项卡下的“领域”列表中选择“新建”。

定义以下常规属性：

名称

输入领域名称。

父领域

定义要创建的领域的位置。选择要在其中创建新领域的父领域。

定义以下领域属性：

领域状态

选择“活动”或“不活动”状态。默认值为“活动”。在领域存在期间，可以随时选择属性图标以更改其状态。如果选择“不活动”，则当登录时，将禁止用户访问。

领域/DNS 别名

允许为领域的 DNS 名称添加别名。该属性只接受“真实的”域别名（不允许使用随机字符串）。

请单击“确认”保存或单击“取消”返回上一页面。

常规属性

“常规属性”页面显示领域的基本属性。要修改这些属性，请从“访问控制”选项卡下的“领域名称”列表中单击该领域。然后编辑以下属性：

领域状态: 选择“活动”或“不活动”状态。默认值为“活动”。在领域存在期间，可以随时选择属性图标以更改其状态。如果选择“不活动”，则当登录时，将禁止用户访问。
领域/DNS 别名: 允许为领域的 DNS 名称添加别名。该属性只接受“真实的”域别名（不允许使用随机字符串）。

编辑属性后，单击“保存”。

注 –

AMAdmin.dtd 中的 recursive=true 标志对于以领域模式在子领域中搜索对象不起作用。该标志只能在传统模式中发挥作用，因为所有子组织均位于相同的根后缀下。在领域模式下，每个子领域都可拥有不同的根后缀，甚至可以位于不同的服务器上。如果要在子领域中搜索对象（例如组），则必须在 XML 数据文件中指定要搜索的子领域。

验证

必须先将常规验证服务注册为领域的服务，用户才能使用其他验证模块登录。核心验证服务允许 Access Manager 管理员为领域的验证参数定义默认值。如果在指定的验证模块里没有定义替代值，那么便可使用这些值。核心验证服务的默认值在 amAuth.xml 文件中定义，并于安装结束后存储在 Directory Server 中。

有关详细信息，参见管理验证

服务

在 Access Manager 中，服务是由 Access Manager 控制台一起管理的一组属性。属性可以仅仅是一些相关信息，如雇员姓名、职务以及电子邮件地址。但是属性通常被用作软件模块（如邮件应用程序或工资单服务）的配置参数。

您可以通过“服务”选项卡在领域中添加并配置许多 Access Manager 默认的服务。您可以添加以下服务：

管理
搜索服务
全局化设置
密码重置
会话
用户

注 –

Access Manager 强制要求服务 .xml 文件中的必需属性具备一些默认值。如果服务的必需属性没有值，则需要添加默认值并重新加载服务。

向领域添加服务

单击要为其添加新服务的领域的名称。

选中“服务”选项卡。

单击“服务”列表中的“添加”。

选择要为领域添加的服务。

单击“下一步”。

通过定义领域属性来配置服务。有关服务属性的说明，参见联机帮助中的“配置”。

单击“完成”。

要编辑服务的属性，请在“服务”列表中单击其名称。

权限

Access Manager 中的委托模型基于已指定给管理员的权限（或权利）。权限是可对资源执行的操作（或行为）；例如对“策略”对象执行的 READ 操作。一组已定义的操作是 READ、MODIFY 和 DELEGATE。资源是可对其执行操作的对象，可以是配置对象，也可以是身份对象。

配置对象的示例是“验证配置”、“策略”、“数据存储库”等。身份对象的示例是“用户”、“组”、“角色”和“代理”。可动态创建一组权限并动态将其添加到 Access Manager，不过在安装期间，会将少量权限添加到 Access Manager 以使其正常运行。一旦加载权限后，就可将其指定给角色和组。属于这些角色和组的用户就可成为委托管理员，并且可执行已指定的操作。管理员基本上就是一些特定的用户，他们是已指定了一组或多组权限的角色和组的成员。

可通过 Access Manager 7.1 为以下管理员类型配置权限：

领域管理员 — 领域管理员拥有对所有对象（配置对象和身份对象）执行 READ、MODIFY 和 DELEGATE 操作的权限。可将领域管理员视为 Unix 系统中的“超级用户”。领域管理员可为所有服务创建子领域，修改配置，也可创建、修改以及删除“用户”、“组”、“角色”和“代理”。
策略管理员 — 策略管理员仅拥有管理策略和策略服务配置的权限。他们可以创建、修改以及删除由“规则”、“主题”、“条件”和“响应”属性组成的策略。不过，为了管理策略，这些管理员需要拥有读取“身份系统信息库主题”和“验证配置”的权限。这些管理员能查看身份和验证配置。
日志管理员 — 日志管理员具有读取和/或写入日志的权限，这些权限可用于防止审计日志被恶意应用程序恶意滥用。日志记录接口是公共接口，任何通过验证的用户都可以读取和写入日志记录，添加此权限正是为防止日志记录被滥用。日志记录接口的主要用户是 J2EE 和 Web 代理，他们只需要 MODIFY 权限，但不应该拥有 READ 权限。类似地，查看日志的管理员只应该拥有 READ 权限，而不应该拥有 MODIFY 权限。为满足这些类型的用法，又进一步将日志记录权限细分为如下：
- 拥有写入权限的日志管理员 – 这些管理员拥有写入所有日志文件的权限。
- 拥有读取权限的日志管理员 – 这些管理员拥有读取所有日志文件的权限。
- 拥有读写权限的日志管理员 – 这些管理员有权读取和写入所有日志文件。

定义 Access Manager 7.1 的权限

Access Manager 7.1 的新安装实例为策略管理员、领域管理员（或传统模式中的组织管理员）和日志管理员提供访问权限。单击您要进行编辑的角色或组的名称，可指定或修改权限。可选择的权限包括：

对所有日志文件的读写权限: 为日志管理员定义读写访问权限。
对所有日志文件的写入权限: 仅为日志管理员定义写入访问权限。
对所有日志文件的读取权限: 仅为日志管理员定义读取访问权限。
仅针对策略属性的读写访问权限: 为策略管理员定义读写访问权限。
所有领域和策略属性的读写访问权限: 为领域管理员定义读写访问权限。

为从 Access Manager 7.0 升级到 7.1 定义权限

如果已将 Access Manager 从版本 7.0 升级到 7.1，那么相关权限配置与新 Access Manager 7.1 安装有所不同，但仍然支持策略管理员、领域管理员和日志管理员的权限。单击您要进行编辑的角色或组的名称，可指定或修改权限。可选择的权限包括：

对数据存储库的只读访问: 为策略管理员定义数据存储库的读取访问权限。
对所有日志文件的读写权限: 为日志管理员定义读写访问权限。
对所有日志文件的写入权限: 仅为日志管理员定义写入访问权限。
对所有日志文件的读取权限: 仅为日志管理员定义读取访问权限。
仅针对策略属性的读写访问权限: 为策略管理员定义读写访问权限。
所有领域和策略属性的读写访问权限: 为领域管理员定义读写访问权限。
所有属性和服务的只读访问权限: 为策略管理员定义所有属性和服务的读取访问权限。

Access Manager 不支持以下定义（无论是单独使用还是一起使用）：

对数据存储库的只读访问
所有属性和服务的只读访问权限

这些权限定义必须和“仅针对策略属性的读写访问权限”定义一起使用，从而为策略管理员定义委托控制。

第 3 章数据存储库

数据存储库是一个可以存储用户属性和用户配置数据的数据库。Access Manager 提供身份系统信息库插件，这些插件连接到 LDAPv3 身份系统信息库框架。这些插件使您不必在现有用户数据库中做任何更改，便可查看和检索 Access Manager 用户信息。Access Manager 框架将来自身份系统信息库插件的数据和其他 Access Manager 插件里的数据整合在一起，为每个用户形成了一个虚拟身份。而后，Access Manager 能使用通用身份在多个身份系统信息库之间进行验证和授权过程。在用户会话结束后将会销毁虚拟用户身份。

Access Manager 数据存储库类型

本节说明可配置的数据存储库类型，提供创建和配置新数据存储库类型的步骤。

可为以下数据存储库类型创建新的数据存储库实例：

Access Manager 系统信息库插件

该数据存储库类型驻留在 Sun Java System Directory Server 实例中，并拥有 Access Manager 信息树。该数据存储库类型使用不属于 LDAP 版本 3 规范的 Directory Server 功能（如角色和服务类），并与以前的 Access Manager 版本兼容。

活动目录

该数据存储类型使用 LDAP 版本 3 规范将身份数据写入到 Microsoft 活动目录的实例中。

平面文件系统信息库

该系统信息库允许用户在 Access Manager 的本地安装实例上以平面 DIT 结构存储数据和身份，而不必创建单独的数据存储库。通常将其用于测试或验证概念部署。

普通 LDAPv3

该数据存储库类型允许将身份数据写入任意与 LDAPv3 兼容的数据库。如果所使用的 LDAPv3 数据库不支持持久性搜索，则无法使用高速缓存功能。

使用 Access Manager 模式的 Sun Directory Server

该数据存储库类型驻留在 Sun Java System Directory Server 实例中，并拥有 Access Manager 信息树。它与 Access Manager 系统信息库插件不同，后者包含更多配置属性，从而可更好地自定义数据存储库。

创建新的数据存储库

以下部分描述连接数据存储库的步骤。

选择要添加新数据存储库的领域。

单击“数据存储库”选项卡。

在“数据存储库”列表中单击“新建”。

请输入数据存储库的名称。

选择要创建的数据存储库的类型。

单击“下一步”。

输入适当属性值以配置数据存储库。

单击“完成”。

数据存储库属性

本节定义用于配置每个新 Access Manager 数据存储库的属性。这些数据存储库属性是：

注 –

Active Directory、普通 LDAPv3 以及使用 Access Manager 模式的 Sun Directory Server 数据存储库类型共享相同的基本插件，因此配置属性是相同的。然而，对于每个数据存储库类型而言，某些属性的默认值是不同的，在 Access Manager 控制台中会相应地显示这些默认值。

Access Manager 系统信息库属性

用于配置 Access Manager 系统信息库插件的属性如下：

类名称

指定实现 Access Manager 系统信息库插件的类文件的位置。

Access Manager 支持的类型和操作

指定允许或可以在该 LDAP 服务器上执行的操作。只有默认操作才是受此 LDAPv3 系统信息库插件支持的操作。LDAPv3 系统信息库插件支持以下操作：

组 -- 读取、创建、编辑、删除
用户 -- 读取、创建、编辑、删除、服务
代理 -- 读取、创建、编辑、删除

可根据 LDAP 服务器设置和任务从上述列表删除权限，但不能添加其他权限。

如果已配置的 LDAPv3 系统信息库插件指向 Sun Java Systems Directory Server 的实例，则可添加角色类型的权限。否则，由于其他数据存储库可能不支持角色，从而可能无法添加该权限。“角色”类型的权限为：

角色 — 读取、创建、编辑、删除

如果用户类型是 LDAPv3 系统信息库所支持的类型，则可对该用户执行读取、创建、编辑和删除服务操作。换句话说，如果支持用户类型，则通过读取、创建、编辑和删除操作便可分别从身份系统信息库中读取、创建、编辑和删除用户条目。user=service 操作会使 Access Manager 服务访问用户条目中的属性。此外，如果将动态服务指定给用户所属的领域或角色，则用户可以访问动态服务属性。

用户也可以管理任意指定服务的用户属性。如果用户将 service 作为操作 (user=service)，则指定了对所有与服务相关的操作提供支持。这些操作是：assignService、unassignService、getAssignedServices、getServiceAttributes、removeServiceAttributes 和 modifyService。

组织 DN 值

定义指向 Access Manager 要管理的 Directory Server 中组织的DN。它将成为在该数据存储库内执行的所有操作的基 DN。

人员容器命名属性

如果用户驻留在人员容器中，则指定该人员容器的命名属性。如果用户没有驻留在人员容器中，则将该字段保留为空。

人员容器值

指定人员容器的值。默认值为 people。

代理容器命名属性

如果代理驻留在代理容器中，则指定该代理容器的命名属性。如果代理没有驻留在代理容器中，则将该字段保留为空。

代理容器值

指定代理容器的值。默认值为 agents。

递归搜索

如果启用，在 Access Manager 系统信息库中执行的搜索会对指定身份进行递归搜索。例如，在以下数据结构中执行递归搜索：

root
realm1
    subrealm11
        user5
    subrealm12
        user6
realm2
    user1
    user2
    subrealm21
        user3
        user4

会产生以下结果：

如果从 root 开始执行搜索，且未在该级别定义任何用户（除 amadmin 和 anonymous 以外），则搜索返回 user 1–6。
如果从 realm1 开始执行搜索且未定义任何用户，则搜索返回 user5 和 user6。
如果从 realm2 开始执行搜索（已定义两个用户），则搜索返回 user 1–4。

复制领域配置

若在领域模式安装中启用了该属性，Access Manager 将为系统信息库中存在的每个领域和子领域创建等效组织及子组织。此外，在领域/子领域中注册的服务还将在新创建的组织/子组织中进行注册。领域 DIT 和组织 DIT 均存在于数据存储库内。

平面文件系统信息库属性

用于配置平面文件系统信息库的属性如下：

文件系统信息库插件类名称

该属性指定为平面文件提供实现的 Java 类文件。不应修改该属性。

文件系统信息库目录

定义用于存储身份及其属性的基目录。

高速缓存

若为启用（默认），将对身份及其属性进行高速缓存。这样，后续请求就不会访问文件系统。

更新高速缓存的时间

启用高速缓存后，该属性将确定检查高速缓存的时间间隔（以分钟为单位），超过该间隔便会对高速缓存中的条目进行检查，以确定是否对文件系统进行过任何更改。检查机制以时间戳为基础。

文件用户对象类

定义创建用户时自动为用户添加的对象类。

密码属性

提供包含用于验证的密码的属性名。该属性用于在启用“数据存储库”验证模块时对用户进行验证。

状态属性

提供存储身份状态的属性名。状态属性的值为活动或不活动。该属性在身份验证期间使用。如果身份为不活动，则不验证用户。

散列的属性

提供属性列表，这些属性的值将散列并存储于文件中。执行散列后，便无法获取原始值。只能对散列的值进行检索。某些用于验证的属性不应永久存储，使用散列便可确保这些属性的保密性。例如，身份的密码属性就是此类型属性的例子。

加密的属性

提供属性列表，这些属性的值将加密并存储于文件中。虽然对其进行了加密和存储，但调用身份系统信息库 API 仍可返回加密前的原始值。这可防止用户直接访问文件系统并读取敏感属性。

LDAPv3 属性

用于配置 LDAPv3 系统信息库插件的属性如下：

LDAP 服务器

输入要连接的 LDAP 服务器的名称。格式应为 hostname.domainname:portnumber。

如果输入多个 host:portnumber 条目，则会尝试连接到列表中的第一个主机。仅当尝试连接当前主机失败时，才会尝试列表中的下一个条目。

LDAP 绑定 DN

指定 Access Manager 将用来向当前连接的 LDAP 服务器验证的 DN 名称。拥有用于绑定的 DN 名称的用户应具有在LDAPv3 插件支持的类型和操作属性中配置的正确的添加/修改/删除权限。

LDAP 绑定密码

指定 Access Manager 将用来向当前连接的 LDAP 服务器验证的 DN 密码。

LDAP 绑定密码（确认）

确认密码。

LDAP 组织 DN

该数据存储库将映射到的 DN。它将成为在此数据存储库内执行的所有操作的基 DN。

LDAP SSL

启用后，Access Manager 将使用 HTTPS 协议连接到主服务器。

LDAP 连接池的最小尺寸

指定连接池中的初始连接数。使用连接池可避免每次都必须创建新的连接。

LDAP 连接池的最大尺寸

指定允许的最大连接数。

搜索返回的结果的最大数目

指定搜索操作所返回的最大条目数。如果达到该限制，Directory Server 将返回与搜索请求相匹配的任何条目。

搜索超时

指定分配给搜索请求的最长时间（以秒计）。如果达到该限制，Directory Server 将返回与搜索请求相匹配的任何搜索条目。

LDAP 遵循引用

如果启用该选项，将指定自动遵循其他 LDAP 服务器的引用。

LDAPv3 系统信息库插件类名称

指定实现 LDAPv3 系统信息库的类文件的位置。

常规属性名称映射

将框架已知的公共属性映射到本地数据存储库。例如，如果框架使用 inetUserStatus 确定用户状态，则本机数据存储库实际可能会使用 userStatus。属性定义区分大小写。

LDAPv3 插件支持的类型和操作

指定允许或可以在该 LDAP 服务器上执行的操作。只有默认操作才是受此 LDAPv3 系统信息库插件支持的操作。LDAPv3 系统信息库插件支持以下操作：

组 -- 读取、创建、编辑、删除
用户 -- 读取、创建、编辑、删除、服务
代理 -- 读取、创建、编辑、删除

可根据 LDAP 服务器设置和任务从上述列表删除权限，但不能添加其他权限。

角色 — 读取、创建、编辑、删除

LDAPv3 插件搜索范围

定义用于查找 LDAPv3 插件条目的范围。该范围必须为以下值之一：

SCOPE_BASE
SCOPE_ONE
SCOPE_SUB（默认值）

LDAP 用户搜索属性

该字段用于定义搜索用户时使用的属性类型。例如，如果用户 DN 为 uid=user1,ou=people,dc=iplanet,dc=com，则命名属性为 uid。

LDAP 用户搜索过滤器

指定用于查找用户条目的搜索过滤器。

LDAP 用户对象类

指定用户的对象类。创建用户之后，用户对象类列表将被添加到该用户的属性列表中。

LDAP 用户属性

定义与用户相关的属性列表。禁止对不在列表之内的用户属性进行任何读/写尝试。属性区分大小写。在这里定义对象类和属性模式之前，必须先在 Directory Server 中定义对象类和属性模式。

LDAP 用户创建属性映射

指定创建用户时需要哪些属性。此属性使用下列语法：

DestinationAttributeName=SourceAttributeName

如果缺少源属性名，则默认为用户 ID (uid)。例如：

cn
sn=givenName

创建用户概要文件时，cn 和 sn 都是必需的。cn 获取名为 uid 的属性的值，sn 则获取名为 givenName 的属性的值。

用户状态属性

指定属性名以表示用户状态。

用户状态活动值

指定活动用户状态的属性名。默认值为活动。

用户状态非活动值

指定不活动用户状态的属性名。默认值为不活动。

LDAP 组搜索属性

该字段用于定义搜索组时使用的属性类型。默认值为 cn。

LDAP 组搜索过滤器

指定用于查找组条目的搜索过滤器。默认值为 (objectclass=groupOfUniqueNames)。

LDAP 组容器命名属性

如果组驻留在容器中，则指定组容器的命名属性。否则，该属性保留为空。例如，如果 cn=group1,ou=groups,dc=iplanet,dc=com 的组 DN 位于 ou=groups 中，则组容器命名属性为 ou。

LDAP 组容器值

指定组容器的值。例如，如果 cn=group1,ou=groups,dc=iplanet,dc=com 的组 DN 位于容器名 ou=groups 中，则组容器值应为 groups。

LDAP 组对象类

指定组的对象类。创建组之后，组属性列表中会添加此组对象类列表。

LDAP 组属性

定义与组相关的属性列表。禁止对不在列表之内的组属性进行任何读/写尝试。属性区分大小写。在这里定义对象类和属性模式之前，必须先在 Directory Server 中定义对象类和属性模式。

组成员资格属性

指定属性名称，该属性的值为包含 DN 的所有组的名称。默认值为 memberOf。

唯一成员属性

指定属性名称，该属性的值是该组所包含的某个 DN。默认值为 uniqueMember。

组成员 URL 属性

指定属性名称，该属性的值是可解析为该组所包含成员的 LDAP URL。默认值为 memberUrl。

LDAP 人员容器命名属性

如果用户驻留在人员容器中，则指定该人员容器的命名属性。如果用户没有驻留在人员容器中，则将该字段保留为空。

LDAP 人员容器值

指定人员容器的值。默认值为 people。

LDAP 代理搜索属性

该字段用于定义搜索代理时使用的属性类型。默认值为 uid。

LDAP 代理容器命名属性

如果代理驻留在代理容器中，则指定该代理容器的命名属性。如果代理没有驻留在代理容器中，则将该字段保留为空。

LDAP 代理容器值

指定代理容器的值。默认值为 agents。

LDAP 代理搜索过滤器

定义用于搜索代理的过滤器。LDAP 代理搜索属性将被置于此字段之前，以构成实际的代理搜索过滤器。

例如，如果 LDAP 代理搜索属性为 uid 且 LDAP 用户搜索过滤器为 (objectClass=sunIdentityServerDevice)，则实际的用户搜索过滤器将是：(&(uid=*)(objectClass=sunIdentityServerDevice))

LDAP 代理对象类

定义代理的对象类。创建代理之后，将在代理属性列表中添加此用户对象类列表

LDAP 代理属性

定义与代理相关的属性列表。禁止对不在列表之内的代理属性进行任何读/写尝试。属性区分大小写。在这里定义对象类和属性模式之前，必须先在 Directory Server 中定义对象类和属性模式。

可验证的身份类型

当领域的验证模块模式设置为“数据存储库”时，指定该数据存储库可验证用户和/或代理身份类型。

持久搜索基 DN

定义用于持久搜索的基 DN。某些 LDAPv3 服务器仅在根后缀级别上支持持久搜索。

持久搜索过滤器

定义可返回目录服务器条目的特定更改的过滤器。数据存储库只接收与所定义过滤器相匹配的更改。

重新启动前的持久搜索最长空闲时间

定义重新启动持久搜索前的最长空闲时间。该值必须大于 1。如果小于或等于 1，重新启动搜索时将不会考虑连接的空闲时间。

如果部署 Access Manager 时包括负载平衡器，则某些负载平衡器会在空闲指定的时间后超时。在这种情况下，您为重新启动持久搜索前的最长空闲时间设置的值应该小于为负载平衡器指定的空闲时间。

出现错误代码后的最大重试次数

定义持久搜索操作遇到在“需要重试的 LDAP 异常错误代码”中指定的错误代码时，可以重试的最大次数。

重试之间的延时

指定每次重试之前的等待时间。仅适用于持久搜索连接。

需要重试的 LDAP 异常错误代码

指定需要重新执行持久搜索操作的错误代码。该属性仅适用于持久搜索，而非所有 LDAP 操作。

高速缓存

如果启用，Access Manager 便可对数据存储库中检索到的数据进行高速缓存。

高速缓存项的最大生存期

指定在高速缓存上删除数据之前，数据的最长存储时间。按秒来定义该值。

高速缓存的最大大小

指定高速缓存的最大大小。值越大，可存储的数据越多，但是这也需要更多的内存。按字节来定义该值。

第 4 章管理验证

“验证服务”为所有在 Access Manager 部署中安装的默认验证类型提供基于 Web 的用户界面。此界面在用户请求访问时显示登录要求屏幕（根据所调用的验证模块），从而为收集验证证书提供动态和可自定义的方法。此界面使用 Sun Java System™ 应用程序框架（有时称为 JATO）创建，该框架是一个用来帮助开发者创建功能性 Web 应用程序的 Java 2 Enterprise Edition (J2EE) 表示框架。

配置验证

本节介绍如何为部署配置验证。第一小节概述默认验证模块类型并提供所有必需的预配置说明。可以为领域、用户、角色等配置同一验证模块类型的多个配置实例。另外，可以添加验证链，这样验证必须满足多个实例的条件后才能成功。本节包括：

验证模块类型

验证模块是一个插件，可以收集用户信息（如用户 ID 和密码），然后根据数据库中的条目检查信息。如果用户提供的信息满足验证条件，则会批准该用户访问请求的资源。如果用户提供的信息不满足验证条件，则会拒绝该用户访问请求的资源。安装 Access Manager 时会随附以下类型的验证模块：

注 –

某些验证模块类型需要预配置然后才能用作验证实例。如有必要，配置步骤会在模块类型说明中列出。

核心

默认情况下，Access Manager 提供了十五个不同的验证模块和一个核心验证模块。核心验证模块提供验证模块的整体配置。在添加和启用活动目录验证模块、匿名验证模块、基于证书的验证模块、HTTP Basic 验证模块、JDBC 验证模块、LDAP 验证模块等验证模块之前，必须先添加和启用核心验证模块。对于默认领域，核心验证模块和 LDAP 验证模块自动启用。

单击“高级属性”按钮，可显示能为领域进行定义的核心验证属性。全局属性不适用于领域，因而不会显示出来。

活动目录

活动目录验证模块以类似于 LDAP 模块的方式执行验证，但是使用 Microsoft 的 Active Directory™ 服务器（LDAP 验证模块使用 Directory Server）。尽管 LDAP 验证模块可以被配置为使用 Active Directory 服务器，但此模块允许在同一个领域下存在 LDAP 和活动目录验证。

注 –

对于此版本，活动目录验证模块仅支持用户验证。仅在 LDAP 验证模块中支持密码策略。

匿名

默认情况下，如果已启用此模块，则用户可以作为匿名用户登录 Access Manager。通过配置“有效匿名用户列表”属性，还可以为此模块定义匿名用户列表。允许匿名访问意味着无需提供密码即可进行访问。匿名访问可以限于特定的访问类型（例如，读取访问或搜索访问）、特定的子树或目录中的特定条目。

证书

基于证书的验证涉及到使用个人数字证书 (personal digital certificate, PDC) 确定用户的身份和验证用户。可以将 PDC 配置为要求用户提供的证书与 Directory Server 中存储的 PDC 相同，并且根据证书撤销列表进行验证。

将基于证书的验证模块添加到领域之前，需要完成许多操作。首先，需要确保与 Access Manager 一起安装的 Web 容器的安全，并配置此 Web 容器使其适用于基于证书的验证。

注 –

如果通过启用 SSL 的 Sun Java System Web Server 6.1 实例配置 Access Manager 证书验证，并且希望定义的 WebServer 接受基于证书和非基于证书的验证请求，则必须在 WebServer 的 obj.conf 文件中设置以下值：

PathCheck fn="get-client-cert" dorequest="1" require="0"

这是由于为此行为设置可选属性时，WebServer 控制台中存在限制。

启用基于证书的模块之前，参见《Sun ONE Web Server 6.1 管理员指南》中的第 6 章“使用证书和密钥”，了解 Web Server 的初始配置步骤。可以在以下位置找到此文档：

http://docs.sun.com/app/docs/coll/S1_websvr61_en

或参见以下位置的《Sun ONE Application Sever Administrator’s Guide to Security》：

http://docs.sun.com/db/prod/s1appsrv#hic

注 –

使用基于证书的模块进行验证的用户必须请求用户浏览器的 PDC。具体说明各不相同，视使用的浏览器而定。有关详细信息，参见浏览器的文档。

要添加此模块，必须作为领域管理员登录 Access Manager，将 Access Manager 和 Web 容器配置为使用 SSL 并启用客户机验证。有关详细信息，参见 Access Manager Post Installation Guide 中的“Configuring Access Manager in SSL Mode”。

数据存储库

数据存储库验证模块允许使用领域的身份系统信息库在用户登录时对其进行验证。如果要根据同一数据存储库系统信息库进行验证，那么采用数据存储库模块便可免去编写验证插件模块，加载然后配置验证模块的麻烦。此外，也无需编写自定义验证模块（其中，需要对该领域中的相应系统信息库进行平面文件验证）。

配置 Access Manager 验证时，此验证类型会提供不少便利。在 Access Manager 7.1 之前的版本中，如果希望 LDAPv3 数据存储库中的用户可验证到其领域，则必须执行以下操作：

配置 LDAPv3 数据存储库
配置 LDAP 验证模块实例，以使其引用相同的领域主题

数据存储库验证模块验证在领域的身份系统信息库中定义的用户。无需任何 LDAP 验证配置。例如，假设领域的身份系统信息库包括一个 LDAPv3 数据存储库，而且相同的领域使用数据存储库验证。在这种情况下，定义于身份系统信息库中的任何用户都可验证到该领域。

HTTP Basic

此模块使用基本验证，该验证是 HTTP 协议的内置验证支持。Web Server 发出对用户名和密码的客户机请求，并将这些信息作为已授权的请求的一部分发送回服务器。Access Manager 将检索用户名和密码，然后在内部将用户验证到 LDAP 验证模块。为使 HTTP Basic 正常工作，还必须添加 LDAP 验证模块（只添加 HTTP Basic 模块将无法正常工作）。用户成功进行验证后，无需提供用户名和密码即可重新进行验证。

JDBC

Java 数据库连接 (Java Database Connectivity, JDBC) 验证模块提供一种验证机制，允许 Access Manager 通过任何 SQL 数据库（提供启用 JDBC 技术的驱动程序）验证用户。可以直接通过 JDBC 驱动程序或 JNDI 连接池连接 SQL 数据库。

注 –

此模块已在 MySQL4.0 和 Oracle 8i 上进行过测试。

LDAP

使用 LDAP 验证模块时，用户登录时必须用特定用户 DN 和密码绑定至 LDAP Directory Server。这是所有基于领域的验证的默认验证模块。如果用户提供了 Directory Server 中的用户 ID 和密码，则会为用户设置有效的 Access Manager 会话并允许其进行访问。对于默认领域，核心验证模块和 LDAP 验证模块自动启用。

成员资格

成员资格验证的实现类似于个性化设置站点，如 my.site.com 或 mysun.sun.com。启用此模块时，用户可以在没有管理员帮助的情况下创建帐户并对其进行个性化设置。利用这个新帐户，用户可以作为已添加的用户来访问。用户还可以访问作为授权数据和用户首选项保存在用户概要文件数据库中的查看器界面。

MSISDN

移动站集成服务数字网络 (Mobile Station Integrated Services Digital Network, MSISDN) 验证模块使用与设备（如移动电话）关联的移动用户 ISDN 来启用验证。它是一种非交互式模块。该模块检索用户 ISDN 并根据 Directory Server 对其进行验证，以查找与编号匹配的用户。

RADIUS

可以将 Access Manager 配置为与已安装的 RADIUS 服务器一起使用。如果企业中正使用原有的 RADIUS 服务器进行验证，这样做很有用。RADIUS 验证模块的启用过程分为两个步骤：

配置 RADIUS 服务器。

有关详细指示，参见 RADIUS 服务器文档。
注册和启用 RADIUS 验证模块。

使用 Sun Java System Application Server 配置 RADIUS

默认情况下，当 RADUIS 客户机建立到其服务器的套接字连接时，在 Application Server 的 server.policy 文件中只允许 SocketPermission 连接权限。为使 RADUIS 验证正常工作，对于以下操作应授予权限：

接受
连接
侦听
解析

要授予套接字连接权限，必须在 Application Server 的 server.policy 文件中添加一个条目。SocketPermission 由主机规范和指定连接到该主机的方式的一组操作组成。请按以下格式指定主机：

host = hostname | IPaddress:portrange:portrange = portnumber 
| -portnumberportnumber-portnumber

Host 可以表示为 DNS 名称、数字 IP 地址或本地主机（对于本地计算机）。DNS 名称主机规范中可包含一处通配符“*”。如果包含通配符，它必须位于最左侧的位置，如 *.example.com。

port（或 port range）是可选的。形式为 N- 的端口规范（其中 N 为端口号）表示编号为 N 及以上的所有端口。形式为 -N 的规范表示编号为 N 及以下的所有端口。

侦听操作仅在与本地主机一起使用时才有意义。任意其他操作存在时，则暗含解析（解析主机/IP 名称服务查找）操作。

例如，当创建 SocketPermission 时，请注意如果将以下权限授予某代码，将允许该代码连接到 machine1.example.com 上的 port 1645，并接受该端口上的连接：

permission java.net.SocketPermission machine1.example.com:1645, "connect,accept";

类似地，如果将以下权限授予某代码，将允许该代码接受本地主机上 1024 到 65535 之间的任意端口上的连接，并可连接或侦听这些端口：

permission java.net.SocketPermission "machine1.example.com:1645", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

注 –

授予代码权限以接受或建立到远程主机的连接可能会引起问题，因为恶意代码可以更容易地在各方之间传送和共享机密数据，使可能不具有数据访问权限的人访问到数据。请确保仅通过指定确切的端口号（而不是指定端口号的范围）授予适当的权限。

SafeWord

可以配置 Access Manager 使其处理对 Secure Computing 的 SafeWord™ 或 SafeWord PremierAccess™ 验证服务器的 SafeWord 验证请求。Access Manager 提供 SafeWord 验证的客户机部分。SafeWord 服务器可位于安装 Access Manager 的系统或单独的系统中。

使用 Sun Java System Application Server 配置 SafeWord

默认情况下，当 SafeWord 客户机建立到其服务器的套接字连接时，在 Application Server 的 server.policy 文件中只允许 SocketPermission 的 connect 权限。为使 SafeWord 验证正常工作，需要对以下操作授予权限：

接受
连接
侦听
解析

host = (hostname | IPaddress)[:portrange] portrange = 
portnumber | -portnumberportnumber-[portnumber]

侦听操作仅在与本地主机一起使用时才有意义。任意其他操作存在时，解析（解析主机/IP 名称服务查找）操作才能执行。

例如，当创建 SocketPermission 时，请注意如果将以下权限授予某个代码，将允许该代码连接到 machine1.example.com 上的 port 1645，并接受该端口上的连接：

permission java.net.SocketPermission machine1.example.com:5030, "connect,accept";

类似地，如果将以下权限授予某些代码，将允许该代码接受本地主机上 1024 到 65535 之间的所有端口上的连接、连接到这些端口或侦听它们：

permission java.net.SocketPermission "machine1.example.com:5030", "connect,accept";
permission java.net.SocketPermission "localhost:1024-", "accept,connect,listen";

注 –

授予代码权限以接受或建立到远程主机的连接可能会引起问题，因为恶意代码可以更容易地在各方之间传送和共享机密数据，使可能不具有数据访问权限的人访问到数据。请确保通过指定确切的端口号（而不是指定一个端口号的范围）仅授予适当的权限。

SAML

安全声明标记语言 (Security Assertion Markup Language, SAML) 验证模块接收和验证目标服务器上的 SAML 声明。SAML SSO 仅在目标计算机上配置了此模块后才会工作（包括升级后，例如从 Access Manager 2005Q4 升级到 Access Manager 7.1）。

SecurID

可以对 Access Manager 进行配置，以处理 RSA 的 ACE/Server 验证服务器的 SecureID 验证请求。Access Manager 提供 SecurID 验证的客户机部分。ACE/Server 可位于安装 Access Manager 的系统或单独的系统中。要验证本地管理的用户 ID（参见 admintool (1M)），必须具备超级用户 (root) 访问权限。

SecurID 验证使用验证帮助应用程序 amsecuridd，这是独立于主 Access Manager 进程以外的进程。在启动时，此帮助应用程序将在端口上侦听配置信息。如果 Access Manager 被安装为以 nobody 身份运行，或者以非超级用户的某种 userid 身份运行，则 AccessManager-base/SUNWam/share/bin/amsecuridd 进程必须仍以超级用户身份运行。有关 amsecuridd 帮助应用程序的详细信息，参见 Access Manager Administration Reference 中的“The amSecurID Helper”。

注 –

在此发行版本的 Access Manager 中，SecurID 验证模块不适用于 Linux 或 Solaris x86 平台，不能在这两个平台上注册、配置或启用。它仅适用于 SPARC 系统。

UNIX

可以配置 Access Manager 使其按照安装了 Access Manager 的 Solaris 或 Linux 系统已知的 Unix 用户 ID 和密码来处理验证请求。尽管 Unix 验证只有一个领域属性和几个全局属性，仍有一些面向系统的注意事项。要验证本地管理的用户 ID（参见 admintool (1M)），必须具备超级用户 (root) 访问权限。

Unix 验证使用验证帮助应用程序 amunixd，这是独立于主 Access Manager 进程以外的进程。在启动时，此帮助应用程序将在端口上侦听配置信息。每个 Access Manager 只有一个 Unix 帮助应用程序用于其所有领域。

如果将 Access Manager 安装为以 nobody 运行，或者以非超级用户的某种 userid 身份运行，则 AccessManager-base/SUNWam/share/bin/amunixd 进程必须仍以超级用户身份运行。Unix 验证模块通过打开到 localhost:58946 的套接字调用 amunixd 守护进程以侦听 Unix 验证请求。要在默认端口上运行 amunixd 帮助应用程序进程，请输入以下命令：

./amunixd

要在非默认端口上运行 amunixd，请输入以下命令：

./amunixd [-c portnm] [ipaddress]

ipaddress 和 portnumber 位于 AMConfig.properties 中的 UnixHelper.ipadrs（以 IPV4 格式）和 UnixHelper.port 属性中。您可以通过 amserver 命令行实用程序运行 amunixd（amserver 自动运行进程，从 AMConfig.properties 中检索端口号和 IP 地址）。

/etc/nsswitch.conf 文件中的 passwd 条目确定是否查询 /etc/passwd 和 /etc/shadow 文件或 NIS 以进行验证。

Windows Desktop SSO

Windows Desktop SSO 验证模块是一个基于 Kerberos 的验证插件模块，用于 Windows 2000™。它允许已通过 Kerberos 分发中心 (Kerberos Distribution Center, KDC) 验证的用户无需重新提交登录条件即可验证到 Access Manager（单点登录）。

用户通过 SPNEGO（Simple and Protected GSS-API Negotiation Mechanism，简单且受保护的 GSS-API 协商机制）协议向 Access Manager 提供 Kerberos 令牌。要通过此验证模块执行基于 Kerberos 的 Access Manager 单点登录，用户必须在客户机端支持 SPNEGO 协议以验证本身。一般而言，支持此协议的任何用户应该都能使用此模块验证 Access Manager。根据客户机端令牌的可用性，此模块提供 SPENGO 令牌或 Kerberos 令牌（这两种情况下协议是相同的）。在 Windows 2000（或更高版本）上运行的 Microsoft Internet Explorer（5.01 或更高版本）当前支持此协议。此外，Solaris（9 和 10）上的 Mozilla 1.4 支持 SPNEGO，但返回的令牌只有一个 KERBEROS 令牌，因为 Solaris 上不支持 SPNEGO。

注 –

必须使用 JDK 1.4 或更高版本利用 Kerberos V5 验证模块和 Java GSS API 的新功能，以执行此 SPNEGO 模块中基于 Kerberos 的 SSO。

Internet Explorer 的已知限制

如果在进行 WindowsDesktopSSO 验证时使用 Microsoft Internet Explorer 6.x，并且浏览器不能访问与 WindowsDesktopSSO 模块中配置的 (KDC) 领域匹配的用户 Kerberos/SPNEGO 令牌，则浏览器在向 WindowsDesktopSSO 模块验证失败后无法对其他模块实施正确的行为。问题的直接原因是：在 Internet Explorer 对 WindowsDesktopSSO 模块失败后，浏览器若未重新启动，将无法传送回叫（其他模块的）给 Access Manager，即使系统提示该回叫。由于用户证书为空，因此 WindowsDesktopSSO 后的所有模块都将失败。

http://www.wedgetail.com/jcsi/sso/doc/guide/troubleshooting.html#ieNTLM

注 –

此版本的 Access Manager 发行时，Microsoft 已修复了此限制。有关详细信息，参见以下文档：

http://www.microsoft.com/technet/security/bulletin/ms06-042.mspx

配置 Windows Desktop SSO

启用 Windows Desktop SSO 验证分为两个步骤：

在 Windows 2000 域控制器中创建用户。
设置 Internet Explorer。

在 Windows 2000 域控制器中创建用户

在域控制器中，为 Access Manager 验证模块创建用户帐户。
1. 从“开始”菜单中，转至“程序”>“管理工具”。
2. 选择“活动目录用户”和“计算机”。
3. 转至“计算机”>“新建”>“计算机”，并添加客户机计算机的名称。如果使用的是 Windows XP，则会在域控制器帐户配置期间自动执行该步骤。
4. 转至“用户”>“新建”>“用户”，并创建具有 Access Manager 主机名的新用户作为用户 ID（登录名称）。Access Manager 主机名不应该包含域名。

在用户帐户与服务提供商名称间建立关联，并将密钥表文件导出至装有 Access Manager 的系统。为此，请运行以下命令：

ktpass -princ host/hostname.domainname@DCDOMAIN -pass password -mapuser userName-out 
hostname.host.keytab
ktpass -princ HTTP/hostname.domainname@DCDOMAIN -pass 
password -mapuser userName-out hostname.HTTP.keytab

注 –

ktpass 实用程序不会作为 Windows 2000 服务器的一部分安装。必须从安装 CD 将其安装到 c:\program files\support 工具目录。

ktpass 命令接受以下参数：

hostname。运行 Access Manager 的主机名（不含域名）。

domainname。Access Manager 的域名。

DCDOMAIN。域控制器的域名。它可能与 Access Manager 域名不同。

password。用户帐户的密码。请确保密码正确，因为 ktpass 不校验密码。

userName。用户帐户 ID。它应与主机名相同。

注 –

确保两个密钥表文件都已安全保管。

服务模板的值应与以下示例类似：

服务主体：HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

密钥文件名：/tmp/machine1.HTTP.keytab

Kerberos 领域：ISQA.EXAMPLE.COM

Kerberos 服务器名：machine2.EXAMPLE.com

返回带有域名的主体：false

验证级别：22

注 –

如果使用的是 Windows 2003 或 Windows 2003 Service Pack，则使用以下 ktpass 命令语法：

ktpass /out filename /mapuser username /princ HTTP/hostname.domainname 
     /crypto encryptiontype /rndpass /ptype principaltype /target domainname

例如：

ktpass /out demo.HTTP.keytab /mapuser http 
/princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT 
/rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM

有关语法定义，参见 http://technet2.microsoft.com/WindowsServer/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true Web 站点。

重新启动服务器。

设置 Internet Explorer

以下步骤适用于 Microsoft Internet Explorer™ 6 及更高版本。如果您使用的是较早版本，请确保 Access Manager 位于浏览器的 Internet 区域并启用“本地 Windows 验证”。

在“工具”菜单中，转至“Internet 选项”>“高级”/”安全”>“安全”。

选择“集成的 Windows 验证”选项。

转至“安全”>“本地 Intranet”。
1. 选择“自定义级别”。在“用户验证/登录”面板中，选择“只在 Intranet 区域自动登录”选项。
2. 转到“站点”并选择所有选项。
3. 单击“高级”，将 Access Manager 添加到本地区域（如果尚未添加）。

Windows NT

可以将 Access Manager 配置为与已安装的 Windows NT/Windows 2000 server 一起使用。Access Manager 提供 NT 验证的客户机部分。

配置 NT 服务器。有关详细信息，参见 Windows NT 服务器文档。
在添加和启用 Windows NT 验证模块之前，必须获取并安装 Samba 客户端，以与 Solaris 系统上的 Access Manager 进行通信。

安装 Samba 客户端

为了激活 Windows NT 验证模块，必须下载 Samba Client 2.2.2 并将其安装到以下目录：

AccessManager-base/SUNWam/bin

Samba Client 是文件和打印服务器，它将 Windows 计算机和 UNIX 计算机融合在一起而无需使用单独的 Windows NT/2000 服务器。有关该软件的详细信息及下载该软件，请访问 http://wwws.sun.com/software/download/products/3e3af224.html。

Red Hat Linux 产品随附有 Samba 客户端，它位于以下目录：

/usr/bin

要使用 Linux 的 Windows NT 验证模块进行验证，将客户机二进制文件复制到以下 Access Manager 目录：

AccessManager-base/sun/identity/bin

注 –

如果有多个接口，则需要额外配置。可通过 smb.conf 文件中的配置设置多个接口，以便传递到 mbclient。

验证模块实例

可以根据默认验证模块为领域创建多个验证模块实例。可以添加同一个验证模块的多个单独配置的实例。

创建新的验证模块实例

单击要为其添加新验证模块实例的领域的名称。

选择“验证”选项卡。

注 –
“管理员验证配置”按钮只能为管理员定义验证服务。如果需要将管理员的验证模块与最终用户的验证模块区别开来，则可以使用该属性。在访问 Access Manager 控制台时，将使用该属性中配置的模块。

在“模块实例”列表中单击“新建”。

输入验证模块实例的名称。该名称必须唯一。

选择领域验证模块的类型。

单击“创建”。

单击新建的模块实例名，并编辑该模块的属性。有关每种模块类型的属性的定义，参见联机帮助中的“验证”部分。

重复执行这些步骤可以添加多个模块实例。

验证链接

可以配置一个或多个验证模块，用户必须将验证证书传递到这些验证模块中。这称为验证链接。Access Manager 的验证链接是通过使用集成在验证服务中的 JAAS 框架实现的。

创建新的验证链

单击要为其添加新验证链的领域的名称。

选择“验证”选项卡。

在“验证链接”列表中单击“新建”。

请输入验证链名称。

单击“创建”。

单击“添加”以定义您要在链里包含的验证模块实例。可以通过从实例列表中选择模块实例名来完成此步骤。此列表中所显示的模块实例名都是在“模块实例”属性中创建的。

为验证链选择标准。这些标志建立了其定义的验证模块的执行标准。执行具有层次结构。“必需”为最高层，“可选”为最低层：

必要

要成功验证必须要通过此模块实例。如果验证成功，将继续验证链接列表中的下一个模块实例。如果验证失败，则立即返回到应用程序（不继续验证链接列表中的下一个模块实例）。

必需

对此模块的验证必须成功。如果链中的任一必需模块验证失败，则整个验证链将最终失败。然而，无论必需模块的验证成功或失败，都将继续链中的下一个模块。

充足

不要求模块实例必须成功。如果验证成功，则立即返回到应用程序（不继续模块实例列表中的下一个验证模块）。如果验证失败，将继续验证链接列表中的下一个验证模块。

可选

不要求模块实例必须成功。无论验证成功或失败，都将继续验证链接列表中的下一个验证模块。

输入验证链的选项。这将以“关键字=值”对的形式为模块启用附加选项。多个选项之间用空格分隔。

定义以下属性：

成功登录 URL

指定验证成功后将用户重定向至的 URL。

登录失败 URL

指定验证失败后将用户重定向至的 URL。

验证后期处理类

定义用于在登录成功或失败后自定义后期验证处理的 Java 类的名称。

单击“保存”。

验证类型

“验证服务”提供了几种不同的验证方法。可通过指定登录 URL 参数或通过验证 API 来使用这些不同的验证方法（有关详细信息，请参见开发者指南中《Sun Java System Access Manager 7.1 Developer’s Guide》中的第 2 章 “Using Authentication APIs and SPIs”）。在能够配置验证模块之前，必须先修改核心验证服务属性“领域验证模块”以包含特定的验证模块名称。

验证配置服务用于定义以下任一验证类型的验证模块：

为其中一种验证类型定义了验证模块后，可以基于成功的或失败的验证进程配置该模块以提供重定向 URL 以及后处理 Java 类规范。

验证类型如何确定访问

对于每种方法，用户验证都可能通过或失败。一旦确定，每种方法都遵守这一过程。步骤 1 到步骤 3 接着成功的验证执行；步骤 4 接着成功和失败的验证执行。

Access Manager 确认验证的用户是否在 Directory Server 数据存储库中定义，以及配置文件是否处于活动状态。

“核心验证”模块中的“用户概要文件”属性可以定义为必需、动态、随用户别名动态变换或忽略。在成功的验证之后，Access Manager 确认是否在 Directory Server 数据存储库中定义了验证的用户，并且如果“用户概要文件”值为必需，则确认用户概要文件是否处于活动状态。（这是默认情况。）如果“用户概要文件”是动态配置，“验证服务”将在 Directory Server 数据存储库中创建用户概要文件。如果“用户概要文件”被设置成忽略，将不进行用户验证。
完成验证后期处理 SPI 的执行。

“核心验证模块”包含一个“验证后期处理类”属性，该属性可以把验证后期处理类的名称作为自己的值。AMPostAuthProcessInterface 是后期处理接口。它可以在验证成功、验证失败或注销时执行。
以下属性会被添加或更新到会话令牌中，并且用户会话会被激活。

realm。这是用户所属领域的 DN。

Principal。这是用户的 DN。

Principals。这是用户已经验证的名称的列表。（此属性可以有多个值，各值之间以管道符分隔。）

UserId。这是模块返回的用户 DN，如果是“LDAP”或“成员资格”以外的模块，则为用户名。（所有的“主体”必须映射到同一用户。用户 ID 是它们映射到的用户 DN。）

注 –
该属性可能是一个非 DN 值。

UserToken。这是一个用户名。（所有的“主体”必须映射到同一用户。UserToken 是它们映射到的用户名。）

Host。这是客户机的主机名或 IP 地址。

authLevel。这是用户已经验证的最高级别。

AuthType。这是已对用户进行验证的验证模块的列表，各项之间以管道符分隔（例如 module1|module2|module3）。

clientType。这是客户机浏览器的设备类型。

Locale。这是客户机的语言环境。

CharSet。这是为客户机确定的字符集。

Role。仅适用于基于角色的验证，这是用户所属的角色。

Service。仅适用于基于服务的验证，这是用户所属的服务。
验证成功或失败后，会在该 URL 中查找信息，以重定向用户。

URL 重定向的位置可以是 Access Manager 页面或 URL。重定向取决于优先顺序，Access Manager 会根据验证方法以及验证的成败，由此优先顺序寻找重定向。此顺序在以下验证方法章节的 URL 重定向部分有详细描述。

URL 重定向

在验证配置服务中，您可以指定成功或不成功验证的 URL 重定向。而 URL 本身是在该服务的“登录成功 URL”和“登录失败 URL”属性中进行定义的。为了启用 URL 重定向，必须将“验证配置”服务添加到您的领域中，以便可以为角色、领域或用户进行配置。添加“验证配置”服务时，请确保添加一个验证模块，例如 LDAP - REQUIRED。

基于领域的验证

此验证方法允许用户向领域或子领域进行验证。这是 Access Manager 的默认验证方法。通过把“核心验证”模块注册到领域，并定义“领域验证配置”属性，可以设置领域的验证方法。

基于领域的验证登录 URL

通过在“用户界面登录 URL”中定义 realm 参数或 domain 参数可以指定验证的领域。验证请求的领域由下列项目按优先级确定：

domain 参数。
realm 参数。

“管理”服务中的 DNS 别名属性的值。

在调用正确的领域后，可以通过“核心验证服务”中的“领域验证配置”属性获取将验证用户的验证模块。用于指定和启动基于领域的验证的登录 URL 是：

http://server_name.domain_name:port/amserver/UI/Login
http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name
http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name

如果没有定义参数，将由登录 URL 中指定的服务器主机和域确定领域。

注 –

如果用户是特定领域的成员并且验证到该特定领域，然后又尝试验证至不同领域，则只会传送 realm 和 module 这两个参数。例如，如果 User1 是 realmA 的成员并且验证到该领域，然后又尝试切换或验证到 realmB，则用户将收到一个警告页面，要求用户使用为 realmB 指定的模块实例启动到 realmB 的新验证，或返回 realmA 中现有的验证会话。如果选择验证到 realmB，则只会传送和使用领域名称和模块名称（如果指定）来确定新的验证过程。

基于领域的验证重定向 URL

在基于组织的验证成功或失败后，Access Manager 会查找信息以重定向用户。下面是应用程序查找这些信息的优先顺序。

成功的基于领域的验证重定向 URL

成功的基于领域的验证重定向 URL 通过按优先顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。
用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

失败的基于领域的验证重定向 URL

失败的基于领域的验证重定向 URL 通过按下列顺序检查以下位置来确定：

验证模块设置的 URL。
gotoOnFail 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-failure-ur 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。
为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

配置基于领域的验证

要为领域设置验证模块，先为领域添加“核心验证”服务。

配置领域的验证属性

找到要为其添加“验证链”的领域。

单击“验证”选项卡。

选择“默认验证链”。

从下拉菜单中选择“管理员验证链”。如果需要将管理员的验证模块与最终用户的验证模块区别开来，则可以使用该属性。默认验证模块为 LDAP。

定义验证链之后，单击“保存”。

基于组织的验证

此验证类型只适用于在“传统”模式下安装的 Access Manager 部署。

此验证方法允许用户向组织或子组织进行验证。这是 Access Manager 的默认验证方法。通过把“核心验证”模块注册到组织，并定义“组织验证配置”属性，可以设置组织的验证方法。

基于组织的验证登录 URL

通过在“用户界面登录 URL”中定义 org 参数或 domain 参数可以指定验证的组织。验证请求的组织由下列项目按优先级确定：

domain 参数。
org 参数。
“管理服务”中的 DNS 别名（组织别名）属性值。

在调用正确的组织后，可以通过“核心验证服务”中的“组织验证配置”属性获取将验证用户的验证模块。用于指定和启动基于组织的验证的登录 URL 是：
http://server_name.domain_name:port/amserver/UI/Login http://server_name.domain_name:port/amserver/UI/Login?domain=domain_name http://server_name.domain_name:port/amserver/UI/Login?org=org_name
如果没有定义参数，将由服务器主机和登录 URL 指定的域确定组织。

注 –

如果用户是特定组织的成员并且验证到该特定组织，然后又尝试验证至不同组织，则只会传送 org 和 module 这两个参数。例如，如果 User1 是 orgA 的成员并且验证到该领域，然后又尝试切换或验证到 orgB，则用户将收到一个警告页面，要求用户使用为 orgB 指定的模块实例启动到 orgB 的新验证，或返回 orgA 中现有的验证会话。如果选择验证到 orgB，则只会传送和使用组织名称和模块名称（如果指定）来确定新的验证过程。

基于组织的验证重定向 URL

在基于组织的验证成功或失败后，Access Manager 会查找信息以重定向用户。下面是应用程序查找这些信息的优先顺序。

成功的基于组织的验证重定向 URL

成功的基于组织的验证重定向 URL 通过按优先顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为用户组织条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。
用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
用户组织条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

失败的基于组织的验证重定向 URL

失败的基于组织的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
gotoOnFail 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为用户组织条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。
为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为用户组织条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

配置基于组织的验证

要为组织设置验证模块，先为组织添加“核心验证”服务。

配置组织的验证属性

找到要为其添加“验证链”的组织。

单击“验证”选项卡。

选择“默认验证链”。

从下拉菜单中选择“管理员验证链”。如果需要将管理员的验证模块与最终用户的验证模块区别开来，则可以使用该属性。默认验证模块为 LDAP。

定义验证链之后，单击“保存”。

基于角色的验证

此验证方法允许用户向领域或子领域内的角色（静态或过滤）进行验证。

注 –

“验证配置服务”在作为实例注册到角色以前，必须首先注册到领域。

验证要想成功，用户必须属于该角色，并且必须向为该角色配置的“验证配置服”实例中定义的每个模块进行验证。每个基于角色验证的实例均可指定下列属性：

冲突解决级别。此属性为可能包含相同用户的两个不同角色定义的“验证配置服务”实例设置优先级级别。例如，如果 User1 同时分配给 Role1 和 Role2，则可以为 Role1 设置较高的冲突解决级别。这样，当用户试图进行验证时，Role1 将优先进行成功或失败重定向以及验证后期处理。

验证配置。此属性定义为角色验证过程配置的验证模块。

登录成功 URL。此属性定义在验证成功后用户被重定向到的 URL。

登录失败 URL。此属性定义在验证失败后用户被重定向到的 URL。

验证后期处理类。此属性定义验证后期界面。

基于角色的验证登录 URL

通过定义 role 参数，可以在“用户界面登录 URL”中指定基于角色的验证。在调用正确的角色后，可以通过为角色定义的“验证配置服务”实例获取将要验证用户的验证模块。

用于指定和启动基于角色的验证的登录 URL 是：

http://server_name.domain_name:port/amserver/UI/Login?role=role_name
http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&role=role_name

如果没有配置 realm 参数，将通过在登录 URL 中指定的服务器主机和域来确定角色所属的领域。

基于角色的验证重定向 URL

在基于角色的验证成功或失败后，Access Manager 会查找信息以重定向用户。下面是应用程序查找这些信息的优先顺序。

成功的基于角色的验证重定向 URL

成功的基于角色的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。
clientType 自定义文件中为用户已验证的角色的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为已验证用户的另一个角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。（如果以前的重定向 URL 失败，此选项是一个替代方法。）
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。
用户已验证角色的 iplanet-am-auth-login-success-url 属性中设置的 URL。
已验证用户的另一个角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。（如果以前的重定向 URL 失败，此选项是一个替代方法。）
用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

失败的基于角色的验证重定向 URL

失败的基于角色的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
clientType 自定义文件中为用户已验证的角色的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为已验证用户的另一个角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。（如果以前的重定向 URL 失败，此选项是一个替代方法。）
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-failure-url 属性中设置的 URL。
用户已验证角色的 iplanet-am-auth-login-failure-url 属性中设置的 URL。
已验证用户的另一个角色的 iplanet-am-auth-login-failure-url 属性中设置的 URL。（如果以前的重定向 URL 失败，此选项是一个替代方法。）
用户领域条目的 iplanet-am-auth-login-failure-url 属性中设置的 URL。
iplanet-am-auth-login-failure-url 属性中设置的作为全局默认值的 URL。

配置基于角色的验证

找到要添加验证配置服务的领域（或组织）。

单击“主题”选项卡。

“过滤的角色”或“角色”。

选择要为其设置验证配置的角色。

选择要启用的“默认验证链”。

单击“保存”。

注 –
如果要创建新角色，验证配置服务将不会自动指定给该角色。请确保在创建新角色之前先选择“角色配置文件”页面顶部的“验证配置”服务选项。

如果启用了基于角色的验证，可以将 LDAP 验证模块保留为默认设置，因为不需要配置成员资格。

基于服务的验证

此验证方法允许用户向在领域或子领域中注册的特定服务或应用程序进行验证。服务在“验证配置服务”内配置成“服务实例”，并且与“实例名称”关联。验证要想成功，用户必须向为服务配置的“验证配置”服务实例中定义的每个模块进行验证。每个基于服务验证的实例均可指定下列属性：

验证配置。此属性定义为服务验证进程配置的验证模块。

登录成功 URL。此属性定义在验证成功后用户被重定向到的 URL。

登录失败 URL。此属性定义在验证失败后用户被重定向到的 URL。

验证后期处理类。此属性定义验证后期界面。

基于服务的验证登录 URL

通过定义 service 参数，可以在“用户界面登录 URL”中指定基于服务的验证。在调用服务后，可以通过为服务定义的“验证配置”服务实例获取将要验证用户的验证模块。

用来指定和启动基于服务的验证的登录 URL 是：

http://server_name.domain_name:port/amserver/UI/
Login?service=auth-chain-name

和

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name

如果没有配置 realm 参数，将通过在登录 URL 中指定的服务器主机和域来确定用户所属的领域。

基于服务的验证重定向 URL

在基于服务的验证成功或失败后，Access Manager 会查找信息以重定向用户。下面是应用程序查找这些信息的优先顺序。

成功的基于服务的验证重定向 URL

成功的基于服务的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。
clientType 自定义文件中为用户已验证服务的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。
用户已验证服务的 iplanet-am-auth-login-success-url 属性中设置的 URL。
用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

失败的基于服务的验证的重定向 URL

失败的基于服务的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
clientType 自定义文件中为用户已验证服务的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-failure-url 属性中设置的 URL。
用户已验证服务的 iplanet-am-auth-login-failure-url 属性中设置的 URL。
用户角色条目的 iplanet-am-auth-login-failure-url 属性中设置的 URL。
用户领域条目的 iplanet-am-auth-login-failure-url 属性中设置的 URL。
iplanet-am-auth-login-failure-url 属性中设置的作为全局默认值的 URL。

配置基于服务的验证

服务的验证模块是在添加了“验证配置”服务之后设置的。为此，请执行以下步骤：

选择要配置基于服务的验证的领域。

单击“验证”选项卡。

创建验证模块实例。

创建验证链。

单击“保存”。

要访问领域的基于服务的验证，请输入以下地址：

http://server_name.domain_name:port/amserver/UI/Login?realm=realm_name&service=auth-chain-name

基于用户的验证

此验证方法允许用户向专门为其配置的验证进程进行验证。这个过程被配置成用户概要文件中的“用户验证配置”属性值。验证要想成功，用户必须向定义的每个模块验证。

基于用户的验证登录 URL

通过定义 user 参数，可以在“用户界面登录 URL”中指定基于用户的验证。在调用正确的用户后，可以通过为用户定义的“用户验证配置”实例获取将要验证用户的验证模块。

用于指定和启动基于角色的验证的登录 URL 是：

http://server_name.domain_name:port/amserver/UI/Login?user=user_name
http://server_name.domain_name:port/amserver/UI/Login?org=org_name&user=user_name

如果没有配置 realm 参数，将通过登录 URL 中指定的服务器主机和域来确定角色所属的领域。

用户别名列表属性

在收到基于用户的验证请求时，“验证”服务会先验证用户是否为有效的用户，然后为其检索“验证配置”数据。如果有多个与用户登录 URL 参数值关联的有效用户概要文件，则所有配置文件都必须映射到指定的用户。可以在用户概要文件的“用户别名属性” (iplanet-am-user-alias-list) 中指定属于该用户的其他概要文件。如果映射失败，将拒绝该用户进行有效的会话。例外情况是，如果用户之一是顶级管理员，则不进行用户映射验证，并且用户被授予顶级管理员权限。

基于用户的验证重定向 URL

在基于模块的验证成功或失败后，Access Manager 会查找信息以重定向用户。下面是应用程序查找这些信息的优先顺序。

成功的基于用户的验证重定向 URL

成功的基于用户的验证重定向 URL 通过按优先顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。
用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

失败的基于用户的重定向 URL

失败的基于用户的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
gotoOnFail 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。
为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

配置基于用户的验证

找到要在其中为用户配置验证的领域。

单击“主题”选项卡，然后单击“用户”。

单击要修改的用户的名称

将显示“用户概要文件”。

注 –
如果要创建新用户，验证配置服务将不会自动指定给该用户。请确保在创建用户之前先选择服务配置文件中的“验证配置”服务选项。如果未选择此选项，用户将不会继承为角色定义的验证配置。

在“用户验证配置”属性中，选择您想要使用的验证链。

单击“保存”。

基于验证级别的验证

每个验证模块均可以与其验证级别的整数值相关联。更改模块的“验证级别”属性相应的值，可以指定验证级别。用户一个或多个验证模块的验证后，验证级别越高，则用户的信任级别就越高。

用户成功地通过模块的验证之后，系统将在用户的 SSO 令牌中设置验证级别。如果用户需要通过多个验证模块的验证并且成功地通过了这些验证，系统将在用户的 SSO 令牌中设置其中最高的验证级别值。

如果用户试图访问某个服务，该服务可以通过查看用户的 SSO 令牌中的验证级别来确定是否允许该用户进行访问。随后服务将用户重定向，使用户以设定的验证级别通过验证模块。

用户还可以访问具有特定验证级别的验证模块。例如，用户使用以下语法进行登录：

http://hostname:port/deploy_URI/UI/Login?authlevel=
auth_level_value

所有验证级别高于或等于 auth_level_value 的模块将显示为验证菜单以供用户选择。如果只找到了一个匹配的模块，则会直接显示该验证模块的登录页。

此验证方法可让管理员指定验证身份的模块的安全级别。每个验证模块都有单独的“验证级别”属性，此属性的值可以定义为任何有效的整数。利用基于“验证级别”的验证，“验证服务”会显示一个模块登录页面，其中有一个菜单，包含验证级别等于或大于登录 URL 参数所指定的值的验证模块。用户可以从提供的列表中选择模块。在用户选择模块之后，剩余的进程取决于基于模块的验证。

基于验证级别的验证登录 URL

通过定义 authlevel 参数，可以在“用户界面登录 URL”中指定基于验证级别的验证。在调用含有相关模块列表的登录屏幕之后，用户必须选择一个用于验证的模块。用于指定和启动基于验证级别的验证的登录 URL 是：

http://server_name.domain_name:port/amserver/UI/Login?authlevel=authentication_level

和

http://server_name.domain_name:port/amserver/UI/
Login?realm=realm_name&authlevel=authentication_level

如果没有配置 realm 参数，将通过登录 URL 中指定的服务器主机和域来确定用户所属的领域。

基于验证级别的验证重定向 URL

在基于验证级别的验证成功或失败后，Access Manager 会查找信息以重定向用户。下面是应用程序查找这些信息的优先顺序。

成功的基于验证级别的验证重定向 URL

成功的基于验证级别的验证重定向 URL 通过按优先顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。
用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

失败的基于验证级别的验证重定向 URL

失败的基于验证级别的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
gotoOnFail 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。
为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

基于模块的验证

用户可以使用以下语法访问特定的验证模块：

http://hostname:port/deploy_URI/UI/Login?module=
module_name

在能够访问验证模块之前，必须先修改核心验证服务属性“领域验证模块”以包含该验证模块名称。如果此属性中不包含该验证模块名称，则当用户尝试进行验证时，将会显示“验证模块被拒绝”页面。

此验证方法允许用户指定用来进行验证的模块。指定的模块必须向用户正在访问的领域或子领域注册。这是在领域的“核心验证服务”的“领域验证模块”属性中进行配置的。在收到基于模块的验证请求时，“验证服务”会验证模块是否按要求正确配置，如果该模块未定义，将拒绝用户访问。

基于模块的验证登录 URL

通过定义 module 参数，可以在“用户界面登录 URL”中指定基于模块的验证。用来指定和启动基于模块的验证的登录 URL 是：

http://server_name.domain_name:port/amserver/UI/Login?module=authentication_module_name
http://server_name.domain_name:port/amserver/UI/
Login?org=org_name&module=authentication_module_name

如果没有配置 realm 参数，将通过登录 URL 中指定的服务器主机和域来确定用户所属的领域。

基于模块的验证重定向 URL

在基于模块的验证成功或失败后，Access Manager 会查找信息以重定向用户。下面是应用程序查找这些信息的优先顺序。

成功的基于模块的验证重定向 URL

成功的基于模块的验证重定向 URL 通过按优先顺序检查以下位置来确定：

验证模块设置的 URL。
goto 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。
用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。
用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。
iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

失败的基于模块的验证重定向 URL

失败的基于模块的验证重定向 URL 通过按以下顺序检查以下位置来确定：

验证模块设置的 URL。
gotoOnFail 登录 URL 参数设置的 URL。
clientType 自定义文件中为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。
clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。
为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。
为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

用户界面登录 URL

在 Web 浏览器的“地址栏”中输入登录 URL 可访问“验证服务”用户界面。该 URL 是：

http://AccessManager-root/.domain_name:port /service_deploy_uri /UI/Login

注 –

在安装过程中，service_deploy_uri 被配置为 amserver。此默认服务部署 URI 将在本文档的全文中使用。

用户界面登录 URL 也可以附加登录 URL 参数来定义特定的验证方法或成功/失败的验证重定向 URL。

登录 URL 参数

URL 参数是附加在 URL 末尾的名称/值对。该参数以问号 (?) 开始，格式为 name=value。一个登录 URL 可以组合使用多个参数，如：

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&locale=ja&goto=http://www.sun.com

如果存在多个参数，参数之间用 (&) 号分隔。但组合必须遵守以下原则：

每个参数在一个 URL 中只能出现一次。例如，module=LDAP&module=NT 是不可计算的。
org 参数和 domain 参数都可以确定登录领域。在这种情况下，登录 URL 中只能使用其中一个参数。如果同时使用两个参数且不指定优先级，将只有一个生效。
参数 user、role、service、module 和 authlevel 用于定义基于各自标准的验证模块。因此，登录 URL 中只能使用其中一个参数。如果同时使用多个参数且不指定优先级，将只有一个生效。

以下各节描述各参数，这些参数在附加到“用户界面登录 URL”并键入 Web 浏览器的“地址栏”中时，可获取不同的验证功能。

注 –

为简化验证 URL 和参数以便在整个领域内分发，管理员可配置一个具备简单 URL 的 HTML 网页，该页面可链接到更复杂的登录 URL 以获取所有已配置的验证方法。

goto 参数

goto=successful_authentication_URL 参数覆写在“验证配置”服务的“登录成功 URL”中定义的值。当验证成功时，将链接到指定的 URL。goto=logout_URL 参数也可用于在用户注销时链接到指定的 URL。成功的验证 URL 示例如下：

http://server_name.domain_name:port/amserver/
UI/Login?goto=http://www.sun.com/homepage.html

goto 注销 URL 的示例如下：

http://server_name.domain_name:port/amserver/
UI/Logout?goto=http://www.sun.com/logout.html。

注 –

Access Manager 按优先顺序查找成功的验证重定向 URL。因为这些重定向 URL 及其顺序基于验证方法，所以此顺序（和相关信息）在“验证类型”部分中进行详细介绍。

gotoOnFail 参数

gotoOnFail=failed_authentication_URL 参数覆写在“验证配置”服务的“登录失败 URL”中定义的值。如果用户验证失败，将链接到指定的 URL。例如，gotoOnFail URL 可能是 http://server_name.domain_name:port/amserver/UI/Login?gotoOnFail=http://www.sun.com/auth_fail.html。

注 –

Access Manager 按优先顺序查找失败的验证重定向 URL。因为这些重定向 URL 及其顺序基于验证方法，所以此顺序（和相关信息）在“验证类型”部分中进行详细介绍。

realm 参数

realm=realmName 参数允许用户作为指定领域中的用户进行验证。

注 –

尚未成为指定领域成员的用户如果试图使用 realm 参数进行验证，会收到一条错误消息。如果以下所有条件均为 TRUE，则可在 Directory Server 中动态创建用户概要文件：

“核心验证服务”中的“用户概要文件”属性必须设置为动态或随用户别名动态变换。
用户必须成功通过所需模块的验证。
该用户在 Directory Server 中还没有配置文件。

使用此参数，将会显示正确的登录页面（基于领域及其语言环境设置）。如果未设置此参数，默认值是顶层领域。例如，realm URL 可以是：

http://server_name.domain_name:port/amserver/UI/Login?realm=sun

org 参数

org=orgName 参数可让用户作为指定组织中的用户进行验证。

注 –

尚未成为指定组织成员的用户如果试图使用 org 参数进行验证，会收到一条错误消息。如果以下所有条件均为 TRUE，则可在 Directory Server 中动态创建用户概要文件：

“核心验证服务”中的“用户概要文件”属性必须设置为动态或随用户别名动态变换。
用户必须成功通过所需模块的验证。
该用户在 Directory Server 中还没有配置文件。

使用此参数，将会显示正确的登录页面（基于组织及其语言环境设置）。如果未设置此参数，默认值是顶层组织。例如，org URL 可以是：

http://server_name.domain_name:port/amserver/UI/Login?org=sun

user 参数

user=userName 参数强制使用在用户概要文件的“用户验证配置”属性中配置的模块进行验证。例如，可以将一个用户的概要文件配置为使用“认证”模块进行验证，同时可以将另一个用户配置为使用 LDAP 模块进行验证。添加此参数会将用户发送到其配置的验证进程，而非为其组织配置的方法。例如：

http://server_name.domain_name:port/amserver/UI/Login?user=jsmith

role 参数

role=roleName 参数会把用户发送到为指定的角色配置的验证过程。尚未成为指定角色成员的用户如果试图用此参数进行验证，会收到一条错误消息。例如：

http://server_name.domain_name:port/amserver/UI/Login?role=manager。

locale 参数

Access Manager 可为验证进程以及控制台本身显示本地化屏幕（翻译成英语以外的语言）。locale=localeName 参数指定的语言环境具有比其他任何已定义的语言环境更高的优先权。在以下位置按顺序搜索配置之后，客户机会显示登录语言环境：

登录 URL 中的 locale 参数值

locale=localeName 参数的值的优先级高于所有其他定义的语言环境。
用户概要文件中定义的语言环境

如果没有 URL 参数，则根据用户概要文件中“用户首选语言”属性的设置值显示语言环境。
HTTP 标题中定义的语言环境

此语言环境由 Web 浏览器设置。
“核心验证服务”中定义的语言环境

这是“核心验证”模块中“默认验证语言环境”属性的值。
“平台”服务中定义的语言环境

这是“平台”服务中“平台语言环境”属性的值。

操作系统语言环境

从此等级顺序得到的语言环境存储在用户的会话令牌中，Access Manager 只使用它来加载本地化验证模块。在成功验证之后，将使用用户概要文件中的“用户首选语言”属性定义的语言环境。如果没有设置，将继续使用验证所用的语言环境。例如：

http://server_name.domain_name:port/amserver/UI/Login?locale=ja。

注 –

有关如何本地化屏幕文本和错误消息的信息可以在 Access Manager 中找到。

module 参数

module=moduleName 参数允许通过指定验证模块进行验证。可以指定任何模块，但它们必须首先在用户所属领域下注册并作为“核心验证”模块中该领域的验证模块之一被选定。例如：

http://server_name.domain_name:port/amserver/UI/Login?module=Unix。

注 –

验证模块名称用在 URL 参数中时区分大小写。

service 参数

service=serviceName 参数允许用户通过服务的已配置验证方案进行验证。使用“验证配置”服务可以为不同的服务配置不同的验证方案。例如，联机薪金应用程序可能需要使用更安全的“证书验证”模块进行验证，而领域的员工目录应用程序可能只需要“LDAP 验证”模块。可以为这些服务中的每一个配置并命名验证方案。例如：

http://server_name.domain_name:port/amserver/UI/Login?service=sv1。

注 –

“验证配置”服务用来为基于服务的验证定义方案。

arg 参数

arg=newsession 参数用于终止用户的当前会话并开始一个新会话。“验证服务”将通过一个请求销毁用户的现有会话令牌并执行新的登录。此选项通常用于“匿名验证”模块。用户首先使用匿名会话进行验证，然后单击注册或登录链接。例如：

http://server_name.domain_name:port/amserver/UI/Login?arg=newsession。

authlevel 参数

authlevel=value 参数告知“验证服务”调用验证级别等于或大于指定验证级别值的模块。每个验证模块都定义了一个固定整数的验证级别。例如：

http://server_name.domain_name:port/amserver/UI/Login?authlevel=1.

注 –

“验证级别”设置在特定于每个模块的配置文件中。

domain 参数

此参数允许用户登录到标识为指定域的领域。指定域必须与领域配置文件的“域名”属性中定义的值相匹配。例如：

http://server_name.domain_name:port/amserver/UI/Login?domain=sun.com.

注 –

尚未成为指定域/领域成员的用户如果试图使用 domain 参数进行验证，会收到一条错误消息。如果以下所有条件均为 TRUE，则可在 Directory Server 中动态创建用户概要文件：

“核心验证服务”中的“用户概要文件”必须设置为动态 或随用户别名动态变换。
用户必须成功通过所需模块的验证。
该用户在 Directory Server 中还没有配置文件。

iPSPCookie 参数

iPSPCookie=yes 参数允许用户以一个持久 cookie 登录。当浏览器窗口关闭以后，持久 cookie 继续存在。要使用此参数，用户所登录的领域必须在其“核心验证”模块中启用“持久 Cookie”。一旦用户进行验证并关闭浏览器，用户可以使用新的浏览器会话登录并定向至控制台而无需重新验证。这将一直有效，直到经过“核心服务”中指定的“持久 Cookie 最长时间”属性值为止。例如：

http://server_name.domain_name:port/amserver/UI/Login?org=example&iPSPCookie=yes

IDTokenN 参数

此参数选项允许用户以 URL 或 HTML 表单传送验证证书。用户可使用 IDTokenN=value 参数通过验证，而无需访问“验证服务用户界面”。此进程称为零页面登录。零页面登录仅适用于使用一个登录页面的验证模块。IDToken0, IDToken1, ..., IDTokenN 的值映射到验证模块登录页面上的字段。例如，LDAP 验证模块可能将 IDToken1 用于 userID 信息，将 IDToken2 用于密码信息。在这种情况下，LDAP 模块 IDTokenN URL 是：

http://server_name.domain_name:port/amserver/UI/
Login?module=LDAP&IDToken1=userID&IDToken2=password

（如果 LDAP 是默认的验证模块，则可以省略 module=LDAP。）

对于匿名验证，登录 URL 参数是：

http://server_name.domain_name:port/amserver/UI/Login?module=Anonymous&IDToken1=anonymousUserID。

注 –

仍支持令牌名称 Login.Token0、Login.Token1、 ...、 Login.TokenN（来自先前的版本），但在以后的版本中将不再支持。建议使用新的 IDTokenN 参数。

帐户锁定

“验证服务”提供这样一项功能：在验证失败次数超过某个特定值后将锁定用户。此功能默认情况下是关闭的，但是可以使用 Access Manager 控制台启用它。

注 –

只有抛出“密码无效”异常的模块可以使用“帐户锁定”功能。

“核心验证”服务包含用于启用和自定义此功能的属性，包括但不限于：

登录失败锁定模式，启用帐户锁定。
登录失败锁定计数，定义用户被锁定之前可以尝试验证的次数。此计数仅对单个用户 ID 有效；只有同一个用户 ID 失败次数达到指定的次数后才会被锁定。
登录失败锁定间隔，定义在锁定用户之前必须达到“登录失败锁定计数”值的时间（以分钟为单位）。
要发送锁定通知的电子邮件地址，指定接收用户锁定通知的电子邮件地址。
N 次失败后警告用户，指定在向用户显示警告消息之前可以发生的验证失败次数。这允许管理员在用户得到即将锁定的警告之后设置附加的登录尝试次数。
登录失败锁定时间，定义用户在锁定后再次尝试验证前所必须等待的时间（以分钟为单位）。
锁定属性名，定义用户概要文件中的哪一个 LDAP 属性针对“物理锁定”设置为不活动。
锁定属性值，定义在锁定属性名中指定的 LDAP 属性将设置为：不活动或活动。

有关任何帐户锁定的电子邮件通知都会发送给管理员。（还会记录帐户锁定活动。）

注 –

有关在 Microsoft® Windows 2000 操作系统上使用此功能的特殊说明，参见附录 A，“AMConfig.properties 文件”中的“简单邮件传输协议 (SMTP)”。”

Access Manager 支持两种类型的帐户锁定：“物理锁定”和“内存锁定”，具体在以下几节中定义。

物理锁定

这是 Access Manager 的默认锁定行为。通过将用户概要文件中 LDAP 属性的状态更改为不活动可以启动此锁定。锁定属性名属性定义用来进行锁定的 LDAP 属性。

注 –

别名用户是通过配置 LDAP 配置文件中的“用户别名列表属性”(amUser.xml 中的 iplanet-am-user-alias-list) 映射到现有 LDAP 用户概要文件的用户。别名用户可以通过将 iplanet-am-user-alias-list 添加到“核心验证服务”中的“别名搜索属性名称”字段来进行验证。也就是说，如果别名用户被锁定，则该别名用户映射至的实际 LDAP 配置文件也将被锁定。这只适合于 LDAP 及“成员资格”以外的验证模块的物理锁定。

内存锁定

将登录失败锁定时间属性的值更改为大于 0，可启用内存锁定。用户的帐户会在内存中锁定指定的分钟数。帐户将在经过该时间段之后解除锁定。以下是使用内存锁定功能时的一些特殊注意事项：

如果重新启动 Access Manager，所有内存中锁定的帐户都将解除锁定。
如果用户的帐户在内存中锁定，而管理员将帐户锁定机制改为物理锁定（通过将锁定时间设置回 0），则用户的帐户将在内存中解除锁定，锁定计数也会重置。
内存锁定后，当使用 LDAP 和“成员资格”以外的验证模块时，如果用户尝试用正确的密码登录，将返回用户在此领域中没有配置文件错误，而不是“用户无效”错误。

注 –

如果在用户的概要文件中设置了“失败 URL”属性，则无论是锁定警告消息，还是表示其帐户已锁定的消息，都不会显示；用户将被重定向至定义的 URL。

验证服务故障转移

如果主服务器因硬件或软件问题失败或者服务器临时关闭，则验证服务故障转移会自动将验证请求重定向到辅助服务器。

必须首先在提供验证服务的 Access Manager 实例上创建验证环境。如果此 Access Manager 实例不可用，则可通过验证故障转移机制在其他的 Access Manager 实例上创建验证环境。验证环境将按以下顺序检查服务器可用性。

验证服务 URL 将被传递给 AuthContext API。例如：
AuthContext(orgName, url)
如果使用此 API，则它将仅使用由 URL 所引用的服务器。即使在该服务器中提供了验证服务，也不会进行故障转移。
验证环境将检查在 AMConfig.properties 文件的 com.iplanet.am.server* 属性中定义的服务器。
如果步骤 2 失败，则验证环境将从提供有命名服务的服务器查询平台列表。此平台列表是在安装共享同一个 Directory Server 实例的多个 Access Manager 实例（通常是为故障转移目的）时自动创建的。

例如，如果该平台列表包含 Server1、Server 2 和 Server 3 的 URL，则验证环境会在 Server 1、Server 2 和 Server 3 之间循环，直到验证在其中一个服务器上成功为止。

平台列表可能不会始终从同一个服务器获得，因为它取决于命名服务的可用性。而且，可能会首先进行命名服务故障转移。多个命名服务 URL 在 com.iplanet.am.naming.url 属性（AMConfing.properties 中）中指定。第一个可用的命名服务 URL 将用于确定服务器，该服务器中包含将会进行验证故障转移的服务器（限于其平台服务器列表范围内）的列表。

全限定域名映射

全限定域名 (Fully Qualified Domain Name, FQDN) 映射可让“验证服务”在用户键入错误的 URL（例如指定部分主机名或 IP 地址来访问受保护的资源）时进行纠正。FQDN 映射通过修改 AMConfig.properties 文件中的 com.sun.identity.server.fqdnMap 属性来启用。用于指定此属性的格式为：

com.sun.identity.server.fqdnMap[invalid-name ]=valid-name

值 invalid-name 是用户可能键入的无效 FQDN 主机名，valid-name 是过滤器将用户重定向到的实际主机名。只要符合规定的要求，可以指定任意数量的映射（如代码示例 1-1 所示）。如果未设置此属性，用户将被发送到 AMConfig.propertiess 文件的 com.iplanet.am.server.host= server_name 属性中配置的默认服务器名称。

示例 4–1 `AMConfig.properties` 中的 FQDN 映射属性

com.sun.identity.server.fqdnMap[isserver]=isserver.mydomain.com
com.sun.identity.server.fqdnMap[isserver.mydomain]=isserver.mydomain.com
com.sun.identity.server.fqdnMap[
            IP address]=isserver.mydomain.com

FQDN 映射的可能用途

此属性可用于为多个主机名创建映射，例如在服务器上的应用程序可由多个主机名访问时便可使用此属性。此属性也可用于配置 Access Manager 使其对特定的 URL 不进行纠错。例如，如果使用 IP 地址访问应用程序的用户不需要重定向，可以通过指定如下映射条目来实现此功能：

com.sun.identity.server.fqdnMap[IP address]=IP address。

注 –

如果定义了多个映射，请确保无效的 FQDN 名称中没有重叠的值。否则可能导致无法访问应用程序。

持久 Cookie

持久 Cookie 在 Web 浏览器关闭之后继续存在，用户可以使用新的浏览器会话登录而无需重新验证。Cookie 的名称由 AMConfig.properties 中的 com.iplanet.am.pcookie.name 属性定义；默认值是 DProPCookie。Cookie 值是 3DES 加密字符串，包含用户 DN、领域名称、验证模块名称、最长会话时间、空闲时间和高速缓存时间。

启用持久 Cookie

在“核心验证”模块中打开持久 Cookie 模式。

在核心验证模块中的持久 Cookie 最长时间属性配置时间值。

将值为 yes 的 iPSPCookie 参数附加到“用户界面登录 URL”。

一旦用户使用此 URL 进行验证，如果浏览器被关闭，用户可以打开新的浏览器窗口并重定向到控制台而无需重新验证。这在到达步骤 2 所定义的时间之前一直有效。

可以使用“验证 SPI”方法打开“持久 Cookie”模式：

AMLoginModule.setPersistentCookieOn()。

传统模式下的多 LDAP 验证模块配置

作为一种故障转移形式，或当 Access Manager 控制台仅提供一个值字段时要配置属性的多个值，管理员可以在一个领域下定义多个 LDAP 验证模块配置。尽管这些附加配置无法通过控制台查看，但如果未找到对于请求用户的授权的初始搜索，这些配置可与主配置一起发挥作用。例如，一个领域可以定义在两个不同的域中搜索 LDAP 服务器进行验证，也可以在一个域中配置多个用户命名属性。对于后者，控制台中只有一个文本字段，如果使用主要搜索条件找不到用户，LDAP 模块将使用第二个范围搜索。以下是配置其他 LDAP 配置的步骤。

添加其他 LDAP 配置

编写一个 XML 文件，在其中包括完整的属性集和第二个（或第三个）LDAP 验证配置所需的新值。

可以通过查看 etc/opt/SUNWam/config/xml 中的 amAuthLDAP.xml 来引用可用的属性。但此步骤创建的 XML 文件是基于 amadmin.dtd 结构的，这与 amAuthLDAP.xml 不同。可以为此文件定义任何或所有属性。代码示例 1-2 是一个子配置文件的示例，该文件包括 LDAP 验证配置可用的所有属性的值。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
  Copyright (c) 2002 Sun Microsystems, Inc. All rights reserved.
  Use is subject to license terms.
-->
<!DOCTYPE Requests
    PUBLIC "-//iPlanet//Sun ONE Access Manager 6.0 Admin CLI DTD//EN"
    "jar://com/iplanet/am/admin/cli/amAdmin.dtd"
>
<!--
  Before adding subConfiguration load the schema with
GlobalConfiguration defined and replace corresponding
 serviceName and subConfigID in this sample file OR load
 serviceConfigurationRequests.xml before loading this sample
-->
<Requests>
<realmRequests DN="dc=iplanet,dc=com">
    <AddSubConfiguration subConfigName = "ssc"
        subConfigId = "serverconfig"
        priority = "0" serviceName="iPlanetAMAuthLDAPService">

              <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-server"/>
            <Value>vbrao.red.iplanet.com:389</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-base-dn"/>
            <Value>dc=iplanet,dc=com</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="planet-am-auth-ldap-bind-dn"/>
            <Value>cn=amldapuser,ou=DSAME Users,dc=iplanet,dc=com</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-bind-passwd"/>
            <Value>
                  plain text password</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-user-naming-attribute"/>
            <Value>uid</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-user-search-attributes"/>
            <Value>uid</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-search-scope"/>
            <Value>SUBTREE</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-ssl-enabled"/>
            <Value>false</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-return-user-dn"/>
            <Value>true</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-auth-level"/>
            <Value>0</Value>
        </AttributeValuePair>
        <AttributeValuePair>
            <Attribute name="iplanet-am-auth-ldap-server-check"/>
            <Value>15</Value>
        </AttributeValuePair>

    </AddSubConfiguration>

</realmRequests>
</Requests>

复制纯文本密码作为在步骤 1 中创建的 XML 文件中的 iplanet-am-auth-ldap-bind-passwd 的值。

在代码示例中，此属性的值被格式化为粗体。

使用 amadmin 命令行工具装入 XML 文件。
./amadmin -u amadmin -w administrator_password -v -t name_of_XML_file.
请注意，第二个 LDAP 配置不可见，也不能用控制台修改。

提示 –
多个 LDAP 配置有可供使用的样例。参见 /AccessManager-base/SUNWam/samples/admin/cli/bulk-ops/ 中的 serviceAddMultipleLDAPConfigurationRequests.xml 命令行模板。可以在 /AccesManager-base/SUNWam/samples/admin/cli/ 的 Readme.html 中找到说明。

会话升级

验证服务允许根据同一用户向一个领域执行的第二次成功验证来升级有效的会话令牌。如果拥有有效会话令牌的用户尝试向其当前领域保护的资源验证，并且这第二次验证请求成功，则该会话将用基于新验证的新属性更新。如果验证失败，用户的当前会话将返回而不进行升级。如果拥有有效会话的用户尝试向不同领域保护的资源验证，该用户将会收到一条询问他们是否要向新领域验证的消息。此时用户可以保持当前的会话，也可以尝试向新领域进行验证。成功的验证将损坏原来的会话，并创建新会话。

在会话升级期间，如果登录页面超时，就会重定向到原来的成功 URL。超时值取决于：

每个模块的页面超时值设置（默认值为 1 分钟）
AMConfig.properties 中的 com.iplanet.am.invalidMaxSessionTime 属性（默认值为 10 分钟）
iplanet-am-max-session-time（默认值为 120 分钟）

com.iplanet.am.invalidMaxSessionTimeout 和 iplanet-am-max-session-time 的值应大于页面超时值，否则在会话升级期间的有效会话信息将丢失，到以前的成功 URL 的 URL 重定向也将失败。

验证插件接口

管理员可以编写适用于其领域的用户名或密码验证逻辑，并将其插入“验证服务”。（只有 LDAP 和“成员资格”验证模块支持此项功能。）在验证用户或更改密码之前，Access Manager 将调用此插件。如果验证成功，验证将会继续；如果验证失败，将会抛出验证失败页面。插件扩展了作为“服务管理 SDK”一部分的 com.iplanet.am.sdk.AMUserPasswordValidation 类。有关此 SDK 的信息可以在 Access Manager Javadocs 的 com.iplanet.am.sdk 软件包中找到。

编写和配置验证插件

新的插件类将扩展 com.iplanet.am.sdk.AMUserPasswordValidation 类，并实现 validateUserID() 和 validatePassword() 方法。如果验证失败，将抛出 AMException。

编译插件类并将 .class 文件放置到所需的位置。更新类路径，使其在运行时可供 Access Manager 访问。

以顶级管理员身份登录 Access Manager 控制台。单击“配置”选项卡，转至“管理服务”的属性。在“用户 ID 和密码验证插件类”字段中键入插件类的名称（包括软件包的名称）。

注销，然后登录。

JAAS 共享状态

JAAS 共享状态可在验证模块之间共享用户 ID 和密码。为以下每个验证模块都定义了选项：

领域（或组织）
用户
服务
角色

如果失败，模块会提示所需的证书。在验证失败后，模块会停止运行，或者清除注销共享状态。

启用 JAAS 共享状态

配置 JAAS 共享状态：

使用 iplanet-am-auth-shared-state-enabled 选项。
共享状态选项的用法为：iplanet-am-auth-shared-state-enabled=true
此选项的默认值为 true。
此变量在验证链接配置的“选项”栏中指定。

在失败时，验证模块会根据 JAAS 规范中建议的 tryFirstPass 选项行为，提示用户提供所需的证书。

JAAS 共享状态存储选项

配置 JAAS 共享状态存储选项：

使用 iplanet-amauth-store-shared-state-enabled 选项。
存储共享状态选项的用法为：iplanet-am-auth-store-shared-state-enabled=true
此选项的默认值为 false。
此变量在验证链接配置的“选项”栏中指定。

在提交、中止或注销后，将清除共享状态。

第 5 章管理策略

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

本章包括以下内容：

概述

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

注 –

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

单个策略能定义二元或非二元决策。二元决策为是/否、真/假或允许/拒绝。非二元决策代表某个属性的值。例如，邮件服务可能包含一个 mailboxQuota 属性，其中为每个用户都设置了最大存储值。通常说来，配置策略可以定义某主体在什么条件下可以对什么资源执行什么操作。

策略管理功能

“策略管理”功能提供了用于创建和管理策略的策略服务。策略服务允许管理员定义、修改、授予、撤消和删除权限，以保护 Access Manager 部署内部的资源。通常，策略服务包括一个数据存储库、一个允许创建、管理和评估策略的界面库以及一个策略执行程序或策略代理。默认情况下，Access Manager 使用 Sun Java Enterprise System Directory Server 进行数据存储，并提供用于策略评估和策略服务自定义的 Java 和 C API（有关详细信息，参见《Sun Java System Access Manager 7.1 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 资源的过程。服务器中已安装的策略代理会截取请求并检查现有的验证凭证（会话令牌）。

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

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

假设代理截取了某一请求，而对于该请求不存在任何现有会话令牌，则代理将用户重定向到登录页面，即使资源受不同验证方法保护也是如此。
正确验证用户凭证后，代理会向定义用于连接到 Access Manager 内部服务的 URL 的“命名服务”发布请求。
如果资源与在代理处配置的非执行列表匹配，则允许访问。
“命名服务”返回策略服务、会话服务和日志记录服务的定位器。
代理将请求发送到“策略服务”以获取适用于用户的策略决策。
是允许用户访问还是拒绝用户访问，需根据当前访问资源的策略决策而定。如果对策略决策的建议指示出不同的验证级别或验证机制，代理会将请求重定向到“验证服务”，直到所有条件都经过验证为止。

策略类型

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

常规策略

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

规则

一条规则包含一种服务类型、一项或多项操作以及一个值。规则用于定义策略。

服务类型定义受保护的资源类型。
操作是可在资源上执行的操作的名称，例如 Web 服务器操作的示例有 POST 或 GET。针对人力资源服务的一项可行的操作可以是更改家庭电话号码。
值用于定义操作的权限，例如，允许或拒绝。

注 –

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

主题

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

Access Manager 身份主题

此主题表明可以将在“领域主题”选项卡下创建和管理的身份作为主题的成员添加。

验证的用户

此主题类型表明任何具有有效 SSO 令牌的用户都是此主题的成员。

所有通过验证的用户都是该“主题”的成员，即使他们已在其他领域（而不是定义策略所在的组织）中进行了验证。如果资源拥有者要开放一些资源（为其他组织的用户所管理的资源）的访问权时，这将非常有用。如果您要限制某个特定组织的成员对受保护资源的访问权，请使用“组织”主题。

Web 服务客户机

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

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

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

通过在领域的“策略配置服务”中选择以下附加主题，便可对其进行使用：

Access Manager 角色: 此主题类型表明任何使用 Access Manager 角色的成员都是此主题的成员。Access Manager 角色是使用运行于传统模式的 Access Manager 以及基于 6.3 的控制台创建的。这些角色所具有的对象类由 Access Manager 进行授权。Access Manager 角色只能通过所属的“Access Manager 策略服务”进行访问。
LDAP 组: 此主题类型表明 LDAP 组的任何成员都是此主题的成员。
LDAP 角色: 此主题类型表明任何使用 LDAP 角色的成员都是此主题的成员。“LDAP 角色”是使用 Directory Server 角色功能的任意角色定义。这些角色具有通过角色定义授权的对象类。可以在“策略配置服务”中修改“LDAP 角色搜索”过滤器以缩小范围并提高性能。
LDAP 用户: 此主题类型表明任何 LDAP 用户都是此主题的成员。
组织: 此主题类型表明领域的所有成员均为该主题的成员

Access Manager 角色与 LDAP 角色

Access Manager 角色是由 Access Manager 创建的。这些角色所具有的对象类由 Access Manager 进行授权。LDAP 角色是使用 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 a.m. 到 5 p.m. 之间进行访问。同时使用“IP 条件”和“时间条件”便可实现上述目的。将规则资源指定为 http://org.example.com/hr/*.jsp，策略将应用到 http://org.example.com/hr 下的所有 JSP 文件，包括子目录中的 JSP 文件。

注 –

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

可以添加的默认条件是：

活动会话时间

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

最长会话时间: 指定从发起会话起，策略可应用的最长持续时间。
终止会话: 如果选择该字段，当会话时间超过“最长会话时间”字段中定义的最长允许时间时，系统将终止该用户会话。

验证链

如果用户已在指定领域中向验证链成功验证，则应用该策略。如果未指定领域，则向任何领域中的验证链进行验证均满足条件。

验证级别（大于或等于）

如果用户的验证级别大于或等于条件中设置的验证级别，则应用该策略。该属性表明指定领域内的验证信任级别。

验证级别（小于或等于）

如果用户的验证级别低于或等于在条件中设置的验证级别，则应用该策略。该属性表明指定领域内的验证信任级别。

验证模块实例

如果用户已在指定领域内向验证模块成功进行验证，则应用该策略。如果未指定领域，则向任何领域中的验证模块进行验证均满足条件。

当前会话属性

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

IP 地址/DNS 名称

根据 IP 地址的范围设置条件。您可以定义的字段包括：

起始/结束 IP 地址

指定 IP 地址的范围。

DNS 名称

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

domainname

*.domainname

LDAP 过滤条件

当已定义的 LDAP 过滤器在 LDAP 目录（在“策略配置”服务中指定）中查找用户条目时，应用该策略。该条件仅在定义该策略的领域内适用。

领域验证

如果用户已向指定领域进行验证，则应用此策略。

时间（天、日期、时间和时区）

根据时间限制设置条件。这些字段包括：

起始/结束日期: 指定日期的范围。
时间: 指定一天中的时间范围。
日: 指定表示天数的范围。
时区: 指定一个标准的或自定义的时区。自定义的时区只能是可由 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》。

引用策略

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

“策略配置”服务包含称作“组织别名引用”的全局属性，该属性允许用户在子领域中创建策略，而不必在顶层或父领域创建引用策略。用户只能创建用于保护 HTTP 或 HTTPS 资源的策略，这些资源的全限定主机名应与领域的领域/DNS 别名相匹配。默认情况下，该属性设置为“否”。

规则

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

引用

引用定义策略评估引用的组织。默认情况下，有两种引用类型：对等领域和子领域。它们分别代表同级领域和子级领域。有关详细信息，参见为对等领域和子领域创建策略。

注 –

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

策略定义类型文档

一旦创建并配置了策略，它就会以 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 属性。

添加已启用策略服务

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

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

/etc/opt/SUNWam/config/xml/

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

添加新的已启用策略服务

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

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

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

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

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

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

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

创建策略

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

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

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

使用 amadmin 创建策略

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

AccessManager-base /SUNWam/dtd。

以下是策略 XML 文件的一个示例。该示例包含所有的默认主题和条件值。有关这些值的定义，参见策略类型。

<Policy name="bigpolicy" referralPolicy="false" active="true" >
<Rule name="rule1">
<ServiceName name="iPlanetAMWebAgentService" />
<ResourceName name="http://thehost.thedomain.com:80/*.html" />
<AttributeValuePair>
<Attribute name="POST" />
<Value>allow</Value>
</AttributeValuePair>
<AttributeValuePair>
<Attribute name="GET" />
<Value>allow</Value>
</AttributeValuePair>
</Rule>
<Subjects name="subjects" description="desccription">
<Subject name="webservicescleint" type="WebServicesClients" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/><Value>CN=sun-unix, 
OU=SUN Java System Access Manager, O=Sun, C=US</Value>
</AttributeValuePair>
</Subject>
<Subject name="amrole" type="IdentityServerRoles" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/><Value>
cn=organization admin role,o=realm1,dc=red,dc=iplanet,dc=com</Value>
</AttributeValuePair>
</Subject>
<Subject name="au" type="AuthenticatedUsers" includeType="inclusive">
</Subject>
<Subject name="ldaporganization" type="Organization" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/>
<Value>dc=red,dc=iplanet,dc=com</Value>
</AttributeValuePair>
</Subject>
<Subject name="ldapuser" type="LDAPUsers" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/>
<Value>uid=amAdmin,ou=People,dc=red,dc=iplanet,dc=com</Value>
</AttributeValuePair>
</Subject>
<Subject name="ldaprole" type="LDAPRoles" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/>
<Value>cn=Organization Admin Role,o=realm1,dc=red,dc=iplanet,dc=com</Value>
</AttributeValuePair>
</Subject>
<Subject name="ldapgroup" type="LDAPGroups" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/>
<Value>cn=g1,ou=Groups,dc=red,dc=iplanet,dc=com</Value>
</AttributeValuePair>
</Subject>
<Subject name="amidentitysubject" type="AMIdentitySubject" includeType="inclusive">
<AttributeValuePair><Attribute name="Values"/>
<Value>id=amAdmin,ou=user,dc=red,dc=iplanet,dc=com</Value>
</AttributeValuePair>
</Subject>
</Subjects>
<Conditions name="conditions" description="description">
<Condition name="ldapfilter" type="LDAPFilterCondition">
<AttributeValuePair><Attribute name="ldapFilter"/>
<Value>dept=finance</Value>
</AttributeValuePair>
</Condition>
<Condition name="authlevelge-nonrealmqualified" type="AuthLevelCondition">
<AttributeValuePair><Attribute name="AuthLevel"/>
<Value>1</Value>
</AttributeValuePair>
</Condition>
<Condition name="authlevelle-realmqaulfied" type="LEAuthLevelCondition">
<AttributeValuePair><Attribute name="AuthLevel"/>
<Value>/:2</Value>
</AttributeValuePair>
</Condition>
<Condition name="sessionproperties" type="SessionPropertyCondition">
<AttributeValuePair><Attribute name="valueCaseInsensitive"/>
<Value>true</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="a"/><Value>10</Value>
<Value>20</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="b"/><Value>15</Value>
<Value>25</Value>
</AttributeValuePair>
</Condition>
<Condition name="activesessiontime" type="SessionCondition">
<AttributeValuePair><Attribute name="TerminateSession"/>
<Value>session_condition_false_value</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="MaxSessionTime"/>
<Value>30</Value>
</AttributeValuePair>
</Condition>
<Condition name="authelevelle-nonrealmqualfied" 
           type="LEAuthLevelCondition">
<AttributeValuePair><Attribute name="AuthLevel"/>
<Value>2</Value>
</AttributeValuePair>
</Condition>
<Condition name="ipcondition" type="IPCondition">
<AttributeValuePair><Attribute name="DnsName"/>
<Value>*.iplanet.com</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="EndIp"/>
<Value>145.15.15.15</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="StartIp"/>
<Value>120.10.10.10</Value>
</AttributeValuePair>
</Condition>
<Condition name="authchain-realmqualfied"
          type="AuthenticateToServiceCondition">
<AttributeValuePair><Attribute name="AuthenticateToService"/>
<Value>/:ldapService</Value>
</AttributeValuePair>
</Condition>
<Condition name="auth to realm" 
      type="AuthenticateToRealmCondition">
<AttributeValuePair><Attribute name="AuthenticateToRealm"/>
<Value>/</Value>
</AttributeValuePair>
</Condition>
<Condition name="authlevelge-realmqualified"
      type="AuthLevelCondition">
<AttributeValuePair><Attribute name="AuthLevel"/>
<Value>/:2</Value>
</AttributeValuePair>
</Condition>
<Condition name="authchain-nonrealmqualfied" 
     type="AuthenticateToServiceCondition">
<AttributeValuePair><Attribute name="AuthenticateToService"/>
<Value>ldapService</Value>
</AttributeValuePair>
</Condition>
<Condition name="timecondition" type="SimpleTimeCondition">
<AttributeValuePair><Attribute name="EndTime"/>
<Value>17:00</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="StartTime"/>
<Value>08:00</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="EndDate"/>
<Value>2006:07:28</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="EnforcementTimeZone"/>
<Value>America/Los_Angeles</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="StartDay"/>
<Value>mon</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="StartDate"/>
<Value>2006:01:02</Value>
</AttributeValuePair>
<AttributeValuePair><Attribute name="EndDay"/>
<Value>fri</Value>
</AttributeValuePair>
</Condition>
</Conditions>
<ResponseProviders name="responseproviders"
       description="description">
<ResponseProvider name="idresponseprovidere" 
     type="IDRepoResponseProvider">
<AttributeValuePair>
<Attribute name="DynamicAttribute"/>
</AttributeValuePair>
<AttributeValuePair>
<Attribute name="StaticAttribute"/>
<Value>m=10</Value>
<Value>n=30</Value>
</AttributeValuePair>
</ResponseProvider>
</ResponseProviders>
</Policy>

策略 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。

使用 Access Manager 控制台创建常规策略

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

单击“策略”选项卡。

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

为策略添加名称和说明。

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

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

单击 “确定” 。

使用 Access Manager 控制台创建引用策略

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

在“策略”选项卡中单击“新建引用”。

为策略添加名称和说明。

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

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

单击 “确定” 。

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

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

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

为子领域创建策略

在 o=isp 中创建引用策略。有关引用策略的信息，参见修改引用策略过程。

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

找到子领域 example.com。

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

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

将策略导出到其他 Access Manager 实例

Access Manager 允许使用 amadmin 命令行工具来导出策略。这在您希望将多个现有策略移动到另一个 Access Manager 实例或者您希望检查以批量模式对现有策略所做的更改时非常有用。要导出策略，使用 amadmin 命令行实用程序将指定策略导出到文件。语法为：

amamdin - u username —w password —ofilename output_file.xml —t policy_data_file.xml

可以在策略名称中使用通配符 (*) 来匹配任意字符串。

以下是 policy_data_file.xml 的一个示例：

<?xml version="1.0" encoding="ISO-8859-1"?>

<!--
    Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved
    Use is subject to license terms.
-->

<!DOCTYPE Requests
    PUBLIC "-//iPlanet//Sun Java System Access Manager 6.2 Admin CLI DTD//EN"
    "/opt/SUNWam/dtd/amAdmin.dtd"
>>

<!--  CREATE REQUESTS -->

<!-- to export to file use option -ofilename fileName -->

<Requests>    

<RealmRequests >    
<RealmGetPolicies realm="/" >
<AttributeValuePair>
<Attribute name="policyName"/>
<Value>p*</Value>
</AttributeValuePair>
</RealmGetPolicies>
</RealmRequests>

<RealmRequests >    
<RealmGetPolicies realm="/" >
<AttributeValuePair>
<Attribute name="policyName"/>
<Value>g10</Value>
<Value>g11</Value>
</AttributeValuePair>
</RealmGetPolicies>

</RealmRequests>
<RealmRequests >    
<RealmGetPolicies realm="/realm1" >
<AttributeValuePair>
<Attribute name="policyName"/>
<Value>*</Value>
</AttributeValuePair>
</RealmGetPolicies>
</RealmRequests>

</Requests>

策略将导出到 Output_file.xml 文件。现在可以对包含在文件中的策略定义做出任何修改。在将策略导入到另一个 Access Manager 实例中之前，必须更改输出文件，使它与 amadmin 命令实用程序兼容。有关如何导入策略的说明，包括与 amadmin 兼容的策略数据文件的示例，参见使用 amadmin 创建策略

管理策略

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

修改常规策略

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

在常规策略中添加或修改规则

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

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

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

搜索服务

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

Liberty 个人配置文件服务

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

URL 策略代理

定义 URL 策略代理服务的授权操作。它用于定义保护 HTTP 和 HTTPS URL 的策略。这是 Access Manager 策略最常见的用途。

单击“下一步”。

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

目前，Access Manager 策略代理只支持 http:// 和 https:// 资源，而不支持使用 IP 地址代替主机名。

协议、主机、端口和资源名称都支持通配符。例如：
http*://*:*/*.html
对于“URL 策略代理”服务，如果未输入端口号，则 http:// 的默认端口号是 80，https:// 的默认端口号是 443。

为规则选择操作。根据服务类型，可选择以下选项：
- 查找（搜索服务）
- 更新（搜索服务）
- 修改（Liberty 个人配置文件服务）
- 查询（Liberty 个人配置文件服务）
- GET（URL 策略代理）
- POST（URL 策略代理）

选择操作值。
- 同意交互式操作 — 为了得到同意而对资源调用 Liberty 交互式操作协议。仅适用于 Liberty 个人配置文件服务类型。
- 交互式操作值 — 为了获得某个值而对资源调用 Liberty 交互式操作协议。仅适用于 Liberty 个人配置文件服务类型。
- 允许 — 允许您访问与规则中定义的资源相匹配的资源。
- 拒绝 — 拒绝您访问与规则中定义的资源相匹配的资源。
  
  在策略中，拒绝规则始终比允许规则具有优先权。例如，如果某种给定的资源存在两个策略，一个拒绝访问而另一个允许访问，结果为拒绝访问（假定两个策略的条件都满足）。建议谨慎使用拒绝策略，因为它们会导致策略间的潜在冲突。通常来说，在定义策略的过程中，应只使用允许规则，在没有策略适用于实现拒绝条件时使用默认的拒绝规则。
  
  当采用了显示拒绝规则时，即使一个或多个策略允许访问，通过多个不同主题（如角色和/或组成员资格）指定给给定用户的策略可能仍然会导致拒绝访问资源。例如，如果应用于“员工”角色的资源的策略为拒绝策略，而应用于“经理”角色的同一资源的策略为允许策略，则被分配了“员工”和“经理”两个角色的用户的策略决策将为拒绝。
  
  解决此问题的一个方法是使用条件插件来设计策略。在上述情况下，将拒绝策略应用于通过“员工”角色验证的用户并将允许策略应用于通过“经理”角色验证的用户的“角色条件”可以帮助区分两种策略。另一个方法是使用 authentication level 条件，其中“经理”角色在更高验证级别进行验证。

单击“完成”。

在常规策略中添加或修改主题

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

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

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

单击“下一步”。

输入主题的名称。

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

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

如果该策略中存在多个主题，至少要有一个主题表明该策略适用于给定的身份，策略才能应用到该身份。

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

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

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

单击“完成”。

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

向常规策略添加条件

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

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

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

定义条件类型字段。

单击“完成”。

向常规策略添加响应提供者

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

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

请输入响应提供者的名称。

定义以下值：

StaticAttribute

这是属性值格式的静态属性，在存储于策略中的 IDResponseProvider 实例中进行定义。

DynamicAttribute

应首先在相应领域的“策略配置服务”中定义此处所选择的响应属性。所定义的属性名称应为已配置数据存储库 (IDRepository) 中现有属性名称的子集。有关如何定义属性的详细信息，参见“策略配置”属性定义。要选择特定属性或多个属性，请按住 "Ctrl" 键并单击鼠标左键。

单击“完成”。

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

修改引用策略

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

在引用策略中添加或修改规则

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

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

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

搜索服务

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

Liberty 个人配置文件服务

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

URL 策略代理

定义 URL 策略代理服务的授权操作。它用于定义保护 HTTP 和 HTTPS URL 的策略。这是 Access Manager 策略最常见的用途。

单击“下一步”。

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

目前，Access Manager 策略代理只支持 http:// 和 https:// 资源，而不支持使用 IP 地址代替主机名。

协议、主机、端口和资源名称都支持通配符。例如：
http*://*:*/*.html
对于“URL 策略代理”服务，如果未输入端口号，则 http:// 的默认端口号是 80，https:// 的默认端口号是 443。

注 –
步骤 6 和 7 对引用策略不适用。

单击“完成”。

在策略中添加或修改引用项

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

在“引用”列表中，单击“新建”。

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

引用— 显示当前引用类型。

名称— 输入引用的名称。

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

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

值 —选择引用的领域名称。

单击“完成”。

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

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

向引用策略添加响应提供者

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

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

请输入响应提供者的名称。

定义以下值：

StaticAttribute

这是属性值格式的静态属性，在存储于策略中的 IDResponseProvider 实例中进行定义。

DynamicAttribute

应首先在相应领域的“策略配置服务”中定义此处所选择的响应属性。所定义的属性名称应为已配置数据存储库 (IDRepository) 中现有属性名称的子集。有关如何定义属性的详细信息，参见“策略配置”属性定义。要选择特定属性或多个属性，请按住 "Ctrl" 键并单击鼠标左键。

单击“完成”。

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

策略配置服务

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

主题结果的生存时间

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

动态属性

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

amldapuser 定义

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

添加策略配置服务

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

基于资源的验证

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

注 –

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

限制

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

如果适用于此资源的策略包含多个验证模块，系统将任意选择一个验证模块。
级别和模式是可为此策略定义的仅有的两个条件。
此功能在不同的 DNS 域中不起作用。

配置基于资源的验证

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

打开 AMAgent.properties。

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

注释掉以下行：

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

将以下行添加到文件：

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

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

重新启动代理。

第 6 章管理主题

“主题”界面启用领域中的基本身份管理。任何在“主题”界面中创建的身份都能在策略（以“Access Manager 身份主题”类型创建的策略）的主题定义中使用。

您可以创建和修改的身份包括：

用户

用户代表个体身份。可以在组中创建和删除用户，也可以在角色和/或组中添加或删除用户。还可以将服务指定给用户。

创建或修改用户

单击“用户”选项卡。

单击“新建”。

为以下字段输入数据：

用户 ID。此字段中应填入用户用来登录到 Access Manager 的名称。此属性可以是一个非 DN 值。

名字。此字段中应填入用户的名字。

姓氏。此字段中应填入用户的姓氏。

全名 — 此字段中应填入用户的全名。

密码— 此字段中应填入“用户 ID”字段中所指定名称的密码。

密码（确认）— 确认密码。

用户状态。此选项指示是否允许用户通过 Access Manager 进行验证。

单击“创建”。

创建用户之后，您可以单击用户的名称来编辑用户信息。有关用户属性的信息，参见“用户”属性。您可以进行的其他修改包括：

向角色和组添加用户

单击所要修改的用户的名称。

选择角色或组。仅显示已指定给用户的那些角色和组。

从“可用”列表中选择角色或组，然后单击“添加”。

当“选定”列表中显示所选的角色或组时，单击“保存”。

向身份添加服务

选择您要添加服务的身份。

单击“服务”选项卡。

单击“添加”。

根据您选择的身份类型，将显示以下服务列表：
- 验证配置
- 搜索服务
- Liberty 个人配置文件服务
- 会话
- 用户

选择您要添加的服务，然后单击“下一步”。

编辑服务的属性。有关服务的说明，请单击步骤 4 中服务的名称。

单击“完成”。

代理配置文件

Access Manager 策略代理对 Web 服务器和 Web 代理服务器上的内容提供保护以防止未授权的侵入。它们基于管理员配置的策略来控制对服务和 Web 资源的访问。

代理对象定义了“策略代理”配置文件，并允许 Access Manager 存储与保护 Access Manager 资源的特定代理有关的验证及其他配置文件信息。通过 Access Manager 控制台，管理员可以查看、创建、修改和删除代理配置文件。

可以在代理对象创建页面定义代理用于通过 Access Manager 进行验证的 UID/密码。如果有多个使用相同 Access Manager 设置的 Web 容器，您可以选择为不同的代理启用多个 ID 并且可以从 Access Manager 单独将其启用和禁用。您也可以集中管理代理的一些首选项值，而不必在每台计算机上都编辑 AMAgent.properties。

创建或修改代理

单击“代理”选项卡。

单击“新建”。

输入以下字段的值：

名称。输入代理的名称或身份。此名称是代理用来登录的名称。不接受多字节用户名称。

密码。输入代理的密码。此密码必须与在 LDAP 验证过程中代理所使用的密码不同。

确认密码。确认密码。

设备状态。输入代理的设备状态。如果设置为“活动”，则代理可以通过进行验证并与 Access Manager 进行通信。如果设置为“不活动”，则代理不能通过 Access Manager 进行验证。

单击“创建”。

创建代理之后，您可以另外编辑以下字段：

说明。输入代理的简短说明。例如，可以输入代理实例名称或其保护的应用程序的名称。

代理关键字值。使用关键字/值对设置代理属性。Access Manager 使用此属性接收有关用户的证书声明的代理请求。当前仅一个属性有效，所有其他属性都将被忽略。请使用以下格式：

agentRootURL=protocol:// hostname:port/

条目必须准确，而且 agentRootURL 区分大小写。

protocol

代表所使用的协议，即 HTTP 或 HTTPS。

hostname

代表代理所驻留的计算机的主机名。此计算机也托管由代理保护的资源。

port

代表安装代理的端口号。代理侦听此端口上的接收通信，并拦截所有要访问主机资源的请求。

配置 Access Manager 以防止 Cookie 劫持

Cookie 劫持就是指冒名顶替者（可能是使用不可信应用程序的黑客）对 cookie 进行未授权的访问。如果被劫持的 cookie 是会话 cookie，则根据系统的配置方式，cookie 劫持可能增加对受保护 Web 资源的未授权访问威胁。

Sun 文档提供标题为“Precautions Against Session-Cookie Hijacking in an Access Management Deployment”（在访问管理部署中防止会话 Cookie 劫持的预防措施）的技术说明，该说明介绍要对抗与会话 cookie 劫持相关的特定安全威胁可采取的预防措施参见以下文档：

《Technical Note: Precautions Against Cookie Hijacking in an Access Manager Deployment》

过滤的角色

过滤的角色是用 LDAP 过滤器创建的动态角色。在创建角色时，会通过过滤器过滤所有用户并为其指定该角色。过滤器会查找条目中的所有属性值对（例如，ca=user*），并自动将包含该属性的用户指定给角色。

创建过滤的角色

在“浏览”窗格中，找到要在其中创建角色的组织。

单击“新建”。

输入过滤的角色的名称。

输入搜索条件信息。

例如，
(&(uid=user1)(|(inetuserstatus=active)(!(inetuserstatus=*))))
如果过滤器保留为空，将默认创建以下角色：
(objectclass = inetorgperson)

单击“创建”以基于过滤条件启动搜索。由过滤条件定义的身份将会自动指定给角色。

创建过滤的角色后，单击角色的名称可查看属于该角色的“用户”。此外，还可以通过单击“服务”选项卡将服务添加到角色。

角色

角色的成员是指拥有该角色的 LDAP 条目。角色本身的条件被定义为具有属性的 LDAP 条目，由条目的标识名 (Distinguished Name, DN) 属性来标识。创建角色之后，请手动添加服务和用户。

创建或修改角色

单击“角色”选项卡。

在“角色”列表中单击“新建”。

输入角色的名称。

单击“创建”。

向角色或组添加用户

单击要为其添加用户的角色或组的名称。

单击“用户”选项卡。

从“可用”列表中选择您要添加的用户，并单击“添加”。

当“选定”列表中显示所选的用户时，单击“保存”。

组

组代表具有共同功能、特性或利益的用户集合。通常来说，这种分组不会涉及权限。组可存在于两个级别，分别是组织和其他受管组中。

创建或修改组

单击“组”选项卡。

在“组”列表中单击“新建”。

输入组的名称。

单击“创建”。

创建组之后，您可以单击组的名称，然后单击“用户”选项卡，将用户添加到组。

第 1 部分 访问控制

第 1 章 Access Manager 控制台

管理视图

领域模式控制台

图 1–1 领域模式管理视图

传统模式控制台

图 1–2 传统模式管理视图

传统模式 6.3 控制台

图 1–3 基于传统 6.3 的控制台

用户概要文件视图

图 1–4 用户概要文件视图

第 2 章 管理领域

创建和管理领域

创建新的领域

常规属性

验证

服务

向领域添加服务

权限

定义 Access Manager 7.1 的权限

为从 Access Manager 7.0 升级到 7.1 定义权限

第 3 章 数据存储库

Access Manager 数据存储库类型

Access Manager 系统信息库插件

活动目录

平面文件系统信息库

普通 LDAPv3

使用 Access Manager 模式的 Sun Directory Server

创建新的数据存储库

数据存储库属性

Access Manager 系统信息库属性

类名称

Access Manager 支持的类型和操作

组织 DN 值

人员容器命名属性

人员容器值

代理容器命名属性

代理容器值

递归搜索

复制领域配置

平面文件系统信息库属性

文件系统信息库插件类名称

文件系统信息库目录

高速缓存

更新高速缓存的时间

文件用户对象类

密码属性

状态属性

散列的属性

加密的属性

LDAPv3 属性

LDAP 服务器

LDAP 绑定 DN

LDAP 绑定密码

LDAP 绑定密码（确认）

LDAP 组织 DN

LDAP SSL

LDAP 连接池的最小尺寸

LDAP 连接池的最大尺寸

搜索返回的结果的最大数目

搜索超时

LDAP 遵循引用

LDAPv3 系统信息库插件类名称

常规属性名称映射

LDAPv3 插件支持的类型和操作

LDAPv3 插件搜索范围

LDAP 用户搜索属性

LDAP 用户搜索过滤器

LDAP 用户对象类

LDAP 用户属性

LDAP 用户创建属性映射

用户状态属性

用户状态活动值

用户状态非活动值

LDAP 组搜索属性

LDAP 组搜索过滤器

LDAP 组容器命名属性

LDAP 组容器值

LDAP 组对象类

LDAP 组属性

第 1 部分访问控制

第 2 章管理领域

第 3 章数据存储库

第 4 章管理验证