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

第 II 部分 访问控制

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

第 4 章 Access Manager 控制台

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

管理视图

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

领域模式控制台

“领域”模式控制台允许管理员管理基于领域的访问控制、默认服务配置、Web 服务和联合。要访问管理员登录屏幕,请在浏览器中使用以下地址语法:

protocol://servername /amserver/UI/Login

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

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

Access Manager 控制台,领域模式管理视图

传统模式控制台

“传统模式”控制台是基于 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,具体取决于您的部署。

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

Access Manager 控制台,传统模式管理视图

传统模式 6.3 控制台

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


注 –

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


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

protocol://servername /amconsole

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

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

 基于 Access Manager 传统模式 6.3 的控制台

用户概要文件视图

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

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

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

Access Manager 控制台 — 用户概要文件视图

第 5 章 管理领域

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

有关领域的详细信息,请参阅《Sun Java System Access Manager 7 2005Q4 Technical Overview》

在“领域”选项卡中,可以配置访问控制的以下属性:

创建和管理领域

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

Procedure创建新的领域

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

  2. 定义以下常规属性:

    名称

    输入领域名称。

    父领域

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

  3. 定义以下领域属性:

    领域状态

    选择“活动”状态或“不活动”状态。 默认值为“活动”。在领域的生命期内,可以随时通过选择“属性”图标来更改其状态。如果选择“不活动”,则当登录时,将禁止用户访问。

    领域/DNS 别名

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

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

常规属性

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

领域状态

选择“活动”状态或“不活动”状态。 默认值为“活动”。在领域的生命期内,可以随时通过选择“属性”图标来更改其状态。如果选择“不活动”,则当登录时,将禁止用户访问。

领域/DNS 别名

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

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

验证

在用户可以使用其他验证模块登录之前,常规验证服务必须注册为领域的服务。核心验证服务允许 Access Manager 7 管理员为领域的验证参数定义默认值。如果在指定的验证模块中没有定义覆盖值,则可以使用这些值。“核心验证服务”的默认值在 amAuth.xml 文件中进行定义,安装结束后将保存在 Directory Server 中。

有关详细信息,请参阅第 7 章,管理验证

服务

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

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


注 –

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


Procedure将服务添加到领域

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

  2. 选择“服务”选项卡。

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

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

  5. 单击“下一步”。

  6. 通过定义领域属性来配置服务。有关服务属性的说明,请参阅联机帮助中的“配置”。

  7. 单击“完成”。

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

权限

权限定义领域中现有的角色或组的访问权限。这些角色或组可用作“Access Manager 身份主题”类型的策略主题定义。单击您要进行编辑的角色或组的名称,可指定或修改权限。您可以指定的权限包括:

第 6 章 数据存储库

数据存储库是一个可用来存储用户属性和用户配置数据的数据库。

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

LDAPv3 数据存储库

当在“领域”和“传统”模式下安装 Access Manager 时,可以为任何普通 LDAPv3 库创建新的数据存储库实例。应该在以下条件下选择 LDAPv3 库类型:

Procedure创建新的 LDAPv3 数据存储库

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

步骤
  1. 选择要为其添加新的数据存储库的领域。

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

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

  4. 输入数据存储库的名称。

  5. 定义 LDAPv3 库插件的属性。

  6. 单击“完成”。

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 服务器设置和任务移除以上权限,但不能添加其他权限。

LDAP 用户搜索属性

该字段用于定义搜索用户时使用的属性类型。例如,如果用户的 DN 为 uid=k user5,ou=people,dc=iplanet,dc=com,则命名属性为 uid。(uid=*) 将附加到用户的搜索过滤器中。

LDAP 用户搜索过滤器

指定用于查找用户条目的搜索过滤器。例如,如果 LDAP 用户搜索属性为 uid 并且 LDAP 用户搜索过滤器为 (objectClass=inetorgperson),则实际用户搜索过滤器为: (&(uid=*)(objectClass=inetorgperson))

LDAP 用户对象类

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

LDAP 用户属性

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

LDAP 组搜索属性

该字段用于定义搜索组时使用的属性类型。例如,如果组 DN 为 cn=group1,ou=groups,dc=iplanet,dc=com,则组的命名属性为 cn,并且 (cn=*) 将附加到组搜索过滤器中。

LDAP 组搜索过滤器

指定用于查找组条目的搜索过滤器。例如,如果 LDAP 组搜索属性为 cn 并且 LDAP 组搜索过滤器为 (objectclass=groupOfUniqueNames),则实际组搜索过滤器为 (&(cn=*)(objectclass=groupOfUniqueNames))

LDAP 组容器命名属性

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

LDAP 组容器值

指定组容器的值。例如,组 DN cn=group1,ou=groups,dc=iplanet,dc=com 驻留在容器名称 ou=groups中,则组容器值将为 groups

LDAP 组对象类

指定组的对象类。创建组之后,此组对象类列表将被添加到组的属性列表中。

LDAP 组属性

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

组成员资格的属性名称

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

组成员的属性名称

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

组成员 URL 的属性名称

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

LDAP 人员容器命名属性

如果用户驻留在人员容器中,则指定该人员容器的命名属性。如果用户没有驻留在人员容器中,则将该字段保留为空。例如,假设用户 DN 为 uid=kuser5,ou=people,dc=iplanet,dc=com,如果人员容器的名称为 ou=people,则命名属性为 ou

LDAP 人员容器值

指定人员容器的值。默认值为 people。例如,假设用户 DN 为 uid=kuser5,ou=people,dc=iplanet,dc=com,如果人员容器的名称为 ou=people,则命名属性为 ou 并且“LDAP 人员容器值”为 people

LDAP 代理搜索属性

该字段用于定义搜索代理时使用的属性类型。默认值为 uid。例如,如果代理的 DN 为 uid=kagent1,ou=agents,dc=iplanet,dc=com,则代理的命名属性为 uid。(uid=*) 将附加到代理的搜索过滤器中。

LDAP 代理容器命名属性

如果代理驻留在代理容器中,则指定该代理容器的命名属性。如果代理没有驻留在代理容器中,则将该字段保留为空。例如,假设用户 DN 为 uid=kagent1,ou=agents,dc=iplanet,dc=com,则代理命名属性为 ou

LDAP 代理容器值

指定代理容器的值。如果代理没有驻留在代理容器中,则将该字段保留为空。在前面的示例中,代理容器值为 agents

LDAP 代理搜索过滤器

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

例如,如果“LDAP 代理搜索属性”为 uid 并且“LDAP 用户搜索过滤器”为 (objectClass=sunIdentityServerDevice),则实际用户搜索过滤器为:(&(uid=*)(objectClass=sunIdentityServ erDevice))

LDAP 代理对象类

定义代理的对象类。创建代理之后,用户对象类的列表将被添加到代理的属性列表中。

LDAP 代理属性

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

持久搜索基本 DN

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

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

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

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

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

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

重试之间的延时

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

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

指定可以重试持久搜索操作的错误代码。该属性仅适用于持久搜索,而非所有 LDAP 操作。

AMSDK 库插件

当在“传统”模式下安装 Access Manager 时,AMSDK 身份库会自动与 Access Manager 信息树混合。在“领域”模式下,可以选择安装 AMSDK 库,但身份库不会与 Access Manager 信息树混合。应该在以下条件下选择 AMSDK 库类型:

Procedure创建新的 AMSDK 库插件

步骤
  1. 选择要在其中配置 Access Manager 库插件的领域。

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

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

  4. 输入库插件的名称。

  5. 选择“Access Manager 库插件”。

  6. 单击“下一步”。

  7. 定义以下字段:

    Access Manager 插件类名称

    指定实现 Access Manager 库插件的类文件的位置。

    Access Manager 组织

    指向 Directory Server 中由 Access Manager 管理的某组织 DN。它将成为在此数据存储库中执行的所有操作的基本 DN。

  8. 单击“完成”。

第 7 章 管理验证

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

配置验证

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

验证模块类型

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


注 –

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


核心

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

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

活动目录

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


注 –

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


匿名

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

证书

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

将基于证书的验证模块添加到领域之前,需要完成许多操作。首先,需要确保与 Access Manager 一起安装的 Web 容器正常运行,并配置此 Web 容器使其适用于基于证书的验证。启用基于证书的模块之前,请参阅《Sun ONE Web Server 6.1 管理员指南》中的第 6 章“使用证书和密钥”,了解有关 Web 服务器的初始配置步骤。可以在以下位置找到此文档:

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

或参阅以下位置的 Sun ONE Application Sever Administrator’s Guide to Security

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


注 –

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


要添加此模块,必须作为领域管理员登录 Access Manager,将 Access Manager 和 Web 容器配置为 SSL,并且启用客户机验证。有关详细信息,请参阅第 3 章,在 SSL 模式下配置 Access Manager

HTTP Basic

此模块使用基本验证,该验证是 HTTP 协议的内置验证支持。Web server 发出对用户名和密码的客户机请求,并将这些信息作为已验证的请求的一部分发送回服务器。Access Manager 将检索用户名和密码,然后在内部根据 LDAP 验证模块验证用户。为使 HTTP Basic 正常工作,还必须添加 LDAP 验证模块(只添加 HTTP Basic 模块将无法正常工作)。用户成功进行验证后,可以在不提供用户名和密码的情况下重新进行验证。

JDBC

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


注 –

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


LDAP

有了 LDAP 验证模块,用户登录时必须用特定用户 DN 和密码绑定至 LDAP 目录服务器。这是适用于所有基于领域的验证的默认验证模块。如果用户提供了 Directory Server 中的用户 ID 和密码, 则建立并允许用户访问有效的 Access Manager 会话。对于默认领域,核心验证模块和 LDAP 验证模块自动启用

成员资格

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

MSISDN

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

RADIUS

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

  1. 配置 RADIUS 服务器。

    有关详细说明,请参阅 RADIUS 服务器文档。

  2. 注册和启用 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

主机可以表示为 DNS 名称、数字 IP 地址或 localhost(对于本地计算机)。可以在指定的 DNS 主机名中包含一处通配符“*”。如果包含该通配符,它必须在最左侧的位置,如 *.example.com

端口(或端口范围)是可选的。形式为 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 连接权限。为使 SafeWord 验证正常工作,对于以下操作应授予权限:

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

host = (hostname | IPaddress)[:portrange] portrange = 

portnumber | -portnumberportnumber-[portnumber]

主机可以表示为 DNS 名称、数字 IP 地址或 localhost(对于本地计算机)。可以在指定的 DNS 主机名中包含一处通配符“*”。如果包含该通配符,它必须在最左侧的位置,如 *.example.com

端口(或 portrange)是可选的。形式为 N- 的端口规范(其中 N 为端口号)表示编号为 N 及以上的所有端口。形式为 -N 的规范表示编号为 N 及以下的所有端口。

侦听操作仅在与本地主机一起使用时才有意义。存在其他任意操作时,都暗含解析(解析主机/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

安全声明标记语言 (SAML) 验证模块接收和验证目标服务器上的 SAML 声明。SAML SSO 仅在目标机器上配置了此模块后才会工作,包括升级后(例如从 Access Manager 2004Q2 升级到 Access Manager 2005Q1)。

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 运行,或以超级用户 (root) 以外的用户 ID 运行,AccessManager-base/SUNWam/share/bin/amsecuridd 进程必须仍以超级用户身份操作。有关 amsecuridd 帮助器的详细信息,请参阅第 20 章,amsecuridd 帮助器


注 –

在此发行版本的 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 运行,或以超级用户外 (root) 以外的用户 ID 运行,AccessManager-base/SUNWam/share/bin/amunixd 进程必须仍以超级用户身份操作。Unix 验证模块通过打开到 localhost:58946 的套接字调用 amunixd 守护进程以侦听 Unix 验证请求。要在默认端口上运行 amunixd 帮助器进程,请输入以下命令:

./amunixd

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

./amunixd [-c portnm] [ipaddress]

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

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

Windows 桌面 SSO

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

用户通过 SPNEGO(简单且受保护的 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 令牌,因为 SPNEGO 在 Solaris 上不受支持。


注 –

必须使用 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://support.microsoft.com/default.aspx?scid=kb;en-us;308074

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

配置 Windows 桌面 SSO

启用 Windows 桌面 SSO 验证分为两个步骤:

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

  2. 设置 Internet Explorer。

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

步骤
  1. 在域控制器中,为 Access Manager 验证模块创建用户帐户。

    1. 从“开始”菜单中,转至“程序”>“管理工具”。

    2. 选择“活动目录用户”和“计算机”。

    3. 以 Access Manager 主机名作为用户 ID(登录名)创建新用户。Access Manager 主机名不应该包含域名。

  2. 在用户帐户与服务提供者名称间建立关联,并将键表文件导出至装有 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 命令接受以下参数:

    hostname。运行 Access Manager 的主机名(不含域名)。

    domainname。Access Manager 的域名。

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

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

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


    注 –

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


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

    服务负责人: HTTP/machine1.EXAMPLE.COM@ISQA.EXAMPLE.COM

    Keytab 文件名:/tmp/machine1.HTTP.keytab

    Kerberos 领域: ISQA.EXAMPLE.COM

    Kerberos 服务器名:machine2.EXAMPLE.com

    返回带有域名的负责人:false

    验证级别: 22

  3. 重新启动服务器。

Procedure设置 Internet Explorer

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

步骤
  1. 在“工具”菜单中,转至“Internet 选项”>“高级”/”安全”>“安全”。

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

  3. 转至“安全”>“本地 Intranet”。

    1. 选择“自定义级别”。在“用户验证/登录”面板中,选择“只在 Intranet 区域自动登录”选项。

    2. 转到“站点”并选择所有选项。

    3. 单击“高级”,将 Access Manager 添加到本地区域(如果尚未添加)。

Windows NT

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

  1. 配置 NT 服务器。有关详细信息,请参阅 Windows NT server 文档。

  2. 在添加和启用 Windows NT 验证模块之前,必须获取并安装 Samba 客户机,以与 Solaris 系统上的 Access Manager 进行通信。

安装 Samba 客户机

要激活 Windows NT 验证模块,必须下载 Samba 客户机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

为了使用 Windows NT 验证模块为 Linux 进行验证,请将客户机二进制文件复制到以下 Access Manager 目录:

AccessManager-base/sun/identity/bin

注 –

如果有多个界面,则需要额外配置。smb.conf 文件中的配置可以设置多个界面,以便传递到 mbclient


验证模块实例

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

Procedure创建新的验证模块实例

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

  2. 选择“验证”选项卡。


    注 –

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


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

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

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

  6. 单击“创建”。

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

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

验证链

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

Procedure创建新的验证链

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

  2. 选择“验证”选项卡。

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

  4. 输入验证链名称。

  5. 单击“创建”。

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

  7. 为验证链选择标准。这些标志建立了其定义的验证模块的执行标准。执行具有层次结构。“必需”位于最高层,“可选”位于最底层:

    必要

    要求模块实例必须成功。如果验证成功,将继续“验证链”列表中的下一个验证模块。如果验证失败,控制立即返回到应用程序(不继续“验证链”列表中的下一个验证模块)。

    必需

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

    充足

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

    可选

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

  8. 输入验证链的选项。这启用了模块的其他选项,格式为“关键字=值”对。多个选项之间用空格分隔。

  9. 定义以下属性:

    成功登录 URL

    指定用户在验证成功后,重新指向的 URL。

    登录失败 URL

    指定用户在验证失败后,重新指向的 URL。

    验证后期处理类

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

  10. 单击“保存”。

验证类型

“验证服务”提供了几种不同的验证方法。可通过指定登录 URL 参数或通过验证 API 来使用这些不同的验证方法《Sun Java System Access Manager 7 2005Q4 Developer’s Guide》中的第 5  章 “Using Authentication APIs and SPIs”一书的第 5 章,“Using Authentication APIs and SPIs”)。在能够配置验证模块之前,必须先修改核心验证服务属性“领域验证模块”以包含特定的验证模块名称。

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

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

验证类型如何确定访问

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

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

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

  2. 完成验证后期处理 SPI 的执行。

    “核心验证模块”包含一个“验证后期处理类”属性,该属性可以把验证后期处理类的名称作为自己的值。AMPostAuthProcessInterface 是后期处理接口。它可以在验证成功、验证失败或注销后执行。

  3. 以下属性会被添加或更新到会话标记中,并且用户会话会被激活。

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

    负责人。这是用户的 DN。

    多个负责人。这是用户已经验证的名称的列表。(此属性可以有多个值,各值之间以管道符分隔。)

    用户 ID。这是模块返回的用户 DN,如果模块不是“LDAP”或“成员资格”,则为用户名。(所有的“负责人”必须映射到同一用户。用户 ID 是它们映射到的用户 DN。)


    注 –

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


    UserToken。这是一个用户名。(所有的“负责人”必须映射到同一用户。UserToken 是它们映射到的用户名。)

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

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

    AuthType。这是用户已经验证的验证模块的管道符分隔列表(例如module1|module2|module3)

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

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

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

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

    服务。仅适用于基于服务的验证,这是用户所属的服务。

  4. 验证成功或失败后,会在该 URL 中查找信息,以重定向用户。

    URL 重定向可以是一个 Access Manager 页面或 URL。重定向取决于 Access Manager 根据验证方法查找重定向的优先顺序,以及验证是成功还是失败。此顺序在以下验证方法章节的 URL 重定向部分有详细描述。

URL 重定向

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

基于领域的验证

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

基于领域的验证登录 URL

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

  1. domain 参数。

  2. realm 参数。

  3. “管理服务”中的 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 中指定的域确定领域。

基于领域的验证重定向 URL

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

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

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

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 (amUser.xml) iplanet-am-user-success-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。

  7. 用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。

  8. 用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  9. 用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  10. iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

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

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

  1. 验证模块设置的 URL。

  2. gotoOnFail 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户条目 ( amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-user-failure-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-user-failure-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

  7. 为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  8. 为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  9. 为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  10. iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

配置基于领域的验证

领域的验证模块是在首次将核心验证服务添加到该领域时设置的。

Procedure配置领域的验证属性

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

  2. 单击“验证”选项卡。

  3. 从下拉菜单中选择“默认验证链”。

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

  5. 定义验证链之后,单击“保存”。

基于组织的验证

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

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

基于组织的验证登录 URL

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

  1. domain 参数。

  2. org 参数。

  3. “管理服务”中的 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 指定的域确定组织。

基于组织的验证重定向 URL

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

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

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

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 (amUser.xml) iplanet-am-user-success-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  5. clientType 自定义文件中为用户组织条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。

  7. 用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。

  8. 用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  9. 用户组织条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  10. iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

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

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

  1. 验证模块设置的 URL。

  2. gotoOnFail 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户条目 ( amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-user-failure-url 属性设置的 URL。

  5. clientType 自定义文件中为用户组织条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

  7. 为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  8. 为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  9. 为用户组织条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  10. iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

配置基于组织的验证

组织的验证模块是在首次将核心验证服务添加到该组织时设置的。

Procedure配置组织的验证属性

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

  2. 单击“验证”选项卡。

  3. 从下拉菜单中选择“默认验证链”。

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

  5. 定义验证链之后,单击“保存”。

基于角色的验证

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


注 –

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


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

冲突解决级别。此属性为可能包含相同用户的两个不同角色定义的验证配置服务实例设置优先级级别。例如,如果 User1 同时分配给 Role1Role2,则可以为 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 通过按以下顺序检查以下位置来确定:

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 ( amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。

  4. clientType 自定义文件中为用户已经验证的角色的 iplanet-am-auth-login-success-url 属性设置的 URL。

  5. clientType 自定义文件中为已验证用户的另一个角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。(如果以前的重定向 URL 失败,此选项是一个替代方法。)

  6. clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  7. clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。

  8. 用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。

  9. 用户已验证角色的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  10. 已验证用户的另一个角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。(如果以前的重定向 URL 失败,此选项是一个替代方法。)

  11. 用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  12. iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

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

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

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 ( amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  4. clientType 自定义文件中为用户已验证的角色的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  5. clientType 自定义文件中为已验证用户的另一个角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。(如果以前的重定向 URL 失败,此选项是一个替代方法。)

  6. clientType 自定义文件中为用户领域条目的 iplanet-am-user-failure-url 属性设置的 URL。

  7. clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

  8. 用户概要文件 (amUser.xml)iplanet-am-user-failure-url 属性中设置的 URL。

  9. 用户已验证角色的 iplanet-am-auth-login-failure-url 属性中设置的 URL。

  10. 已验证用户的另一个角色的 iplanet-am-auth-login-failure-url 属性中设置的 URL。(如果以前的重定向 URL 失败,此选项是一个替代方法。)

  11. 用户领域条目的 iplanet-am-auth-login-failure-url 属性中设置的 URL。

  12. iplanet-am-auth-login-failure-url 属性中设置的作为全局默认值的 URL。

Procedure配置基于角色的验证

步骤
  1. 找到要在其中添加验证配置服务的领域(或组织)。

  2. 单击“主题”选项卡。

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

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

    如果“验证配置”服务还没有添加到此角色,请单击“添加”,选择“验证服务”,然后单击“下一步”。

  5. 从下拉菜单中选择要启用的“默认验证链”。

  6. 单击“保存”。


    注 –

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

    如果启用了基于角色的验证,可以将 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

e

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

基于服务的验证重定向 URL

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

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

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

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 ( amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。

  4. clientType 自定义文件中为用户已验证服务的 iplanet-am-auth-login-success-url 属性设置的 URL。

  5. clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  6. clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  7. clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。

  8. 用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。

  9. 用户已验证服务的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  10. 用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  11. 用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  12. iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

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

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

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 ( amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  4. clientType 自定义文件中为用户已验证服务的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  5. clientType 自定义文件中为用户角色条目的 iplanet-am-user-failure-url 属性设置的 URL。

  6. clientType 自定义文件中为用户领域条目的 iplanet-am-user-failure-url 属性设置的 URL。

  7. clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

  8. 用户概要文件 (amUser.xml) 的 iplanet-am-user-failure-url 属性中设置的 URL。

  9. 用户已验证服务的 iplanet-am-auth-login-failure-url 属性中设置的 URL。

  10. 用户角色条目的 iplanet-am-auth-login-failure-url 属性中设置的 URL。

  11. 用户领域条目的 iplanet-am-auth-login-failure-url 属性中设置的 URL。

  12. iplanet-am-auth-login-failure-url 属性中设置的作为全局默认值的 URL。

Procedure配置基于服务的验证

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

步骤
  1. 选择要配置基于服务的验证的领域。

  2. 单击“验证”选项卡。

  3. 创建验证模块实例。

  4. 创建验证链。

  5. 单击“保存”。

  6. 要访问领域的基于服务的验证,请输入以下地址:

    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 通过按优先顺序检查以下位置来确定:

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 (amUser.xml) iplanet-am-user-success-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。

  7. 用户概要文件 (amUser.xml) 的 iplanet-am-user-success-url 属性中设置的 URL。

  8. 用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  9. 用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  10. iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

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

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

  1. 验证模块设置的 URL。

  2. gotoOnFail 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户条目 ( amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-user-failure-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-user-failure-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

  7. 为用户条目 (amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  8. 为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  9. 为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  10. iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

Procedure配置基于用户的验证

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

  2. 单击“主题”选项卡,然后单击“用户”。

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

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


    注 –

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


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

  5. 单击“保存”。

基于验证级别的验证

每个验证模块均可以与其验证级别的整数值相关联。单击“服务配置”中验证模块的属性箭头,然后更改模块的“验证级别”属性相应的值,可以指定验证级别。用户通过验证,获得了对一个或多个验证模块的访问权时,验证级别越高,则它为该用户定义的信任级别就越高。

用户成功地通过模块的验证之后,系统将在用户的 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 通过按优先顺序检查以下位置来确定:

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 ( amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。

  7. 用户概要文件 (amUser.xml)iplanet-am-user-success-url 属性中设置的 URL。

  8. 用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  9. 用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  10. iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

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

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

  1. 验证模块设置的 URL。

  2. gotoOnFail 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户条目 ( amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-user-failure-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-user-failure-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

  7. 为用户条目 (amUser.xml)iplanet-am-user-failure-url 属性设置的 URL。

  8. 为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  9. 为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  10. 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

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

基于模块的验证重定向 URL

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

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

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

  1. 验证模块设置的 URL。

  2. goto 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户概要文件 ( amUser.xml) 的 iplanet-am-user-success-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-auth-login-success-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-success-url 属性设置的作为全局默认值的 URL。

  7. 用户概要文件 (amUser.xml)iplanet-am-user-success-url 属性中设置的 URL。

  8. 用户角色条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  9. 用户领域条目的 iplanet-am-auth-login-success-url 属性中设置的 URL。

  10. iplanet-am-auth-login-success-url 属性中设置的作为全局默认值的 URL。

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

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

  1. 验证模块设置的 URL。

  2. gotoOnFail 登录 URL 参数设置的 URL。

  3. clientType 自定义文件中为用户条目 ( amUser.xml) 的 iplanet-am-user-failure-url 属性设置的 URL。

  4. clientType 自定义文件中为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  5. clientType 自定义文件中为用户领域条目的 iplanet-am-user-failure-url 属性设置的 URL。

  6. clientType 自定义文件中为 iplanet-am-auth-login-failure-url 属性设置的作为全局默认值的 URL。

  7. 为用户角色条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  8. 为用户领域条目的 iplanet-am-auth-login-failure-url 属性设置的 URL。

  9. 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 中并键入 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 参数

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


注 –

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

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

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

org 参数

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


注 –

尚未成为指定域/组织成员的用户如果试图使用 org 参数进行验证,会收到一则错误消息。如果以下所有条件均成立,则可在 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 参数使指定语言环境的优先级高于其他定义的语言环境。在以下位置按特定顺序搜索配置之后,客户机会显示登录语言环境:

  1. 登录 URL 中的 locale 参数值

    locale=localeName 参数的值的优先级高于所有其他定义的语言环境。

  2. 用户概要文件中定义的语言环境

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

  3. HTTP 标题中定义的语言环境

    此语言环境由 Web 浏览器设置。

  4. “核心验证服务”中定义的语言环境

    这是“核心验证”模块中“默认验证语言环境”属性的值。

  5. “平台”服务中定义的语言环境

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

操作系统语言环境

从此等级派生的语言环境存储在用户的会话令牌中,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.

注 –

尚未成为指定域/领域成员的用户如果试图使用 org 参数进行验证,会收到一则错误消息。如果以下所有条件均成立,则可在 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.Token0Login.Token1...Login.TokenN(来自先前的版本)仍受支持,但在以后的版本中将不再受支持。建议使用新的 IDTokenN 参数。


帐户锁定

“验证服务”提供这样一项功能:在验证失败 n 次后将锁定用户。此功能默认情况下是关闭的,但是可以使用 Access Manager 控制台启用它。


注 –

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


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

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


注 –

有关在 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 的值来启用内存锁定。在指定的分钟数内将在内存中锁定用户帐户。帐户将在过了该时间段之后解除锁定。以下是使用内存锁定功能时的一些特殊注意事项:


注 –

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


验证服务故障转移

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

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

  1. 验证服务 URL 将被传递给 AuthContext API。例如:


    AuthContext(orgName, url)

    如果使用此 API,则它将仅使用由 URL 所引用的服务器。即使在该服务器中提供了验证服务,也不会进行故障转移。

  2. 验证环境将检查在 AMConfig.properties 文件的 com.iplanet.am.server* 属性中定义的服务器。

  3. 如果步骤 2 失败,则验证环境将从提供有命名服务的服务器查询平台列表。此平台列表是在安装共享同一个 Directory Server 实例的多个 Access Manager 实例(通常是为故障转移目的)时自动创建的。

    例如,如果该平台列表包含 Server1Server2Server3 的 URL,则验证环境会在 Server1 Server2Server3 之间循环,直到在其中一个服务器上验证成功为止。

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

全限定域名映射

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

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 属性中配置的默认服务器名称。


示例 7–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、领域名称、验证模块名称、最长会话时间、空闲时间和高速缓存时间。

Procedure启用持久 Cookie

步骤
  1. 在核心验证模块中打开持久 Cookie 模式

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

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

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

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

    AMLoginModule.setPersistentCookieOn()

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

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

Procedure添加其他 LDAP 配置

步骤
  1. 编写一个 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>
    
    
    
    
    
                   
  2. 将纯文本密码作为在步骤 1 中创建的 XML 文件中的 iplanet-am-auth-ldap-bind-passwd 的值进行复制。

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

  3. 使用 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。超时值取决于:

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

验证插件接口

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

Procedure编写和配置验证插件

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

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

  3. 以顶级管理员身份登录 Access Manager 控制台。单击“服务管理”选项卡,访问管理服务的属性。在用户 ID 和密码验证插件类字段中键入插件类的名称(包括软件包的名称)。

  4. 注销,然后登录。

JAAS 共享状态

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

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

启用 JAAS 共享状态

配置 JAAS 共享状态:

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

JAAS 共享状态存储选项

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

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

第 8 章 管理策略

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

本章包括以下内容:

概述

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


注 –

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


单个策略能定义二进制或非二进制的决策。二进制决策为 yes/notrue/ falseallow/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 中的 ReferralRuleResourceNameSubjectConditionAttributeValue


可以添加的默认条件是:

验证级别

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

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

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

对于“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()

如果条件不满足,则只有 AuthLevelCondiitonAuthSchemeCondition 提供建议。

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 ConditionsSubjectsReferralsresponse providers。所需 XML 属性是 name,它指定策略的名称。属性 referralPolicy 指明策略是否为候选策略;如果未定义,则它默认为标准策略。可选 XML 属性包括 namedescription


注 –

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


Rule 元素

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


注 –

已定义的策略也可以不包括定义的 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 元素的子元素。它包含 AttributeValue 元素但没有 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 属性包括定义集合名称的 nameincludeType,后者规定集合是否如定义的那样,用于确定策略是否用于“不”属于该主题成员的用户。


注 –

定义了多个主题时,要使策略得以应用,至少要有一个主题应该应用于用户。将 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 角色;以及创建子领域或对等领域候选项时存在相关领域。

    请注意,SubrealmReferralPeerRealmReferralRealm 主题、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. 重新启动代理。

第 9 章 管理主题

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

你可以创建和修改的身份包括:

用户

用户代表个体身份。可以创建或删除组的用户,也可以从角色和/或组添加或移除用户。此外,还可以将服务指定给用户。

Procedure创建或修改用户

步骤
  1. 单击“用户”选项卡。

  2. 单击“新建”。

  3. 为以下字段输入数据:

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

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

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

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

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

    密码(确认) —确认密码。

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

  4. 单击“创建”。

  5. 创建用户之后,您可以单击用户的名称来编辑用户信息。有关用户属性的信息,请参阅“用户”属性。您可以进行的其他修改包括:

Procedure将用户添加到角色和组

步骤
  1. 单击所要修改的用户的名称。

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

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

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

Procedure将服务添加到身份

步骤
  1. 选择您要添加服务的身份。

  2. 单击“服务”选项卡。

  3. 单击“添加”。

  4. 根据您所选择的身份类型,将显示以下服务列表:

    • 验证配置

    • 搜索服务

    • Liberty 个人配置文件服务

    • 会话

    • 用户

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

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

  7. 单击“完成”。

代理

Access Manager 策略代理可以保护 Web 服务器和 Web 代理服务器上的内容不受未授权的侵入。它们控制对基于策略(由管理员配置)的服务和 Web 资源的访问。

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

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

Procedure创建或修改代理

步骤
  1. 单击“代理”选项卡。

  2. 单击“新建”。

  3. 输入以下字段的值:

    名称。输入代理的名称或身份。此为代理将用来登录 Access Manager 的名称。不接受多字节名称。

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

    确认密码。确认密码。

    设备状态。输入代理的设备状态。如果将状态设置为“活动”,代理将能够通过 Access Manager 进行验证并与之进行通信。如果将状态设置为“不活动”,代理将无法通过 Access Manager 进行验证。

  4. 单击“创建”。

  5. 创建代理之后,您可以另外编辑以下字段:

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

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

    agentRootURL=http:// server_name:port/

创建唯一策略代理身份

默认情况下,当在一个可信赖环境中创建多个策略代理时,这些策略代理包含的 UID 和密码相同。因为 UID 和密码是共享的,所以 Access Manager 不能区分各个代理,这可能导致会话 Cookie 容易被截取。

当“身份提供者”为第三方或企业中未授权组开发的应用程序(或“服务提供者”)提供验证、授权和有关用户的配置文件信息时,这个缺点可能会出现。可能的安全问题包括:

Procedure创建唯一策略代理身份

步骤
  1. 使用 Access Manager 管理控制台为每个代理设置一个条目。

  2. 运行以下有关密码的命令,此密码是在创建代理过程中输入的。此命令应该在安装代理的主机上调用。

    AccessManager-base/SUNWam/agents/bin/crypt_util agent123

    此时输出以下信息:

    WnmKUCg/y3l404ivWY6HPQ==

  3. 更改 AMAgent.properties 以反映新值,然后重新启动该代理。示例:

    # The username and password to use for the Application 
    
    authentication module.
    
    
    
    com.sun.am.policy.am.username = agent123
    
    com.sun.am.policy.am.password = WnmKUCg/y3l404ivWY6HPQ==
    
    
    
    # Cross-Domain Single Sign On URL
    
    # Is CDSSO enabled.
    
    com.sun.am.policy.agents.cdsso-enabled=true
    
    
    
    # This is the URL the user will be redirected to after successful login
    
    # in a CDSSO Scenario.
    
    com.sun.am.policy.agents.cdcservletURL = http://server.example.com:port
    
    /amserver/cdcservlet
  4. 更改安装有 Access Manager 的 AMConfig.properties 以反映新值,然后重新启动 Access Manager。示例:

    com.sun.identity.enableUniqueSSOTokenCookie=true
    
    com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer
    
     
    
    com.sun.identity.authentication.uniqueCookieDomain=.example.com
  5. 在 Access Manager 控制台中,选择“配置”>“平台”。

  6. 在“Cookie 域”列表中更改 Cookie 域名:

    1. 选择默认 iplanet.com 域,然后单击“删除”。

    2. 输入 Access Manager 安装的主机名,然后单击“添加”。

      示例:server.example.com

      应该会在浏览器上看见两个 Cookie 集:

      • iPlanetDirectoryPro – server.example.com(主机名)

      • sunIdentityServerAuthNServer – example.com(主机名)

过滤的角色

过滤的角色是 LDAP 过滤器创建的动态角色。在创建角色时,会通过过滤器过滤所有用户并为其分配该角色。 过滤器会搜索条目中的所有属性值对(例如, ca=user*),并自动将包含该属性的用户分配给角色。

Procedure创建过滤的角色

步骤
  1. 在“浏览”窗格中,找到要在其中创建角色的组织。

  2. 单击“新建”。

  3. 输入过滤的角色的名称。

  4. 输入搜索条件信息。

    例如,


    (&(uid=user1)(|(inetuserstatus=active)(!(inetuserstatus=*))))

    如果过滤器保留为空,将默认创建以下角色:


    (objectclass = inetorgperson)
  5. 单击“创建”以基于过滤条件启动搜索。通过过滤条件定义的身份将会自动指定给角色。

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

角色

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

Procedure创建或修改角色

步骤
  1. 单击“角色”选项卡。

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

  3. 输入角色的名称。

  4. 单击“创建”。

Procedure将用户添加到角色或组

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

  2. 单击“用户”选项卡。

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

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

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

Procedure创建或修改组

步骤
  1. 单击“组”选项卡。

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

  3. 输入组的名称。

  4. 单击“创建”。

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