将 IBM Tivoli Access Manager 3.9 与 WebSphere Application Server 集成在一起：一个完整的安全性解决方案

介绍

IBM® Tivoli® Access Manager for e-Business，版本 3.9（以前称为 Tivoli Policy Director），是一个安全管理应用程序，它为企业应用程序提供集中式的认证、授权和单次登录。版本 3.9 已经添加了一些新功能，当与 WebSphere® Application Server 4.02 或更高版本一起使用时，这些新功能可以为 WebSphere 托管的应用程序提供健壮的安全性。本文将讨论 IBM TivoliAccess Manager 带给 WebSphere Application Server 的重要安全性功能，首先讨论其中一些已经有一、两个版本可用的功能，最后讨论 IBM Tivoli Access Managers 带给 WebSphere Application Server 的新的基于 J2EE 角色的授权。我们还将讨论一些技术，这些技术能帮助 Access Manager 和 WebSphere Application Server 更好地在一起工作。

为什么要把 IBM Tivoli Access Manager 与 WebSphere Application Server 一起使用？

WebSphere 有它自己的安全性，但由于一些原因，WebSphere Application Server 要使安全管理在外部实现，由 Access Manager 为 WebSphere Application Server 和运行在其中的应用程序提供安全管理。Access Manager 使您能够把 WebSphere Application Server 和非 WebSphere Application Server 应用程序集中起来管理其安全性，这样就允许在整个企业实现完整的单次登录解决方案。

Access Manager 可以保护对资源的非 HTTP 和非 RMI/IIOP 访问，就象带 Access Manager 的 WebSphere MQ 队列可以保护对业务集成（Business Integration）的访问，带 Access Manager 的操作系统可以保护对操作系统的访问一样。这种访问使 WebSphere Application Server 能够加入广泛的、内聚的单次登录体系结构，如果让 WebSphere Application Server 管理自己的安全性的话，它是无法参与这么广泛的、内聚的单次登录体系结构的。

外部实现安全性还允许新旧应用程序都进行单次登录，使旧的应用程序能够加入相同的整体安全性体系结构。除了 WebSphere Application Server 自己的安全性，Access Manager 提供了统一、灵活的高度安全管理，利用高性能且很灵活的体系结构，不仅扩展为包括基于规则的决策，而且可以与现有的用户注册数据和授权数据库集成。

Access Manager 为 WebSphere 带来了哪些安全性功能？

Access Manager 与许多应用程序、应用程序服务器、门户网站集成在一起，并且它还提供 C 和 Java™ 授权 API，这些 API 可以被定制的安全性应用程序使用。WebSphere 品牌的产品，除 WebSphere Application Server 外，Access Manager 还可以与下面这些产品集成在一起。

• WebSphere Edge Server
• WebSphere Everyplace Access
• WebSphere MQ 和 MQI
• WebSphere Portal Server

现在，我们只讨论 WebSphere Application Server。Access Manager 为 WebSphere Application Server 提供的重要安全性功能有：

• WebSEAL 提供的用户认证
• 为使用 WebSEAL 进行单次登录提供的轻量级第三方认证（Lightweight Third-Party Authentication，LTPA）支持
• 共享的用户注册表功能
• 供编程之用的 Java 安全性类
• 运行在 WebSphere Application Server 上的 Java 管理应用程序
• 单次登录到基于表单的登录
• 一个代替内置的 WebSphere Application Server 安全性的 J2EE 授权模块

本文将逐个描述这些安全性功能，对一些功能的描述可能要比其它的深入一些，但最关注的还是 Access Manager 为 WebSphere Application Server 提供的 J2EE 授权。

什么是 WebSEAL？

WebSEAL 是 Access Manager 的 Web 逆向代理安全服务器（Web reverse proxy security server，RPSS）组件。下图 1 显示了 RPSS 怎样嵌入在 Web 体系结构中。

图 1. Web 逆向代理安全性服务器在 Web 体系结构中的位置

逆向代理服务器是一个侦听 HTTP 端口的 Web 服务器，通常侦听 HTTP 端口 80，用于要求特殊 URI 的请求，防止对这些 URI 进行直接访问。逆向代理服务器位于非保护区，并要求内部防火墙（在图表的右侧）中有较少的洞，因为它只需传送 HTTP 和 HTTPS。逆向代理服务器向 DMZ 后（或 DMZ 内部）的 Web 服务器转发请求。它一直跟踪自己保护的 IP 地址，并在发送请求前把该请求的目标地址更改为实际的目标地址。RPSS 可以在转发请求前提供认证和授权。

在这个体系结构中，WebSEAL 位于外部和内部防火墙之间的 DMZ 内，并接收发往 Web 服务器或应用程序服务器 WebSphere 的请求。在 WebSEAL 和 Web 服务器及应用程序服务器之间有四种安全性选择。

• WebSEAL 负责用户认证以及把映射的凭证传送给 WebSphere。WebSphere 用它自己的用户注册表执行授权。
• 与第 1 种选择一样，但 WebSEAL 和 WebSphere 共享用户注册表。
• WebSEAL 还执行授权，但要通过运行一个访问目录内容的 CGI 程序（query_contents）来确定受保护的文件。
• WebSEAL 处理认证，运行在 WebSphere Application Server 中的应用程序使用 Access Manager Java PDPermission 或 Access Manager JAAS 类管理它们自己的授权。这些 API 将授权控制权交还给 Access Manager。

在本文的后面部分，我们将讨论第五种选择。

第二种情况是一个很常见的实现。WebSEAL 执行认证，而 WebSphere 处理它自己的授权需要。一个共享的用户注册表能除去重复的数据。要了解更多信息，请参阅共享的用户注册表部分。

您可能想知道 WebSEAL 是如何连接到 WebSphere 的。WebSEAL 被配置通过“智能联接”与它后面的 Web 服务器或应用程序服务器交谈，“智能联接”是请求 URL 的一部分，指示 WebSEAL 将 URL 路径的其余部分转发到后端 Web 服务器或应用程序服务器。智能联接

• 允许将多个服务器（WebSEAL 或第三方的）集成到一个统一的 Web 空间内。
• 将 Access Manager 安全性扩展到第三方的 Web 服务器。WebSEAL 提供认证和授权检查及强制服务。
• 允许 Web 群集增长，并提供负载平衡和容错 HTTP 以及 HTTPS 联接。
• 向后端服务器提供 TCP 和 SSL 连接。

可以把智能联接配置为允许 WebSEAL 在把请求传送给后面的 Web 服务器之前修改请求的头内容和基本的认证凭证。也就是说，WebSEAL 可以决定如何转发用户标识和密码。

下表 1 显示了创建联接时的四个基本认证配置选项

表 1. 用于 BA 头的 WebSEAL 联接选项

–b ignore	向 Web 服务器“原样”转发用户的用户标识和密码
–b GSO	从 GSO 数据库检索用户访问特定目标所需的相应用户标识和密码对，并将它们转发到目标 Web 服务器。
–b filter	将用户的用户标识放在一个单独的 iv-user 头中，并将 WebSEAL 自己的用户标识和密码放在 basic-auth 头中。
–b supply	将用户的用户标识放在一个单独的 iv-user 头中，让用户的用户标识作为 basic-auth 用户名，但把一个假密码作为 basic-auth 密码。

图 2. 用 WebSEAL 配置的联接

在这张图中，如果 WebSEAL 接收到对 http://yourServer:80/supplyToWAS/abc/somepage.html 的请求，WebSEAL 将把带 /abc/somepage.html 的相同 HTTP 方法（GET、PUT 等）转发给 WebSphere。这里用的是 -b supply 选项，被发送到 Web 服务器或 WebSphere Application Server 的请求将有一个新的 iv-user 头，这个 iv-user 头包含用户的用户标识。

在上面的图 2 中，WebSphere Application Server 把用户认证委托给 WebSEAL，因此它需要确定一个请求是不是来自 WebSEAL 以避免二级认证。这种委托要求在 WebSphere Application Server 和 WebSEAL 之间建立一种信任关系或者信任关联。注意，“拦截器”（Interceptor）在上面的 WebSphere 中地位非常重要。这是一个 Web 信任关联拦截器（Web Trust Association Interceptor，TAI），WebSphere Application Server 加载这个类来建立对 WebSEAL 的信任，WebSphere Application Server 通过它相信 WebSEAL 早已经认证了用户。TAI 可以认出 WebSEAL 给请求添加的 iv-user 头，这个 iv-user 头包含用户最初的用户标识。如果 WebSphere Application Server 要求的话，这个拦截器还可以根据 iv-user 和其它请求头的值确定这是来自 WebSEAL 的请求，并可以提供用户身份。

TAI 只有三个方法，按下面这种顺序调用。

• public boolean isTargetInterceptor(HttpServletRequest req)
throws WebTrustAssociationException;
• public void validateEstablishedTrust(HttpServletRequest req)
throws WebTrustAssociationFailedException;
• public String getAuthenticatedUsername(HttpServletRequest req)
throws WebTrustAssociationUserException;

isTargetInterceptor() 确定请求是不是由 WebSEAL 发出的。因为可能有不止一个代理服务器在转发请求，所以这个方法要确保使用了相应的、正确的拦截器。validateEstablishedTrust() 被调用来认证 WebSEAL（或另一个代理服务器）。现在，要调用的就是 getAuthenticatedUsername()，得知请求确实来自 WebSEAL，并且 WebSEAL 已经对用户进行过认证。

在这种情况下，WebSphere Application Server 仍将对请求应用其授权策略。请参阅 WebSphere Application Server InfoCenter，了解关于如何配置 WebS