前言：
考慮到現在分布式應用都不可或缺的一個重要部分：單點登錄，決定花點時間去學下。本來想直接上現成的CAS框架的，初步的了解了一下后，覺得這個太龐大了，而且不好定制，要完全深度用起來也沒那么簡單（雖然可能上手容易）。於是腦袋一熱，決定自己根據CAS協議自己實現一個（雖然不是很喜歡CAS,但CAS協議還是完全的SSO的標准），開始后前后各種被打斷，工作啦，加班啦，花時間解決自己的終身大事啦，拖拖拉拉到現在終於初步得已實現。但是現在還僅僅是實現，尚有很多待優化的部分，由於個人工作還是比較忙的，所以就不去完善了。代碼我會放到github，有興趣的完全可以基於它去提交你們的更新，當然，也可以直接留言跟我說需要改進的地方。廢話就到這里，下面直接進入主題。
技術棧：
- SpringMVC
- Filter
- Listener
- Cookie/Session
- Redis/Spring Data Redis
- HttpClient
架構&流程：
a：攔截請求
b：跳轉到SSO-Server進行登錄
c：返回token
d：驗證token
e：驗證成功，寫入cookie
f：返回資源頁面
項目組件介紹：
- bounter-sso（項目根目錄）
- sso-server（sso服務器，主要負責登錄、token驗證、刷新token時間、登出）
- sso-client（sso客戶端，主要負責攔截請求，跟sso服務器通信）
- bounter-app1（虛擬的應用1）
- bounter-app2（虛擬的應用2）
項目運行：
- 本地配置虛擬主機（找到hosts文件，加入下面部分）
- 在jetty中分別啟動sso-client、bounter-app1、bounter-app2
主要功能：
- 單點登錄
實現原理幾乎完全按照CAS協議，下面是CAS協議的鏈接：
- Token的集中存儲與驗證
本來打算將token保存在sso服務器的session中的，結果發現通過HttpClient進行token驗證時，HttpClient生成的請求
與瀏覽器的請求是不同的session，因此，token驗證時無法獲取原瀏覽器session中的token。最后只能采用redis來集中保存
token，這樣通過HttpClient驗證時就能獲取到瀏覽器保存到redis中的token了。順帶也解決了請求過多時服務器session內存消耗太大的問題。
- 單點登出
主要參考以前CAS源碼實現，主要原理大概如下：
-
- 每次有新的會話時，在應用app端保存會話id到一個線程安全的容器中
- sso服務器把會話對應的app地址保存到該會話對應的token下，在redis中保存結構如下：
其中，url包含了不同應用app的sessionid
3. 應用發出注銷請求時，先注銷掉本應用自己的session，然后訪問sso服務器，清除該會話在服務器對應的token，然后注銷服務器session，最后觸發服務器session注銷的listener
4. 在處理注銷的listener中通過httpclient通知該token對應的所有的應用app根據sessionid參數進行注銷，同時移除app端會話容器中保存的會話id
- token失效時間的刷新
每次建立新的會話時在sso服務器重設redis失效時間，如下：
//刷新key為sso-token的失效時間
stringRedisTemplate.expire(ssoToken,EXPIRE_TIME,TimeUnit.MINUTES);
后期改進點：
- 可以把cookie/session改成JWT(Json Web Token)從而實現完全的無狀態化和移動端的支持
- token，jsessionid等的加密與安全
- 權限控制
源碼地址：