JAVA架構之單點登陸 任務調度 權限管理 性能優化大型項目實戰

單點登陸SSO（Single Sign On）說得簡單點就是在一個多系統共存的環境下，用戶在一處登陸後，就不用在其餘系統中登陸，也就是用戶的一次登陸能獲得其餘全部系統的信任。單點登陸在大型網站裏使用得很是頻繁，例如像阿里巴巴這樣的網站，在網站的背後是成百上千的子系統，用戶一次操做或交易可能涉及到幾十個子系統的協做，若是每一個子系統都須要用戶認證，不只用戶會瘋掉，各子系統也會爲這種重複認證受權的邏輯搞瘋掉。實現單點登陸說到底就是要解決如何產生和存儲那個信任，再就是其餘系統如何驗證這個信任的有效性，所以要點也就如下兩個：

• 存儲信任

• 驗證信任

若是一個系統作到了開頭所講的效果，也就算單點登陸，單點登陸有不一樣的實現方式，本文就羅列我開發中所碰見過的實現方式。

以Cookie做爲憑證媒介 
最簡單的單點登陸實現方式，是使用cookie做爲媒介，存放用戶憑證。 
用戶登陸父應用以後，應用返回一個加密的cookie，當用戶訪問子應用的時候，攜帶上這個cookie，受權應用解密cookie並進行校驗，校驗經過則登陸當前用戶。

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

• Cookie不安全

• 不能跨域實現免登

對於第一個問題，經過加密Cookie能夠保證安全性，固然這是在源代碼不泄露的前提下。若是Cookie的加密算法泄露，***者經過僞造Cookie則能夠僞造特定用戶身份，這是很危險的。 
對於第二個問題，更是硬傷。

經過JSONP實現 
對於跨域問題，可使用JSONP實現。 
用戶在父應用中登陸後，跟Session匹配的Cookie會存到客戶端中，當用戶須要登陸子應用的時候，受權應用訪問父應用提供的JSONP接口，並在請求中帶上父應用域名下的Cookie，父應用接收到請求，驗證用戶的登陸狀態，返回加密的信息，子應用經過解析返回來的加密信息來驗證用戶，若是經過驗證則登陸用戶。

這種方式雖然能解決跨域問題，可是安全性其實跟把信任存儲到Cookie是差很少的。若是一旦加密算法泄露了，***者能夠在本地創建一個實現了登陸接口的假冒父應用，經過綁定Host來把子應用發起的請求指向本地的假冒父應用，並做出迴應。 
由於***者徹底能夠按照加密算法來僞造響應請求，子應用接收到這個響應以後同樣能夠經過驗證，而且登陸特定用戶。

經過頁面重定向的方式 
最後一種介紹的方式，是經過父應用和子應用來回重定向中進行通訊，實現信息的安全傳遞。 
父應用提供一個GET方式的登陸接口，用戶經過子應用重定向鏈接的方式訪問這個接口，若是用戶尚未登陸，則返回一個的登陸頁面，用戶輸入帳號密碼進行登陸。若是用戶已經登陸了，則生成加密的Token，而且重定向到子應用提供的驗證Token的接口，經過解密和校驗以後，子應用登陸當前用戶。

這種方式較前面兩種方式，接解決了上面兩種方法暴露出來的安全性問題和跨域的問題，可是並無前面兩種方式方便。 
安全與方便，原本就是一對矛盾。

使用獨立登陸系統 通常說來，大型應用會把受權的邏輯與用戶信息的相關邏輯獨立成一個應用，稱爲用戶中心。 用戶中心不處理業務邏輯，只是處理用戶信息的管理以及受權給第三方應用。第三方應用須要登陸的時候，則把用戶的登陸請求轉發給用戶中心進行處理，用戶處理完畢返回憑證，第三方應用驗證憑證，經過後就登陸用戶。