1 背景

　　在網站建設的過程中，多個應用系統一般是在不同的時期開發完成的。各應用系統由于功能側重、設計方法和開發技術有所不同，也就形成了各自獨立的用戶庫和用戶認證體系。隨著網站的發展，會出現這樣的用戶群體：以其中的一個用戶為例，他（她）使用網站的多個應用系統，但在每個應用系統中有獨立的賬號，沒有一個整體上的網站用戶賬號的概念，進入每一個應用系統前都需要以該應用系統的賬號來登錄。這帶給用戶不方便的使用感受，用戶會想：既然我使用的是同一個網站上的應用，為什么不能在一次在網站上登錄之后不必再經過應用系統認證直接進入應用系統呢？用戶的要求我們稱之為 "單點登錄"。

圖 1.1 網站用戶要求單點登錄

2 分析

　　在多個擁有各自獨立的用戶體系的應用系統間實現單點登錄，我們要考慮以下的問題：

• 單點登錄系統的實現在各應用系統都采用B/S模式這一前提下進行。
• 需要在各應用系統間統一用戶認證標志，用戶登錄后可以得到用戶令牌，各應用系統認可統一的用戶令牌。
• 用戶令牌應當是安全加密的，并且要限定時效期。
• 由于每個應用系統都有自己的用戶庫，一個用戶可能在不同的應用系統中使用不同的賬號，因此每個要使用多個應用系統的用戶要設置一個統一的用戶賬號并以此賬號進行單點登錄，該賬號與該用戶在各應用系統中的一個賬號形成映射關系。
• 各應用系統可能屬于不同的域，因此要實現跨域的單點登錄。
• 已經上線運行的應用系統需要進行改造來支持單點登錄，正在開發的應用系統則可以在開發階段增加對單點登錄的支持，但應用系統之間應該是松耦合。
• 由于各應用系統往往都已經處于穩定運行期，單點登錄系統的實現應該對各應用系統的登錄認證體系沖擊最小，各應用系統原有的登錄流程依然可用。
• 一些應用服務器平臺雖然提供對單點登錄的支持，但要求應用系統用戶認證的設計符合其規范，這對已經處于運行期的應用系統來說難以實現。

3 設計

　　以下是系統的整體設計結構：

圖 3.1 系統結構圖

3.1 單點登錄管理應用

　　我們首先設計單點登錄管理應用：

圖 3.2 單點登錄管理應用

　　用戶在其中注冊一個單點登錄賬號，然后針對每個應用系統綁定一個該應用系統中原有的賬號，并維護這些注冊和綁定信息。綁定的過程需要單點登錄管理應用服務器到應用系統服務器上驗證用戶提供的該應用系統中原有賬號和密碼，應用服務器均以相同的Web Service接口提供該功能支持。

3.2 用戶單點登錄流程

　　 之后以用戶單點登錄管理應用和令牌傳輸識別的標準來實現用戶單點登錄流程。

1、用戶訪問應用系統。

圖 3.3 用戶單點登錄流程 - 步驟一

2、應用系統如果檢查到用戶沒有在自己的服務器登錄，則將用戶請求重定向到單點登錄服務器上。（使用重定向就可以處理各服務器跨域的情況）

圖 3.4 用戶單點登錄流程 - 步驟二

3、單點登錄服務器檢查到用戶已經單點登錄（如果用戶沒有單點登錄則要求用戶登錄，登錄標志存儲為客戶端瀏覽器的Cookie），找到該用戶在相應應用系統上綁定的賬號。

圖 3.5 用戶單點登錄流程 - 步驟三

4、單點登錄服務器根據第三步的結果生成用戶令牌，重定向回應用系統。

圖 3.6 用戶單點登錄流程 - 步驟四

5、應用系統接收統一格式的用戶令牌，取得用戶在本系統上的登錄賬號，將用戶在本系統上狀態置為登錄，返回用戶請求訪問的頁面。

圖 3.7 用戶單點登錄流程 - 步驟五

　　如果用戶在訪問應用系統之前已經在單點登錄服務器上登錄過，第二步到第四布對用戶來說就是透明的，用戶感覺只是向應用系統發出了訪問請求，然后得到了頁面反饋。

4 實現

(略)

5 總結

　　本方案設計的用戶單點登錄系統做到了：

• 真正了實現單點登錄、全網訪問，方便用戶的使用過程。
• 各系統之間耦合度低，應用系統的改造不破壞其固有流程和結構，整個系統的實施過程安全平滑。
• 統一了單點登錄服務器到應用服務器的用戶認證信息訪問標準，統一了令牌安全加密的傳輸和識別標準，為將來更多應用系統提供了統一的單點登錄框架。
• 整合了過去分散在各應用系統中雖然有內在關聯卻難以判別的用戶信息資源，為更進一步的用戶個性化服務打下了基礎。