将 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，了解关于如何配置 WebSphere Application Server 和 WebSEAL 之间的信任关联的详细信息。

下图 3 显示了一个创建智能联接的示例。

图 3. 创建一个 WebSEAL 联接

在下面的图 9 的底部，Access Manager 受保护的对象空间内还显示了 supplyToWAS 联接。参数指定 WebSEAL 应该添加所有与用户相关的头，联接类型应该是 TCP 联接而不是 SSL，目标主机是 miller-t21，端口为 9080，以及联接应该被命名为 /supplyToWAS。

然后，当 WebSphere Application Server 放心地让 WebSEAL 提供认证，而自己执行授权时，完整的流程如下面的图 4 所示。

图 4. 安全流程

WebSEAL 先接收请求，然后提问并认证用户，把联接的凭证格式放入请求的头中。请求是经过 Web 服务器传送给 WebSphere Application Server 的，然后该服务器负责授予请求者对 servlets 和 EJB 的访问权。

图 5 显示如果我们使用 -b supply 选项把 WebSEAL 与 WebSphere Application Server 联接起来，请求头会是什么样。

图 5. 使用 –b supply 的请求头

当用户 Gianluca 访问主机 oleg1 上的 HeaderDumperServlet 时，基本的授权头将“gianluca”作为用户标识，但 Gianluca 的密码已经被删掉了，代替它的是存储在 webseald.conf 文件中的密码“pqssw0rd”。webseald.conf 是 WebSEAL 的配置文件，它必须驻留在受保护的目录中。在创建联接时，WebSEAL 已经根据“–c all”选项添加了 iv-user、iv-groups 和 iv-creds 头。iv-user 包含 WebSphere Application Server 请求时 TAI 返回的用户标识。Gianluca 是高手组的一个成员，用 iv-groups 头来标识。

Access Manager 3.9 还为早已在 DMZ 使用 Web 服务器的客户提供了 WebSEAL 的替身。Web Server Plug-In 可以提供许多与 WebSEAL 相同的功能。目前支持的 Web 服务器是 Windows® 2000 Server 的 IIS 5.0、Solaris 7 的 iPlanet 6.0 和 AIX® 5L 的 IBM HTTP Server 1.3.19。更多的支持即将出现。

Access Manager 中的 LTPA 支持

轻量级第三方认证（Lightweight Third-Party Authentication，LPTA）是 IBM 的一种基于使用代表用户凭证的令牌的技术。据说，“第三方”给人的感觉是信任是建立在“第三方” LTPA 服务器负责用户认证和令牌创建的基础上，而不是基于直接在两台服务器之间共享的密钥。

在没有 WebSEAL 的环境中，进行用户认证时，这种令牌是由 WebSphere Application Server 创建的，并存储在一个 cookie 中，这个 cookie 随 HTTP 响应一起被传送回浏览器。在这个用户后来再访问时，将该令牌从这个 cookie 中抽取出来，并用它来认证用户。这样，用户只需输入一次用户标识和密码，此后 LTPA 令牌就可以标识他们。用户在访问 Lotus Domino 资源时也不需要重新认证。

这种方法有两个缺点：

• 只有 WebSphere Application Server 和 Domino 支持 LTPA，LTPA 还没被业界广泛接受。Kerberos 是使用更为普遍的第三方认证机制。
  
  
• 用户的凭证（以令牌的形式）被一路发送回浏览器，然后再随请求发送回服务器。这样就比较容易受到攻击，尤其是在浏览器和 Web 服务器之间没有使用 SSL 的时候。

下图 6 显示了 WebSEAL 如何解决第二个缺点。

图 6. 用 WebSEAL 进行 LTPA

假设 WebSEAL 和 WebSphere 的 Web 服务器之间有预先配置好的信任，可能会使用每一方的 X5.09 证书来建立一个 SSL 会话：

	用户请求一个受保护的资源。 对用户进行认证提问。 用户认证要通过输入自己的用户标识和密码，或者也可能使用证书。
	WebSEAL 使用 LDAP 注册表中的信息对用户进行认证。
	WebSEAL 签发一个 LTPA 令牌，高速缓存它，并将其与请求一起发送到 Web 服务器，然后再发送到 WebSphere Application Server。
	WebSphere Application Server 接受令牌，允许请求者访问所请求的资源。 WebSEAL 通过将 SSL 会话标识或者进入的用户请求的其它 cookie 映射到 LTPA 令牌来维护状态，并且每次都将它们发送到 WebSphere Application Server。

使用 WebSEAL 时，令牌永远不会发送到浏览器，这样就避免了尽管很小但却是潜在的安全性弱点。在 WebSEAL 和 WebSphere Application Server 之间建立信任时，信任关联拦截器机制要优于 LTPA，原因在于目前只有 WebSphere Application Server 和 Domino 支持 LTPA，而 TAI 速度更快，因为不必每次都对令牌进行加密、解密。

共享的用户注册表

WebSphere 可以与另一个应用程序共享同一个用户注册表，通常是通过更改其中一方使用的模式来实现的。当 WebSphere 与 Domino 共享同一个用户注册表时，它们双方都加入同一个单次登录安全性体系结构。WebSphere 也可以与 Access Manager 共享一个用户注册表，例如，WebSEAL 提供认证，而 WebSphere Application Server 授予请求者对资源的访问权。

WebSphere 具有对几个用户注册表的内置支持，这几个注册表显示在一个组合框内。（SecureWay 代表 IBM Directory Server。“SecureWay”一词已经不再使用了。）Access Manager 3.9 现在支持一组同样的用户注册表，并与 WebSphere 共享。具体说来，Access Manager 3.9 新添加了对下列产品的支持：

• Lotus Domino Server 5.0.4
• Windows 2000 Advanced Server 上的 Microsoft® Active Directory

除这些之外还有 IBM Directory Server 3.2.2（LDAP）和 iPlanet Directory Server 5.0。

图 7. 共享用户注册表

在 WebSphere Application Server 和 Access Manager 之间共享 LDAP 用户注册表有两种方法：

• Access Manager 可以导入 WebSphere Application Server 的缺省模式。
• 您可以将 WebSphere Application Server 中的设置改为 Access Manager 的缺省模式。

由于最简单的办法是先安装带 Access Manager 的 LDAP，然后再把 WebSphere Application Server 配置为与 Access Manager 使用同一个注册表，所以第二种选择就是最容易的。

为此，您必须把 WebSphere Application Server 使用的一些设置更改为访问 LDAP 目录。下图 8 显示了 LDAP Advanced Properties 对话框。要从 WebSphere Application Server Security Center Authentication 页面访问这个对话框，请先选择 LTPA 和 LDAP 启用该对话框的 LDAP Settings 部分，然后单击 Advancedunder LDAP Settings。

图 8. WebSphere Application Server Security Center LDAP Advanced Properties 对话框

必须从缺省 LDAP (SecureWay) 设置改为其它设置的两个域为：

• Group Filter — 把 (&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames))) 改为 (&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)
(objectclass=accessGroup)))
  
  
• Group Member ID Map — 把 groupOfNames:member;groupOfUniqueNames:uniqueMember 改为 groupOfNames:member;groupOfUniqueNames:uniqueMember;accessGroup:member

主要是把图 8 中显示的那些字符串添加到缺省值中。这使得 WebSphere Application Server 能够使用缺省的 Access Manager LDAP 模式，可以共享注册表。一旦修改了这些设置，下拉组合框将从 SecureWay 更改为 Custom。

供编程之用的 Java 安全性类

aznAPI 是一个 Open Group 标准的基于 C-/C++ 的授权 API，在此我们不讨论。除 aznAPI 的纯 Java 替换类之外，Access Manager 还为应用程序提供一个基于 JAAS 的 LoginModule（名为 com.tivoli.mts.PDLogin）和一个许可权类（名为 com.tivoli.mts.PDPermission）。

PDLoginModule 类用 Access Manager 管理认证。应用程序可以使用 PDLoginModule 对一个 Access Manager 用户进行认证，创建一个相应的 PDPrincipal 对象和一个包含用户凭证的 PDCredential 对象。PDPrincipal 类实现 java.security.Principal 接口。

可以用 PDPermission 访问决定授权的 Access Manager。PDPermission 可以定位当前的主体（Subject）、抽取认证信息并与 Access Manager 联系以确定该主体是否有权以特定的方式（读、写、调用等）访问资源。PDPermission 通过 SSL 访问 Access Manager 的授权服务器。Access Manager 将来的版本将提供本地访问。Servlet、EJB 或实用程序代码可以按照 JAAS 标准使用这些类。不过，非 JAAS 应用程序也可以使用它们。

PDPermission 的 API 相当简单。构造函数使用 Access Manager 的对象空间内的一个目标资源名和一种 Access Manager 访问方式或操作集作为参数。然后 Java2 安全管理器（Java2 Security Manager）检查许可权，如果不允许主体访问基于被请求操作的目标资源，Java2 安全管理器将抛出 AccessControlException 异常。清单 1 是一个非常简单的示例。

清单 1. 使用 PDPermission 类。

// The user wants read access to some resourcejava.security.Permission whatTheyWant   = new PDPermission("/some/resource", "r");try{   securityManager.checkPermission(whatTheyWant);   // They are allowed   ...}catch(AccessControlException ace){   // They are not allowed}

Access Manager 基于 Web 的管理

Web Portal Manager 是在 WebSphere 上运行的一种 J2EE Web 应用程序，而且是 Access Manager 3.9 的管理应用程序。至少在 Access Manager 3.9 的第一个发行版中，随 WebSphere Advanced Edition Single Server（AEs）提供了 WPM，但安装脚本要等到 WebSphere Application Server 的那个版本才能提供。但您可能想把它安装在 WebSphere Application Server AE 中，特别是当您在其它生产系统中管理 Access Manager 的时候更是如此。

为允许以正常、自动化的、面向 AEs 的安装方式将 WPM 安装到 WebSphere Application Server AE 中，您可以用自己的 BAT 文件代替缺省安装使用的 BAT 文件，用这些文件停止服务器，执行安装，并重新启动服务器。您需要创建的三个 BAT 文件是：

• StopServer.bat — 只提供停止 WebSphere Application Server AEs 的命令
• SEAppInstall.bat — 提供用于把应用程序安装到 WebSphere Application Server AEs 中的文件。我们的 SEAppInstall.bat 版本使用 XMLConfig 和 AMWPM.xml 把 pdwpm.ear 安装到 WebSphere Application Server AE 中。请参阅下面的清单 2。
• StartServer.bat — 也只是提供启动 WebSphere Application Server AEs 的命令。

用到了另外两个文件。AMWPM.xml 包含 Web Portal Manager 应用程序的配置信息，被 XMLConfig 用来安装应用程序。pdwpm.ear 是 WPM 应用程序本身。这两个文件都应该驻留在 %WAS_HOME%/installableApps 目录中。

把三个 BAT 文件放在 %WAS_HOME%/bin 目录中。StopServer.bat 和 StartServer.bat 都是长度为零的空文件。SEAppInstall.bat 如下面的清单 2 所示。

清单 2. WPM 的 SEAppInstall 的替换样本。

@echo offrem echo "Installing AM Web Portal Manager into WebSphere"@hostname > Samples.tmp@for /f "tokens=1" %%h in (Samples.tmp) Do set HOSTNAME=%%h@del Samples.tmp>nulcall "%WAS_HOME%/bin/setupCmdLine.bat"echo "Installing pdwpm.ear Enterprise Application"call "%WAS_HOME%/bin/XMLConfig.bat"    -import "%WAS_HOME%/installableApps/AMWPM.xml"    -adminNodeName %HOSTNAME%    -substitute "was.install.root=%WAS_HOME%;server_root=   %WAS_HOME%;com.ibm.ejs.sm.adminServer.primaryNode=%HOSTNAME%"rem echo "Regenerate the plugin-cfg.xml file"call %WAS_HOME%/bin/GenPluginCfg.bat -adminNodeName %HOSTNAME%rem echo ""echo "AM Web Portal Manager installation complete"

为简单起见，把应用程序安装到了缺省服务器中。AMWPM.xml 如下面的清单 3 所示。

清单 3. 把 pdwpm.ear 安装到 WebSphere AE 中的 XML 脚本。

<?xml version="1.0"?><!DOCTYPE websphere-sa-config SYSTEM    "file:///$XMLConfigDTDLocation$$dsep$xmlconfig.dtd" ><websphere-sa-config>   <enterprise-application action="create" name="PD Web Portal Manager">      <source-node>$com.ibm.ejs.sm.adminServer.primaryNode$</source-node>      <ear-file-name>$was.install.root$/installableApps/pdwpm.ear         </ear-file-name>      <enterprise-app-install-info>         <node-name>$com.ibm.ejs.sm.adminServer.primaryNode$            </node-name>         <ear-install-directory>$was.install.root$/installedApps/            PD_Web_Portal_Manager.ear</ear-install-directory>      </enterprise-app-install-info>      <application-binding>         <authorization-table/>         <run-as-map/>      </application-binding>      <web-module name="Access Manager Web Portal Manager">         <war-file>pdwpm.war</war-file>         <context-root>/pdadmin</context-root>         <module-install-info>            <application-server-full-name>               /NodeHome:$com.ibm.ejs.sm.adminServer.primaryNode$               /EJBServerHome:Default Server/</application-server-full-name>         </module-install-info>         <web-module-binding>            <virtual-host-name>default_host</virtual-host-name>         </web-module-binding>      </web-module>      <web-module name="AMWPM Delegate Administration">         <war-file>pdwpm_delegate.war</war-file>         <context-root>/delegate</context-root>         <module-install-info>            <application-server-full-name>               /NodeHome:$com.ibm.ejs.sm.adminServer.primaryNode$               /EJBServerHome:Default Server/</application-server-full-name>         </module-install-info>         <web-module-binding>            <virtual-host-name>default_host</virtual-host-name>         </web-module-binding>      </web-module>      <web-module name="AMWPM Self Registration">         <war-file>pdwpm_sampleReg.war</war-file>         <context-root>/register</context-root>         <module-install-info>            <application-server-full-name>               /NodeHome:$com.ibm.ejs.sm.adminServer.primaryNode$               /EJBServerHome:Default Server/</application-server-full-name>         </module-install-info>         <web-module-binding>            <virtual-host-name>default_host</virtual-host-name>         </web-module-binding>      </web-module>   </enterprise-application></websphere-sa-config>

（在查看时，有些代码行可能是折行的。）使用这些文件，您可以把 Web Portal Manager 安装到 WebSphere AE 中。

组成 Web Portal Manager 的 Web 模块有三个：pdadmin、delegate 和 register。pdadmin 是用于配置 WebSEAL 的主要应用程序。delegate 和 register 分别用于委托用户管理和自注册（self-registration）。

图 9. Web Portal Manager pdadmin 应用程序

单次登录到基于表单的登录

一般大家都认为单次登录是一件很不错的事情。通过这种方式，用户不必为必须反复的登录到他们在一天中想要访问的每个应用程序而生气。使用 WebSEAL 进行单次登录最好的一点是允许用户使用任意数目的认证机制，即使后端不支持这些认证机制也没关系。但上面讨论的 WebSEAL -b 单次登录选项全都是用于基本认证的 — 传递 BA 中的用户凭证和 HTTP 请求中的其它头。当一个希望加入单次登录环境的应用程序要求进行基于表单的登录时会发生什么事？好象是用户将不得不再手工登录一次。

不要烦恼，我们有解决方案！Access Manager 3.9 提供了一种基于表单的单次登录（forms-based single sign-on，FSSO）功能，使 WebSEAL 能够自动让一个早已认证过的 Access Manager 用户登录到使用 HTML 表单请求登录的后端应用程序。当启用 FSSO 时：

• WebSEAL 拦截由后端应用程序发起的认证过程。
• WebSEAL 提供登录表单所需的数据，并代表用户提交登录表单。
• WebSEAL 保存并恢复所有的 cookie 和头。
• 用户不知道又在进行登录。
• 后端应用程序不知道登录表单不是直接来自用户。

用户看不到来自后端应用程序的登录表单，不必重新通过后端应用程序的认证，仅仅因为应用程序使用的不是基本认证，而是基于表单的认证。

FSSO 分三部分。首先，WebSEAL 必须能够发现应用程序正在把登录表单发送给用户。虽然 WebSEAL 可以解析每个从应用程序发往用户的页面，并查找登录表单，但却有损性能。让 WebSEAL 直接或间接地（通过重定向）监视用户请求登录页面（比如 login.html）可能更容易。其次，在标识了页面和页面内的登录表单后，WebSEAL 必须能够填充表单并将其随任何隐藏的域、cookie 和请求头一起发送回应用程序，就象用户在自己的浏览器单击了 Submit 一样。最后，在用户登录以后，WebSEAL 必须将后端应用程序的响应传回用户，就好象用户自己执行了登录一样。

FSSO 是用一个配置文件安装的，该文件描述如何标识 WebSEAL 将要发现并处理的页面和登录表单。因而，必须为目标服务器创建一个联接，在这个服务器上登录页面和表单操作 URI 都是可访问的。该联接是通过用 -S 选项指定配置文件创建的。配置文件格式如下。

清单 3. FSSO 配置的模板文件

[forms-sso-login-pages]login-page-stanza =<first-login-page >#login-page-stanza =<second-login-page >#login-page-stanza =<third-login-page >[<first-login-page>]login-page =<regular-expression-page-match >login-form-action =<regular-expression-form-match >gso-resource =<gso-target >argument-stanza =<args-for-first-login-page >[<args-for-first-login-page>]<name >=<method >:<value >

这种文件常以 [forms-sso-login-pages] 开头。可以在同一个文件中标识多个登录页面，每个页面有一个相应的 login-page-stanza 条目。这使得单个服务器要为来自多个应用程序的登录页面服务，每个应用程序都要求不同的认证数据。

login-page 值是一个正则表达式，与用户请求登录时要访问的 URI 匹配。它与联接名相对，不包含联接名。login-form-action 是登录表单操作 URI，也是一个正则表达式。WebSEAL 使用这个值来标识登录页面上的表单。如果页面上只有一个表单，您可以将该值设置为 *。

如果没使用 GSO 存储用户名和密码，gso-resource 可以为空白。否则，要从 GSO 数据库检索那些内容就要使用 GSO 资源。argument-stanza 为包含一列定制的参数的节（stanza）命名，这些参数要随认证请求一起提交。

在定制的参数节中，名称参数的值被设置为等于 HTML“input”标记的“name”属性的值。按理可能会有：

• gso:username — GSO 中当前用户的用户名
• gso:password — GSO 中当前用户的密码
• cred:<name> — 凭证属性 <name> 的值
• string:<text> — 固定的文本

清单 4. FSSO 的 HTML 页面示例。

<html>   <form action="handleLogin.jsp" method="post">      <input type="hidden" name="dologin" value="yes">      <input type="hidden" name="countrySelect">      Username:<input type="text" name="userid"><BR>      Password:<input type="password" name="password">      <input type="submit" value="login">   </form></html>

下面是与清单 4 对应的示例文件：

清单 5. FSSO 配置的“fsso.conf”示例文件。

[forms-sso-login-pages]login-page-stanza = wpm-login#login-page-stanza = wpm-delegate#login-page-stanza = wpm-selfreg[wpm-login]login-page = /*/auth/handleLogin.jsplogin-form-action = handleLogin.jspgso-resource = wpm_ssoargument-stanza = wpm-login-args[wpm-login-args]userid = gso:usernamepassword = gso:passwordcountrySelect = string:897

如果登录还要求国家或地区代码的话，这个配置文件可能是用于 Web Portal Manager 自身的。相应的联接可能如下面的清单 6 所示：

清单 6. FSSO 的样本联接。

pdadmin> server task webseald-jonharr1 create -t tcp -h jonharr1 -p 81 -S "C:/Program Files/Tivoli/PDweb/etc/fsso.conf" /avery-junction3

单次登录到基于表单的登录使使用基于表单的认证的应用程序能够加入单次登录的环境。

代替 WebSphere Application Server 内置安全性的 J2EE 授权模块（J2EE Authorization Module）

早些时候，当我们讨论 WebSEAL 时，我们说过 Access Manager 和 WebSphere 之间的安全性集成还有第五种选择。到现在为止，我们主要讨论的情形都是 Access Manager 提供认证，而由 WebSphere Application Server 自己授权访问 servlet、JSP 和 EJB。我们也已经看过了运行在 WebSphere Application Server 上的应用程序如何使用 PDPermissions 类执行自己的授权。

Access Manager 最激动人心的新功能之一 — 首先被添加在 Policy Director 3.8 修订包 3 和 WebSphere Application Server 4.02 中 — 是 WebSphere Application Server 依靠 Access Manager 进行完整的基于 J2EE 角色的授权的能力。WebSphere Application Server 容器可以将这个职责委托给 Access Manager，使它能为 WebSphere Application Server 资源以及与 WebSphere Application Server 不相关的资源提供集中式安全性策略管理。如需要更多的关于基于 J2EE 角色的授权的信息，请参阅我的文章 Security in WebSphere Application Server Advanced Edition Version 4.0

用这种方法把 Access Manager 与 WebSphere Application Server 集成在一起的时候，Access Manager 确定用户是否具有访问被请求资源所需的任何角色。输入是一样的，但角色的成员资格现在由 Access Manager 管理。必须把 Access Manager 和 WebSphere Application Server 配置为共享一个用户注册表。

这种组合的优势有很多：

• 它使企业能够利用 Websphere 和非 WebSphere 资源上的公共安全性模型，此安全性模型具有公共用户身份和简档、基于 Access Manager 授权，与此同时，使用 Access Manager 的 Web Portal Manager 对 J2EE 和非 J2EE 应用程序实行单点安全管理。可以有一个管理接口，通过这个接口既可以管理静态内容访问（Web 服务器）又可以管理动态内容访问（角色和 JAAS）。
• 对于在 WebSphere Application Server 中运行的 J2EE 应用程序，集成是透明的，因为不需要对编码或部署进行应用程序级的更改。
• 它提供了通过单个“合理的”Access Manager 策略数据库动态管理多个 WebSphere Application Server 应用程序的“角色”关系的能力。这意味着，不需要重新启动应用程序就可以更改用户／组到角色的映射。Access Manager ACL 提供了比目前的 WebSphere 安全性实现要灵活得多的用户到角色策略集。
• 访问控制检查可以根据旧的授权表和／或规则引擎进行。
• 对于单个克隆的应用程序，每个服务器的访问控制都可以与其它机器的不同。
• 可以根据业务而不是技术来委托访问控制管理。
• 集中式日志记录可以与入侵检测系统集成在一起。
• 安全性支持是基于标准的：它遵守 J2EE 1.2 安全性规范（J2EE 1.2 Security Specification）。在 WebSphere 中，它将遵守 Java 规范请求（Java Specification Request，JSR）115。

PDWASAuthzManager.jar 中实现了与 WebSphere Application Server 的集成的 AMWAS 模块。这个 JAR 以及 PDPerm.properties、cacerts 和 pdperm.ks 在安装和配置过程中被复制到 %WAS_HOME% 目录结构中。AMWAS 模块依赖 Access Manager Java Runtime（PDJRTE）中的类，并使用 Java API 与 Access Manager 授权服务器通信。

角色到用户的映射存储在 Access Manager ACL 数据库中。访问决定受到了特定单元、主机或运行应用程序实例的服务器的进一步限制。AMWAS 不是角色到方法的映射。

图 10. Access Manager 的方块图 — WebSphere Application Server 集成

在上面的图 10 中，WebSphere Application Server 容器依靠 Access Manager 做出授权决定。它是这样工作的：

1. 当启用了安全性，并且一个未经认证的用户试图访问受保护的资源时，WebSphere Application Server（或 WebSEAL）根据与 Access Manager 共享的 LDAP 注册表对用户进行认证。
   
   
2. 然后 WebSphere Application Server 容器使用应用程序的 EJB 的部署描述符或 Web 模块中的方法许可权（method-permission）或安全性限制（security-constraint）确定访问资源所必需的角色。
   
   
3. 作为一种替代方法，如果应用程序本身使用编程实现的（programmatic）安全性比如 isCallerInRole()，那么就会使用与上面相同的机制。
   
   
4. 容器向 AMWAS 传送下列内容：
   • 主体（Principal）— 一个用户标识或者特殊的“每个人”的情况。AMWAS 将其映射到一个 Access Manager 用户或者一个“未经认证”的凭证。
   • 角色列表（List of Role）— 对于声明式安全性，角色列表是 WebSphere Application Server 从应用程序配置中（最初是从部署描述符中）获得的。对于编程实现的安全性，比如 isUserInRole(roleName)，这是个只包含一个角色的列表。
   • 上下文（Context）— WebSphere Application Server 传送给 AMWAS 的附加信息。这些信息包括应用程序名（appname）、单元名（cellname）、主机名（hostname）和服务器名（servername）。
     
     
5. 对于列表中的每个角色，AMWAS 都使用从提供的用户标识映射过来的凭证进行一次 PDPermission 调用，看看用户（或“未经认证的”）是否与该角色关联在一起。只要 Access Manager 策略数据库有为上下文信息指定的策略，授权服务器就可以在进行授权决定时使用这些信息。目前，这些 API 调用都是通过 SSL 进行的远程调用，但在 WebSphere Application Server 5.0 中，这些调用可以在本地 Access Manager 授权服务器上进行。
   
   
6. Access Manager 授权服务器从共享的 LDAP 目录检索用户和组成员资格信息，并在 Access Manager 保护的对象空间内检索为用户定义的许可权。
   
   
7. 只要用户被授予列表中的任何一种角色，就会返回 Yes。如果用户没有被授予任何角色，则返回 No。
   
   
8. WebSphere Application Server 相应地决定是许可还是拒绝对受保护资源的访问。

AMWAS 的安装和配置以及随后的应用程序安全性迁移的细节问题都不在本文的讨论范围内。但总之，这个过程需要进行下列操作。

• 安装 AMWAS。
• 配置 AMWAS。
• 迁移 WebSphere Application Server 管理应用程序。
• 迁移运行在 WebSphere Application Server 上的您想保护的其它应用程序。
• 管理 Access Manager 中的用户／组到角色的映射。

为使 AMWAS 能够管理运行在 WebSphere Application Server 上的应用程序的授权，必须将存储在应用程序的部署描述符中的安全性信息迁移到 Access Manager 中。迁移工具是一个单机 Java 应用程序，它使用 Access Manager Java Admin API 与 Access Manager 通信。该工具创建一个树，叶子是角色以及 Access Manager 中的访问控制列表（用户和组的 ACL，具有“调用”许可权的用户和组会被映射到角色），如下面的图 11 所示。由于迁移工具使用应用程序 EAR 的用户和组到角色的映射， 因此，需要重新导出已经在 WebSphere Application Server 中完全配置了这些信息的应用程序，以便将所有的映射放回 ibm-application-bnd.xmi 文件中。角色定义本身来自 application.xml。

提示 1：在导出时，很重要的一点是应用程序在 WebSphere Application Server 中的显示名称与应用程序 EAR 中的显示名称必须匹配。例如，如果一个企业应用程序的名称在 WebSphere Application Server Admin Console 中显示为“Banker 2001”，那么相应的 application.xml 应该包含下面这一条目

...   <application id="Application_ID">      <display-name>Banker 2001</display-name>...

在向 Access Manager 迁移应用程序之前检查这一点不失为一个好注意。如果它们不匹配，则更改两个中的一个。重命名 WebSphere Application Server Admin Console 中的企业应用程序名称，使其与 application.xml 中的 <display-name> 值匹配，可能会更容易些。

提示 2：在 Access Manager 3.9 的第一个发行版中，当使用 WebSphere Application Server Admin Console 导出应用程序时，WebSphere Application Server 使用 LDAP 作为用户注册表，应用程序将组映射到角色，组名称将与 ibm-application-bnd.xmi 内组的名称完全不同。迁移工具并不能很好地处理这个问题。例如，

<authorizations xmi:id="RoleAssignment_1">   <role href="META-INF/application.xml#SecurityRole_1"/>   <groups xmi:id="Group_1" name="cn=bank_clients, o=ibm,c=us"       accessId="group:oleg1.ibm.com:389/cn=bank_clients, o=ibm,c=us"/></authorizations>

您需要修改文件使组（groups）条目如下所示：

<authorizations xmi:id="RoleAssignment_1">   <role href="META-INF/application.xml#SecurityRole_1"/>   <groups xmi:id="Group_1" name="bank_clients"       accessId="group:oleg1.ibm.com:389/cn=bank_clients, o=ibm,c=us"/></authorizations>

然后迁移工具才能适当地迁移应用程序。这额外的一步只适用于组而不适用于用户，在 Access Manager 后来的版本中并非必需。

迁移后，应该在 Access Manager 中用 WPM 或 pdadmin 管理用户／组到角色的映射，而不是在 WebSphere Application Server 中管理，否则 Access Manager 将看不到它们。反过来，在 Access Manager 中对映射所做的更改不会在应用程序 EAR 中得到更新。

WebSphere Application Server 管理应用程序自身必须被迁移，因为 Access Manager 必须有管理角色（AdminRole 和 cos_naming*）的定义；否则，WebSphere Application Server 将不启动。这一点还可以通过在 Access Manager 对象空间内手工创建这些对象来实现，但到目前为止，管理应用程序的迁移仍是最容易的办法。（但在 Access Manager 3.9 中，您仍然不得不手工创建 ACL 条目才能实际授予 WebSphere Application Server 管理用户 AdminRole。）

图 11. 在 Access Manager 保护的对象名称空间中将访问控制列表附加到对象。

用于所有 WebSphere 应用程序的顶层受保护对象称为 WebAppServer。它有一个名为 deployedResources 的子对象。这两个对象名称一起充当在 WebSphere 应用程序中定义的所有 J2EE 角色的顶层前缀。它们是在迁移工具首次运行时被创建的。同时，该工具还创建了一个带调用操作（由字母 i 指定）的 WebAppServer 操作组和一个名为 pdwas-admin 的组，后者代表 WebSphere Application Server 管理员。该工具将 WebSphere Application Server 管理用户添加到 pdwas-admin 组。

上面的图 11 说明了缺省情况下用户和组如何与角色和应用程序关联起来，可选的还有 cellname、hostname 或 servername。AppName 的值必须与应用程序在 application.xml 中的显示名称完全匹配。单元就是管理域。层次图中更底层的，限制也更多的 ACL 可以覆盖上面的 ACL。

Access Manager 支持在多个应用程序中定义同一个角色的能力。这是因为基于角色的访问控制（role-based access-control，RBAC）。在 RBAC 中，角色是一个已命名的作业函数，描述用户的权限与职责。将它映射到 J2EE 角色并不难。但由于 RBAC 角色是与一个组织关联在一起的，而该组织可能会使用多个应用程序，所以同一个角色可能会应用到多个应用程序。因此，这样给层次排序是合理的。

（一般说明：通常用户和组是与组织 — 或者部署了应用程序的位置或公司 — 关联在一起，而角色或 J2EE 角色是应用程序自身的部分，不管部署位置在哪，都不会变。基于角色的认证在用户和已配置的许可权之间提供了一定级别的间接性。）

除可插的授权之外，AMWAS 还提供 Web Trust Association Interceptor 属性和一些类文件，这对于在 WebSEAL 和 WebSphere 之间建立信任关联是必需的。

接下来会出现什么？

我们期待 WebSphere Application Server 5 即将出现的版本能做的一件事是使 Access Manager 集成能全面支持 JSR 115，即 Java 容器授权合同（Java Authorization Contract for Containers）规范。从文档来看，JACC 规范“定义了 J2EE 容器和授权策略模块之间的合同，这样，就可以提供适合操作环境的容器授权功能。”换言之，就是 JSR 115 定义了外部授权提供者如何与 J2EE 进行交互。WebSphere Application Server 5 将附带 Access Manager 的一个嵌入版本，这个 Access Manager 不仅提供符合 JSR 115 的本地授权 API，还将让 WebSphere Application Server 来管理 LDAP 用户注册表中的用户配置，而不是只允许它以只读权限访问该注册表。

此外，带 Access Manager 的 WebSphere Application Server 5 将与 Tivoli Identity Manager 的一个端点集成在一起，充当 Tivoli Identity Manager 的一个端点。WebSphere Application Server 5 XD 未来的版本将具备 Access Manager 早已提供的 Kerberos 支持。

结束语

IBM Tivoli Access Manager 与 WebSphere Application Server 的集成是一种强大而又灵活的组合，提供了健壮的、可伸缩的、多层应用程序安全性。WebSphere Application Server 现在可以加入无缝的、统一的、集中管理的企业安全性体系结构。这些产品将来的版本将提供强大的多的集成。别走开！