TAM webseal 联结 junction

摘自IBM 文库
WebSEAL 联结
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 ta sk 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
/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.da ：
pdadmin> server task webseald-<instance-name> create -t ssl -h \
/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. W ebSEAL 认证后端服务器（正常的 SSL 进程）
o WebSEAL 验证来自后端服务器的服务器证书。

请参阅WebSEAL 验证后端服务器证书。

o WebSEAL 验证包含在证书中的专有名称（DN）（-D）（可选，但强烈建议），请参阅专有名称（DN）匹配。

2. 后端服务器认证 WebSEAL（两种方法）
o后端服务器验证来自 WebSEAL 的客户机证书（-K）。

请参阅使用客户机证书的WebSEAL 认证。

o后端服务器验证在基本认证（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 服务器：
TCP 代理联结示例（作为一行输入）：
pdadmin> server task webseald-<instance-name> create -t tcpproxy \
-H clipper -P 8081 -h -p 80 /ibm
SSL 代理联结示例（作为一行输入）：
pdadmin> server task webseald-<instance-name> create -t sslproxy \
-H clipper -P 8081 -h -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 如下所示：
/file.html
WebSEAL 作为前端逆向代理，通过 WebSEAL 联结功能为后端应用程序服务器提供安全服务。

此功能导致通过不同的 URL 表达式访问资源。

例如（WebSEAL 环境），客户机输入的在一个联结的后端应用程序服务器上的同一资源的 URL 必须如下所示：
/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 表达式示例：
/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-type s]节配置其它的 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：
o如果 URL 是 HTTP 并且主机／端口与 TCP 联结的服务器匹配，则将 URL 修改为到 WebSEAL 的相对于服务器的 URL 并反映联结点。

例如：
http://<host-name>[:<port>]/file.html
变为：
/tcpjct/file.html
o如果 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. W ebSEAL 将原始Content-Length 头的值放置在称为X-Old-Content-Length 的新的头中。

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

2. W ebSEAL 在request.log文件中记录更改过的（过滤后的）Content-Length 值。

3. C ontent-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 ...。