單點登入原理

單點登入sso（single sign on）說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。

單點登入在大型**裡使用得非常頻繁，例如，阿里旗下有**、天貓、支付寶等**，還有背後的成百上千的子系統，使用者一次操作或交易可能涉及到幾十個子系統的協作，如果每個子系統都需要使用者認證，不僅使用者會瘋掉，各子系統也會為這種重複認證授權的邏輯搞瘋掉。

所以，單點登入要解決的就是，使用者只需要登入一次就可以訪問所有相互信任的應用系統。

早期我們開發web應用都是所有的包放在一起打成乙個war包放入tomcat容器來執行的,所有的功能,所有的業務,後台管理,門戶介面,都是由這乙個war來支援的,這樣的單應用,也稱之為巨石應用,因為十分不好擴充套件和拆分。

在巨石應用下,使用者的登入以及許可權就顯得十分簡單,使用者登入成功後,把相關資訊放入會話中,http維護這個會話,再每次使用者請求伺服器的時候來驗證這個會話即可,大致可以用下圖來表示:

驗證登入的這個會話就是session,維護了使用者狀態,也就是所謂的http有狀態協議,我們經常可以在瀏覽器中看到jsessionid,這個就是用來維持這個關係的key。

由於**的訪問量越來也大，單機部署已經是巨大瓶頸，所以才有了後來的分布式集群部署。例如：如果引入集群的概念,1單應用可能重新部署在3臺tomcat以上伺服器,使用nginx來實現反向**, 此時,這個session就無法在這3臺tomcat上共享,使用者資訊會丟失，所以不得不考慮多伺服器之間的session同步問題，這就是單點登入的**。

單點登入的實現方案，一般就包含：cookies，session同步，分布式session方式，目前的大型**都是採用分布式session的方式。我先從cookie的實現談起，你就能很清楚的知道為什麼需要分布式session方式實現單點登入。

最簡單的單點登入實現方式，是使用cookie作為媒介，存放使用者憑證。使用者登入父應用之後，應用返回乙個加密的cookie，當使用者訪問子應用的時候，攜帶上這個cookie，授權應用解密cookie並進行校驗，校驗通過則登入當前使用者。

不難發現以上方式把信任儲存在客戶端的cookie中，這種方式很容易令人質疑：

對於第乙個問題，通過加密cookie可以保證安全性，當然這是在源**不洩露的前提下。如果cookie的加密演算法洩露，攻擊者通過偽造cookie則可以偽造特定使用者身份，這是很危險的。對於第二個問題，不能跨域實現免登更是硬傷。所以，才有了以下的分布式session方案。

例如阿里有很多系統分割為多個子系統，獨立部署後，不可避免的會遇到會話管理的問題，類似這樣的電商**一般採用分布式session實現。

再進一步可以根據分布式session，建立完善的單點登入或賬戶管理系統。

流程執行：

（1）使用者第一次登入時，將會話資訊（使用者id和使用者資訊），比如以使用者id為key，寫入分布式session；

（2）使用者再次登入時，獲取分布式session，是否有會話資訊，如果沒有則調到登入頁；

（3）一般採用cache中介軟體實現，建議使用redis，因此它有持久化功能，方便分布式session宕機後，可以從持久化儲存中載入會話資訊；

（4）存入會話時，可以設定會話保持的時間，比如15分鐘，超過後自動超時；

結合cache中介軟體，實現的分布式session，可以很好的模擬session會話。

以上分別從單點登入的原理、**、實現機制來完整的解讀單點登入。

實現單點登入說到底就是要解決如何產生和儲存那個信任，再就是其他系統如何驗證這個信任的有效性，因此要點也就以下兩個：

儲存信任建議可以採用分布式檔案儲存redis來實現。

單點登入原理

單點登入原理

單點登入原理

單點登入原理

相關推薦