赵本山的经典台词大象:利用 HttpClient 实现 WI/SSO 中的 Eager Sign in

级别： 中级
2008 年 1 月 31 日
本 文首先简单介绍了 IBM WI/SSO 的基本概念及其实现方式，在此基础上着重讨论 Eager Sign in 登录认证方式，指出和分析 Eager Sign in 的一些问题，并且提供相应的解决方案。WI/SSO 默认的 Eager Sign in 将用户认证信息直接提交到 WebSEAL 提供的认证表单，缺乏灵活性以及适用性。本文的解决方案在自定义登录页面和 WebSEAL 认证表单之间加入了中间过程，将该登录认证过程分为两步提交：1）提供一个自定义登录页面和 Servlet 用来收集用户认证信息，通常是用户名和口令；2）在服务器端将该 Servlet 收集到的认证信息连同必要的 HTTP 请求数据通过 HttpClient 一同提交到 WebSEAL 的认证表单，并根据 WebSEAL 返回的结果进行相应的处理。如果在认证过程中发生任何错误，通过结果处理可以转到自定义的错误页面，避免 WebSEAL 默认的认证错误处理。该解决方案的优点在于其灵活性以及适用性，可以有效地提升用户体验。
SSO 基本概念
单点登录（Single Sign On，简称为 SSO），是目前比较流行的企业业务整合的解决方案之一。利用 SSO，用户只需在应用服务器上登录一次，便可以访问启用了 SSO 域中的任何应用服务器，而无需再次登录。其实质就是获得对企业资源的访问权限。
单点登录不仅是企业应用集成（EAI）的一个重要方面，还是 SOA 按需时代的要求之一。它不仅降低安全风险和管理消耗，并且大大简化 SOA 的安全问题，从而提高服务之间的合作效率。
SSO 实现
SSO 并不是 Java EE 中的标准实现，而是各中间件提供商在提供 Java EE 应用服务器集群时提供的一种共享认证信息的机制，所以各厂商提供的实现方式不一样。例如 IBM 的 WebSphere 是通过 Cookies 记录认证信息，BEA 的 WebLogic 通过 Session 共享技术实现认证信息的共享，国内深圳金蝶的 Apusic 采用的技术和 BEA WebLogic 基本一致。
WI/SSO 基本概念及原理
IBM 提供的 SSO 解决方案——WI/SSO（Web Identity/Single Sign On）是 IBM 为其外部应用提供的标准用户服务，用来对 ibm.com 的用户进行注册，授权以及管理。它允许用户通过 IBM Tivoli Access Manager(TAM) 中的 WebSEAL 逆向代理安全服务器组件访问被保护的应用程序。WebSEAL 会对用户进行统一认证，并且管理用户认证信息。

如 图 1 所示，WebSEAL 位于外部和内部防火墙之间的非保护区（Demilitarized Zone，DMZ），用来向绿色区域的 Web 服务器转发请求。它会一直跟踪受保护的 IP 地址，接收发往 Web 服务器或应用服务器的请求，提供认证和授权服务，并在发送请求前把该请求的地址更改为实际目标地址转发出去。
图 2 以一个典型的用户登录会话为例，描述了 WI/SSO 认证过程。

首先，用户请求 ibm.com 域中任何被 WebSEAL 保护的资源，并将用户名 / 口令或者证书提交给 WebSEAL，要求认证；
WebSEAL 利用 LDAP 注册表中存储的用户信息对用户进行认证；
WebSEAL 签发一个 LTPA 令牌，在本地缓存并发送给 Web 服务器，最后发送到应用服务器；
应用服务器接受令牌并允许用户访问受保护的资源；WebSEAL 通过将 SSL 会话标识或者用户请求带来的的其它 Cookie 映射到 LTPA 令牌来维护状态，并且将它们发送到应用服务器。
在 整个认证过程中， WI/SSO 还提供一些用于单点登录的标准静态页面，例如登录页面、帐户被锁页面等等。通常这些静态页面用来重定向到 WI 用户服务应用中相应 JSP 页面，同时设置一些 Cookie 的值。表 1 列出了几个重要的静态 HTML 页面与 JSP 页面、Cookie 之间的对应关系。
静态页面相应的 JSP设置的 Cookies描述
login.html login.jsp?persistParge=true PD-ERR=%ERROR_CODE%
PD-REFPAGE=%URL%
PD-REFERER=%REFERER% 登录页面
acct_locked.html acc_locked.jsp PD-REFPAGE=%URL% 五次登录，帐户被锁
help.html help.jsp PD-REFPAGE=%URL% 已登录用户再次登录
WI/SSO 的登录认证方式
IBM WI/SSO 方案提供两种基本登录认证方式：
标准登录认证
使用标准方式登录认证时，在应用中页面中需要添加一个标记为类似“现在登录”的链接，指向受 WebSEAL 保护的任何资源，点击该链接将自动导向到 WI/SSO 登录页面（如图 3 所示）。

由图 3 可知，标准登录认证方式的登录页面是由 WebSEAL 统一提供的，这势必会导致在对遗留系统进行 SSO 方案集成时，登录、修改密码、出错等页面风格与企业应用风格不一致的问题，同时也会给用户造成一定的困惑。
为解决此问题，WI/SSO 中还提供另一种更为灵活的登录认证方式，这就是 Eager Sign in。
Eager Sign in 登录认证
Eager Sign in 登录认证方式允许应用提供根据企业应用风格自定义的登录页面，不再使用 WebSEAL 提供的标准登录页面，并且以 WebSEAL 所认可的方式提交认证请求。之后，WebSEAL 会对用户提交的认证信息进行认证，如果认证成功，会将用户重定向到应用指定的目标页面；否则，将用户重定向到 WebSEAL 标准的错误页面或者相应的登录 / 修改口令 / 用户被锁页面。
通过上面的介绍可以看到，Eager Sign in 登录认证方式的登录页面可以由企业应用自身提供，保持了遗留应用系统的整体风格，从而带来更完美的用户体验。因此，本文后面部分将着重介绍这种登录认证方式，并结合其不足提出改进的解决方案。



回页首
Eager Sign in 登录认证方式要求用户根据企业应用整体风格自定义登录页面。为了以 WebSEAL 所认可的方式提交用户认证请求，需要在自定义的登录页面中加入一个 Form 表单，如下所示：

enctype="application/www-x-form-urlencoded">
该 表单用来收集用户名和口令，并以设定的方式将用户名称 username 和口令 password 等参数 POST 到 WebSEAL 的标准登录表单 pkmslogin.form。WebSEAL 对用户进行认证，根据 WebSEAL 的配置将用户重定向到 loginredir.jsp 页面。该页面用来设置 IBMISS/IBMISP Cookie，并且将用户重定向到应用在 PD-SGNPAGE Cookie 指定的目标页面。至此，成功完成了整个 Eager Sign in 登录认证过程。
但是，如果在登录过程中出现任何错误，WebSEAL 会将用户自动重定向到标准的登录错误处理页面，比如标准的登录页面、修改口令页面、用户被锁页面等。下一小节将重点讨论 Eager Sign in 的不足并加以分析。
虽然 Eager Sign in 登录认证方式允许用户自定义登录页面，并且指定登录成功后所转向的目标页面，但是却不允许用户定制登录失败后的出错处理页面。显然这在某种程度上会影响用户的网络体验，主要体现为如下几个方面：
用户登录认证失败，页面会自动转向到 WI/SSO 所定义的标准登录页面，应用程序不能自定义错误处理页面以及控制页面转向流程；
当登录失败尝试超过五次时，会自动转向到标准的帐户锁定页面，页面并不十分友好。同样的，应用程序也不能自定义帐户锁定提示页面；
对所保护应用页面的请求都必须通过 WebSEAL 逆向代理服务器转向，降低了应用的性能；
不能和企业已有应用系统的认证模块相结合，企业应用整合困难；
将认证信息直接提交到 WebSEAL 提供的认证表单，缺乏灵活性和适用性。



回页首
为 解决 Eager Sign in 的几个问题，本文提供了利用 HttpClient 实现 WI/SSO Eager Sign in 的分步登录认证方案——在自定义登录页面和 WebSEAL 认证表单之间加入了中间过程，将用户登录认证过程分为两步提交。首先，应用提供自定义的登录页面自身用于采集用户认证信息，一般包括用户名和口令；其次， 在服务器端将采集到的认证信息以及必要的 HTTP 请求数据通过 HttpClient 提交到 WebSEAL 的认证表单，并对认证结果分析处理。如果在认证过程中发生任何错误 , 通过结果处理可以转到自定义的错误页面，避免 WebSEAL 默认的认证错误处理。该解决方案的优点在于其灵活性以及适用性，可以有效地提升用户体验。
HTTP 协议可能是现在 Internet 上使用得最多、最重要的协议了，越来越多的 Java 应用程序需要直接通过 HTTP 协议来访问网络资源。虽然 java.net 工具包提供了通过 HTTP 访问互联网资源的基本功能，但它并不完全满足企业应用程序所需要的丰富性和灵活性要求。Apache HttpClient 提供了一个高效、快速更新、功能丰富的支持 HTTP(S) 协议的客户端编程工具，极大地方便网络访问应用开发。
HttpClient 的主要功能包括以下几个方面，更多详细的功能可以参见 HttpClient 的主页http://commons.apache.org/httpclient。
实现了所有 HTTP 的方法（GET，POST，PUT，HEAD 等）
支持自动转向
支持 HTTPS 协议
针 对 Eager Sign in 登录认证方式不能控制登录流程等问题，本文提出了分步登录认证的方案，目的是利用 HttpClient 模拟客户端浏览器与 WebSEAL 进行交互，从而控制认证流程。若用户未通过认证，由 HttpClient 捕获 WebSEAL 响应的 HTTP 信息，并且对认证结果进行分析处理，最终将用户重定向到应用提供的登录处理页面，以获得极大的灵活性和适用性。该分步认证方案不仅可以控制 WebSEAL 认证流程，而且可以和企业应用很好的配合，从而兼容遗留认证模块。一旦认证成功，改进的登录认证方案就可以减少客户端浏览器与 WebSEAL 的交互，进而提高应用效率。
下面详细介绍利用 HttpClient 实现 WI/SSO 登录的分步认证策略：
第一步，提供自定义登录页面用以采集用户认证信息，包括用户名以及口令，设置 WebSEAL 认证表单需要的请求参数。
用户自定义的登录页面表单中的参数需要满足如下一些条件：
表单要 POST 到第二步所使用的 Servlet，也就是说表单使用这个 Servlet 为 Action
POST 请求主体必须包含如下三个参数： 用户名 username
口令 password
登录表单的类型 login-form-type
以用户名 / 口令方式认证时，login-form-type 的值必须为 "pwd"
content-length 请求头必须与请求体的长度相等
例如，使用 telenet 提交认证信息数据：
prompt>telnet webseal.example.com 80
Connected to webseal.example.com.
Escape character is '^]'.
POST /myServlet HTTP/1.1
host: webseal.webseal.com
content-length: 56
username=testuser&password=my0passwd&login-form-type=pwd
其中，login-form-type 指定了用户登录方式，例如：
用户名 / 口令登录表单：
令牌登录表单：
自定义的认证信息采集页面应该如下面的代码片段所示：

第二步，将采集到的认证信息用户名和口令参数连同必要的 Cookie、Header 提交到 WebSEAL 的认证表单，并对返回结果进行分析处理。具体如下：
(1) 在向 WebSEAL 认证表单提交认证信息之前，首先利用 HttpClient Get 方法尝试获取一个受保护的页面，用于判断该用户是否已经登录。如果返回响应状态是 SC_OK 200，并且返回内容为所访问的受保护页面，则说明该页面已找到，用户可以直接访问到受保护的资源，即用户已经成功登录过，不需要再次提交认证信息；否则 说明该用户没有登录，需要继续执行（2），向 WebSEAL 提交认证信息。
(2) 在提交认证请求之前，为了能控制页面转向流程，首先需要禁止 HttpClient Post 方法的自动转向功能：
将 登录页面采集到的认证信息如用户名和口令参数连同必要的 Cookie、Header 拷贝到 postMethod 中。值得注意的是，为了符合 WebSEAL 的规范，定制登录成功页面，需要为 HttpClient 额外添加两个会话 Cookie，分别是 PD-SGNPAGE 和 PD-FROMPAGE。其中，
1. PD-SGNPAGE ——指定用户认证成功后所导向的目标页面编码后的 URL；
2. PD-FROMPAGE ——指定用户选择“取消”后所显示页面编码后的 URL。它必须是一个没有被保护的页面，并且可能是与目前所显示页面相同的页面（带有登录表单的页面）。
(3) 提交 postMethod 并判断返回状态代码：
int statusCode = ssoHttpClient.executeMethod(postMethod);
如 果返回 SC_OK 200 状态，说明登录失败或者已经登录，转入认证失败处理，要么是无效的用户名 / 口令，要么是多次尝试失败被锁，要么是已经登录再次提交认证信息；如果返回 SC_MOVED_TEMPORARILY 302 状态，说明登录成功，将会重定向到 loginredir.jsp 页面，继续请求重定向页面，最终会重定向到受保护的目标页面。
其 中，HTTP 的返回代码为 200 说明页面已经找到，对 GET 和 POST 请求的应答文档跟在后面。返回代码为 302 是暂时重定向，说明所请求的资源在一个不同的 URL 处临时保存。出现该状态代码时，HttpClient 的方法（和客户端浏览器类似）一般会自动访问 HTTP 请求头中 Location 头指定的 URL。将 HttpClient 的方法自动转向功能取消掉，所以需要再次发起请求才能完成重定向，这带来的好处是我们可以控制页面的转向。
认证成功

将 认证信息提交到 WebSEAL 认证表单后，如果认证成功，则执行如图 4 所示的流程。请求 loginredir.jsp 页面，并判断返回状态代码，如果页面请求成功，会再次返回 SC_MOVED_TEMPORARILY 302 状态。同时，loginredir.jsp 还会根据用户标识设置 IBMISS 和 IBMISP 两个 Cookie 值，并重定向到 PD-SGNPAGE Cookie 中指定的登录成功后显示的目标页面。
继续请求用户指定的登录成功后显示的目标页面，并判断返回状态代码，如果请求成功，返回 SC_OK 200 状态，说明目标页面已经找到，可以访问受 WebSEAL 保护的页面。
为了将目标页面返回给用户浏览器端，还需要将 postMethod 中的 Header 和 HttpClient 获取到的 Cookie 加到 HttpServletResponse 中以发送给客户端浏览器。至此，用户完成登录认证，并定向到登录成功页面。
认证失败
图 5 描述了用户登录失败的情况。可以看到，由于分步登录方案人为控制认证流程，Servlet 可以捕获 WebSEAL 重定向到标准错误页面的响应，从而可以导向到应用自定义的错误页面。这样就避免了 Eager sign in 不能自定义错误处理页面的问题。

将认证信息提交到 WebSEAL 认证表单后，如果认证失败，返回 SC_OK 200 状态，则执行如图 5 所示的流程。
WebSEAL 返回的响应页面内容如下：