在 IBM Tivoli Access Manager 保护的环境中实现 Lotus Quickr 8.5（Domino base） 和 Lotus Connections 2.5 的集成

在 IBM Tivoli Access Manager 保护的环境中实现 Lotus Quickr 8.5（Domino base） 和 Lotus Connections 2.5 的集成

简介： 在企业级应用环境中，IBM Tivoli Access Manager(TAM) 作为一种典型的网络安全管理解决方案应用得十分广泛。在 TAM 的保护下 , 相比产品自身的单点登录而言，多产品间的集成时单点登录的实现面临证书共享，cookie 传递等问题，本文将以 Lotus Quickr for Domino 和 Lotus Connections 这两种协作软件间的集成为例，讨论如何在 TAM 保护下实现企业级产品的集成，剖析单点登录的工作原理，并提供常见问题的分析和诊断方法。单点登录 (SSO) 概述：

SSO 是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。

目前的企业应用环境中，往往有很多的应用系统，如团队协作管理系统 (Lotus Quickr), 个人社交网络 (Lotus Connections)，即时通讯系统 (LotusSametime) 等，这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和用户密码，进行身份验证；而且应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台，使用 SSO 技术可以解决以上这些问题 .

SSO 的主要的实现技术包括：基于 cookies 的实现，Broker-based( 基于经纪人 ), Agent-based( 基于代理 ) , 基于网关 ，基于安全断言标记语言 (SAML) 等，本文中的场景将着重基于 cookies 和基于代理这两种方式的实现。

回页首

Lotus Quickr与 LotusConnections 集成过程中基于 cookies 实现单点登录

在了解基于 Cookies 实现单点登录之前，需要简单了解一下产品各自是如何利用 cookies 实现自身的登录的 , 以 Lotus Quickr 自身的登录（浏览器模式）为例 : 如下图 1 所示：

1. 1. 第一次访问时首先由浏览器向 Quickr 服务器发出 HTTP 请求，如果此请求需要浏览受保护的页面（即登录以后才能看到内容），则 Quickr 服务器返回一个登录页面；
   2. 客户填好登录信息，通过浏览器将用户名和密码发送到 Quickr 服务器，Quickr 服务器通过查询 LDAP 来确定此用户名和密码是否正确，如果有效，则将该用户信息以 cache 的形式存储在服务器端，并用 LTPA 密钥将之进行加密，作为 cookie 返回给浏览器；
   3. 浏览器将该 cookies 存于本地，下次发送 HTTP 请求的时候将该 cookies 一起发送至服务器端，此时服务器只需将此 cookies 解密，与服务器上维护的用户信息 cache 队列进行比对，如发现用户信息有效则直接通过，不需要再次到 LDAP 服务器上进行验证，将浏览器请求的页面内容返回：

图 1. 基于 Cookies 的登录机制
 

需要说明的是，浏览器可以将 cookies 存于不同的地方，比如可以选择存于自己的 hostname.domain.name 文件夹下，也可以存于 domain.name文件下下，如图 2 所示。这两者的区别在于如果存于hostname.domain.name 下，则只有向该 host 发送请求的时候才会带上该 cookies，如果存于 domain.name 文件夹下，则只要向该域内的任何服务器发送请求 , 该 cookies 都可以被包含在请求内。

图 2. 本地的 Cookies 文件夹
 

在 Quickr Domino 与 Lotus Connections 的集成中便是采用后一种方法来实现域内的单点登录的：

例如 Quickr Domino 的服务器地址为 quickr.domain.name， Lotus Connections 的服务器地址为Connections.domain.name

1. 当用户登录到 quickr.domain.name 时，本地的浏览器便将该用户的 cookies 存于 domain.name 文件夹下；
2. 当用户在有效期内再次登录 Connections.domain.name 时浏览器便会将该 cookies 附于请求中一起发送到 Lotus Connections 的服务器中，Lotus Connections 服务器用共用的 LTPA Key 将该 cookies 解密，得到用户信息，并拿到公用的 LDAP 上进行验证，如果通过，则赋予该用户权限。

这样该用户只用在 Quickr Domino 服务器上登录一次，便可以在 Lotus Connections 服务器上获得自己的权限，实现从 LotusQuickr 到 LotusConnections 的单点登录，反之从 Lotus Connections 到 Lotus Quickr 亦然。

需要注意的是必须保证这两个服务器处于同一域内，而且共享同一个 LDAP，共用同一个 LTPA key。

回页首

基于 TivoliAccess Manager 实现 LotusConnections 和 LotusQuickr 集成环境中的单点登录

在企业环境中，往往会借助 IBM Tivoli Access Manager — WebSEAL 组件用于实现反向代理，反向代理充当门户和其他 Web 应用程序的联系人的联合单一登录点。使用上述反向代理，由于身份验证逻辑存在于 Tivoli Access Manager WebSEAL 层中，可以在将来支持更复杂的身份验证机制。IBMTivoli Access Manager WebSEAL 负责管理并保护基于 Web 的信息和资源，其通常作为逆向 Web 代理，从 Web 浏览器接收 HTTP ／ HTTPS 请求并交付来自其自己的 Web 服务器或来自联结的后端 Web 应用程序服务器的内容。通过 WebSEAL 的请求由 Tivoli Access Manager 授权服务评估，以确定是否授权用户访问所请求的资源。

本文中讨论的集成环境拓扑结构图如下所示：

图 3. TAM Lotus Quickr 和 LotusConnections 集成环境的拓扑结构图
 

在此环境中，Lotus Quickr 和 Lotus Connections 服务器均置于 TAM WebSEAL 之后，浏览器直接访问 TAM WebSEAL统一接口，从而保护了Lotus Domino 和 Lotus Connections 的真实 URL 不会暴露给客户。

值得注意是如图 3 中虚线所示，Lotus Quickr 和 Lotus Connections 的集成过程中互相并不知道对方真实的地址，而是间接通过和 TAMWebSEAL 的通讯来完成。

同样在讨论 TAM WebSEAL 保护的环境中产品间的单点登录问题之前，需要简单了解一下该环境下单产品单点登录的过程，如图 4 所示，以登录 Lotus Connections 服务器为例：

• 浏览器向 WebSEAL 服务器发出 HTTP 请求，WebSEAL 发现请求的是受保护页面，于是它向浏览器返回登录页面（TAM 自己的登录页面）
• 用户输入登录信息后浏览器将用户名和密码发送至 WebSEAL 服务器，WebSEAL 将该用户名密码发给 Policy 服务器进行校验，Policy 服务器通过和 LDAP 里的用户进行比对后验证通过，返回给 WebSEAL 服务器，WebSEAL 生成与该用户信息对应的 Cookies:PD-H-SESSION-ID 发回给浏览器，作为其下次访问的凭证；
• 浏览器将该 Cookies 保存在本地，以后凡是向 WebSEAL 发送的请求中都带上此 Cookies，而该 Cookies 在通过 WebSEAL 时则被自动解析成用户信息，经过 LTPA key 进行加密后形成 LTPA Token，代替原来的 PD-H-SESSION-ID 随请求发送至后端服务器（Lotus Connections 或 Lotus Quickr）, 以 Lotus Connections 为例，它利用 LTPA Key 将得到的 LTPA Token 进行解密，得到用户信息，拿到 LDAP 服务器上进行验证，如果通过，则返回需要的内容给 WebSEAL，WebSEAL 将之发送回浏览器，至此完成一次请求的全过程。

图 4. TAM 保护下单产品的登录过程
 

可以看出如果想要利用 TAM 实现 Lotus Quickr 和 Lotus Connections 集成过程中的单点登录，服务器之间需要满足一些制约条件：

• Policy 服务器，Lotus Quickr 服务器，Lotus Connections 服务器需要保证使用同一个 LDAP，在同一个域中（保证 Cookies 能够随 HTTP 请求一同发出），而且需要保证他们加密解密 LTPA Token 使用的是同一个 LTPA key；
• 另外为了防止 Cookies 过期，这三个服务器需要保证时间同步，误差最好在 5 分钟以内。

回页首

TAM 环境下集成环境中实现单点登录的配置：

在 TAM 下根据图（4）中所示的拓扑结构图进行 Lotus Quickr 和 Lotus Connections 之间的集成，可以参考下面的帮助文档 [1][2][3] 进行配置，其中为 LotusQuickr 和 LotusConnections 单独配置 TAM 可以参照参考资料中 [4][5] 的帮助文档，

值得注意的是，在这样的拓扑结构中 Lotus Connections 和 Lotus Quickr 服务器都是通过 TAM WebSEAL服务器来进行通讯的，他们之间并不会直接通讯，因此在所有需要填写 Lotus Connections 或 Lotus Quickr 服务器 host 地址的时候，这里都应该用 WebSEAL 服务器的 host 地址来代替，而且如果配置的是标准的 junction[10]，则需要在 URL 中将 junction 的名字加上 , 比如 http://quickrserver.domain.name 会被替换成http://tamserver.domain.name/junctionname

另外为了保证三者使用的是同一个 LTPA key，一般的做法是从 Lotus Connections 的 WebSphere 的管理界面中导出 LTPA key，然后分别拷贝到 TAM 和 Lotus Quickr 服务器上，并分别在创建 junction 的时候引用和在配置 LotusQuickr 单点登录文件的时候导入。

回页首

TAM 环境下集成环境中实现单点登录的问题诊断案例：

如前所述，在 TAM 环境下对单点登录问题的诊断也主要从这些方面入手：

• 配置是否正确，上述的几个条件是否准确无误的满足了
• 了解每个 HTTP 请求需要走的路径，保证其携带的通行证（Cookies）是否正确：想要通过 TAM WebSEAL，需要有 PD-H-SESSION-ID Cookies，想要被后端服务器 (Lotus Quickr, Lotus Connections) 接受，则需要带有正确的 LTPA Token Cookies。

下面以一个案例来说明如何从 cookies 着手，分析诊断单点登录的问题：

当我们进行 activity 的集成测试时碰到如下问题 :

根据 [2] 做好集成后，从 Lotus Connections Activity 上往 Lotus Quickr 发布文档时碰到一个未授权的错误：CLFRA0489E:You are not authorized to publish to this location.

图 5. 从 Activities 向 LotusQuickr 发布文档时出错截图
 

经过仔细检查，排除了配置上的错误以后，下一步的诊断的重点转向了请求中的 Cookies：既然在这个环境中 Activity 服务器是通过 TAM 向 Quickr 服务器发送 HTTP 请求的，那么这个请求应该首先能够通过 TAM WebSEAL 服务器的认证才能到达 Quickr 服务器 , 正确的传送顺序如图 6 所示的红色箭头：

Lotus Connections 服务器向 WebSEAL 发送一个包含名为PD-H-SESSION-ID 的 Cookies 的请求 (1)，当 WebSEAL 收到此请求时，也同时收到了这个 Cookies，WebSEAL 对该 Cookies 进行解析得到对应的用户信息 (2)，然后利用已知的 LTPA key 对之进行加密形成 LTPA-Token(3），然后以 Cookie 的形式发送至 Lotus Quickr 服务器 , 当 Lotus Quickr 服务器收到该 LTPA-token(4) 以后同样利用 LTPA key 进行解析，得到用户信息，通过验证 , 完成一个完整的消息发送。

图 6. Lotus Connections 和 LotusQuickr 如何在 TAM 集成通讯
 

基于以上的分析，我们在诊断过程中引用了一个第三方的网络封包分析工具：wireshark 来抓取服务器间的通讯消息包来进行分析，这是一个开源的软件，你可以通过 http://www.wireshark.org/ 来下载和使用它。

在我们的场景中，TAM WebSEAL 上安装了一个 wireshark，用来监测 WebSEAL 与 Lotus Connections 和 Lotus Domino 之间的通讯，在 activities 向 Quickr 服务器上发布文档时，wireshark 抓到下面的数据包：

清单 1. 修改之前Activity 将文档发布到 Lotus Quickr 服务器的 Post请求

POST /new/LotusQuickr/testactivity/  Main.nsf?Login&RedirectTo=%2Fdm%2Fatom%2Flibrary%2F_Ptestactivity  _RMain.nsf%2Ffolder%2F_Ptestactivity_RMain.nsf_FCD0EF97D625305B905  25670800167213%2Ffeed  HTTP/1.1           Content-Type: text/plain           Slug: testTXT.txt           Content-Type: text/plain  Cookie: JSESSIONID=0000mM16gVQkRk08kXP411ZLhqS:-1;  oatagcloudview=cloud;  NonceToken=C9E2F4EE1DF5D5F5482576DC002D87FF;  QuickrPickerRecentHosts=http%3A%2F%2Ftamserverhost.domain.name  %2Fjunctionname; LtpaToken2=P41OU44j3iCk4XbikPLoF46R/  IsQixiujvkGlxLotus ConnectionsmUXl4Ag3zymIsrwq2seRHXZxiOM6tB7z  E41cYt23btT55eTgDCkqxuQnyweHe7h5ngI8XTsLotus Quickr  VpZ0K03UNLgxazz3GHW05GGPLhJtTh7XkfOWm7DCBXHfw0cLGF/UCR0UbOchtD4  nXO3H6C8DMrImMB/Ix0YbZJplTkVXiZsNAq4ccHj7YNRB4X1JXr6s+hS5H5fBf2/  w9yTxCNjxEt5lGcTygCQLwxjD1FtMzJlgO/m65k3uFO9hzoX4TtX0uX1b6cQok7  fhSasvEcdmPLh6/UNy1nJ0/jj4ld/NWauejPoAal4Llu4scJHOeNQ264q5PrvRv6Qi  +tS3RfQjNDCCiJStWRzXonQYsZ9XnvY+hxKFizdKUVSAU2Tl274cmdiIIM=           User-Agent: Jakarta Commons-HttpClient/3.0

 

我们发现在请求 1 中包含了一个名为 LtpaToken2 的 Cookies 而非我们期望的 PD-H-SESSION-ID, 因而 TAM WebSEAL 给其返回了一个登录页面，导致这个请求在这个阶段就被阻拦。

发现了问题的所在，我们需要解决的是如何让请求 1 中带上 PD-H-SESSION-ID 这个 Cookie，但是从前面的 TAM 登录过程（图 4）可以看出，Lotus Connections 服务器上并不会保留 TAM WebSEAL颁发的凭证PD-H-SESSION-ID，因为原有请求中的 PD-H-SESSION-ID 在通过 TAM WebSEAL 的时候早就被拦截并被解析替换成了 LTPA Token，想让 PD-H-SESSION-ID 能够顺利到达 Lotus Connections 服务器，则需要在 TAM WebSEAL上做一些额外的配置使之能够顺利的通过 TAM WebSEAL，TAM 的帮助中心中提供了一个在创建 junction 的时候用到的 -k 参数 [10]，它可以帮我们解决这个问题，根据帮助文档中的说明，我们重新为 Lotus Connections 中的 activities 创建了一个带 -k 参数的 junction :

清单 2. 创建junction 的命令

server task default-webseald-tamserver.domain.name create -t tcp -h  Lotus Connectionsserver.domain.name -k -x -p 80 -i -b ignore -f -A -2 -F  LTPAKey_Path -Z ltpa_key_password /activities

 

重启服务器后我们重新跟踪请求 1，发现此时 PD-H-SESSION-ID 已经被包含在请求之中，而且 Activities 的文档也顺利的发布到了 LotusQuickr 服务器上了：

清单 3. 修改后Activity 将文档发布到 Lotus Quickr 服务器的 Post请求

POST /activities/service/html/post/publishFile HTTP/1.1  Host: tamserver.domain.name  User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8)  Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729)  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  Accept-Language: en-us,zh-cn;q=0.5  Accept-Encoding: gzip,deflate  Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7  Keep-Alive: 300  Connection: keep-alive  LotusConnectionsClient: Activities  Content-Type: application/x-www-form-urlencoded;charset=UTF-8  X-Requested-With: XMLHttpRequest  Referer: http://tamserver.domain.name/activities/service/html/mainpage  Content-Length: 342  Cookie: PD-H-SESSION-ID=  4_xrm2IRZaIj5qNwSwzap5Q+kgnSv8NbZ7ERt20lH4kSDGVQuN;  JSESSIONID=00006d9TmVNNUDEVrJJjlF-azjz:-1;  NonceToken=E3C15664EBC83438482576DC002AC4B2;  QuickrAcceptLanguages=en-us%2Czh-cn%3Bq%3D0.5;  QuickrStringLocale=en%2Czh; QuickrStyleLocale=en;  IV_JCT=%2Fnew; oatagcloudview=cloud;  QuickrPickerRecentHosts=http%3A%2F%2Ftamserver.domain.name  %2Fjunctionname  Pragma: no-cache  Cache-Control: no-cache