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