WebSphere Application Server 中使用 JAAS 的登录场景和技术

引言

IBM WebSphere Application Server 大量使用登录模块来执行应用服务器的各种登录任务。JAAS 是一个 J2SE API，它提供了进行身份验证和授权的服务。因为 JAAS 非常重要，并且可能是 WebSphere Application Server 安全性方面最复杂的部分，所以本文对这种身份验证服务进行了介绍，以及如何在各种常见的登录场景中使用它。

尽管登录和身份验证通常可互换使用，但是必须理解它们之间的差别，因为在安全设计阶段将两者混为一谈会导致在实现中出现一些严重的问题：

• 身份验证是安全凭据的验证。身份验证过程的结果为有效或无效。
• 登录是为一个标识收集所需凭据的过程。登录过程通常涉及到各种凭据的身份验证。
• 身份验证是一次性的、无状态的活动。登录则具有较长时间的效果，并附带某种类型的上下文，像一个有状态的活动。

在 WebSphere Application Server 中，术语领域 (realm)定义了一个可以识别标识的安全边界。WebSphere Application Server 仅使用由用户注册中心生成的一个名称作为领域名，因此在 WebSphere 中，术语用户注册中心和领域通常可互换使用。

像 WebSphere Application Server 这样即时可用的系统，通常在运行过程中具有很高的安全性。可以将其假想为应用服务器外面的一个边界（就像一个气球）。当您启动自定义的安全性时，例如使用 JAAS 编写一个自定义登录模块，对于这个边界而言，可能会发生两件事情：

• 如果设计和实现都是正确的，那么这个边界就得到了扩展：您就拥有一个更大的气球。
• 如果实现不是很安全，那么这个边界上就会出现漏洞：导致气球消气了，或者最糟糕的情况是气球炸了。

此时，唯一的建议是：在决定为应用程序或者应用服务器使用自定义登录之前，请多加考虑，首先并且始终尝试使用内置的和受支持的产品功能。

先决条件

本文假定您对下列主题有基本的了解：

• JAAS 登录模块、回调处理程序、主题、主体
• WebSphere Application Server 安全性
• 初始和传播登录
• 水平和下游传播

有关推荐的阅读材料，请参见参考资料部分。

本文适用于分布式平台中的 WebSpere Application Server V6.0.2 及更高版本（包括 V6.1）、以及不同应用服务器之间使用的 RMI/IIOP 和 CSIv2。本文并不适用于应用程序客户机和应用服务器之间的通信，尽管有些场景可以在这种环境中正常工作。（本文中的配置细节和示例代码使用 WebSphere Application Server V6.0.2 进行过测试。）

回页首

系统登录、应用程序登录

本文对 WebSphere Application Server 中登录的含义进行了简单解释，以使您能够了解：主题 [Java™] 包含正在应用服务器中执行代码的标识的相关信息。登录模块的目的是创建、更新或更改当前主题。登录模块是登录过程中的组成部分，并且在登录配置中列举和重用这些模块。

WebSphere Application Server 区别对待两种不同类型的登录（准确地说是登录配置）：

• 系统登录在应用服务器中进行预定义，并用于内部登录过程（例如：RMI/IIOP 入站、出站）。可以对这些配置进行更改，主要是通过添加新的登录模块，但是不应该将它们删除。在对登录进行更改时请多加小心，因为这些更改可能会破坏以前安装的且正在运行的应用程序。
• 在 J2EE 应用程序中可以使用应用程序登录。

自定义登录模块和登录配置可以作为系统登录或应用程序登录的一部分。主要的差别在于其可用性范围。系统登录需要配置应用服务器，而应用程序登录则需要配置应用程序。

回页首

概要性登录场景

下面用两种基本的概要性登录场景来表示各种登录实现的基本原理：

登录到独立的应用程序

独立的应用程序登录很容易描述（如图 1 所示）。

图 1. 登录到独立的应用程序

1. 用户启动该应用程序。
2. 因为这是一个需要登录的安全的应用程序，所以该应用程序将调用 Login 模块。
3. Login 模块使用 Callback 处理程序以完成...
4. 使用各种回调从用户处收集登录信息。
5. 用户输入登录信息，例如：在对话框中输入用户名和密码。
6. Login 模块接收登录信息，并作出相应的决策，即该用户是否具有访问这个应用程序的权限。例如，Login 模块可以根据本地属性文件对用户名和密码进行比较。

独立登录并不是最常见的场景，尽管它适用于各种分布式环境的情况，比如服务器端登录。

客户机-服务器场景中的登录

客户机-服务器登录通常用于分布式环境中。图 2 和其中的执行流程显示了两个应用服务器之间的简单登录过程。

图 2. 客户机-服务器场景中的登录

1. 应用程序在发送服务器中进行远程调用，并调用出站请求组件。
2. 出站请求组件使用 Login 模块以执行登录，以使用合适的标识进行远程调用。
3. Login 模块使用 Callback 处理程序以完成...
4. 从当前安全上下文中收集登录信息。这个安全上下文中可能包含一些令牌以存储用户标识。（在这个示例中，该应用服务器应该已具有来自先前登录的安全上下文。）
5. Login 模块向 Outbound 请求返回主题，所以请求可以使用它进行远程调用。
6. Outbound 请求对目标服务器进行远程调用。应用服务器获取主题中可用的信息，对其进行序列化、并放入到请求中，因为该协议（在这个示例中是 CSIv2）对它提供了支持。
7. Inbound 请求组件在目标服务器端接收远程调用。
8. Inbound 请求使用 Login 模块创建一个主题以处理该请求。
9. Login 模块使用 Callback 处理程序以收集登录信息，它是...
10. 从用于通过网络进行远程调用的协议（在这个示例中是 CSIv2）中收集到的信息。
11. Login 模块返回主题。
12. 创建安全上下文。这个上下文为正在执行的线程存储主题和其他安全信息。
13. 在处理了这个请求之后，目标服务器继续执行。

分布式环境的其他细节

在分布式环境中，对于登录过程而言，客户机与服务器是相互独立的。客户机和服务器之间不存在登录过程特定的通信。换句话说，在进行实际的远程调用（业务）之前，客户机并不使用登录特定的内容与服务器进行联系。登录信息与远程调用一起传输。

可以假想有这样一种情况，某个人要从欧洲到美国去旅行。可以将这种情况看作是一个分布式系统，其中：

• 客户机是欧洲的机场。
• 服务器是美国的机场。
• 消息是这个旅行者，要从一个特定的机场到另一个特定的机场。
• 移民局就好像是一个登录模块。
• 护照就是主题，而在越过国境时，护照上的印章则是一种令牌类型。
• 移民局对护照的检查就等价于登录（递交护照）和身份验证（在某处、在数据库中检查标识）。

关键在于，这个旅行者需要在出行之前准备好相关材料（护照），并在旅途中随身携带这些材料。不能够提前发送护照，并确保这个人能够顺利通过目的地的移民局。这个旅行者必须亲自跨越目的地边界，并随身携带护照。

这种情况与 WebSphere Application Server 登录完全相同。登录信息（凭据），稍后用于身份验证或者验证，与有效的远程调用一同传输，而不是在调用之前作为单独的数据包。

登录场景细节

前面的描述没有涉及到存储在个别应用服务器中的、或在不同服务器之间传递的登录信息。登录信息依赖于几个可变的因素：

• 可以使用什么类型的登录信息？
• 在这些服务器之间存在信任关系吗？
• 这些服务器是否属于相同的安全领域？
• 这些服务器是否共享相同的用户注册中心？
• 用于传输登录信息的协议支持哪些内容？
• 用于进行登录的 API 支持哪些内容（例如，令牌、身份验证机制、验证）？

本文的剩下部分为各种登录场景提供了详细的描述，其中每个场景中的登录信息都取决于对上述这些问题的回答。

回页首

详细的登录场景和实现

根据特定的安全需求和其他的一些可变因素，应用程序程序员必须实现一种或多种特定的登录模块。在下面的部分中，描述了 WebSphere Application Server 中可用的各种场景（或模式）。此外，下载部分中还提供了一个电子表格，其中介绍了一些登录场景和需求矩阵，以帮助您根据自己的需要找到合适的实现。

这些场景分别是：

1. 标识传播（缺省）
2. 标识断言
3. 使用信任验证进行标识断言
4. 服务器端标识断言
5. 由应用程序代码进行出站标识映射
6. 使用自定义登录模块进行出站标识映射
7. 入站标识映射
8. 安全属性传播
9. 自定义令牌传播
10. 使用登录进行自定义令牌对象传播

场景 1：标识传播（缺省）

发送服务器仅将用户标识（X.509 证书、主体名、或基于初始登录所使用的凭据的专用名称 (DN)）发送到目标服务器。发送服务器并不传播密码或者任何其他私有的凭据（秘密）。例如，当发送服务器中的一个 Servlet 向目标服务器进行远程调用 (RMI/IIOP) 时，会在通信过程中发送客户机的标识（访问该 Servlet 的用户标识）。

为什么使用这种场景呢？

• 这个场景很简单，并且它不需要进行任何自定义工作或特定的配置。

条件

• 这些服务器必须共享用户注册中心。
• 这些服务器必须共享相同的 LTPA 密钥。
• 并没有将这两台服务器必须位于相同的单元中作为一条单独的要求，但是前面的两个条件可以保证这一点。它们可以是两台使用相同的 LTPA 密钥并共享相同的用户注册中心的独立服务器。

该场景是如何工作的？

1. 发送服务器已经通过客户机标识得到了安全上下文。在发送请求的时候，出站登录为标识获得凭据，并将序列化后的数据发送到目标服务器。以 LTPA 令牌的形式存储和发送这些凭据。通过共享 LTPA 密钥，在这两台服务器之间建立了信任关系，所以不再需要传输服务器的标识。
2. 目标服务器接收请求，并将反序列化后的令牌传递给应用服务器进行解密。
3. 目标服务器调用 RMI_INBOUND 登录配置中的登录模块，以便从传入的请求获得凭据。登录模块用于检索和解密各种令牌，以获得其中的用户凭据。
4. 凭据用于创建主题，以便在目标服务器上执行代码。

同时，建立 CSIv2 会话并用于将来的请求。这个安全主题关联于 CSIv2 会话。只要会话处于打开状态并保持有效，那么就没有必要重新运行登录过程。

配置

不需要任何特定的配置，WebSphere Application Server 将使用 CSIv2 通信作为缺省配置为 RMI/IIOP 进行标识传播。

自定义

缺省场景不需要任何自定义工作。

场景 2：标识断言

这是标识传播（缺省场景 1）的增强版本。

在标识断言场景中，这些服务器并不使用 LTPA 密钥来建立信任关系。要避免因为信任发送服务器而带来的相关风险，这种断言过程中引入了服务器验证。在服务器验证的过程中，目标服务器将检查发送服务器是否值得信任。在进行了身份验证之后，通过将发送服务器的标识与预配置的受信任的服务器标识列表进行对比，就可以完成这项检查工作。发送端断言的标识采用为初始登录（例如，用户 ID、DN、证书）提供的原始凭据的形式。

为什么使用这种场景呢？

• 这个场景不需要在服务器之间共享 LTPA，因此这些服务器无需位于相同的单元中。

条件

• 发送服务器和目标服务器必须共享相同的用户注册中心。
• 必须在两台应用服务器（发送和目标服务器）中启用和配置标识断言特性。
• 目标服务器必须将发送服务器列入到受信任的服务器列表中。

风险

• 断言的标识并不作为令牌传输，它采用纯文本格式，而没有经过加密。要解决这个问题，您应该在发送和目标服务器之间使用 SSL 连接。

该场景是如何工作的？

1. 发送服务器已经通过客户机标识得到了安全上下文。服务器将经过序列化的凭据（包括用于基本身份验证的发送服务器标识）发送给目标服务器。服务器 ID 和密码在 GSS 令牌中发送，并使用 JGSS API 产生和使用。登录过程中的这个部分不使用 JAAS API。客户机的标识作为用户名发送（不带密码），因为使用的是基本身份验证。
2. 目标服务器接收请求，检索 GSS 令牌，提取服务器标识，对其进行身份验证，并与受信任的服务器标识列表进行比较。如果该发送服务器是受信任的，那么执行过程将继续。
3. 目标服务器调用 RMI_INBOUND 登录配置中的登录模块，以便从传入的请求获得凭据。
4. 登录模块使用 NameCallback 回调以检索客户机的标识，并构建用于在应用服务器中执行代码的主题。
5. 应用服务器使用断言中的客户机标识，以便在目标服务器中运行代码。

配置

确保这些服务器不共享相同的 LTPA 密钥，为两台服务器生成两个不同的 LTPA 密钥：

1. 为发送服务器配置标识断言：

   1. 通过导航到 Security => Global security => Authentication protocol => CSIv2 outbound authentication，在 WebSphere Application Server 中启用标识断言。
   2. 重新启动服务器。

2. 为目标服务器配置标识断言：

   1. 通过导航到 Security => Global security => Authentication protocol => CSIv2 inbound authentication，启用标识断言。
   2. 在这个示例中，将该发送服务器的服务器 ID 添加到受信任的服务器字段中：uid=wasserver1, dc=demo, dc=ibm, dc=net（它不需要是完全限定的，这取决于用户注册中心配置）。如果有多台服务器，那么可以使用 |（管道）符号来列举它们。
   3. 重新启动这些服务器。

自定义

不需要进行任何自定义。这个场景建立在配置设置的基础上。

场景 3：使用信任验证进行标识断言

这个场景提供了各种选项以编程方式验证断言的用户标识，从而增强了标识断言场景（场景 2）。发送服务器端需要进行信任验证，以验证断言的标识。从技术上看，这样做的原因是，使用给定的编程模型可以插入任何用户标识、甚至伪造的标识。

这个场景可能看起来类似于出站标识映射（场景 5），但主要的差别在于，这些服务器共享相同的用户注册中心，不进行任何映射。出站标识映射场景还需要所有的凭据，以便在目标服务器中执行初始登录，而这个场景则不需要。

为什么使用这种场景呢？

• 这个场景不需要在服务器之间共享 LTPA，因此服务器不需要位于相同的单元中。
• 它为以编程方式断言任何有效的用户标识提供了灵活性。
• 只需要在发送服务器端进行自定义。不需要在目标服务器中编写任何代码。

条件

• 必须在两台应用服务器（发送和目标服务器）中启用和配置标识断言特性。
• 发送服务器和目标服务器必须共享相同的用户注册中心。
• 目标服务器必须将发送服务器列入到受信任的服务器列表中。

风险

• 任何信任验证都交由开发人员去实现。必须对其进行正确的实现，以避免产生任何安全问题。
• 断言的标识并不作为令牌进行传输，它采用纯文本格式，而没有经过加密。要解决这个问题，您应该在发送和目标服务器之间使用 SSL 连接。

这个场景使用了共享状态表，该表是一个哈希表，用于 WebSphere Application Server 中，以便在登录模块（在一个登录配置中执行）之间共享信息。

该场景是如何工作的？

1. 发送服务器已经通过特定的标识获得了现有的安全上下文。
2. 在发送服务器进行远程调用之前，客户机代码使用自定义的应用程序登录配置进行登录：
   1. 第一个登录模块（由开发人员实现）将获得新的标识。例如，回调可用于为新的标识提供详细的信息。
   2. 在对标识进行验证（验证信任关系）之后，将该标识信息放到登录的共享状态中。
   3. 第二个登录模块（应用服务器所附带）从共享状态中获得标识信息，并在应用服务器中进行实际标识切换。
3. 当发送服务器中的应用程序代码进行远程调用时，该标识将反映新的、断言的标识。当为 CSIv2 出站配置启用了标识断言属性时，会在进行远程调用之前切换主题。
4. 服务器将经过序列化的凭据（以及断言的标识），包括发送服务器的标识（服务器 ID 和服务器密码），发送到目标服务器。在 GSS 令牌中发送服务器 ID 和密码，而 GSS 令牌由 JGSS API 产生和使用。登录过程中的这个部分不使用 JAAS API。将客户机的标识作为基本身份验证中的用户名来发送。
5. 目标服务器接收请求，检索 GSS 令牌，提取服务器标识，并与受信任的服务器标识列表进行比较。如果该发送服务器是受信任的，那么执行过程将继续。
6. 目标服务器调用 RMI_INBOUND 登录配置中的登录模块，以便从传入的请求获得凭据。
7. 登录模块使用 NameCallback 回调以检索客户机的标识，并构建用于在应用服务器中执行代码的主题。
8. 应用服务器自动地切换到断言中使用的标识。在此之后，就可以在目标服务器上使用客户机的标识运行代码。

配置

确保这些服务器不共享相同的 LTPA 密钥，为这两台服务器生成两个不同的 LTPA 密钥。

1. 通过导航到 Security => Global security => Authentication protocol => CSIv2 outbound authentication，为发送服务器启用标识断言。
2. 在发送服务器中，配置一个新的应用程序登录以处理标识断言：
   1. 创建一个新的应用程序登录配置。
   2. 添加自定义登录模块，并确保将该内容添加到最前面。使用本文中提供的示例代码，具体配置如下：
      • 登录配置名称： CustomIDassertion
      • 模块类名： com.ibm.issw.security.loginmodules.RMI_IDAssertion_LM
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required
   3. 添加 WebSphere Application Server 标识断言登录模块作为第二个模块：
      • 模块类名： com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required
   4. 重新启动发送服务器。
3. 为目标服务器配置标识断言：
   1. 通过导航到 Security => Global security => Authentication protocol => CSIv2 inbound authentication，启用标识断言。
   2. 将发送服务器的服务器 ID 添加到受信任的服务器字段，在我们的示例中：cn=wasserver1, dc=demo, dc=ibm, dc=net。如果有多台服务器，可以使用 |（管道）符号来列举它们。
   3. 重新启动目标服务器。

自定义

这里的自定义部分是实现一个新的自定义登录模块，以便为断言的标识收集凭据，并为标识执行验证。有关自定义登录模块的更详细的信息，请参考本文下载文件部分中的 RMI_IDAssertion_LM.java 源代码以及嵌入的注释。

示例代码

示例登录模块使用 WebSphere Application Server 的一个回调处理程序来收集断言的标识。另一种方法是，在应用程序登录模块中开发和使用负责收集信息的自定义回调处理程序。断言所使用的实际标识在 Web 应用程序中定义为一个环境变量：WEB_USER2，其值为 user2。您可以通过编辑 web.xml 文件来更改这个值。在实例的应用程序中，可以使用更复杂的逻辑来收集断言的用户标识。

场景 4：服务器端标识断言

服务器端标识断言的过程与使用信用验证进行标识断言（场景 3）相同。不同之处在于，不通过任何协议（没有 CSIv2）在参与的组件之间传递安全信息。因为更改发生在本地（在进程中），所以应用服务器本身必须为执行过程更改安全上下文。

这个场景是登录到独立的应用程序场景的一种实现。从编程模型的角度来看，这个场景与场景 3（使用信用验证进行标识断言）相同。将其作为一种单独的场景进行描述的原因是，从应用程序设计的角度来看，它有所不同。

当应用程序仅在涉及到服务器端组件时才必须更改标识时，或者当基础结构不提供安全拦截器（或者处理程序）以执行登录时，服务器端标识断言是非常有用的。例如，消息驱动的 Bean 可以在调用会话 EJB 之前，使用消息中的信息设置适当的标识。另一个示例：用户标识作为方法签名中定义的参数进行传递。

为什么使用这种场景呢？

• 如果需要在服务器端切换标识，并且无法通过编程方式以外的其他任何方式来完成。
• 当某个特定的协议（例如，CSIv2）无法用于传播标识断言的安全信息，但标识作为消息中的一部分是可用的。

条件

• 这个场景假定服务器端断言所使用的标识是可用的。它可以是发送服务器远程调用的一部分，或者是目标服务器应用程序逻辑的结果。

风险

• 标识验证由自定义的代码来执行。
• 服务器端标识断言行为不是声明性的，在开发人员、组装人员和部署人员角色之间存在重叠，这可能会在调试或者跟踪过程中导致混乱。（可以通过代码中正确的文档说明以及代码中的调试/跟踪信息来解决这个问题。）

该场景是如何工作的？

1. 应用程序获得断言的标识。
2. 应用程序代码调用客户应用程序登录配置进行服务器端标识断言。
3. 应用程序开始执行配置中的登录模块。第一个登录模块应该是一个自定义登录模块：
   1. 自定义登录模块获得新的标识（这取决于具体的需求和实现）。
   2. 应该根据用户注册中心来检查标识，以确保新标识的有效性。
   3. 标识位于登录共享状态中，并使用了特定的密钥。
4. 最后一个登录模块 IdentityAssertionLoginModule，从共享状态中获得标识信息，并构建一个新的主题。
5. 应用程序代码接收新的主题，然后调用 WSSubject.setRunAsSubject(returned_subject) 方法为当前线程切换标识。
6. 在执行了前面的操作之后，将以新的标识来运行代码。

配置

在目标服务器中，配置一个新的应用程序登录以处理标识断言：

1. 创建一个新的应用程序登录配置，名为 Server_side_identity_assertion。
2. 添加自定义登录模块。确保这是列表中的第一个登录模块。使用示例代码，指定下面的内容：
   • 登录配置名称： CustomServerIDassertion
   • 模块类名： com.ibm.issw.security.loginmodules.RMI_IDAssertion_LM
   • 使用登录模块代理：Enabled
   • 身份验证策略：Required
3. 作为第二个模块，添加 WebSphere Application Server 标识断言登录模块： com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule。
4. 重新启动服务器。

因为它不使用 CSIv2，所以服务器端标识断言不需要任何用于 CSIv2 通信的标识断言配置。

自定义

可以进行与场景 3 中相同的自定义工作。

示例代码

在这个特定的示例中，服务器端的断言标识作为远程调用的方法参数发送。断言所使用的实际标识在发送服务器 Web 应用程序定义为环境变量 WEB_USER2，其值为 user2。如果需要，可以编辑 web.xml 文件来更改这个值。

尽管这个场景不需要共享用户注册中心或 LTPA 密钥，但是示例中使用了标识传播（缺省传播）进行远程调用，以使配置更加简单。

场景 5：由应用程序代码进行出站标识映射

标识映射就是将一个标识更改为来自另一个用户注册中心中不同的标识。尽管标识断言（请参见前面的场景）可以更改标识，但是它只能够在相同的用户注册中心中进行更改。可以通过几种方法来对标识进行映射，如在数据库中进行查找、使用一种算法、等等；这些技术超出了本文的讨论范围。

对标识进行映射可用于下列不同的目的：

• 它可以实现某种场景，如 EJB 组件的 run-as 映射。
• 它可以使用某种映射机制在两个用户注册中心之间实现映射。

有两种出站映射场景。在第一个场景（第二个是场景 6）中，由应用程序代码执行标识映射，而不使用和配置自定义登录模块。在这个示例中，在进行远程调用之前，应用程序开发人员负责检索当前标识、映射和创建新的标识，并执行到目标服务器的远程登录。

为什么使用这种场景呢？

• 当需要在不同的用户注册中心之间更改标识时。
• 发送和目标服务器互不信任。
• 因为没有共享 LTPA 密钥，而无法使用 LTPA 令牌传输标识。
• 不可以或不允许更改应用服务器配置（添加自定义登录模块）。
• 由应用程序代码来处理标识映射，这是首选的方法。

条件

• 应用程序必须将用户标识映射为凭据。将在目标服务器上对这些凭据（例如，用户 ID 和密码）进行验证。

风险

• 敏感的数据（如密码）通过网络发送。在发送和目标服务器之间使用 SSL，以确保通信的安全。
• 该场景在初始登录时需要提供用户凭据（如用户 ID 和密码）。您必须找到一种安全的方法来存储和检索这些敏感的凭据信息。

该场景是如何工作的？

1. 在进行远程调用之前，应用程序代码必须创建一个在目标服务器上有效的新主题。
   1. 您必须检索当前标识，然后使用映射函数生成一个新的标识。
   2. 要创建一个新的主题，应用程序必须使用 WSLogin 应用程序登录登录到目标服务器（目标领域）。登录所得到的结果就是这个新的主题。
2. 应用程序使用新的主题进行远程调用。

配置

这个场景需要为每个应用服务器使用不同的用户注册中心。将发送服务器配置为使用一个用户注册中心，而将目标服务器配置为使用另一个用户注册中心。服务器之间的出站映射无需共享 LTPA 密钥就可以正常工作。对于一个更现实的测试，需要确保应用服务器使用不同的 LTPA 密钥。

使用出站标识映射需要在发送服务器中对 WSLogin 应用程序登录的现有配置进行更改：

1. 打开 Security => Global security => JAAS Configuration => Application logins 并选择 WSLogin。
2. 从 JAAS 登录模块中选择 com.ibm.ws.security.common.auth.module.WSLoginModuleImpl 项目。
3. 为这个登录模块更改下面两个自定义属性，将它们的值更改为 true：
   • use_realm_callback
   • use_appcontext_callback
4. 重新启动服务器。

自定义

这个场景只需要在应用程序代码中进行自定义，而不需要开发一个新的登录模块。有关更详细的信息，请参阅下载部分中的 OutboundIdentityMappingOutbound.java 源代码。

示例代码

标识映射使用属性文件来确定映射的用户标识。在所有的三个标识映射场景中都使用了 user_mapping.properties 文件。对与每个场景相关的部分使用注释进行了标记。

该文件需要遵循下面的格式：

user1->10.10.10.62=user1@Target;10.10.10.62:389;byte2eat

• user1 = 原始用户 ID
• 10.10.10.62 = 目标服务器的地址
• user1@Target = 映射的用户 ID
• 10.10.10.62:389 = 远程服务器的领域
• byte2eat = 映射用户的密码

可以在 Web 应用程序 (web.xml) 的环境变量中对属性文件的位置进行配置。其缺省值为：/opt/IBM/WebSphere/AppServer/properties/user_mapping.properties。在进行测试之前，请确保该目录结构指向正确的位置。

场景 6：使用自定义登录模块进行出站标识映射

第二个出站标识映射场景使用了发送服务器端中的一个自定义登录模块。这种方法的优点是，它不需要附加的应用程序代码来执行标识映射。由出站自定义登录模块来进行标识映射和标识切换。这个自定义登录模块的代码与场景 5 中使用的应用程序中的代码几乎完全相同。

为什么使用这种场景呢？

• 当需要在不同的用户注册中心（领域）之间更改标识时。
• 发送和目标服务器互不信任。
• 当因为没有共享 LTPA 密钥，而无法使用 LTPA 令牌传输标识时。
• 要处理标识映射，首选的方法是在应用服务器中由基础结构执行处理过程。换句话说，应用程序不应该包括安全特定的基础结构代码。

条件

• 登录模块必须将用户标识映射为凭据。将在目标服务器上对这些凭据（如用户 ID 和密码）进行验证。

风险

• 敏感数据（如密码）通过网络发送。在发送和目标服务器之间使用 SSL，以确保通信的安全。
• 该场景在初始登录时需要提供用户凭据（如用户 ID 和密码）。您必须找到一种安全的方法来存储和检索这些敏感的凭据信息。

该场景是如何工作的？

1. 发送服务器对目标服务器进行远程调用。
2. 在实际调用之前，发送服务器调用 RMI_OUTBOUND 登录配置中的登录模块。首先调用自定义登录模块。
3. 出站登录模块创建一个在目标服务器上有效的新主题。
   1. 登录模块必须检索当前标识，然后使用映射函数生成一个新的标识。
   2. 要创建一个新的主题，登录模块必须使用 WSLogin 应用程序登录进行登录，就像登录到目标服务器（使用目标领域）。登录所得到的结果是一个新的主题。
4. 必须用这个新主题替换旧主题。在登录模块的 commit() 方法中，可以使用特权代码清除当前主题并替换相应的主体、公开的和私有的凭据。
5. 在登录模块完成相应的工作之后，使用新的主题进行远程调用。

配置

1. 在发送服务器上配置新的登录模块：
   1. 将自定义登录模块添加到 RMI_OUTBOUND 登录配置。确保将该内容添加到最前面。指定下面的内容：
      • 模块类名： com.ibm.issw.security.loginmodules.OutboundMapping_LM
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required

      这个示例需要下面描述的附加的、特定的配置。

   2. 在应用了这些更改之后，单击 Set order 按钮将该登录模块移动到列表的最上方。
2. 在发送服务器上修改 WSLogin 应用程序登录配置：
   1. 打开 Security => Global security => JAAS Configuration => Application logins 并选择 WSLogin。
   2. 从 JAAS 登录模块中选择 com.ibm.ws.security.common.auth.module.WSLoginModuleImpl 项目。
3. 为这个登录模块更改下面两个自定义属性，将它们的值更改为 true：
   • use_realm_callback
   • use_appcontext_callback
4. 在发送服务器中为 CSIv2 出站身份验证启用自定义出站登录特性。
5. 重新启动服务器。

自定义

这个场景需要一个新的自定义登录模块和配置。在下载资料 OutboundMapping_LM.java 中可以找到登录模块的代码示例。

示例代码

这个场景还依赖于描述当前和新的标识之间映射的属性文件。一个自定义的属性中保存了属性文件的位置，该属性位于 Global security => System login configuration => RMI_OUTBOUND => JAAS login modules => com.ibm.issw.security.loginmodules.OutboundMapping_LM => Custom properties。创建一个新的属性，名为 mapping.file，该属性的值表示文件的位置（例如，/opt/IBM/WebSphere/AppServer/properties/user_mapping.properties）。这个场景中条目的格式如下：

10.10.10.61|389/user1->10.10.10.62|389=user1@Target;byte2eat

• 10.10.10.61|389/user1 = 带领域的原始唯一用户 ID
• 10.10.10.62|389 = 目标服务器的领域
• user1@Target = 映射的用户 ID
• byte2eat = 映射的用户密码

这里，使用 |（管道）符号来代替：配置中的冒号，这是因为 Java 在处理属性文件时的限制。

场景 7：入站标识映射

入站映射可以根据从发送服务器接收到的信息，帮助在目标服务器中对标识进行更改。在出站映射不满足标识映射的需求的情况下，入站标识映射可以提供一些新的选择。入站映射主要依赖于发送和目标服务器之间的信任关系。

为什么使用这种场景呢？

• 目标服务器的用户注册中心不存在用户标识。换句话说，发送服务器不与目标服务器共享用户注册中心。
• 发送服务器完全不清楚映射机制或新的用户标识。
• 当无法使用安全凭据来创建一个新的标识时。
• 当发送服务器上的映射未知或者不可用时。

条件

• 发送和目标服务器必须相互信任。
• 必须有一种机制来传输实际用户标识，如标识断言。
• 目标服务器必须能够将传入的标识映射为新的标识。如果在目标服务器端这种功能不可用，那么您应该考虑使用出站标识映射场景来代替。

该场景是如何工作的？

1. 发送服务器进行远程调用，并将调用者的标识放到请求中。
2. 目标服务器接收传入的请求，并开始调用 RMI_INBOUND 登录配置中的登录模块。
3. 第一个登录模块是这个自定义的入站映射登录模块：
   1. 该登录模块可以通过执行映射来确定调用的标识。
   2. 根据为目标服务器配置的用户注册中心对新的标识进行检查，以便对其进行验证。
   3. 然后将有效用户的标识（还包括其他一些属性）存储在其他登录模块所使用的共享状态中。
4. 后面的登录模块 (com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule) 使用共享状态中的信息来构造新的主题，以便执行进一步的操作。
5. 在登录过程完成之后，该标识切换为目标服务器中的新标识。

配置

1. 在目标服务器上配置新的登录模块：
   1. 将自定义登录模块添加到 RMI_INBOUND 登录配置。指定下面的内容：
      • 模块类名： com.ibm.issw.security.loginmodules.InboundMapping_LM
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required

      这个示例需要下面描述的附加的、特定的配置。

   2. 在应用了这些更改之后，使用 Set order 按钮将该登录模块移动到列表的最上方。
2. 重新启动服务器。

自定义

这个场景需要一个自定义登录模块，以便目标服务器能够执行标识映射。有关更详细的信息，请阅读 InboundMapping_LM 文件中的源代码。

示例代码

这个场景还依赖于描述当前和新的标识之间映射的属性文件。该文件的位置配置为一个自定义属性，该属性位于 Global security => System login configuration => RMI_INBOUND => JAAS login modules => com.ibm.issw.security.loginmodules.InboundMapping_LM => Custom properties。创建一个新的属性，名为 mapping.file，该属性的值指定了文件的位置（例如：/opt/IBM/WebSphere/AppServer/properties/user_mapping.properties）。这个场景中条目的格式如下：

10.10.10.61|389/uid-user1,ou-People,dc-demo,dc-ibm,
dc-net=uid=user1@Target,ou=People,dc=demo,dc=ibm,dc=net

• 10.10.10.61|389/uid-user1,ou-People,dc-demo,dc-ibm,dc-net = 带领域的原始完全限定的用户 ID
• uid=user1@Target,ou=People,dc=demo,dc=ibm,dc=net = 映射的完全限定的用户 ID

这里使用 |（管道）符号来代替：配置中的冒号，这是因为 Java 在处理属性文件时的限制。另外，出于相同的原因，将原始用户 ID 中的 =（等号）符号替换为 -（连字符）。

在继续深入学习本文之前，您必须熟悉 WebSphere Application Server 中各种类型的安全令牌，如传播、身份验证、授权、单点登录令牌。

场景 8：安全属性传播

安全属性传播是应用服务器所提供的一种服务，用以传播各种属性、令牌、或与安全上下文相关的对象。发送服务器可以在发送到目标服务器的安全上下文中插入一些属性。使用特定的协议来传输安全属性，在使用 RMI/IIOP 的情况下，传输协议为 CSIv2，这是在远程调用过程中用来传输安全属性信息的专用层。

实际上，安全属性传播要比前面的定义更复杂一些，因为这些属性可以是 WebSphere 令牌、自定义令牌、令牌的属性、或者自定义的对象。传播还可能发生在不同的方向上：水平的或者下游。（有关更详细的信息，请参见 WebSphere Application Server 信息中心。）

属性是字符串的键-值对，具有下面的结构：

token-attributes {
	String key
	String[] values
}

WebSphere Application Server 中有一个安全 Helper 类，用于将属性插入到安全上下文，并从安全上下文中读取属性。WebSphere Application Server 使用特殊的传播令牌来携带这些属性。

为什么使用这种场景呢？

• 当需要提供安全相关的附加信息并将其附加到实际用户标识（主题）时，可以使用这些安全属性来保存该信息。
• 它非常易于使用，并且只需要进行很少的编码就可以在服务器之间传播自定义的安全信息。它不需要自定义登录模块或新的登录模块配置。
• 应用服务器之间不需要共享令牌类。

条件

• 必须在应用服务器上启用安全属性传播特性。
• 在应用程序代码中对属性进行设置和获取。
• 这些属性存储为 String，并使用 String 类型的键值，这可能需要对象的序列化和反序列化。
• 如果这些服务器位于不同的领域，那么必须配置受信任的目标领域列表。

该场景是如何工作的？

将用于传播安全属性的缺省传播令牌附加于运行的线程。安全属性传播负责将属性附加到特定的令牌，以及令牌的序列化/反序列化和传播。您可以使用 put/get 方法来访问这些安全属性。

1. 发送服务器的应用程序以编程方式将属性放入到传播令牌中。
2. 当启用了安全属性传播服务时，应用服务器自动地从线程中获得传播令牌，并将其插入到使用 CSIv2 协议的远程调用中。
3. 目标服务器接收请求，并检索传播令牌。将令牌附加于该线程。
4. 目标服务器上的应用程序可以查询传播令牌，并检索任何所需的属性。

配置

要保持这个示例尽量简单，这两台服务器需要使用相同的用户注册中心，并共享 LTPA 密钥：

1. 通过导航到 Security => Global security => Authentication protocol => CSIv2 outbound authentication，为发送服务器启用安全属性传播。
2. 重新启动发送服务器。
3. 通过导航到 Security => Global security => Authentication protocol => CSIv2 inbound authentication，为目标服务器启用安全属性传播。
4. 重新启动目标服务器。

配置选项：

• 安全属性传播还可以工作于服务器并不共享相同的用户注册中心和 LTPA 密钥的环境中。在这些情况下，必须在 CSIv2 出站身份验证中为发送服务器配置受信任的目标领域字段。要对这个选项进行测试：

  1. 请按照下面的步骤使用自定义登录模块场景（场景 6）对出站标识映射中的服务器进行配置。
  2. 按照前面的描述配置安全属性传播。
  3. 将目标服务器的领域添加到发送服务器的 CSIv2 出站身份验证，例如，10.10.10.62:389。

  为了满足特定的需要，可以像这样将场景和配置混合在一起，后面将详细讨论这个问题。

自定义

这个场景只需要进行很少的自定义工作。您需要为发送和目标应用程序添加几行代码，以放入和接收安全属性。有关更详细的信息，请参见适用的源代码：对于发送，请参见 SecurityAttributePropagationOutbound.java；对于接收，请参见 SecurityAttributePropagationInboundBean.java。

示例代码

该示例代码使用了一个自定义的身份验证令牌。存在各种其他类型的令牌，但是从编程模型、实现和配置的观点来看，它们本质上是相同的。在自定义登录模块代码中对令牌的属性进行硬编码。通常基于某种逻辑对这些属性进行设置，或者在登录过程中使用各种回调对其进行收集。

场景 9：自定义令牌传播

传播自定义的令牌为安全属性传播（场景 8）提供了附加的灵活性，因为它允许开发人员命名、指定类型和实现任何令牌。这个令牌必须实现一个特定的接口以便让 WebSphere Application Server 处理序列化/反序列化以及令牌的传播。

WebSphere Application Server 为各种特定的令牌类型提供了相应的接口。每种类型的令牌都具有特殊的目的，WebSphere Application Server 分别对它们进行适当地处理。这些区别包括令牌附加的对象（线程、主题）、传播的方向（下游、水平）、以及使用它的目的（身份验证）。

为什么使用这种场景呢？

• 令牌可以携带与安全相关的附加信息。在有些情况下，一个简单的用户标识不足以构建适当的安全上下文。在其他的情况下，不能使用传播令牌的方法来传播原始用户凭据。
• 当下游传播无法满足需要，例如，当需要水平传播时。
• 当前可用的令牌并不合适，例如，在与另一个应用服务器进行集成时。

条件

• 应用服务器之间必须共享令牌实现类。
• WebSphere Application Server 具有一组预定义的令牌类型（接口），它们分别对应于特定的行为。任何自定义的实现都必须考虑这些行为。

风险

• 自定义的令牌实现应该当心令牌中存储的敏感数据，因此它应该在序列化和反序列化的过程中执行某种类型的加密。

使用令牌的变体

在使用令牌时，应该考虑令牌的整个生命周期和生存期。了解在 WebSphere Application Server 中各种类型的令牌如何传播、以及应用于何处，这是非常重要的。WebSphere Application Server 信息中心中为不同类型的令牌提供了很好的概述，但是让我们先全面的介绍这些令牌是如何使用的。

首先，令牌的生存期并不局限于单个远程调用、或单个协议。它们的生存期可以跨越多个调用以及多种协议。很可能通过一个过期时间来界定生存期，特别是在分布式环境中，要使一个令牌失效是非常困难的。

令牌的生命周期非常简单：作为初始登录中的一部分，在用户第一次与应用程序交互的过程中创建令牌。然后，令牌将过期或失效（如果可能）。在大多数情况下，令牌可以在整个用户会话中生存；否则，必须对其进行重新颁发，而重新颁发令牌可能需要一个新的初始登录。当令牌可用时，WebSphere Application Server 将使用这个可用的令牌来执行传播登录。

对于登录模块中对令牌的处理，可以使用不同的变体。安全架构师可以决定应用程序所需的行为类型，而应用程序开发人员可以使用 WebSphere SPI 中合适的变体。图 3 介绍了一些变体。

图 3. 令牌处理变体

图 3 介绍了客户端应用程序对发送服务器进行调用的三种变体（A，B，C）。在每种变体中：

• 带阴影的圆圈表示应用程序代码。
• 发送服务器可能使用一个特定的入站和一个出站登录模块来处理令牌。
• 发送服务器对目标服务器进行远程调用。
• 目标服务器可能使用一个特定的入站和一个出站登录模块来处理令牌。
• 目标服务器对下游服务器进行远程调用。
• 不带阴影的登录模块将主动地处理令牌，而带阴影的登录模块（如果存在）则不会。

变体 A：

• 为什么我们只需要入站自定义登录模块呢？或者，问题听起来类似于：如果我们只有一个自定义的入站登录模块，那么这个令牌来自何处，为什么没有自定义的出站登录模块呢？请记住，当讨论令牌时，您必须考虑到令牌的整个生存期，而不是局限于单个调用。用户（或者外部系统）第一次访问应用程序，第一个登录模块是一个入站登录模块。这个入站登录模块将生成令牌。在生成了令牌之后，按照水平或者下游的方向，为所有后续的调用对令牌进行维护和传播。这也表示，该令牌在主题（或者执行线程）中始终是可用的。因为该令牌是可用的，并且它自动地进行传播，所有不需要特定的出站登录模块来创建令牌。

• 对于所有的 WebSphere Application Server 令牌，这是缺省的变体。本文中提供的示例就符合这个变体。

变体 B：

• 令牌还可以用于为单个远程调用传输安全相关的信息。在这个示例中，发送服务器在出站登录模块中准备远程调用的令牌。目标服务器使用入站登录模块获得令牌。

变体 C：

• 这种变体是最完整的，它具有所有主动处理令牌的登录模块。它基本上是变体 A 场景的扩展，其中出站登录模块也可以出于任何原因来访问令牌。

该场景是如何工作的？

1. 发送服务器进行远程调用。
2. 应用服务器自动地从主题和执行线程中获得令牌，然后使用 CSIv2 协议将它们插入到远程调用中。自定义令牌的工作方式与任何其他 WebSphere 安全令牌相似，并且应用服务器自动地对其进行传输。在传输过程中，对令牌进行序列化，最好同时进行加密。
3. 目标服务器接收协议 (CSIv2) 中嵌入令牌的请求。
4. 目标服务器对令牌进行反序列化，并将它们附加到主题或线程，这取决于令牌的具体类型。有关如何对令牌进行处理的更详细的信息，请参考 WebSphere Application Server 信息中心。

配置

下面描述的示例代码和配置是变体 A 的一个实现。其他变体的配置都非常相似，区别在于，是在服务器上对登录模块进行配置：RMI_INBOUND 或者 RMI_OUTBOUND。

1. 在发送服务器中配置新的登录模块：
   1. 将自定义登录模块添加到 RMI_INBOUND 系统登录配置。确保它放在 com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule 登录模块的后面。然后指定下面的这些值：
      • 模块类名： com.ibm.issw.security.loginmodules.CustomAuthenticationToken_LM
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required
   2. 为 DEFAULT、WEB_INBOUND 系统登录配置重复步骤 1a。
2. 在目标服务器上配置新的登录模块。
   1. 将自定义登录模块添加到 RMI_INBOUND 系统登录配置。确保将它添加到 com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule 登录模块的后面。然后指定下面的这些值：
      • 模块类名： com.ibm.issw.security.loginmodules.CustomAuthenticationToken_LM
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required
   2. 为 DEFAULT、WEB_INBOUND 系统登录配置重复步骤 2a。

配置选项：

• 对于服务器之间不共享相同的用户注册中心和 LTPA 密钥的环境，自定义令牌传播也可以正常工作，就像安全属性传播（场景 8）的情况一样。自定义令牌传播不需要配置受信任的目标领域。要对这种情况进行测试，只需要使用通过自定义登录模块场景进行出站标识映射（场景 6）的配置，以设置一个不在服务器之间共享 LTPA 密钥或者用户注册中心的环境。

自定义

要传播自定义的令牌，需要获取主题。完成这项任务的方法之一是，在发送服务器端执行标准的（或者自定义的）登录，并在目标服务器端使用自定义登录模块。您需要决定：

• 将要使用哪种类型的令牌？
• 应该如何对令牌进行传播？
• 使用令牌的目的是什么？

（有关不同令牌类型的更详细的信息，请参见 WebSphere Application Server 信息中心。）

这个场景所需要的自定义组件包括：

• 针对特定令牌类型的自定义令牌实现。
• 入站请求的自定义登录模块，用来创建或检索令牌，这取决于它是初始登录还是传播登录。

场景 10：使用登录进行自定义令牌对象传播

自定义令牌对象（因为没有更合适的名称）实际上是一个常规的可序列化对象。将自定义的令牌对象用于传播，这是传播方式中最灵活的场景，因为它不受任何自定义令牌的限制。

为什么使用这种场景呢？

• 当 String 类型的键-值对不足以传播所需的安全属性时。

条件

• 不同的应用服务器之间必须共享自定义对象实现类。

风险

• 自定义的对象实现应该当心对象中存储的敏感数据，因此它应该在序列化和反序列化的过程中包含加密处理。

该场景是如何工作的？

1. 发送服务器进行远程调用。
2. 应用服务器自动地从主题中获取该对象，作为一个私有凭据，并将其插入到使用该协议 (CSIv2) 的远程调用中。自定义令牌对象的工作原理与其他 WebSphere 安全令牌相同，应用服务器将自动对其进行传输。在传输的过程中，对令牌进行序列化，并且最好同时对其进行加密。
3. 目标服务器接收在协议 (CSIv2) 中嵌入对象的请求。
4. 目标服务器对该对象进行反序列化，并将其附加到主题。

配置

这个示例代码是场景 9中变体 A 的一个实现，并且下面描述了这种变体所特有的配置。

1. 在发送服务器中配置新的登录模块：
   1. 为 RMI_INBOUND 系统登录配置添加自定义登录模块。将它添加到 com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule 登录模块的后面。指定这些值：
      • 模块类名： com.ibm.issw.security.loginmodules.CustomTokenObject_LM
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required
   2. 为 DEFAULT、WEB_INBOUND 系统登录配置重复步骤 1a。
2. 在目标服务器上配置新的登录模块：
   1. 将自定义登录模块添加到 RMI_INBOUND 系统登录配置。将它添加到 com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule 登录模块的后面。指定这些值：
      • 模块类名： com.ibm.issw.security.loginmodules.CustomTokenObject_LM
      • 使用登录模块代理：Enabled
      • 身份验证策略：Required
   2. 为 DEFAULT、WEB_INBOUND 系统登录配置重复步骤 2a。

配置选项：

• 对于服务器之间不共享相同的用户注册中心和 LTPA 密钥的环境，自定义令牌传播也可以正常工作，就像安全属性传播（场景 8）的情况一样。自定义令牌对象传播不需要配置受信任的目标领域。要对这种情况进行测试，只需要使用自定义的登录模块场景（场景 6）对出站标识映射中的配置 from the ，以设置一个不在服务器之间共享 LTPA 密钥或者用户注册中心的环境。

自定义

该场景中的自定义工作基本上与场景 9 中的相同，除了自定义对象的实现独立于 WebSphere 令牌之外。

回页首

组合这些场景

可以对本文中描述的场景进行组合和混合，以满足您特定的需求。JAAS 和登录模块提供一种可供使用的、相当灵活的框架。例如：

1. 使用入站标识映射进行标识断言

   在目标服务器端获取断言的标识，然后将其用于执行入站标识映射。

2. 通过入站标识映射使用自定义的令牌对象进行标识断言

   在自定义的令牌对象中传输断言的标识，然后在目标服务器中获得该标识，并用于入站标识映射模块。

3. 使用自定义的令牌对象和服务器端标识断言进行标识断言

   在自定义的令牌对象中传输断言的标识，然后由服务器端的标识断言登录模块获得该标识并用于对标识进行断言。

还存在许多其他形式的组合。对哪些场景进行组合，这取决于具体的需求。本文中提供的登录场景和需求矩阵可以帮助您为应用程序设计最佳的登录解决方案。在这个电子表格中：

• 第一列中列出了本文中描述的所有登录场景。
• 标题栏中列出了每个场景的配置和应用程序需求。
• 在这个矩阵（带编号的列表）的下面给出了一些说明，您应该在选择解决方案之前，弄清楚矩阵中的这些内容。

这个矩阵可以帮助您：

• 查找或检查特定的登录场景所需的配置和应用程序需求。
• 浏览各种场景，通过与您的解决方案的需求进行匹配，以找到合适的场景。
• 浏览配置和应用程序需求，为您的解决方案查找合适的场景或者场景的组合。

回页首

Web 入站登录的 Trust Association Interceptor

本文没有深入地介绍 WebSphere Trust Association Interceptor (TAI)，主要是因为它与 JAAS 没有什么关系。然而，因为我们关心的是登录（特别是 Web 应用程序登录），所以可以将 Trust Association Interceptor 看作是位于 Web 容器前面的一种特殊类型的入站登录模块。这个模块完全截获传入的 Web (HTTP) 请求并执行登录，完成与登录模块类似的工作。所以在完成登录之后，它将传递标识，而不是主题。稍后，这个标识将用于创建主题。在 WEB_INBOUND 系统登录配置之前调用 Trust Association Interceptor。

有关 Trust Association Interceptor 更详细的信息，请参见 WebSphere Application Server 信息中心。

回页首

示例代码的设置

这个部分描述了如何设置 WebSphere Application Server 环境，以便对本文提供的示例代码进行测试。图 4 显示了要测试这些场景所需的最简单的设置。

图 4. 测试这些场景

在这个测试环境中：

• 共有三个节点，两个应用服务器节点和一个 Developer 节点。
• 每个应用服务器节点都安装了一个 LDAP 服务器作为用户注册中心。有些场景需要使用两个不同的用户注册中心。当只需要一个用户注册中心（两台应用服务器共享相同的用户注册中心）时，使用 appsrv01 节点（这个用户注册中心中包含两个服务器的 ID）的 LDAP 服务器。
• 这个环境中没有部署管理器。
• 不需要配置单元，并且对于使用两个浏览器会话的两台应用服务器，可以很容易地对配置任务进行管理。
• 图中还列出了示例中使用的用户。可以根据需要，采用任何方式对名称进行更改，只需要确保不同用户注册中心的名称不同，以便进行测试。
• 有两个企业应用程序，每个应用服务器一个：SenderApplication、TargetApplication。
• 还有三个库（JAR 文件），必须将其安装在这些应用服务器上。图 5 是一个部署图，用以帮助分发应用程序和库。

图 5. 示例环境的应用程序部署

请注意，对于所有的自定义登录模块，只有一个库文件 (JAR)。这可以使得示例的部署工作更加简单。通常，您的代码可以分为下面几部分：

• 发送服务器的系统登录模块和实用工具类（例如，回调处理程序和回调）。将它们部署到发送服务器的 lib 目录。
• 发送服务器的应用程序登录模块和实用工具类。它们作为部署于发送服务器的企业应用程序中的实用工具模块进行存储。
• 目标服务器的系统登录模块和实用工具类。将它们部署到目标服务器的 lib 目录。
• 目标服务器的应用程序登录模块和实用工具类。它们作为部署于目标服务器的企业应用程序中的实用工具模块进行存储。
• 将两台服务器共享的登录模块和实用工具类部署到这两台服务器的 lib 目录。
• 将登录模块的共享类（如令牌）部署到两台服务器的 lib 目录。

每个场景的应用服务器配置都不相同。要对这个场景进行测试，最好的方法是根据需要为特定的场景配置应用服务器，然后在尝试或者测试新的场景之前，返回到原始的、缺省的 WebSphere Application Server 安全配置（或者“未配置”）。

在配置和部署了场景之后，启动服务器，然后使用这个 URL 来访问 index 页面，该页面集中了所有的场景。http://appserver01.demo.ibm.net:9080/sender/index.html。当 Web 应用程序需要时，使用发送服务器的用户注册中心中的用户名进行登录。可以查看 SystemOut.log 文件，以了解实际测试工作的详细内容以及该代码所执行的工作。示例代码生成大量可供阅读的信息输出。

回页首

结束语

在您开始编写登录模块对应用服务器进行自定义的时候，请三思而后行。检查 WebSphere Application Server 可用的登录选项，因为您可能希望能够使用其中的某个选项，而无需进行更多的自定义工作。首先尝试找出一种基于配置、而不需要编写自定义代码的解决方案。如果您必须编写自定义的登录解决方案，您一定要清楚自己在做什么。您必须确保自定义的登录不会破坏该应用服务器上已经安装且正在运行的各种应用程序。不要只对您的代码进行测试：检查代码，并将它交给其他人进行检查。当涉及到自定义安全解决方案时，您应该尽可能地多加小心。

尽管本文面向 RMI/IIOP 和 CSIv2，但是您可能已经意识到，其中有关登录的概念和大多数的技术与其他的协议非常类似，包括 HTTP、WS-Security、等等。