根據CAS協議寫的簡單的SSO框架

---

 

前言：

考慮到如今分佈式應用都不可或缺的一個重要部分：單點登陸，決定花點時間去學下。原本想直接上現成的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）

 

 

項目運行：

1. 本地配置虛擬主機（找到hosts文件，加入下面部分）

127.0.0.1     www.sso.com

127.0.0.1     www.app1.com

127.0.0.1     www.app2.com

 

2. 在jetty中分別啓動sso-client、bounter-app一、bounter-app2

 

 

主要功能：

• 單點登陸

實現原理幾乎徹底按照CAS協議，下面是CAS協議的連接：

https://apereo.github.io/cas/4.2.x/images/cas_flow_diagram.png

 

• Token的集中存儲與驗證

原本打算將token保存在sso服務器的session中的，結果發現經過HttpClient進行token驗證時，HttpClient生成的請求

與瀏覽器的請求是不一樣的session，所以，token驗證時沒法獲取原瀏覽器session中的token。最後只能採用redis來集中保存

token，這樣經過HttpClient驗證時就能獲取到瀏覽器保存到redis中的token了。順帶也解決了請求過多時服務器session內存消耗太大的問題。

 

• 單點登出

主要參考之前CAS源碼實現，主要原理大概以下：

1. 1. 每次有新的會話時，在應用app端保存會話id到一個線程安全的容器中
   2. 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等的加密與安全
• 權限控制

 

源碼地址：

https://github.com/13babybear/bounter-sso