SSO的概念：
單點登錄SSO（Single Sign-On）是身份管理中的一部分。SSO的一種較爲通俗的定義是：SSO是指訪問同一服務器不同應用中的受保護資源的同一用戶，只需要登錄一次，即通過一個應用中的安全驗證後，再訪問其他應用中的受保護資源時，不再需要重新登錄驗證。
SSO的用途：
目前的企業應用環境中，往往有很多的應用系統，如辦公自動化（OA）系統，財務管理系統，檔案管理系統，信息查詢系統等等。這些應用系統服務於企業的信息化建設，爲企業帶來了很好的效益。但是，用戶在使用這些應用系統時，並不方便。用戶每次使用系統，都必須輸入用戶名稱和用戶密碼，進行身份驗證；而且應用系統不同，用戶賬號就不同，用戶必須同時牢記多套用戶名稱和用戶密碼。特別是對於應用系統數目較多，用戶數目也很多的企業，這個問題尤爲突出。問題的原因並不是系統開發出現失誤，而是缺少整體規劃，缺乏統一的用戶登錄平臺，使用SSO技術可以解決以上這些問題
SSO的好處：
- 方便用戶：從用戶實際使用角度考慮
用戶使用應用系統時，能夠一次登錄，多次使用。用戶不再需要每次輸入用戶名稱和用戶密碼，也不需要牢記多套用戶名稱和用戶密碼。單點登錄平臺能夠改善用戶使用應用系統的體驗。
- 方便管理員：從日常維護管理角度考慮
系統管理員只需要維護一套統一的用戶賬號，方便、簡單。相比之下，系統管理員以前需要管理很多套的用戶賬號。每一個應用系統就有一套用戶賬號，不僅給管理上帶來不方便，而且，也容易出現管理漏洞。 - 簡化應用系統開發：從應用擴展角度考慮 開發新的應用系統時，可以直接使用單點登錄平臺的用戶認證服務，簡化開發流程。單點登錄平臺通過提供統一的認證平臺，實現單點登錄。因此，應用系統並不需要開發用戶認證程序。
SSO架構及原理：
單點登錄的實質就是安全上下文（Security Context）或憑證（Credential）在多個應用系統之間的傳遞或共享。當用戶登錄系統時，客戶端根據用戶的憑證（例如用戶名和密碼）爲用戶建立一個安全上下文，安全上下文包含用於驗證用戶的安全信息，系統用這個安全上下文和安全策略來判斷用戶是否具有訪問系統資源的權限。
上圖中的流程反映出當應用系統調用信息平臺所提供的SSO登錄過程中的步驟。從上圖中，當應用系統或用戶訪問應用系統的單點登錄頁面（aspx、JSP、Servlet、ASP）時，應用系統需要檢查用戶當前請求中是否包含信息平臺的單點登錄信息（如Cookie）。如果當前請求中包含SSO Token，應用系統應該獲取SSO Token的數據，並把SSO Token的數據通過信息平臺提供的WebService(或其它方式)對其進行驗證。如果當前請求中不包含SSO Token，應用系統可以直接返回登錄錯誤信息給客戶端。應用系統可以根據信息平臺對SSO Token的驗證結果進行相應的處理。
SSO的技術：
- 基於cookies實現：
利用瀏覽同域名之間自動傳遞cookies機制，實現兩個域名之間系統令牌傳遞問題；另外，關於跨域問題，雖然cookies本身不跨域，但可以利用它實現跨域的SSO。如：代理、暴露SSO令牌值等。 - Broker-based(基於經紀人)
這種技術的特點就是，有一個集中的認證和用戶帳號管理的服務器。經紀人給被用於進一步請求的電子的身份存取。中央數據庫的使用減少了管理的代價，併爲認證提供一個公共和獨立的“第三方”。例如 集團SMAP 、Kerberos、Sesame、IBM KryptoKnight（憑證庫思想）等 - Agent-based(基於代理)
在這種解決方案中，有一個自動地爲不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如, 它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理被放在服務器上面，在服務器的認證系統和客戶端認證方法之間充當一個“翻譯”；例如 SSH等。 - Token-based
現在被廣泛使用的口令認證，比如FTP，郵件服務器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用 - 基於網關
- 基於安全斷言標記語言(SAML)實現
SAML（Security Assertion Markup Language，安全斷言標記語言）的出現大大簡化了SSO，並被OASIS批准爲SSO的執行標準。
筆者實現的單點登錄：
筆者基於實現成本最低，當然安全係數是最低的基於Cookie的單點登錄系統。單點登錄的交互過程如下圖（圖畫的不專業，見笑了）：
簡單描述一個筆者的實現過程
步驟1：用戶通過瀏覽器訪問系統A，驗證是否有SSO信息
A,系統A首先讀取客戶端的cookie,若cookie的值爲空則轉步驟2，否則繼續往下判斷；
B,讀取系統A的Session，若Session與cookie的token值相同，則直接返回用戶所訪問的頁面；若不同則繼續轉C步驟處理；
C,調用SSO的Web服務【這期間需要對調用web服務的參數如帳號密碼進行驗證，也可以對訪問IP或IP段做訪問控制】，驗證cookie中的值包含的時間戳是否過期，若過期則轉步驟2；若未過期則判斷SSO是否被篡改，篡改則轉步驟2，未篡改則記錄**用戶於**時間登錄了**系統（還可以記錄客戶端的相關信息，如OS，Browser，IP等信息）轉步驟D；
D，返回用戶信息，重新記錄Session及cookie信息。
步驟2：無SSO信息，返回重定向信息至用戶端，轉步驟3
步驟3：用戶端收到信息後，跳轉至單點登錄的統一認證界面
步驟4：單點登錄站點接收到頁面請求後，將統一認證界面返回給用戶
步驟5：用戶輸入帳號密碼進行登錄
步驟6：單點服務到數據庫中驗證用戶的信息
步驟7：返回Token信息，將token寫入cookie
若驗證通過，則將時間戳信息+加密後的用戶信息作爲token值寫入cookie。其中，token的時間戳加上超時時間的1/3>=當前時間，則重新生成一個時間戳及Des加解密用的key、iv；從而保證用戶在操作頁面時得以延長超時時間。
步驟8：認證通過後系統又重新定到系統A
在剛重定向至系統A時，由於系統A無Session系統，故仍會執行步驟1的判斷，調用Web服務去驗證token信息（這一步有點重複，不知各位大俠有何更好解決辦法。若通過系統A自身調用SSO接口進行驗證並記錄session或cookie則不存在這個問題），直到在返回後重寫cookie。
步驟9：用戶通過系統A的鏈接進入系統B
步驟10：系統B首先判斷服務端的Session及客戶端的Cookie的Token是否一致。
由於系統B第一次被某個用戶訪問，故無Session信息，只有Cookie信息
步驟11：調用SSO的Web服務將Token信息傳遞給SSO進行驗證
步驟12：校驗Token信息
判斷token是否過期，若過期則跳轉至SSO登錄；未過期則對token進行解密，若不能解密，則token被篡改，重新跳轉SSO登錄（判斷過程跟步驟1一致）
步驟13：返回Token信息,系統B寫Session及Cookie
步驟14:將用戶向系統B請求的頁面返回給用戶