WebSEAL 联结

转载自http://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1134-01/zh_CN/HTML/amweb41_admin10.htm

WebSEAL 联结是前端 WebSEAL 服务器和后端 Web 应用程序服务器之间的 HTTP 或 HTTPS 连接。结点从逻辑上将后端服务器的 Web 空间与 WebSEAL 服务器的 Web 空间结合起来，从而产生整个 Web 对象空间的统一视图。结点允许 WebSEAL 代表后端服务器提供保护性服务。WebSEAL 在将所有对资源的请求通过结点传递给后端服务器之前执行那些请求的认证与授权检查。结点同时还允许在客户机和所联结的后端应用程序之间实现各种单一注册解决方案。

可以用 pdadmin 命令行实用程序或 Web Portal Manager 创建 WebSEAL 联结。 本章讨论配置 WebSEAL 联结的很多选项的详细信息。

主题索引：

• WebSEAL 联结概述
• 使用 pdadmin 创建联结
• 配置基本 WebSEAL 联结
• 相互认证的 SSL 联结
• 创建 TCP 和 SSL 代理联结
• 通过 SSL 的 WebSEAL 至 WebSEAL 联结
• 修改 URL 到后端资源
• 附加的联结选项
• 使用 WebSEAL 联结的技术注释：
• 在第三方服务器上使用 query_contents

WebSEAL 联结概述

可以创建以下 WebSEAL 联结类型：

• 基于 TCP 连接的 WebSEAL 到后端服务器的联结
• 基于 SSL 连接的 WebSEAL 到后端服务器的联结
• 通过 HTTP 代理服务器、基于 TCP 连接的 WebSEAL 到后端服务器的联结
• 通过 HTTPS 代理服务器、基于 SSL 连接的 WebSEAL 到后端服务器的联结
• 基于 SSL 连接的 WebSEAL 到 WebSEAL 的联结

在创建任何联结时，必须致力于以下两个关注点：

1. 决定在 WebSEAL 对象空间中的何处联结（安装）Web 应用程序服务器。
2. 选择联结类型。

联结数据库位置和格式

现在 WebSEAL 联结信息存储在 XML 格式的数据库文件。联结数据库目录的位置在 webseald.conf 配置文件的 [junction] 节中定义。该目录与 WebSEAL 服务器根（[server] 节中的 server-root 参数）相关：

[junction]
junction-db = jct

• 每个联结都在带有 .xml 扩展名的单独文件中定义。
• 使用 pdadmin 实用程序创建和管理联结和选项。
• XML 格式允许您手工创建、编辑、复制和备份联结文件。

应用粗粒度访问控制：总结

1. 使用 pdadmin 实用程序或者 Web Portal Manager 在 WebSEAL 和后端服务器之间创建联结。
2. 在联结点上放置适当的 ACL 策略以提供对后端服务器的粗粒度控制。

应用细粒度访问控制：总结

1. 使用 pdadmin 实用程序或者 Web Portal Manager 在 WebSEAL 和后端服务器之间创建联结。

   WebSEAL 不能自动“查看”和理解第三方文件系统。必须使用称为 query_contents 的特殊应用程序通知第三方对象空间的 WebSEAL，告诉它清查第三方 Web 空间并报告 WebSEAL 的结构和内容。

2. 复制 query_contents 程序到第三方服务器。
3. 将 ACL 策略应用到统一对象空间中的适当对象上。

创建 WebSEAL 联结的指导

以下指南总结了联结的“规则”：

• 可在主 WebSEAL 对象空间中的任何地方添加联结。
• 可在同一安装点联结多个已复制的后端服务器

  安装在同一联结点的多个已复制的后端服务器必须为同一类型的 — TCP 或 SSL

• 第三方服务器通过联结继承 ACL 策略。
• 联结点名称应唯一且不应该与本地 WebSEAL 服务器 Web 空间中的任何目录匹配。例如，如果 WebSEAL 具有的资源格式为 /path/...，不要创建名称为 /path 的联结点。
• 如果来自后端服务器的 HTML 页面包含程序（例如 JavaScript 或 applet），并且该程序带有到该目录的与服务器有关的 URL，则联结点不应匹配后端服务器 Web 空间中的任何目录。例如，如果来自后端服务器的页面包含 URL 格式为 /path/... 的程序，则不要创建名为 /path 的联结点。
• 不要创建多个指向相同的后端应用程序服务器／端口的 WebSEAL 联结。这种类型的配置可能会引起对资源的无法预料的访问控制，因此不是建议或支持的Tivoli Access Manager 配置策略。

  每个 WebSEAL 联结可以由一唯一的访问控制（ACL）集保护。然而，每个新近创建的联结的 ACL 策略将覆盖附加到相同的后端服务器／端口的先前创建的联结的策略。后继用较多许可的 ACL 保护的联结会危及用较少许可的 ACL 保护的先前联结的安全。WebSEAL 和 Tivoli Access Manager 授权模型无法保证具有此种类型的联结实现的安全访问控制。

• WebSEAL 支持 HTTP 1.1 交叉联结。

WebSEAL 联结的附加参考

请参阅了解 WebSEAL 联结以获取 WebSEAL 联结的概念性概述。

关于联结命令选项的完整信息，请参阅附录B. WebSEAL 联结参考。

使用 pdadmin 创建联结

在使用 pdadmin 前，您必须作为 sec_master 管理用户登录到安全域。

例如：

UNIX：

# pdadmin
pdadmin> login
输入用户标识：sec_master
输入密码：
pdadmin>

Windows：

MSDOS> pdadmin
pdadmin> login
输入用户标识：sec_master
输入密码：
pdadmin>

要创建 WebSEAL 联结，使用 pdadmin server task create 命令：

pdadmin> server task <server-identification> create <options>

此命令的 server-identification 组件是此命令所使用的 Tivoli Access Manager 服务器和 Tivoli Access Manager 服务器主机名称的结合。

<Access-Manager-server>-<host-name>

单个 WebSEAL 服务器的语法：

对于 Tivoli Access Manager WebSEAL，Access-Manager-server 是 webseald 而 host-name 是 WebSEAL 服务器计算机的名称：

pdadmin> server task webseald-<host-name> create <options>

最初安装在机器上的 WebSEAL 服务器总是按机器名称来命名。例如，如果计算机名称是 cruz，则单独 WebSEAL 安装的服务器标识为：

webseald-cruz

多个 WebSEAL 实例的语法：

如果在同一机器上安装多个 WebSEAL 服务器实例，Access-Manager-server 是 WebSEAL 服务器实例的配置名称，后跟 webseald，再后跟主机名：

<instance-name>-webseald-<host-name>

例如，如果两个附加 WebSEAL 实例的配置名称是 webseal2 和 webseal3，服务器标识如下所示：

webseal2-webseald-cruz
webseal3-webseald-cruz

使用 server list 命令验证服务器标识：

pdadmin> server list
webseald-cruz
webseal2-webseald-cruz
webseal3-webseald-cruz

配置基本 WebSEAL 联结

WebSEAL 支持 WebSEAL 和后端 Web 应用程序服务器之间的标准 TCP（HTTP）和安全 SSL（HTTPS）联结。

WebSEAL 和后端服务器之间的联结不依赖于客户机和 WebSEAL 服务器之间的连接类型（及其安全级别）。

使用 pdadmin 创建基本 WebSEAL 联结所需的强制命令选项包括：

• 后端应用程序服务器的主机名（ -h 选项）
• 结点类型：tcp、ssl、tcpproxy、sslproxy、local（-t 选项）
• 联结点（安装点）

pdadmin> server task webseald-<instance-name> create -t <type> -h \
<host-name> <jct-point>

例如：

pdadmin> server task webseald-cruz create -t tcp -h doc.tivoli.com /pubs

注:

当将该参数指定到  -h 选项时，“最佳实践”的建议是始终使用后端服务器的全限定域名。

创建 TCP 类型联结

通过 TCP 连接的 WebSEAL 联结提供了联结的基本属性，但不提供通过联结的安全通信。

图形 22. 非安全 TCP（HTTP）联结

要创建安全 TCP 联结并添加初始服务器，请使用带 -t tcp 选项的 create 命令：

pdadmin> server task webseald-<instance-name> create -t tcp -h <host-name> \
[-p <port>] <jct-point>

TCP 联结的缺省端口值（若未指定）是 80。

创建 SSL 类型联结

SSL 联结功能和 TCP 联结很象，附加功能是加密所有 WebSEAL 和后端服务器间的通信。

图形 23. 安全 SSL（HTTPS）联结

SSL 联结允许安全的端到端的浏览器到应用程序的事务。可以使用 SSL 保护从客户机到 WebSEAL 以及从 WebSEAL 到后端服务器的通信。 使用 SSL 联结时，后端服务器必须启用 HTTPS。

要创建安全 SSL 联结并添加初始服务器，请带 -t ssl 选项使用 create 命令：

pdadmin> server task webseald-<instance-name> create -t ssl -h <host-name> \
[-p <port>] <jct-point>

SSL 联结的缺省端口值（如果不指定）是 443。

验证后端服务器证书

当客户机请求后端服务器上的资源时，WebSEAL 作为安全服务器，将代表客户机执行请求。SSL 协议指定了在对后端服务器提出请求时，服务器必须使用服务器端证书提供其身份证明。

当 WebSEAL 从后端服务器接收到此证书时，它必须通过将证书与证书数据库中根 CA 证书列表对照来验证真实性。

Tivoli Access Manager 使用 SSL 的 IBM Global Security Kit（GSKit）实现。 必须使用 GSKit iKeyman 实用程序来添加 CA 的根证书，该 CA 签署了 WebSEAL 证书密钥文件（pdsvr.kdb）的后端服务器证书。

SSL 联结示例

通过 SSL 的，位于联结点 /sales 的联结主机 sales.dascom.com：

pdadmin> server task webseald-<instance-name> create -t ssl -h \
sales.tivoli.com /sales

注:

在上例中， -t ssl 选项规定了缺省端口 443。

通过 SSL 的，位于联结点 /travel 的端口 4443 上的联结主机 travel_svr：

pdadmin> server task webseald-<instance-name> create -t ssl -p 4443 \
-h travel_svr /travel

添加后端服务器到联结

要提高由 Tivoli Access Manager 保护的资源的高可用性，可将多个已复制的后端服务器联结到相同的联结点。

• 联结到相同点的多个后端服务器必须具有相同的 WebSEAL 版本和相同的 Web 文档空间。
• 联结到相同点的多个后端服务器必须使用相同的联结类型（TCP 或 SSL）。
• WebSEAL 使用一个最小繁忙算法来决定哪个后端服务器副本拥有最少的请求连接数并将任何新的请求转发到此服务器。

创建初始联结。例如：

pdadmin> server task webseald-cruz create -t tcp -h server1 /sales

添加附加的后端服务器副本。例如：

pdadmin> server task webseald-cruz add -h server2 /sales

相互认证的 SSL 联结

WebSEAL 支持通过 SSL 联结（-t ssl 或 -t sslproxy）的 WebSEAL 服务器和后端服务器之间的相互认证。 以下概述总结了通过 SSL 的相互认证支持的功能（将在相应位置列出命令选项）：

1. WebSEAL 认证后端服务器（正常的 SSL 进程）
   • WebSEAL 验证来自后端服务器的服务器证书。请参阅WebSEAL 验证后端服务器证书。
   • WebSEAL 验证包含在证书中的专有名称（DN）（-D）（可选，但强烈建议），请参阅专有名称（DN）匹配。
2. 后端服务器认证 WebSEAL（两种方法）
   • 后端服务器验证来自 WebSEAL 的客户机证书（-K）。请参阅使用客户机证书的 WebSEAL 认证。
   • 后端服务器验证在基本认证（BA）头中的 WebSEAL 身份信息（-B、-U、-W），请参阅使用 BA 头的 WebSEAL 认证。

控制通过 SSL 进行相互认证的命令选项提供以下功能：

• 可指定客户机证书或 BA 认证方法。
• 可以在每个联结的基础上应用认证方法。

处理通过联结的客户机标识信息中描述了将 -b 选项（用于处理 BA 信息）与通过 SSL 的相互认证相结合的特殊注意事项。

WebSEAL 验证后端服务器证书

WebSEAL 根据标准 SSL 协议验证后端服务器证书。 后端服务器将服务器证书发送到 WebSEAL。WebSEAL 对照根认证中心（CA）证书的预定义列表验证服务器证书。

WebSEAL 使用的密钥数据库必须包含认证中心（CA）的证书，这些证书构成应用程序服务器证书（从签署 CA 开始并包含根证书）的可信链。

可使用 iKeyman 应用程序来创建和管理根 CA 证书的数据库。

专有名称（DN）匹配

可通过专有名称（DN）匹配来增强服务器端的证书验证。 要启用服务器 DN 匹配，必须在创建至该服务器的 SSL 联结时指定后端服务器 DN。 虽然 DN 匹配是可选的配置，但强烈推荐用通过 SSL 联结的相互认证来实现该功能。

在服务器端证书验证期间，包含在证书中的 DN 将与联结定义的 DN 进行比较。 如果这两个 DN 不匹配，到后端服务器的连接将失败。

要启用服务器 DN 匹配，则在使用 -D "<DN>" 选项创建 SSL 联结时，指定后端服务器 DN。 为了保持字符串中的空格，请将此 DN 字符串用双引号引起来。例如：

-D "/C=US/O=Tivoli/OU=SecureWay/CN=Access Manager"

-D 选项仅适合与 -K 或 -B 选项一起使用。

使用客户机证书的 WebSEAL 认证

使用 -K 选项可启用使用其客户机证书的 WebSEAL 对联结的后端服务器进行认证。

-K "<key-label>" 

该方案的条件包括：

• 设置后端服务器以要求用客户机证书来验证 WebSEAL 身份。
• 在认证已联结的后端服务器时，使用 iKeyman 实用程序创建、标号并存储仅用作 WebSEAL 的客户机证书的特殊密钥。
• 同时强烈推荐配置用于 DN 匹配的联结（-D）。

-K 选项使用指定存储在 GSKit 密钥数据库中的必需证书的密钥标签的参数。使用 iKeyman 实用程序可添加新证书至密钥数据库。

必须将 key-label 参数用引号引起来。例如：

-K "cert1_Tiv"

如果密钥驻留在加密硬件上，则必须用密钥标签指定 WebSEAL 标记设备。

-K "<token-name>:<key-label>"

例如：

-K "websealtoken:junctionkey"

请参阅为加密和密钥存储配置密码术硬件。

请参阅配置密钥数据库参数。

使用 BA 头的 WebSEAL 认证

使用 -B -U "<username>" -W "<password>" 选项来通过基本认证启用 WebSEAL 认证。

-B -U "<username>" -W "<password>" 

该方案的条件包括：

• 设置后端服务器以要求使用 BA 头来验证 WebSEAL 身份。
• 请不要用任何 -b 选项配置联结。（但在内部，-B 选项使用 -b filter。）
• 配置 WebSEAL 为将 BA 头中待认证的标识信息发送到后端服务器。
• 强烈建议同时配置用于 DN 匹配的联结（-D）。

必须将用户名和密码用双引号引起来。例如：

-U "WS1" -W "abCde"

处理通过联结的客户机标识信息

可将联结设置为在 BA 头中指定客户机标识信息。-b 选项允许 4 个可能的参数：filter、supply、ignore 和 gso。 这些参数的详细信息可在配置单一注册解决方案的 BA 头中查找。

-b 选项将影响用于相互认证的联结设置，必须考虑选项的正确组合。

使用 -b supply

• 通过 BA 头的 WebSEAL 认证不允许与该选项同时使用。该选项使用 BA 头用于原始客户机用户名和“dummy”密码。
• 允许通过客户机证书的 WebSEAL 认证与该选项同时使用。

使用 -b ignore

• 通过 BA 头的 WebSEAL 认证不允许与该选项同时使用。该选项使用 BA 头用于原始客户机用户名和密码。
• 允许通过客户机证书的 WebSEAL 认证与该选项同时使用。

使用 -b gso

• 通过 BA 头的 WebSEAL 认证不允许与该选项同时使用。该选项使用 BA 头用于 GSO 服务器提供的用户名和密码信息。
• 允许通过客户机证书的 WebSEAL 认证与该选项同时使用。

使用 -b filter

• 在内部，当 WebSEAL 认证设置为使用 BA 头信息时使用 -b filter 选项。

  WebSEAL BA 头将用于所有后继的 HTTP 事务。 对于后端服务器，WebSEAL 表现为所有时间都是登录的。

• 允许通过客户机证书的 WebSEAL 认证与该选项同时使用。
• 如果后端服务器要求（从浏览器）获得实际的客户机标识，可使用 CGI 变量 HTTP_IV_USER、HTTP_IV_GROUP 和 HTTP_IV_CREDS。对于脚本和 servlet，请使用对应的特定于 Tivoli Access Manager 的 HTTP 头：iv-user、iv-groups、iv-creds。

创建 TCP 和 SSL 代理联结

可创建 WebSEAL 联结，该联结允许使用 HTTP 或 HTTPS 代理服务器遍历网络拓扑结构的 WebSEAL 通信。 可配置该联结，以便将请求作为标准的 TCP 通信或受保护的 SSL 通信来处理。

create 命令的 type 选项要求以下参数之一，以便建立通过代理服务器的、基于 TCP 或 SSL 的联结：

• -t tcpproxy
• -t sslproxy

create 和 add 命令需要以下选项和参数来标识代理服务器及目标 Web 服务器：

-H <host-name>	代理服务器的 DNS 主机名或 IP 地址。
-P <port>	代理服务器的 TCP 端口。
-h <host-name>	目标 Web 服务器的 DNS 主机名或 IP 地址。
-p <port>	代理 Web 服务器的 TCP 端口。对于 TCP 联结，缺省值为 80；对于 SSL 联结，缺省值为 443。

TCP 代理联结示例（作为一行输入）：

pdadmin> server task webseald-<instance-name> create -t tcpproxy \
-H clipper -P 8081 -h www.ibm.com -p 80 /ibm

SSL 代理联结示例（作为一行输入）：

pdadmin> server task webseald-<instance-name> create -t sslproxy \
-H clipper -P 8081 -h www.ibm.com -p 443 /ibm

图形 24. 代理联结示例

通过 SSL 的 WebSEAL 至 WebSEAL 联结

Tivoli Access Manager 支持前端 WebSEAL 服务器和后端 WebSEAL 服务器之间的 SSL 联结。使用带 -C 选项的 create 命令可通过 SSL 联结两个 WebSEAL 服务器并提供相互认证。

示例：

pdadmin> server task webseald-<instance-name> create -t ssl -C -h serverA /jctA

相互认证发生在以下两种状态下：

• SSL 协议允许后端 WebSEAL 服务器通过其服务器证书向前端 WebSEAL 服务器认证。
• 在基本认证（BA）头中，-C 选项使前端 WebSEAL 服务器可以将其身份信息传递到后端 WebSEAL 服务器。

此外，-C 选项启用 -c 选项的功能，该功能允许将特定于 Tivoli Access Manager 的客户机身份和组员资格信息放到以后端 WebSEAL 服务器为目的地的请求的 HTTP 头中。 头参数包括 iv-user、iv-groups 和 iv-creds。请参阅在 HTTP 头中提供客户机标识（-c）。

以下条件应用于 WebSEAL 至 WebSEAL 联结：

• 该联结仅适用于 -t ssl 或 -t sslproxy 联结类型。
• 两个 WebSEAL 服务器必须共享公共 LDAP 注册表。 它允许后端 WebSEAL 服务器认证前端 WebSEAL 服务器的标识信息。

修改 URL 到后端资源

从后端应用程序返回给客户机的页面最常包含的是到位于这些应用程序服务器上的资源的 URL 链接。构造这些链接以将任何请求定向回这些资源的正确位置是很重要的。

例如（非 WebSEAL 环境），客户机输入的在某个应用程序服务器上的资源 URL 如下所示：

http://www.abc.com/file.html

WebSEAL 作为前端逆向代理，通过 WebSEAL 联结功能为后端应用程序服务器提供安全服务。此功能导致通过不同的 URL 表达式访问资源。

例如（WebSEAL 环境），客户机输入的在一个联结的后端应用程序服务器上的同一资源的 URL 必须如下所示：

http://webseal.abc.com/jct/file.html

WebSEAL 的联结功能更改了必须用来访问联结的后端系统上的资源的服务器和路径信息。只有当 URL 包含联结的标识时，到后端联结的服务器上的资源的链接才会成功。

要支持联结功能并维护 URL 的完整性，WebSEAL 必须在以下可能的地方：

1. 修改在发送给客户机的响应中找到的 URL（链接）
2. 修改由于 WebSEAL 无法更改的 URL（链接）而导致的对资源的请求

要注意的是，WebSEAL 用于过滤和处理 URL 的规则和机制不适用于指向 Tivoli Access Manager 联结环境外部的资源的链接。

下图总结了 WebSEAL 可用于修改 URL 到联结后端资源的解决方案：

图形 25. 总结：修改 URL 到后端资源

本节包含以下主题：

• 了解 URL 中使用的路径类型
• 过滤响应中的 URL
• 处理请求中的 URL
• 处理跨多个 -j 联结的来自服务器的 cookies

了解 URL 中使用的路径类型

任何 HTML 页面都有可能包含到后端服务器或其它地方的其它资源的 URL（链接）。 URL 表达式可使用以下格式显示：

• 相对
• 相对于服务器
• 绝对

包含 URL 的以相对格式表达的链接从不要求 WebSeal 的操作。缺省情况下，浏览器通过对相对 URL 预置正确的模式、服务器和目录信息（包括联结）来处理链接中的相对 URL。前置信息派生自链接位于的页面的请求 URL。

相对 URL 表达式示例：

abc.html          ../abc.html
./abc.html        sales/abc.html

然而，相对于服务器和绝对路径格式会产生困难。仅当 WebSEAL 能够修改 URL 路径表达式并包含联结信息时，以绝对或相对于服务器的格式表示的到后端资源的链接才会成功。

相对于服务器 URL 表达式示例：

/abc.html          /accounts/abc.html

绝对 URL 表达式示例：

http://www.tivoli.com/abc.html

注:

鼓励所有 Web 脚本的程序员为动态生成的 URL 使用 相对链接（不是绝对或相对于服务器的）。

过滤响应中的 URL

本节描述了 WebSEAL 如何过滤来自联结的后端应用程序服务器的响应中的 URL。

• WebSEAL 的标准 URL 过滤规则
• 用脚本过滤修改绝对 URL
• 过滤 Content-Length 头的更改

WebSEAL 的标准 URL 过滤规则

WebSEAL 使用一个标准规则集来过滤响应客户机请求的页面中包含的 URL。要应用标准 URL 过滤，WebSEAL 必须能够“看到”后端服务器发送的页面中的 URL。WebSEAL 无法为嵌入在脚本中的 URL 使用标准过滤规则。

缺省情况下，WebSEAL 只过滤从已联结服务器接收到的 MIME 类型为“text/html”和“text/vnd.wap.wml”的文档。可使用 webseald.conf 配置文件的 [filter-content-types] 节配置其它的 MIME 类型。

浏览器总可以适当地处理相对 URL。缺省情况下，浏览器通过在相对 URL 前添加正确的模式、服务器和目录信息（包括联结）来处理链接中的相对 URL。预置信息派生自链接位于其上的页的请求 URL。

然而，WebSEAL 必须将联结名称添加到引用联结服务器上的资源的绝对和相对于服务器的 URL 的路径中。

• 相对于服务器的 URL 表示一个相对于已联结服务器的文档根的 URL 位置，例如：

  /dir/file.html

  相对于服务器的 URL 通过添加已联结服务器的联结点到路径名来修改。例如：

  /jct/dir/file.html

• 绝对 URL 表示相对于主机名或 IP 地址（及可选的网络端口）的 URL 位置。例如：

  http://<host-name>[:<port>]/file.html，或
  https://<host-name>[:<port>]/file.html

  可根据以下规则集修改绝对 URL：

  • 如果 URL 是 HTTP 并且主机／端口与 TCP 联结的服务器匹配，则将 URL 修改为到 WebSEAL 的相对于服务器的 URL 并反映联结点。例如：

    http://<host-name>[:<port>]/file.html

    变为：

    /tcpjct/file.html

  • 如果 URL 是 HTTPS 并且主机／端口与 SSL 联结的服务器匹配，则将 URL 修改为到 WebSEAL 的相对于服务器的 URL 并反映联结点。例如：

    https://<host-name>[:<port>]/file.html

    变为：

    /ssljct/file.html

此外：

• 只有在 webseald.conf 配置文件的 [filter-content-types] 节中定义的内容类型的 URL 才被过滤。
• 通常将过滤 META 标记以刷新请求，例如：

  <META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://server/url">

• 如果 BASE 标签包含 HREF 属性，则此标签将从响应移至客户机。

通过联结的服务器过滤 URL 的参数位于 webseald.conf 配置文件的 [filter-url] 节中。[filter-url] 节包含 HTML 标记列表，WebSEAL 将过滤或修改这些标记来调整通过联结的服务器获取的绝对 URL。

缺省情况下将配置常用 HTML 标记。 管理员可能需要添加包含 URL 的附加 HTML 标记。

用脚本过滤修改绝对 URL

WebSEAL 需要附加配置来进行脚本中嵌入的绝对 URL 的处理。Web 脚本语言包含 Javascripts、VBscripts、ASP、JSP、ActiveX 和其它。webseald.conf 配置文件包含启用或禁用对嵌入的绝对 URL 过滤的参数：

[script-filtering]
script-filter = no

缺省情况下将禁用脚本过滤。要启用脚本过滤，请设置：

script-filter = yes

script-filter 机制希望绝对 URL 具有标准模式、服务器或资源格式：

http://server/resource

script-filter 机制用正确的联结信息（作为相对路径名）替换链接的模式和服务器部分：

/junction-name/resource

此过滤解决方案分析 HTML 代码中嵌入的脚本并因此需要附加的处理开销，这会对性能有负面的影响。请将 script-filter 参数的使用限于需要支持过滤嵌入的绝对 URL 的联结。

下图说明了该绝对 URL 过滤解决方案：

图形 26. 过滤绝对 URL

可以选择性地配置 WebSEAL 以将原始绝对 URL 重写为绝对 URL，而不是相对 URL（缺省值）。 要启用该功能，将 webseald.conf 配置文件的 [script-filtering] 节中的 rewrite-absolute-with-absolute 参数设置为等于“yes”：

[script-filtering]
rewrite-absolute-with-absolute = yes

启用该功能时，上图中的示例 URL 会显示为：

http://<webseal-hostname>/jctA/abc.html

过滤 Content-Length 头的更改

通常情况下，来自后端服务器的响应中的 Content-Length 头指示正在返回的内容的大小。当 WebSEAL 过滤 URL 并将联结信息添加到页面中包含的 URL 的路径时，页面的实际大小会变得比内容头（Content-Header）指示的要大。

直到新内容实际将流写入到客户机中，WebSEAL 没有办法知道新内容长度是多少。在这时，插入新的 Content-Length 头已经太迟了。WebSEAL 用以下方法响应此情况：

1. WebSEAL 将原始 Content-Length 头的值放置在称为 X-Old-Content-Length 的新的头中。

   任何为查找此头而写的小应用程序或应用程序都可以访问原始的（过滤前的）Content-Length 值。

2. WebSEAL 在 request.log 文件中记录更改过的（过滤后的）Content-Length 值。
3. Content-Length 头不再出现。

处理请求中的 URL

当 URL 是由客户机端应用程序（小应用程序）动态生成或嵌入在 HTML 代码的脚本中时会产生困难。Web 脚本语言包含 Javascripts、VBscripts、ASP、JSP、ActiveX 和其它。此页面一到达客户机浏览器，这些 applet 及脚本就会执行。WebSEAL 从没有机会将它的标准过滤规则应用于这些动态生成的 URL。

本节描述了 WebSEAL 如何处理客户机端动态生成的相对于服务器链接，这些链接可在对联结后端服务器上的资源的请求中找到。

• 使用联结 cookie（-j）处理相对于服务器的 URL
• 使用联结映射处理相对于服务器的 URL

注:

不存在可用于处理客户机端生成的绝对 URL 的解决方案。

使用联结 cookie（-j）处理相对于服务器的 URL

最初由小应用程序和脚本在客户机端生成的相对于服务器的 URL 缺少对联结点的了解。WebSEAL 无法过滤 URL 因为它在客户机端生成。使用此 URL 对资源的客户机请求期间，WebSEAL 会试图使用联结 cookie 重新处理相对于服务器的 URL。

在以下方案中，位于请求页面上的脚本在一到达浏览器就动态生成相对于服务器的 URL 表达式。如果客户机请求由此链接指定的资源，WebSEAL 接收到对本地页面的请求。查找该页面失败后，它将向客户机返回“找不到”错误。

-j 选项提供了一个基于 cookie 的解决方案，用于处理由客户机上运行的脚本动态生成的相对于服务器的 URL。

一般语法：

pdadmin> server task <server-name> create ... -j ...

对于每个请求页面发送一个“联结标识”cookie 到客户机。该 cookie 包含以下头名称和值：

IV_JCT = </junction-name>

当客户机从此页面使用动态生成的相对于服务器的 URL 发出请求时，WebSEAL（象以前一样）接收本地资源的请求。 无法定位资源时，WebSEAL 立即使用 cookie 提供的联结信息重试该请求。使用 URL 表达式中的正确联结信息，可成功定位资源。

下图阐述了过滤相对于服务器的 URL 的解决方案

图形 27. 处理相对于服务器的 URL

另见处理跨多个 -j 联结的来自服务器的 cookies。

WebSEAL 为处理动态生成的相对于服务器的 URL 提供了可选的、不基于 cookie 的解决方案。请参阅使用联结映射处理相对于服务器的 URL。

使用联结映射处理相对于服务器的 URL

由 applet 和脚本在客户机端生成的相对于服务器的 URL 最初缺少对联结点的了解。WebSEAL 无法过滤 URL 因为它在客户机端生成。使用此 URL 对资源的客户机请求期间，WebSEAL 会试图使用联结映射重新处理相对于服务器的 URL。

除基于 cookie 的解决方案外，Tivoli Access Manager 提供备用方案以过滤动态生成的相对于服务器的 URL。 可以创建和激活联结映射表，该表将特定的目标资源映射到联结名称。

WebSEAL 使用联结映射表中包含的数据检查相对于服务器的 URL 中的位置信息。 如果 URL 中的路径信息匹配表中的条目，WebSEAL 将该请求指向与该位置关联的联结。

该表是名为 jmt.conf 的 ASCII 文本文件。在 webseald.conf 配置文件的 [junction] 节中指定了该文件的位置：

jmt-map = lib/jmt.conf

表中数据条目的格式由联结名称、空格和资源位置模式构成。也可使用通配符表达资源位置模式。

在联结映射配置文件的以下示例中，两个后端服务器在 /jctA 和 /jctB 与 WebSEAL 联结：

#jmt.conf
#<junction-name> <resource-location-pattern>
/jctA /documents/release-notes.html
/jctA /travel/index.html
/jctB /accounts/*
/jctB /images/weather/*.jpg

原始 jmt.conf 映射表是一个空文件。 在向文件添加数据后，必须使用 jmt load 命令“装入”数据，以便 WebSEAL 获知新信息。

pdadmin> server task <server-name> jmt load
已成功装入 JMT 表。

以下条件应用于联结映射表解决方案：

• 该解决方案不需要 -j 选项或联结 cookie
• 需要设置映射表并由安全管理员激活
• 该解决方案不处理绝对 URL 创建的链接
• 资源位置模式在本地 Web 空间和联结的 Web 应用程序服务器上必须是唯一的。
• 如果在文件中有完全相同的模式条目，则将不装入映射表。但 WebSEAL 将继续运行。
• 如果在装入映射表时出错，则映射表将不可用。但 WebSEAL 将继续运行。
• 如果映射表为空或表的条目有错误，则将不装入该映射表。但 WebSEAL 将继续运行。
• 装入映射表时发生的任何错误将导致 WebSEAL 服务器日志文件（webseald.log）中的可服务性条目的产生。

处理跨多个 -j 联结的来自服务器的 cookies

第一部分：-j 联结修改 Set-Cookie Path 属性

除了为浏览器提供联结标识 cookie 外，用 -j 选项配置的联结还支持对作为后端应用程序的响应发送的 cookies 的处理。

浏览器规则：

如果来自服务器的响应中的 Set-Cookie 头包含 Path 属性 （例如 Path=/xyz），则浏览器只有在请求 URL（从返回的页面激活）以该路径开头（例如 /xyz/memo.html）的时候才返回 cookie。

问题：

当联结环境包含用于处理响应中的可见及嵌入的 URL 的混合解决方案时，浏览器返回 cookies 的能力变弱。例如，可见的相对于服务器的 URL 的标准 WebSEAL 过滤通常除了修改 URL 本身外还将联结名称添加到服务器 cookie 的 Path 属性（例如，Path=/jct/xyz）。 当链接由用户激活时，URL 路径名和 cookie Path 属性之间的该匹配允许浏览器返回 cookie。

然而，只有在用户将链接（URL）激活后，基于 -j 联结 cookie 的解决方案才将联结名称添加到 URL。当预先修改的链接激活时， URL 路径名称（/xyz/memo.html）不与 Path 属性（Path=/jct/xyz）匹配。不返回服务器 cookie。

解决方案：

-j 选项将任何服务器 cookie（Set-Cookie）的 Path 属性 转换为“/”（例如，Path=/）。因为所有相对于服务器的路径名称以“/”开头，所以返回所有服务器 cookies 而不管原始 Path 属性规范的要求。

第二部分：-j 联结修改 Set-Cookie Name 属性

-j 选项同时也支持从跨多个联结的服务器返回的 cookies。

浏览器规则：

浏览器始终用包含相同 Name 属性（Set-Cookie）的最新到达的 cookie 替换任何已存储的 cookie，除非 Path 和／或 Domain 属性是唯一的。

问题：

前面一节描述了 -j 联结选项如何修改 Set-Cookie 头的 Path 属性以允许浏览器 在某一环境中返回 cookies，在该环境中 WebSEAL 正在应用不同过滤规则用于包含在响应页面中的可见及嵌入的 URL。

在多个后端服务器跨不同联结连接到 WebSEAL 的情况下（例如在 WebSphere 环境中），每个服务器都可能以相同的 Name 属性发送 cookies（Set-Cookie）。 如果联结使用 -j 选项，则每个 cookie 的 Path 属性变为相同的（Path=/）。 因为相同的 WebSEAL 服务器是浏览器的联系点，同样 Domain 属性变为相同。 尽管这些相同的 cookie 从唯一的后端应用程序到达，但是浏览器重写相同名称的 cookies。

解决方案：

-j 联结选项提供附加功能，该功能唯一地重命名任何随后端应用程序服务器响应返回的 cookie。Set-cookie 头的 Name 属性前置特殊字符串。该字符串包含负责交付响应（带有 cookie）的特定联结的名称。

AMWEBJCT_<jct-name>_

例如，如果名称为 JSESSIONID 的 cookie 跨越名为 /jctA 的联结到达，则 cookie 的 Name 属性更改为：

Name=AMWEBJCT_jctA_JSESSIONID

附加的联结选项

可使用附加选项提供以下附加 WebSEAL 联结功能：

• 强制新联结（-f）
• 在 HTTP 头中提供客户机标识（-c）
• 在 HTTP 头中提供客户机 IP 地址（-r）
• 限制 WebSEAL 生成的 HTTP 头的大小
• 将会话 cookie 传递到联结的门户网站服务器（-k）
• 支持不区分大小写的 URL（-i）
• 状态保存联结支持（-s, -u）
• 为状态保存结点指定后端服务器 UUID（-u）
• 联结到 Windows 文件系统（-w）

强制新联结（-f）

要强制新联结覆盖现有联结，必须使用 -f 选项。

以下示例（服务器实例名称 = cruz）阐述了此过程：

1. 登录到 pdadmin：

   # pdadmin
   pdadmin> login
   输入用户标识：sec_master
   输入密码：
   pdadmin>

2. 使用 server task list 命令显示所有当前联结点：

   pdadmin> server task webseald-cruz list
   /

3. 使用 server task show 命令显示联结的详细信息：

   pdadmin> server task webseald-cruz show /
   联结点：/
   类型：本地
   联结硬限制：0 — 使用全局值
   联结软限制：0 — 使用全局值
   活动的工作程序线程：0
   根目录：/opt/pdweb/www/docs

4. 创建新的本地联结来代替当前联结点（需要 -f 选项来强制使用覆盖现有联结的新联结）：

   pdadmin> server task webseald-cruz create -t local -f -d /tmp/docs /
   创建结点于

5. 列出新联结：

   pdadmin> server task webseald-cruz list
   /

6. 显示该联结的详细信息：

   pdadmin> server task webseald-cruz show /
   联结点：/
   类型：本地
   联结硬限制：0 — 使用全局值
   联结软限制：0 — 使用全局值
   活动的工作程序线程：0
   根目录：/tmp/docs

在 HTTP 头中提供客户机标识（-c）

-c 选项允许将特定于 Tivoli Access Manager 的客户机身份和组员资格信息插入到以联结的第三方服务器为目的地的请求的 HTTP 头。HTTP 头信息使已联结的第三方服务器上的应用程序基于客户机的 Tivoli Access Manager 身份执行特定于用户的操作。

HTTP 头信息必须由后端服务器变换为环境变量格式，以便由后端服务器上的服务使用。通过用下划线（_）代替所有破折号（-）并在字符串的开始处添加“HTTP”而将头信息转换为 CGI 环境变量格式。HTTP 头的值成为新环境变量的值。

特定于 PD 的 HTTP 头字段	CGI 环境变量等式	描述
iv-user =	HTTP_IV_USER =	客户机的短名或长名。如果客户机未认证（未知），则缺省值为“Unauthenticated”。
iv-groups =	HTTP_IV_GROUPS =	客户机所属的组的列表。由逗号分隔的引号引起来的条目构成。
iv-creds =	HTTP_IV_CREDS =	代表 Tivoli Access Manager 凭证的已编码不透明数据结构。向远程服务器提供凭证，这样中间层应用程序就可以使用授权 API 调用授权服务。请参阅 IBM Tivoli Access Manager Authorization C API Developer's Reference。

特定于 Tivoli Access Manager 的 HTTP 头条目可作为环境变量 HTTP_IV_USER、HTTP_IV_GROUPS 和 HTTP_IV_CREDS 用于 CGI 程序。 有关其它应用程序框架产品，请参阅产品文档以获得从 HTTP 请求抽取头的指导信息。

-c 语法

-c 选项指定了发送何种特定于 Tivoli Access Manager 的 HTTP 头数据至后端应用程序服务器。

-c <header-types>

header-types 参数包括：all、iv_user、iv_user_l、iv_groups 和 iv_creds。

参数	描述
iv_user	提供在请求的 HTTP 头中作为 iv-user 字段的用户名（短格式）。
iv_user_l	提供在请求的 HTTP 头中作为 iv-user 字段的用户完整 DN（长格式）。
iv_groups	提供在请求的 HTTP 头中作为 iv-groups 字段的用户组列表。
iv_creds	提供在请求的 HTTP 头中作为 iv-creds 字段的用户凭证信息。

注:

使用 iv-user 或 iv-user-l，但不要同时使用它们。

-c all 选项将所有三种类型的身份信息插入到 HTTP 头中（在这种情况下使用短名称格式，iv_user）。

注:

仅使用逗号分隔多个参数。不要输入空格。

示例：

-c all

-c iv_creds

-c iv_user,iv_groups

-c iv_user_l,iv_groups,iv_creds

注:

有关如何配置高速缓存 -c 联结信息的环境变量的描述，也请参阅《 IBM Tivoli Access Manager 性能调整指南》中的 WebSEAL 部分。通过应用此高速缓存配置可能提高 -c 联结情况下的 WebSEAL 性能。

在 HTTP 头中提供客户机 IP 地址（-r）

-r 选项允许将客户机 IP 地址信息插入到以联结的应用程序服务器为目的地的请求的 HTTP 头。HTTP 头信息使联结的第三方服务器上的应用程序能够基于此 IP 地址信息执行操作。

HTTP 头信息必须由后端服务器变换为环境变量格式，以便由后端服务器上的服务使用。头信息通过用下划线（_）代替所有破折号（-）并在字符串的开始处添加“HTTP”而变换为 CGI 环境变量格式。HTTP 头的值成为新环境变量的值。

注:

IP 地址的值并不总是表示源客户机的地址。IP 地址值可表示代理服务器的地址或网络地址转换程序（NAT）。

特定于 PD 的 HTTP头字段	CGI 环境变量等式	描述
iv-remote-address	HTTP_IV_REMOTE_ADDRESS	客户机的 IP 地址。该值可表示代理服务器的 IP 地址或网络地址转换程序（NAT）。

-r 选项指定发送到后端应用程序服务器的进入请求的 IP 地址。该选项没有任何参数。

限制 WebSEAL 生成的 HTTP 头的大小

可以限制插入到联结的后端服务器的请求中的 WebSEAL 生成的 HTTP 头的大小。webseald.conf 配置文件的 [junction] 节中的 max-webseal-header-size 参数指定了 WebSEAL 生成的 HTTP 头的最大大小（字节）。值“0”将禁用该功能：

[junction]
max-webseal-header-size = 0

如果后端应用程序服务器因为 WebSEAL 生成的 HTTP 头太大而拒绝它们，此参数是非常有用的。例如，属于许多组的某个用户的 iv-creds 头可能会太大。

在配置时，此参数会将使超出最大值的 WebSEAL 生成的头分割成多个头。以下 CGI 应用程序的输出示例阐述了分割头的结果：

HTTP_IV_CREDS_1=Version=1, BAKs3DCCBnMMADCCBm0wggZpAgIDkDCCAYUwKzA
HTTP_IV_CREDS_2=+0+8eAgI8iAICEdYCAgCkAgFUBAaSVNCJqncMOWNuPXNlY21==
HTTP_IV_CREDS_SEGMENTS=2

如果启用此功能，必须修改后端应用程序来识别分隔头，而不是标准的特定于 WebSEAL 的 HTTP 头。

将会话 cookie 传递到联结的门户网站服务器（-k）

Web 门户网站是提供一批广泛的个性化资源和服务的服务器。-k 选项允许您将 Tivoli Access Manager 会话 cookie（最初在客户机和 WebSEAL 之间建立）发送到后端门户网站服务器。目前情况下，该选项的存在是为了直接支持 WebSEAL 和 Plumtree Corporate Portal 解决方案的集成。

当客户机从门户网站服务器请求个人资源列表时，门户网站服务器通过访问位于其它支持应用程序服务器（同时受 WebSEAL 保护）的资源，来构建此列表。会话 cookie 允许门户网站服务器代表客户机无缝单一注册到这些应用程序服务器。

创建 WebSEAL 和后端门户网站服务器之间的联结时，请包含不带参数的 -k 选项。

门户网站服务器配置需要考虑的条件：

• 对于通过用户名和密码的访问，需要格式认证。请不要使用基本认证（BA）。
• 必须将 webseald.conf 配置文件的 [session] 节中的 ssl-id-sessions 参数设置为“no”。对于 HTTPS 通信，此设置强制使用会话 cookie（而不是 SSL 会话标识）来维护会话状态。
• 如果门户网站服务器是 WebSEAL 群集的前端服务器，请启用故障转移类型 cookie。故障转移 cookie 包含加密的凭证信息，该信息允许认证对于处理请求的任何复制的 WebSEAL 服务器都为成功。

支持不区分大小写的 URL（-i）

缺省情况下，当对访问控制执行检查时，Tivoli Access Manager 区分大小写处理 URL。-i 选项用来指定在对已联结的后端服务器的请求执行授权检查时，WebSEAL 不区分大小写处理 URL。

当在联结上设置该选项时，WebSEAL 在分析 URL 时不区分大写和小写字符。 缺省情况下，Web 服务器期望区分大小写。

虽然大部分 HTTP 服务器支持将 URL 定义为区分大小写的 HTTP 规范，但是某些 HTTP 服务器对 URL 不区分大小写。

例如，在不区分大小写的服务器上，以下两个 URL：

http://server/sales/index.htm

http://server/SALES/index.HTM

可看作同一个 URL。 这种行为需要管理员对两个 URL 放置相同的访问控制（ACL）。

通过使用 -i 选项联结第三方服务器，WebSEAL 不区分指向该服务器的 URL 的大小写。

状态保存联结支持（-s, -u）

大多数启用 Web 的应用程序为来自客户机的一系列 HTTP 请求维护“状态”。该状态用于，例如：

• 通过 CGI 程序生成的数据条目格式字段跟踪用户进度
• 在执行一系列数据库查询时，维护用户的上下文
• 在在线购物车应用程序中维护商品列表，用户可以自由浏览和选择商品来购买

可复制运行启用 Web 应用程序的服务器，以便通过负载分配提高性能。 当 WebSEAL 服务器提供到这些复制的后端服务器的联结时，它必须保证客户机会话内包含的所有请求都被转发到正确的服务器，而不是根据负载平衡规则在已复制的后端服务器中分布。

缺省情况下，Tivoli Access Manager 通过在所有可用的复制服务器上分发请求来均衡后端服务器负载。Tivoli Access Manager 使用“最空闲（least-busy）”算法。此算法将每个新的请求定向到已有连接数最少的服务器。

create 命令 -s 标志覆盖此负载平衡规则并创建“状态保存联结”，该联结确保在整个会话期间将客户机请求都转发到同一个服务器。在发生初始客户机请求时，WebSEAL 就在包含指定后端服务器的 UUID 的客户机系统上放置一个 cookie。当客户机将来对相同资源进行请求时，cookie 的 UUID 信息确保请求始终路由到相同的后端服务器。

-s 选项适用于多个后端服务器在同一联结点联结到单个前端 WebSEAL 服务器的情况。请注意，一旦将初始联结创建为状态保存，则使用不带 -s 选项的 add 命令，从而将剩余的已复制的后端服务器联结到同一联结点。

如果该方案涉及多个联结到同一个后端服务器的前端 WebSEAL 服务器，必须使用 -u 选项将每个后端服务器 UUID 正确指定到每个前端 WebSEAL 服务器。请参阅为状态保存结点指定后端服务器 UUID（-u）。

为状态保存结点指定后端服务器 UUID（-u）

在创建到后端 Web 应用程序服务器的新联结时，WebSEAL 通常生成唯一全局标识符（Unique Universal Identifier，UUID）来标识后端服务器。该 UUID 在内部使用并用来维护状态保存联结（create -s）。

在发生初始客户机请求时，WebSEAL 就在包含指定后端服务器的 UUID 的客户机系统上放置一个 cookie。当客户机对相同资源作出进一步的请求时，cookie 的 UUID 信息确保请求始终路由到相同的后端服务器。

图形 28. 状态保存结点使用后端服务器 UUID

当多个前端 WebSEAL 服务器联结到多个后端服务器时，状态保存结点的处理将变得更加复杂。 通常，前端 WebSEAL 服务器和后端服务器之间的每个联结为后端服务器生成一个唯一的 UUID。 这意味着一个后端服务器在每个前端 WebSEAL 服务器上有不同的 UUID。

多个前端服务器需要负载平衡机制在两个服务器之间分布负载。例如，可以使用特定的 UUID 通过 WebSEAL 服务器 1 来建立到后端服务器的初始“状态”。

然而，如果来自同一客户机的后继请求用负载平衡机制通过 WebSEAL 服务器 2 路由，则该“状态”不再存在，除非 WebSEAL 服务器 2 使用相同的 UUID 来标识同一台后端服务器。 通常不会是这种情况。

-u 选项允许向每个前端 WebSEAL 服务器提供特定后端服务器的相同 UUID。

作为示例，考虑有两个复制的前端 WebSEAL 服务器，它们都具有到两个后端服务器的状态保存结点。 当创建 WebSEAL 服务器 1 和后端服务器 2 之间状态保存联结时，将生成唯一的 UUID（UUID A）来标识后端服务器 2。但是在创建 WebSEAL 服务器 2 和后端服务器 2 之间的状态保存联结时，将生成不同的新 UUID（UUID B）来标识后端服务器 2。

图形 29. 不同的 UUID

如果来自客户机的后继请求路由通过 WebSEAL 服务器 2，则通过 WebSEAL 服务器 1 在客户机和后端服务器 2 之间建立的“状态”将失败。

在联结创建期间，请应用以下进程来指定 UUID：

1. 创建从 WebSEAL 服务器 1 到每个后端服务器的联结。

   使用 create -s 和 add。

2. 列出在“步骤 1”中为每个后端服务器生成的 UUID。

   使用 show。

3. 创建从 WebSEAL 服务器 2 到每个后端服务器的联结并指定在“步骤 2”中标识的 UUID。

   使用 create -s -u 和 add -u。

下图中，WebSEAL-1 和 WebSEAL-2 都将后端服务器 1 识别为 UUID 1。WebSEAL-1 和 WebSEAL-2 都将后端服务器 2 识别为 UUID 2。

图形 30. 为状态保存结点指定后端服务器 UUID

示例：

在以下示例中，

• WebSEAL-1 称为 WS1
• WebSEAL-2 称为 WS2
• 后端服务器 1 称为 APP1
• 后端服务器 2 称为 APP2

pdadmin> server task webseald-WS1 create -t tcp -h APP1 -s /mnt
pdadmin> server task webseald-WS1 add -h APP2 /mnt
pdadmin> server task webseald-WS1 show /mnt

（这将显示 UUID1 和 UUID2）

pdadmin> server task webseald-WS2 create -t tcp -h APP1 -u <UUID1> -s /mnt
pdadmin> server task webseald-WS2 add -h APP2 -u <UUID2> /mnt

当客户机与后端服务器 2 建立状态保存结点时，它将接收到包含 UUID 2 的 cookie。 以上示例确保客户机总是连接到后端服务器 2，而不管以后的请求是通过 WebSEAL-1 还是 WebSEAL-2 路由的。

联结到 Windows 文件系统（-w）

WebSEAL 对客户机端请求执行安全性检查，这些请求是向基于 URL 中指定的文件路径中的联结后端服务器提出的。因为 Win32 文件系统提供访问长文件名的两种不同方法，在安全检查中可能发生危及安全的行为。

第一种方法确认完整的文件名。例如：

abcdefghijkl.txt

第二种方法为向后兼容性识别旧的 8.3 文件名称格式。例如：

abcdef~1.txt

在 Windows 环境中创建联结时，将访问控制仅限于一个对象表示法并且不允许绕过安全机制“后门”的可能性，这是非常重要的。

联结上的 -w 选项提供了以下保护措施：

• 阻止 8.3 文件名格式的使用

  当使用 -w 选项配置联结时，用户不能通过使用短文件名格式（8.3）避免长文件名上的显式 ACL。对于输入的任何短格式文件名服务器会返回“403 禁止访问”的错误消息。

• 禁止目录和文件名中有尾随点

  如果文件或目录末尾包含句点，将返回 403“禁止访问”错误消息。

• 通过设置 -i 选项来实施“不区分大小写”

  -w 选项自动调用 -i 选项。此选项指定，当 WebSEAL 执行对联结的后端服务器的请求的授权检查时，WebSEAL 不区分大小写处理 URL。成功的 ACL 检查后，当请求被发送到后端服务器时将恢复原始的 URL。

  注:
  如果只需要对文件名进行不区分大小写的控制，则在联结上只使用  -i 而非  -w 选项。

示例：

在 Windows 环境中，文件：

\Program Files\Company Inc\Release.Notes

还可以通过以下路径访问：

1. \progra~1\compan~2\releas~3.not
2. \Program Files\Company Inc.\Release.Notes
3. \program files\company inc\release.notes

示例 1 阐述了 Windows 如何创建别名（为了 DOS 兼容性），此别名在文件名中不包含空格并符合 8.3 格式。-w 选项导致 WebSEAL 拒绝使用此格式进行 ACL 检查。

示例 2 阐述了 Windows 如何包含尾随的扩展点。-w 选项导致 WebSEAL 拒绝使用此格式进行 ACL 检查。

示例 3 阐述了 Windows 如何允许文件名不区分大小写。-w 选项调用 -i 选项以确保不区分大小写的 ACL 检查。

使用 WebSEAL 联结的技术注释：

• 在同一个联结上安装多个服务器
• 跨联结实施许可权的例外
• 跨联结的证书认证
• 处理域 cookies

在同一个联结上安装多个服务器

可以在同一联结点安装多个复制服务器。 可以在同一点上安装任意多个服务器。

安装在同一联结点上的所有服务器必须为副本（镜像 Web 空间），并且必须使用相同的协议 — HTTP 或 HTTPS。 不要在同一联结点上安装不同的服务器。

从主 Tivoli Access Manager 服务器 Web 空间访问属于联结服务器的页面。 您应该可以访问这些页面（当然要根据许可权），并且这些页面应该显示一致。如果偶尔有页面找不到或更改，则意味着没有正确复制页面。

请检查该文档存在，并且复制服务器文档树中的文档相同。

跨联结实施许可权的例外

某些 Tivoli Access Manager 许可权不能跨联结实施。例如，不能使用 x 许可权控制 CGI 脚本的执行，也不能使用 l 许可权执行目录列表。 例如，WebSEAL 不能准确确定后端服务器上请求的对象是 CGI 程序文件、动态目录列表还是常规的 HTTP 对象。

跨联结访问对象（包括 CGI 程序和目录列表）只能通过 r 许可权进行控制。

跨联结的证书认证

安装时，WebSEAL 是使用非缺省测试证书配置的。测试证书通过 webseald.conf 配置文件的 [ssl] 节中的 webseal-cert-keyfile-label 参数指定为活动的服务器端证书。

如果联结的后端应用程序服务器要求 WebSEAL 使用客户机端的证书标识自己，则必须首先使用 iKeyman 实用程序创建、安装和标号该证书。然后，使用 -K <key-label> 选项配置联结。请参阅相互认证的 SSL 联结。

如果未使用 -K 配置联结，则 GSKit 通过自动发送包含在密钥文件数据库中的“缺省”证书，处理相互认证的请求。如果这不是所需的响应，则必须确保密钥文件数据库（pdsrv.kdb）中没有标记为“缺省”（星号）的证书。

总结：

• 使用标号名称标识所有需要的证书。
• 不要将密钥文件数据库中的任何证书标记为“缺省”。
• 使用 webseal-cert-keyfile-label 参数控制 WebSEAL 服务器端的证书响应。
• 通过 -K 联结选项控制 WebSEAL 客户机端证书响应。

处理域 cookies

webseald.conf 配置文件的 [session] 节中的 allow-backend-domain-cookies 参数允许您控制 WebSEAL 处理 cookie 头中的域属性的方式。

当该参数设为“no”时，WebSEAL 执行“尾匹配”（tail matching）来决定该域（作为属性包含在 cookie 头中）是否有效。如果 cookie 头中的域有效，则该 cookie 发送到浏览器，并且域属性从 cookie 头除去。 当浏览器接收到没有域属性的 cookie 时，它仅将 cookie 返回给源服务器。如果“尾匹配”确定 cookie 头中的域无效，则 cookie 不发送到浏览器。浏览器无 cookie 返回。

[session]
allow-backend-domain-cookies = no

当该参数设为“yes”时，WebSEAL 不执行“尾匹配”并允许所有 cookies 发送到浏览器（而不管域属性的值）。浏览器可将 cookies 返回到适当的服务器。

[session]
allow-backend-domain-cookies = yes

在第三方服务器上使用 query_contents

如果要使用 Tivoli Access Manager 安全服务保护第三方应用程序 Web 空间的资源，必须向 WebSEAL 提供有关第三方 Web 空间内容的信息。

名为 query_contents 的 CGI 程序将提供该信息。query_contents 程序搜索第三方 Web 空间内容并将该库存信息提供给 WebSEAL 上的 Web Portal Manager。 WebSEAL 安装程序自带该程序，但是必须手工地在第三方服务器上安装。根据第三方服务器是在运行 UNIX 还是 Windows，有不同的程序文件类型可用。

每当代表联结的受保护对象空间部分在“对象空间”管理面板上展开时，Web Portal Manager 的“对象空间”管理器将自动运行 query_contents。既然 Web Portal Manager 知道有关第三方应用程序空间的内容，您可以显示此信息并对适当的对象应用策略模板。

安装 query_contents 组件

通常，安装 query_contents 比较容易。安装涉及从 Tivoli Access Manager 服务器复制一个或两个文件到第三方服务器以及编辑配置文件。

以下 Tivoli Access Manager 目录包含了程序模板：

UNIX：

<install-path>/www/lib/query_contents

Windows：

<install-path>\www\lib\query_contents

目录内容包括：

文件	描述
query_contents.exe	用于 Win32 系统的主可执行程序。应该安装在第三方 Web 服务器的 cgi-bin 目录下。
query_contents.sh	用于 UNIX 系统的主要可执行程序。应该安装在第三方 Web 服务器的 cgi-bin 目录下。
query_contents.c	源代码。提供源代码是为了满足万一您需要更改 query_contents 的行为。大多数情况下，这是不必要的。
query_contents.html	HTML 格式的帮助文件。
query_contents.cfg	标识 Web 服务器文档根的样本配置文件。

在第三方 UNIX 服务器上安装 query_contents

在以下目录中查找名为 query_contents.sh 的外壳程序脚本：

<install-path>/www/lib/query_contents

1. 将 query_contents.sh 复制到第三方 Web 服务器上正常运行的 /cgi-bin 目录中。
2. 将 .sh 扩展名从文件名除去。
3. 手工编辑脚本文件以正确指定 doc 根目录。
4. 为 Web 服务器的管理帐户设置 UNIX 执行位。

在第三方 Win32 服务器上安装 query_contents

Windows 的特殊联结选项：

如果您需要并在后端联结的 Windows Web 应用程序服务器上安装 query_contents 程序，则当创建到此服务器的联结时必须使用 -q 选项。

此要求的原因是在缺省情况下，WebSEAL 在 cgi-bin 目录中查找 query_contents 程序：

/cgi-bin/query_contents

如果更改了 query_contents 程序的名称或者更改了其目录位置， 您必须在创建联结时使用 -q <location> 选项。位置参数指定了程序的新位置和名称。

在 Windows 平台上使用的 query_contents 程序的名称为 query_contents.exe。.exe 扩展名的存在使程序名称有所不同。因此，WebSEAL 无法找到缺省的程序名。必须使用 -q <location> 选项及参数以便告诉 WebSEAL 在何处查找该文件。例如：

create -t tcp -h <host-name> ... -q /cgi-bin/query_contents.exe /<junction-name>

UNIX 服务器不要求 -q 选项，因为 query_contents 程序名称和位置匹配缺省条件。

过程：

在以下目录中，定位名为 query_contents.exe 的可执行程序和名为 query_contents.cfg 的配置文件：

Windows： <install-path>\www\lib\query_contents

1. 请确保第三方 Web 服务器具有正确配置的 CGI 目录。
2. 为了测试目的，请确保第三方 Web 服务器上的文档根中存在有效的文档。
3. 将 query_contents.exe 复制到第三方 Web 服务器的 CGI 目录中。
4. 将 query_contents.cfg 复制到 Windows 目录。

   此目录的缺省值如下表所示：

   操作系统	Windows 目录
   Windows 95 和 98	c:\windows
   Windows NT 4.x 和 2000	c:\winnt

5. 编辑 query_contents.cfg 文件以正确指定第三方 Web 服务器的文档根目录。

   该文件包含 Microsoft Internet Information Server 和 Netscape FastTrack 服务器的示例条目。 在此文件中，以分号（;）开始的行是注释并被 query_contents 程序忽略。

6. 创建到后端 Windows 服务器的联结并使用 -q 选项来指定 query_contents.exe 作为正确的文件。例如：

   pdadmin> server task webseald-<instance-name> create -t tcp -h <host-name> ... \
   -q /cgi-bin/query_contents.exe /<junction-name>

测试配置

1. 在 Win32 机器的 MS-DOS 提示符下，执行 CGI 目录中的 query_contents 程序，如下所示：

   MSDOS> query_contents dirlist=/

   应当出现与以下输出相似的内容：

   100
   index.html
   cgi-bin//
   pics//

   数字 100 是表示成功的返回状态。 最重要的是至少要看见数字 100 是第一个值（并且可能是唯一的一个）。

   如果看见的是错误码，则该配置文件不在正确的位置或者不包含有效的文档根条目。 检查 query_contents.cfg 文件的配置，并确保文档根存在。

2. 在浏览器中，输入以下 URL

   http://<win32-machine-name>/cgi-bin/query_contents.exe?dirlist=/

   该命令将返回与上述步骤相同的结果。 如果不返回该结果，则 Web 服务器的 CGI 配置不正确。请查阅服务器的文档以更正该问题。

定制 query_contents

query_contents 的任务是返回包含在 URL 请求中的目录内容。

例如，要获得服务器 Web 空间根目录的内容，浏览器使用如下方式在 URL 上运行 query_contents：

http://third-party-server/cgi-bin/query_contents?dirlist=/

query_contents 脚本执行以下操作：

1. 读标准 CGI 环境变量 $SERVER_SOFTWARE 以确定服务器类型。

   基于 Web 服务器类型，将变量 $DOCROOTDIR 设置成典型的文档根位置。

2. 从请求的 URL 中读取环境变量 $QUERY_STRING，以获得请求的操作并获取对象路径。

   操作值存储在变量 $OPERATION 中，对象路径存储在 $OBJPATH 中。 在以上示例中，$OPERATION 是 dirlist 而 $OBJPATH 是“/”。

3. 在对象路径上执行目录列表（ls）并将结果输出到标准输出，以便 Tivoli Access Manager 服务器使用。 表示子目录的条目具有附加的双斜杠（//）。

   典型的输出如下：

   100
   index.html
   cgi-bin//
   pics//

   数字 100 是表示成功的返回状态。

定制文档根目录

UNIX：

要定制 UNIX 服务器的 query_contents.sh，可能需要修改文档根目录的设置。

如果 query_contents 返回错误状态（不同于 100 的数），并且没有文件列出，请检查脚本并在必要时修改 $DOCROOTDIR 变量，以匹配服务器配置。

如果正确指定了文档根目录但脚本仍然失败，则可能是 cgi-bin 位置规范不正确。检查 $FULLOBJPATH 变量并修改分配给它的值，以反映正确的 cgi-bin 位置。

Windows：

要定制 Windows 服务器的 query_contents.exe，请修改 query_contents.cfg 文件。

附加功能

query_contents 程序的源代码（query_contents.c）随 Tivoli Access Manager 分发，无须授权。

可向该程序添加附加功能，以支持某些第三方 Web 服务器的特殊功能。 这些功能包括：

• 目录映射 — 将不在文档根下的子目录映射到 Web 空间。
• 不基于文件系统的 Web 空间的生成。

  这可能是主管数据库的 Web 服务器的情况。

保护 query_contents

Tivoli Access Manager 使用 query_contents CGI 程序来显示 Web Portal Manager 中联结的 Web 服务器对象空间。保护该文件以防止未授权的用户运行是很重要的。

必须设置安全策略，仅允许 policy server（pdmgrd）标识可以访问 query_contents 程序。以下示例 ACL（query_contents_acl）满足此条件：

group ivmgrd-servers Tl

user sec_master dbxTrlcam

使用 pdadmin 实用程序将此 ACL 附加至联结服务器上的 query_contents.sh（UNIX）或 query_contents.exe（Windows）对象。例如（UNIX）：

pdadmin> acl attach /WebSEAL/<host>/<junction-name>/query_contents.sh \
query_contents_acl