其實就是統一用戶管理平台,如今各種系統數不勝數,這就難免需要用戶名和密碼登錄，但是賬戶越多越容易忘記，而且每次訪問需要登錄還很麻煩，所以單點登錄系統應運而生，這也是我上班的第一個任務-利用公司現有的SSO服務器來配置客戶端開發用戶登錄接口從而和別的公司對接。
起初我還以為是做外包的，認為i很簡單啊，不就是要實現一個用戶登錄驗證之后再來個重定向嗎，於是自己回顧一下之前的最最原始的MVC模式，把基本功能實現之后最后在加上個頁面重定向到目標地址，蠻有“成就感”的給經理看看。 結局就是做的全是無用功，重新來過，應該是基於公司已有的SSO服務器來開發，於是乎，漫長的摸索單點登錄系統的道路開始了。。。
在網上也看了很多的資料，較為粗略的看了下原理：
1. SSO服務器的處理大致流程就是：用戶在A客戶端登錄---->SSO服務器驗證用戶信息---->驗證成功后在SSO服務器端會記下一個TGC(Ticket Granted Cookie)票據而且返回到A客戶端時還帶有一個ticket參數(它是唯一，不可偽造的參數),在A客戶端拿到 Service 和新產生的 Ticket 過后，與 SSO服務器進行身份核實，以確保 Service和Ticket 的合法性---->退出登陸時,會向SSO服務器發送logout請求（清除Session）,之后SSO服務器會廣播到其他應用服務器的logout（清除Session）。
下面拿我做過的案例來說：
例如原始應用的網址是http://localhost:8080/cas-client/，在這個客戶端登錄頁面里form表單包含登錄用戶名和密碼，一開始有如下語句，轉向CAS服務器的單點登錄頁面https://sso.nubb.com/login?service=http://localhost:8080/cas-client/。
SSO服務器完成主體認證后，會使用下面URL進行重定向http://localhost:8080/cas-client/?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。 收到ticket之后，應用程序需要驗證ticket。這是通過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是SSO服務器提供的。
SSO服務器通過校驗路徑獲得了ticket之后，通過內部的數據庫對其進行判斷。如果判斷是有效性，則返回一個NetID給應用程序。 隨后CAS將ticket作廢，並且在客戶端留下一個cookie。
以后其他應用程序就使用這個cookie進行認證（當然通過CAS的客戶端），而不再需要輸入用戶名和密碼。
