基于 Tivoli Access Manager 实现 Lotus Connections
在企业级应用环境中，IBM Tivoli Access Manager(TAM) 作为一种典型的网络安全管理解决方案应用得十分广泛。在 TAM 的保护下 , 相比产品自身的单点登录而言，多产品间的集成时单点登录的实现面临证书共享，cookie 传递等问题，本文将以 Lotus Quickr for Domino 和 Lotus Connections 这两种协作软件间的集成为例，讨论如何在 TAM 保护下实现企业级产品的集成，剖析单点登录的工作原理，并提供常见问题的分析和诊断方法。
作者: 忍者神龟 发布时间: 2011-04-20
首先先介绍一下 单点登录 (SSO)
SSO 是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。
目前的企业应用环境中，往往有很多的应用系统，如团队协作管理系统 (Lotus Quickr), 个人社交网络 (Lotus Connections)，即时通讯系统 (Lotus Sametime) 等，这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和 用户密码，进行身份验证；而且应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企 业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台，使用 SSO 技术可以解决以上这些问题 .
SSO 的主要的实现技术包括：基于 cookies 的实现，Broker-based( 基于经纪人 ), Agent-based( 基于代理 ) , 基于网关 ，基于安全断言标记语言 (SAML) 等，本文中的场景将着重基于 cookies 和基于代理这两种方式的实现。
SSO 是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。
目前的企业应用环境中，往往有很多的应用系统，如团队协作管理系统 (Lotus Quickr), 个人社交网络 (Lotus Connections)，即时通讯系统 (Lotus Sametime) 等，这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和 用户密码，进行身份验证；而且应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企 业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台，使用 SSO 技术可以解决以上这些问题 .
SSO 的主要的实现技术包括：基于 cookies 的实现，Broker-based( 基于经纪人 ), Agent-based( 基于代理 ) , 基于网关 ，基于安全断言标记语言 (SAML) 等，本文中的场景将着重基于 cookies 和基于代理这两种方式的实现。
作者: 忍者神龟 发布时间: 2011-04-20
基于 Tivoli Access Manager 实现 Lotus Connections 和 Lotus Quickr 集成环境中的单点登录
在企业环境中，往往会借助 IBM Tivoli Access Manager — WebSEAL 组件用于实现反向代理，反向代理充当门户和其他 Web 应用程序的联系人的联合单一登录点。使用上述反向代理，由于身份验证逻辑存在于 Tivoli Access Manager WebSEAL 层中，可以在将来支持更复杂的身份验证机制。IBM Tivoli Access Manager WebSEAL 负责管理并保护基于 Web 的信息和资源，其通常作为逆向 Web 代理，从 Web 浏览器接收 HTTP ／ HTTPS 请求并交付来自其自己的 Web 服务器或来自联结的后端 Web 应用程序服务器的内容。通过 WebSEAL 的请求由 Tivoli Access Manager 授权服务评估，以确定是否授权用户访问所请求的资源。
在此环境中，Lotus Quickr 和 Lotus Connections 服务器均置于 TAM WebSEAL 之后，浏览器直接访问 TAM WebSEAL 统一接口，从而保护了 Lotus Domino 和 Lotus Connections 的真实 URL 不会暴露给客户。
值得注意是如图 3 中虚线所示，Lotus Quickr 和 Lotus Connections 的集成过程中互相并不知道对方真实的地址，而是间接通过和 TAM WebSEAL 的通讯来完成。
同样在讨论 TAM WebSEAL 保护的环境中产品间的单点登录问题之前，需要简单了解一下该环境下单产品单点登录的过程，如图 4 所示，以登录 Lotus Connections 服务器为例：
• 浏览器向 WebSEAL 服务器发出 HTTP 请求，WebSEAL 发现请求的是受保护页面，于是它向浏览器返回登录页面（TAM 自己的登录页面）
• 用户输入登录信息后浏览器将用户名和密码发送至 WebSEAL 服务器，WebSEAL 将该用户名密码发给 Policy 服务器进行校验，Policy 服务器通过和 LDAP 里的用户进行比对后验证通过，返回给 WebSEAL 服务器，WebSEAL 生成与该用户信息对应的 Cookies
D-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 将之发送回浏览器，至此完成一次请求的全过程。
在企业环境中，往往会借助 IBM Tivoli Access Manager — WebSEAL 组件用于实现反向代理，反向代理充当门户和其他 Web 应用程序的联系人的联合单一登录点。使用上述反向代理，由于身份验证逻辑存在于 Tivoli Access Manager WebSEAL 层中，可以在将来支持更复杂的身份验证机制。IBM Tivoli Access Manager WebSEAL 负责管理并保护基于 Web 的信息和资源，其通常作为逆向 Web 代理，从 Web 浏览器接收 HTTP ／ HTTPS 请求并交付来自其自己的 Web 服务器或来自联结的后端 Web 应用程序服务器的内容。通过 WebSEAL 的请求由 Tivoli Access Manager 授权服务评估，以确定是否授权用户访问所请求的资源。
在此环境中，Lotus Quickr 和 Lotus Connections 服务器均置于 TAM WebSEAL 之后，浏览器直接访问 TAM WebSEAL 统一接口，从而保护了 Lotus Domino 和 Lotus Connections 的真实 URL 不会暴露给客户。
值得注意是如图 3 中虚线所示，Lotus Quickr 和 Lotus Connections 的集成过程中互相并不知道对方真实的地址，而是间接通过和 TAM WebSEAL 的通讯来完成。
同样在讨论 TAM WebSEAL 保护的环境中产品间的单点登录问题之前，需要简单了解一下该环境下单产品单点登录的过程，如图 4 所示，以登录 Lotus Connections 服务器为例：
• 浏览器向 WebSEAL 服务器发出 HTTP 请求，WebSEAL 发现请求的是受保护页面，于是它向浏览器返回登录页面（TAM 自己的登录页面）
• 用户输入登录信息后浏览器将用户名和密码发送至 WebSEAL 服务器，WebSEAL 将该用户名密码发给 Policy 服务器进行校验，Policy 服务器通过和 LDAP 里的用户进行比对后验证通过，返回给 WebSEAL 服务器，WebSEAL 生成与该用户信息对应的 Cookies
D-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 将之发送回浏览器，至此完成一次请求的全过程。
作者: 忍者神龟 发布时间: 2011-04-20
可以看出如果想要利用 TAM 实现 Lotus Quickr 和 Lotus Connections 集成过程中的单点登录，服务器之间需要满足一些制约条件：
• Policy 服务器，Lotus Quickr 服务器，Lotus Connections 服务器需要保证使用同一个 LDAP，在同一个域中（保证 Cookies 能够随 HTTP 请求一同发出），而且需要保证他们加密解密 LTPA Token 使用的是同一个 LTPA key；
• 另外为了防止 Cookies 过期，这三个服务器需要保证时间同步，误差最好在 5 分钟以内。
• Policy 服务器，Lotus Quickr 服务器，Lotus Connections 服务器需要保证使用同一个 LDAP，在同一个域中（保证 Cookies 能够随 HTTP 请求一同发出），而且需要保证他们加密解密 LTPA Token 使用的是同一个 LTPA key；
• 另外为了防止 Cookies 过期，这三个服务器需要保证时间同步，误差最好在 5 分钟以内。
作者: 忍者神龟 发布时间: 2011-04-20
欢迎大家留言交流
作者: 忍者神龟 发布时间: 2011-04-20
感谢分享~~~~~~~~~
作者: loveit 发布时间: 2011-04-20
支持一个~~~~~~~~~·
作者: loveit 发布时间: 2011-04-20
感谢分享~~~~~~~·
作者: hm_nkjack 发布时间: 2011-04-20