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