WI/SSO 默認的 Eager Sign in 將用戶認證信息直接提交到 WebSEAL 提供的認證表單，缺乏靈活性以及適用性。本文的解決方案在自定義登錄頁面和 WebSEAL 認證表單之間加入了中間過程，將該登錄認證過程分為兩步提交：1）提供一個自定義登錄頁面和 Servlet 用來收集用戶認證信息，通常是用戶名和口令；2）在服務器端將該 Servlet 收集到的認證信息連同必要的 HTTP 請求數據通過 HttpClient 一同提交到 WebSEAL 的認證表單，并根據 WebSEAL 返回的結果進行相應的處理。如果在認證過程中發生任何錯誤，通過結果處理可以轉到自定義的錯誤頁面，避免 WebSEAL 默認的認證錯誤處理。該解決方案的優點在于其靈活性以及適用性，可以有效地提升用戶體驗。

　　SSO 與 IBM WI/SSO

　　SSO 介紹

　　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 基本一致。

　　IBM WI/SSO 介紹

　　WI/SSO 基本概念及原理

　　IBM 提供的 SSO 解決方案——WI/SSO（Web Identity/Single Sign On）是 IBM 為其外部應用提供的標準用戶服務，用來對 ibm.com 的用戶進行注冊，授權以及管理。它允許用戶通過 IBM Tivoli Access Manager(TAM) 中的 WebSEAL 逆向代理安全服務器組件訪問被保護的應用程序。WebSEAL 會對用戶進行統一認證，并且管理用戶認證信息。

　　圖 1 WI/SSO 體系結構

　　如圖 1 所示，WebSEAL 位于外部和內部防火墻之間的非保護區（Demilitarized Zone，DMZ），用來向綠色區域的 Web 服務器轉發請求。它會一直跟蹤受保護的 IP 地址，接收發往 Web 服務器或應用服務器的請求，提供認證和授權服務，并在發送請求前把該請求的地址更改為實際目標地址轉發出去。

　　圖 2 以一個典型的用戶登錄會話為例，描述了 WI/SSO 認證過程。

　　圖 2 典型的用戶登錄會話場景

　　首先，用戶請求 ibm.com 域中任何被 WebSEAL 保護的資源，并將用戶名 / 口令或者證書提交給 WebSEAL，要求認證；

　　WebSEAL 利用 LDAP 注冊表中存儲的用戶信息對用戶進行認證；

　　WebSEAL 簽發一個 LTPA 令牌，在本地緩存并發送給 Web 服務器，最后發送到應用服務器；

　　應用服務器接受令牌并允許用戶訪問受保護的資源；WebSEAL 通過將 SSL 會話標識或者用戶請求帶來的的其它 Cookie 映射到 LTPA 令牌來維護狀態，并且將它們發送到應用服務器。

　　在整個認證過程中， WI/SSO 還提供一些用于單點登錄的標準靜態頁面，例如登錄頁面、帳戶被鎖頁面等等。通常這些靜態頁面用來重定向到 WI 用戶服務應用中相應 JSP 頁面，同時設置一些 Cookie 的值。表 1 列出了幾個重要的靜態 HTML 頁面與 JSP 頁面、Cookie 之間的對應關系。

　　表 1. WI/SSO 的幾個標準頁面

?

靜態頁面	相應的 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 WI/SSO 登錄頁面

　　由圖 3 可知，標準登錄認證方式的登錄頁面是由 WebSEAL 統一提供的，這勢必會導致在對遺留系統進行 SSO 方案集成時，登錄、修改密碼、出錯等頁面風格與企業應用風格不一致的問題，同時也會給用戶造成一定的困惑。

　　為解決此問題，WI/SSO 中還提供另一種更為靈活的登錄認證方式，這就是 Eager Sign in。

　　Eager Sign in 登錄認證

　　Eager Sign in 登錄認證方式允許應用提供根據企業應用風格自定義的登錄頁面，不再使用 WebSEAL 提供的標準登錄頁面，并且以 WebSEAL 所認可的方式提交認證請求。之后，WebSEAL 會對用戶提交的認證信息進行認證，如果認證成功，會將用戶重定向到應用指定的目標頁面；否則，將用戶重定向到 WebSEAL 標準的錯誤頁面或者相應的登錄 / 修改口令 / 用戶被鎖頁面。

　　通過上面的介紹可以看到，Eager Sign in 登錄認證方式的登錄頁面可以由企業應用自身提供，保持了遺留應用系統的整體風格，從而帶來更完美的用戶體驗。因此，本文后面部分將著重介紹這種登錄認證方式，并結合其不足提出改進的解決方案。

　　WI/SSO Eager Sign in

　　Eager Sign in

　　Eager Sign in 登錄認證方式要求用戶根據企業應用整體風格自定義登錄頁面。為了以 WebSEAL 所認可的方式提交用戶認證請求，需要在自定義的登錄頁面中加入一個 Form 表單，如下所示：

<form action="../../pkmslogin.form" method="POST"
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 缺點

　　雖然 Eager Sign in 登錄認證方式允許用戶自定義登錄頁面，并且指定登錄成功后所轉向的目標頁面，但是卻不允許用戶定制登錄失敗后的出錯處理頁面。顯然這在某種程度上會影響用戶的網絡體驗，主要體現為如下幾個方面：

　　用戶登錄認證失敗，頁面會自動轉向到 WI/SSO 所定義的標準登錄頁面，應用程序不能自定義錯誤處理頁面以及控制頁面轉向流程；

　　當登錄失敗嘗試超過五次時，會自動轉向到標準的帳戶鎖定頁面，頁面并不十分友好。同樣的，應用程序也不能自定義帳戶鎖定提示頁面；

　　對所保護應用頁面的請求都必須通過 WebSEAL 逆向代理服務器轉向，降低了應用的性能；

　　不能和企業已有應用系統的認證模塊相結合，企業應用整合困難；

　　將認證信息直接提交到 WebSEAL 提供的認證表單，缺乏靈活性和適用性。

　　分步登錄認證方案

　　為解決 Eager Sign in 的幾個問題，本文提供了利用 HttpClient 實現 WI/SSO Eager Sign in 的分步登錄認證方案——在自定義登錄頁面和 WebSEAL 認證表單之間加入了中間過程，將用戶登錄認證過程分為兩步提交。首先，應用提供自定義的登錄頁面自身用于采集用戶認證信息，一般包括用戶名和口令；其次，在服務器端將采集到的認證信息以及必要的 HTTP 請求數據通過 HttpClient 提交到 WebSEAL 的認證表單，并對認證結果分析處理。如果在認證過程中發生任何錯誤 , 通過結果處理可以轉到自定義的錯誤頁面，避免 WebSEAL 默認的認證錯誤處理。該解決方案的優點在于其靈活性以及適用性，可以有效地提升用戶體驗。

　　HttpClint 介紹

　　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 指定了用戶登錄方式，例如：

　　用戶名 / 口令登錄表單： <INPUT TYPE="HIDDEN" NAME="login-form-type" VALUE="pwd">

　　令牌登錄表單： <INPUT TYPE="HIDDEN" NAME="login-form-type" VALUE="token">

　　自定義的認證信息采集頁面應該如下面的代碼片段所示：

<form action="myServlet" enctype="application/x-www-form-urlencoded" method="post">
<input type="hidden" name="login-form-type" value="pwd"/>
<input type="text" name="username" id="username" value=""/>
<input type="password" name="password" id="password" value=""/>
</form>

　　第二步，將采集到的認證信息用戶名和口令參數連同必要的 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 的方法自動轉向功能取消掉，所以需要再次發起請求才能完成重定向，這帶來的好處是我們可以控制頁面的轉向。

　　認證結果分析處理

　　認證成功

　　圖 4 認證成功流程

　　將認證信息提交到 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 不能自定義錯誤處理頁面的問題。

　　圖 5 認證失敗流程

　　將認證信息提交到 WebSEAL 認證表單后，如果認證失敗，返回 SC_OK 200 狀態，則執行如圖 5 所示的流程。

　　WebSEAL 返回的響應頁面內容如下：

<html>
<head>
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Cache-Control" content="no-cache" />
<meta http-equiv="Expires" content="0" />
<meta http-equiv="Set-Cookie" content="PD-REFPAGE=/pkmslogin.form;
path=/; domain=.ibm.com" />
<meta http-equiv="Set-Cookie" content="
PD-REFERER=https://webauth.ibm.com/SSOWithLTPA/login.jsp; path=/; domain=.ibm.com" />
<meta http-equiv="Set-Cookie" content="PD-ERR=0x132120c8; path=/; domain=.ibm.com" />
<meta http-equiv="Refresh" content="0; url=
https://www-304.ibm.com/usrsrvc/account/userservices/jsp/login.jsp?persistPage=true" />
<title>IBM Registration>/title>
</head>
</html>

　　可以看出，該頁面的作用是設置 PD-REFPAGE、PD-REFERER 和 PD-ERR 三個 Cookie 值，并且交由客戶端自動刷新頁面到請求頭中所指定的 URL，可能是要求再次登錄或者帳戶被鎖的頁面。在這里，我們可以通過匹配自動刷新的 URL 地址的方法判斷用戶認證的失敗原因，包括如下兩種情況：無效的用戶名 / 口令，多次失敗嘗試用戶被鎖。另外還有一種情況是：用戶已經登錄但仍然提交認證信息到 WebSEAL 認證表單，自動刷新的目標 URL 會是 help.jsp。

　　其中，PD-REFPAGE 代表了用戶所請求的頁面或 WebSEAL 緩存的頁面 url。這個 url 認證成功后 WebSEAL 所應該請求的頁面。

　　PD-REFERER 代表了請求從哪兒來的頁面，或是 HTTP referrer 請求頭。如果用戶在地址欄手動輸入地址，或是使用書簽觸發一個登錄的流程，該 Cookie 的值即為空“none”，意味著不能判定 referrer 請求頭。

　　PD-ERR 通過登錄或賬戶管理頁面設置。該 Cookie 的值即錯誤編碼用來查找錯誤信息。

　　認證失敗的情況如下：

　　無效的用戶名 / 口令

　　如果用戶提交了非法或者無效的用戶名 / 口令，則 WebSEAL 返回自動刷新到要求再次登錄的頁面，刷新的目標 URL 是 https://www-304.ibm.com/usrsrvc/account/userservices/jsp/login.jsp?persistPage=true

　　多次登錄失敗嘗試

　　用戶多次輸入錯誤的用戶名 / 口令，提交到 WebSEAL 認證表單，則 WebSEAL 返回自動刷新到提示用戶被鎖的頁面，刷新的目標 URL 是 https://www-304.ibm.com/usrsrvc/account/userservices/jsp/acct_locked.jsp

　　已經登錄再次提交認證信息

　　如果用戶已經成功登錄并且再次提交認證信息，則 WebSEAL 返回自動刷新到提示用戶已經登錄的頁面，刷新的目標 URL 是 https://www-304.ibm.com/usrsrvc/account/userservices/jsp/help.jsp

　　最后，需要 Get 方法中的 Header 和 HttpClient 的 Cookie 一并加入 HttpServletResponse 中返回給用戶，并根據分析的失敗原因，重新請求應用中定義的相應錯誤處理頁面。

　　從上面的介紹中可以看出，該方案保留了 Eager Sign in 方式自定義登錄頁面的優點，能夠很好地和遺留系統的頁面風格保持一致。還針對 Eager Sign in 方式缺少靈活性和適用性的問題，使用分步登錄認證的策略，即使用 HttpClient 模擬客戶端瀏覽器與 WebSEAL 進行交互認證。一旦在該過程中發生認證錯誤，HttpClient 能捕獲該錯誤并重定向到應用本身的錯誤處理頁面，這樣也實現了錯誤頁面的定制，提升了用戶體驗。

　　此外，由于分步登錄的方案能夠人為控制頁面轉向流程，使用戶有可能在 WI/SSO 方案之外根據企業已有應用系統的認證策略增加一些安全措施，減少了遷移的工作量，做到了與遺留系統認證模塊的完美結合。并且，由于集成了已有的認證策略，用戶在登錄之后，不必將受保護應用的所有頁面請求都通過 WebSEAL 逆向代理服務器轉向，從而提高了應用的性能。

　　遇到的問題及解決辦法

　　下面介紹在利用 HttpClient 實現 WI/SSO Eager Sign in 過程中可能遇到的一些問題及其解決辦法。

　　字符編碼和 Content-Length 請求頭

　　自定義登錄頁面的編碼方式可能出現在不同地方，一是服務器返回的 HTTP 頭中，二是得到的 html/xml 頁面中。為正確讀取認證信息，在服務器端讀取用戶提交的信息時必須指定字符編碼。從請求中獲取參數時，設置字符編碼方式一般是：

　　httpRequest.setCharacterEncoding("UTF-8");

　　一旦設置完請求的編碼方式，則會按照 UTF-8 的方式讀取用戶提交的參數值。

　　將參數通過 HttpClient 接口添加到 Post 方法后，HttpClient 會對整個提交的內容進行編碼，從而導致實際的內容長度和請求 Content-Length 頭不一致，所以最好在處理請求頭時忽略 Content-Length 頭。或者調用 HttpClient 接口對內容進行編碼后獲取新的內容長度，從而保證傳入的 Content-Length 值和實際內容長度一致，以便能夠正確的提交到 WebSEAL 認證表單。

String content = EncodingUtil.formUrlEncode(postMethod.getParameters(),
postMethod.getRequestCharSet());
postMethod.setRequestHeader("Content-Length", "" + content.length());

　　Cookie 處理

　　HttpClient Cookie 規范參數

　　在 HttpClient 中有兩種方法來指定 Cookie 規范的使用：

HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);

　　這種方法設置的規范只對當前 HttpState 有效。另一種方法是指定系統的屬性，對每個新建立的 HttpState 對象都有效。

System.setProperty(“apache.commons.httpclient.cookiespec”, “COMPATIBILITY”);

　　PD-ERR 和 PD-ID

　　用戶認證成功后，會生成 PD-ID Cookie，當該 Cookie 被添加到客戶瀏覽器之后，任何到受 SSO 保護的應用的請求都會附上該 Cookie。同樣，用戶輸入了無效的用戶名 / 口令提交到 WebSEAL 認證表單進行認證時，會生成 PD-ERR Cookie，除非顯式地清除，該 Cookie 會一直存在客戶端的請求中直到當前會話結束。

　　用戶認證失敗后，SSO 生成 PD-ERR 同時清除 PD-ID；用戶再次提交正確的用戶名 / 口令 , 認證成功后，SSO 會生成 PD-ID 同時清除 PD-ERR Cookie。所以我們需要在服務器端對客戶瀏覽器的請求的 Cookie 和 HttpClient 認證結果中的 Cookie 進行同步，以到達認證狀態的一致性。

　　Cookie 域

　　WI/SSO 所生成的所有 Cookie 的域都被指定為 ibm.com，從而保證在 ibm.com 域下的受 SSO 保護的應用之間作邊界切換時能夠共享 Cookie。但是有時候從請求中獲取 Cookie 時 Domain 和 Path 可能都為空，所以不得不重置這些 Cookie，將其 Domain 設置為 ibm.com，Path 設置為“/”，這樣，發送到 ibm.com 域下所有應用的請求都會附上這些 Cookie。

　　支持 HTTPS 協議

　　WI/SSO 依賴于 SSL 進行用戶信息的傳遞。HttpClient 提供對 SSL 的支持，但是在使用 SSL 之前必須安裝 JSSE。這里有兩種方法可以打開 HTTPS 連接，一種是將服務器頒發的證書導入到本地的 keystore 中，另一種是擴展 HttpClient 來實現自動接受證書。就第一種方法可以參考引用中的 HttpClient 入門文章，下面介紹第二種方法。

　　擴展 HttpClient 實現自動接受證書

　　因為這種方法自動接受證書，因此存在一定的安全問題，所以在使用該方法前請仔細考慮應用系統的安全需求，在真正產品中并不建議使用自動接受證書或者接受所有證書。

　　具體步驟如下：

　　提供一個自定義的 Socket factory。自定義的類必須實現 HttpClient 接口 org.apache.commons.httpclient.protocol.SecureProtocolSocketFactory，在實現接口的類中調用自定義的 X509TrustManager，就這些類的實現可以參考 HttpClient 官方網站。

　　創建一個 org.apache.commons.httpclient.protocol.Protocol 實例，指定協議名稱和默認的端口號： Protocol https = new Protocol(“https”, new MySecureProtocolSocketFactory(), 443);

　　注冊創建的 https 協議對象，然后就可以按照普通方式打開 HTTPS 的目標地址 Protocol.registerProtocol(“https”, https);

　　HttpClient 重定向

　　HttpClient 支持自動轉向處理，但是像 POST 和 PUT 方式這種要求接受后繼服務的請求方式，暫時不支持自動轉向，因此如果碰到 POST 方式提交后返回的是 301 或者 302 的話需要自己處理，所要請求的地址可以在頭字段 location 中得到。不過需要注意的是，有時候 location 返回的可能是相對路徑，因此需要對 location 返回的值做一些處理才可以發起向新地址的請求。

　　另外除了在頭中包含的信息可能使頁面發生重定向外，在頁面中也有可能會發生頁面的重定向。引起頁面自動轉發的標簽是：<meta http-equiv="refresh" content="5; url=http://www.ibm.com/us">。如果你想在程序中也處理這種情況的話得自己分析頁面來實現轉向。需要注意的是，在上面那個標簽中 url 的值也可以是一個相對地址，如果是這樣的話，需要對它做一些處理后才可以轉發。

　　為了禁止 httpClient 自動重定向，需要在 post 之前將 httpClient 的重定向功能關閉：

httpMethod.setFollowRedirects(false);

　　總結

　　本文針對 WI/SSO 中 Eager Sign in 的登錄認證方式缺少靈活性和適用性的問題提出了分步登錄的認證方案。該方案不僅保留了 Eager Sign in 方式自定義登錄頁面的優點，還實現了錯誤頁面的定制，結合了已有系統的認證策略，從而做到與遺留系統認證模塊的完美結合，提升了用戶體驗。

　　值得注意的是，我們并不能保證本文所提出的分布登錄認證方案可以完美地實現企業應用單點登錄集成。

<!-- 分頁 --><!-- 分頁end -->

利用 HttpClient 實現 WI/SSO 中的 Eager Sign in