單點登錄 SSO 的實現原理與方案詳解
本文轉載自微信公眾號「mikechen的互聯網架構」,作者mikechen。轉載本文請聯系mikechen的互聯網架構公眾號。
為什么需要單點登錄
單點登錄SSO(Single Sign On)說得簡單點就是在一個多系統共存的環境下,用戶在一處登錄后,就不用在其他系統中登錄,也就是用戶的一次登錄能得到其他所有系統的信任。
單點登錄在大型網站里使用得非常頻繁,例如,阿里旗下有淘寶、天貓等網站,還有背后的成百上千的子系統,用戶一次操作或交易可能涉及到幾十個子系統的協作,如果每個子系統都需要用戶認證,不僅用戶會瘋掉,各子系統也會為這種重復認證授權的邏輯搞瘋掉。
所以,單點登錄要解決的就是,用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
單點登錄的來源
1.早期web單系統應用
早期我們開發web應用都是所有的包放在一起打成一個war包放入tomcat容器來運行的,所有的功能,所有的業務,后臺管理,門戶界面,都是由這一個war來支持的,這樣的單應用,也稱之為巨石應用,因為十分不好擴展和拆分。
在巨石應用下,用戶的登錄以及權限就顯得十分簡單,當瀏覽器向服務器發送登錄請求時,驗證通過之后,會將用戶信息存入seesion中,然后服務器會生成一個sessionId放入cookie中,隨后返回給瀏覽器。
大致可以用下圖來表示:
驗證登錄的這個會話就是session,維護了用戶狀態,也就是所謂的HTTP有狀態協議,我們經常可以在瀏覽器中看到JSESSIONID,這個就是用來維持這個關系的key。
2.分布式集群部署
由于網站的訪問量越來也大,單機部署已經是巨大瓶頸,所以才有了后來的分布式集群部署。
例如:如果引入集群的概念,單應用可能重新部署在3臺tomcat以上服務器,使用nginx來實現反向代理。
但是增加新的服務器之后,不同的服務器之間的sessionId是不一樣的,可能在A服務器上已經登錄成功了,能從服務器的session中獲取用戶信息,但是在B服務器上卻查不到session信息,只好退出來繼續登錄,結果A服務器中的session因為超時失效,登錄之后又被強制退出來要求重新登錄。
所以不得不考慮多服務器之間的session數據一致的問題,這就是單點登錄的最早來源。
單點登錄的實現方式
單點登錄的本質就是在多個應用系統中共享登錄狀態,如果用戶的登錄狀態是記錄在 Session 中的,要實現共享登錄狀態,就要先共享 Session。
所以實現單點登錄的關鍵在于,如何讓 Session ID(或 Token)在多個域中共享。
1.同域下的單點登錄
一個企業一般情況下只有一個域名,通過二級域名區分不同的系統。
比如我有個域名:mikechen.cc,同時有兩個業務系統分別為:
- blog.mikechen.cc
- video.mikechen.cc
我們要做單點登錄(SSO),需要一個登錄系統,叫做:sso.mikechen.cc。
我們只要在sso.mikechen.cc登錄,blog.mikechen.cc和video.mikechen.cc也登錄了。
實現方式:其實這里就是利用了 二級域名 寫 一級域名的 Cookie 。
sso.mikechen.cc登錄以后,可以將Cookie的域設置為頂域,即.mikechen.cc,這樣所有子域blog.mikechen.cc和video.mikechen.cc的系統都可以訪問到頂域的Cookie。
此種實現方式比較簡單,但不支持跨主域名,局限性限于一級域名是一樣的。
2.不同域下的單點登錄
同域下的單點登錄是巧用了Cookie頂域的特性,如果是不同域呢,比如:下面三個是不同域的
- mikechen1.cc
- mikechen2.cc
- mikechen3.cc
實現方式:我們可以部署一個SSO認證中心,認證中心就是一個專門負責處理登錄請求。
所有的請求(登錄、退出、獲取用戶信息、當前用戶狀態)都請求sso 系統,sso 系統維護用戶信息。
此種實現方式相對復雜,支持跨域,擴展性好。
基于SSO認證中心的開源項目代表:CAS,其中 CAS是Central Authentication Service,即中央認證服務,下圖是CAS的基本過程:
以上就是基于單點登錄的介紹!