[[360300]]

隨著公司業務的發展，子系統越來越多，實現SSO單點登錄的需求就愈加迫切。

我們一些子系統中都有使用Redis存儲Session，這最初是為了解決應用集群部署時的Session共享問題，卻也為應用之間共享Session提供了支持，但單靠應用之間共享Session是無法實現單點登錄的。

在單應用中，當用戶登錄系統后，用戶的登錄狀態被存儲在服務端的Session中，并通過響應頭的Cookie字段將SessionId傳遞給瀏覽器存儲，后續請求服務端時，瀏覽器會自動在請求頭加上Cookie，所以才能保持用戶的登錄狀態。

使用Redis共享Session，集群之間可以共享Session的原理與服務重啟后依然保持登錄狀態的原理相同。

在應用重啟后，由于瀏覽器還是攜帶cookie發起請求，如果Session未過期，那么從Redis獲取到的Session就能繼續使用。

由此可見，雖然應用之間可通過Redis共享Session，但要求瀏覽器向每個應用發起請求都能帶上相同Cookie才能實現單點登錄。

然瀏覽器卻不支持不同域名之間Cookie共享，服務端也不能操控客戶端瀏覽器訪問不同域名下的站點都帶上相同的SessionId。要實現單點登錄我們只能另辟蹊徑。

雖然瀏覽器不支持不同域名之間共享Cookie，但同一個主域名的不同子域名應用間可通過配置Cookie為主域名方式實現Cookie共享，前提是所有子系統都共用一個主域名。這種方案可取也不可取，短期而言可取，長期而言不可取。

如果只是實現web應用之間相互跳轉，由用戶在應用a點擊按鈕跳轉到應用b，也可以這樣實現：當用戶在應用a點擊跳轉應用b時，在跳轉鏈接上帶上SessionId，應用b根據SessionId讀取用戶信息再寫入Session。

先不討論安全性如何，這種方式的弊端也很明顯，用戶不能直接在瀏覽器輸入應用B的域名跳轉，而只能通過應用A跳轉到應用B，要返回應用A也只能從應用B點擊按鈕跳轉回應用A。

雖然通過點擊按鈕方式實現應用之間互相跳轉不是一個好的計策，但至少通過在跳轉鏈接上攜帶SessionId共享登錄狀態這個思路是可取的。

根據這個思路，我們是否可以實現不通過點擊按鈕方式也能讓瀏覽器自動帶上SessionId呢?

可以，但要通過重定向實現。

當用戶在系統A登錄后，直接在瀏覽器上修改域名訪問系統B時，系統B檢查到用戶未登錄后將請求重定向到系統A，系統A檢查到請求從系統B重定向過來，并且用戶已經登錄，那么可將SessionId拼接到重定向鏈接上，再重定向回系統B。系統B獲取到系統A的SessionId，然后根據SessionId從Redis查詢用戶信息，再寫入系統B的Session中。如此就能實現自動攜帶SessionId跳轉。

只不過，這種方式要求每個系統都實現一遍這樣的功能，并且每個系統也都要提供登錄功能。

為了簡化實現，以及后續的新系統不再重復實現登錄功能，我們應該考慮將登錄功能抽離為一個獨立的應用，其它系統不再提供登錄功能。

將登錄功能抽離為獨立應用之后，實現SSO單點登錄流程梳理如下：

將SSO抽離為一個獨立的應用，獨立的域名，提供登錄頁面，要求其它應用不再提供登錄頁面，都必須通過SSO登錄。

其它應用在接收到請求時，首先根據session判斷是否已經登錄了，如果未登錄則重定向到SSO登錄頁面，并且在重定向鏈接帶上是哪個應用跳轉過來的，當用戶在SSO登錄成功后重定向回原來的應用。

瀏覽器重定向到SSO登錄頁面時，瀏覽器會存儲SSO的cookie，用戶在SSO登錄成功后，SSO存儲用戶的登錄狀態。SSO生成一個token，重定向回原應用，在重定向鏈接上帶上token。

原應用檢查請求攜帶token，這時需要訪問SSO驗證token并獲取用戶信息，SSO驗證成功后返回用戶信息，原應用將用戶信息存儲到Session中，驗證成功后再重定向到首頁。

如果用戶此時通過在瀏覽器輸入應用B的域名訪問應用B，由于應用B檢查到Session沒有用戶信息(未登錄)，于是重定向到SSO應用。

因為用戶在SSO登錄過了，重定向請求SSO應用時瀏覽器會帶上cookie，所以SSO應用發現用戶已經登錄，于是生成一個token并重定向回應用B。

應用B接收重定向請求，從請求中獲取到token，接著訪問sso應用驗證token并獲取用戶信息，在獲取用戶信息成功后再寫入Session，最后重定向到首頁。

根據梳理的流程，總結每個應用需要實現的功能：

SSO應用：

提供登錄功能，支持從哪個應用重定向過來，登錄成功后就重定向回哪個應用去;

提供根據token獲取當前登錄用戶信息的接口。

其它應用：

未登錄則重定向跳轉到SSO，在跳轉鏈接上帶上登錄成功后重定向調用的接口;

提供給SSO重定向調用的接口，用于接收SSO傳遞的token，根據token從SSO獲取登錄用戶信息，將用戶信息寫入Session，最后重定向到前端首頁。

在前后端分離的系統上實現這一流程并不容易，實際實現比本文描述的步驟還要多。

我們通過封裝SDK的方式，盡可能將繁瑣的步驟封裝起來，讓其它應用對接SSO時僅需要依賴一個jar包，并添加少量的配置。

SDK通過Servlet提供的過濾器攔截所有請求：

1、如果請求是“/checketSsoToken”，則說明是用戶在SSO登錄成功后(瀏覽器重定向)跳轉過來的，并且會攜帶token參數。此時SDK需要請求SSO檢驗token，并將獲取的用戶信息寫入Session中，然后重定向到當前應用的前端首頁。

2、如果不是“/checketSsoToken”，則查看配置，判斷當前請求是否不需要登錄也可放行，如果是則放行，否則判斷Session中是否記錄用戶已經登錄，如果未登錄，則響應重定向，由前端跳轉到SSO登錄。

由于前后端分離，前端通過ajax請求接口，后端判斷未登錄響應重定向無法真正重定向，所以要求前端攔截所有請求的響應，如果響應頭有重定向標志，應從請求頭獲取重定向鏈接，然后讓瀏覽器重定向。

3、如果是退出登錄請求，則先清除應用自身緩存的用戶登錄信息，再重定向到SSO退出登錄。

實際實現的單點登錄流程如下：

1、用戶在瀏覽器中輸入應用A的域名，要跳轉到前端的index.html頁面;(nginx反向代理配置實現)

2、前端在首頁調用一個后端接口，如獲取菜單，觸發校驗登錄(前端實現)，未登錄則拼接重定向鏈接，響應給前端，要求重定向到SSO登錄頁面(SDK封裝實現);

3、用戶在SSO登錄成功后，由SSO重定向調用應用A的“/checketSsoToken”。此url在應用A重定向到SSO登錄時作為參數拼接在URL后面，由后端提供，前端只負責重定向;(SSO應用實現)

4、應用A請求SSO的校驗token接口，并將響應的用戶信息寫入session，重定向回前端首頁。(SDK封裝實現)

需要注意的是，假設SSO設置的session過期時間為一個小時，如果用戶在SSO登錄后跳轉回應用A，一個小時不操作后再跳轉應用B，此時會因為SSO的session已經過期導致無法同步登錄狀態，用戶就得要重新登錄，所以SSO的session過期時間應該根據需要合理設置，不應該設置太短。

最后留下一道思考題：如何同步退出登錄狀態?

當用戶在應用A退出登錄時，只有應用A和SSO知道用戶退出登錄了，但其它應用卻不得而知。

最簡單的方式就是除SSO之后，將其它應用的Session過期時間配置盡可能短。又或者每次打開應用的首頁都先跳轉到SSO，如果已經登錄，自然會重定向回來，這一個步驟對用戶來說是透明的。

 

最后，由于每個應用都用了Shiro實現接口權限校驗，也用了Shiro的注解，所以權限校驗的實現，我們在SDK適配了Shiro的注解，但完全棄用了Shiro。

本文轉載自微信公眾號「Java藝術」，可以通過以下二維碼關注。轉載本文請聯系Java藝術公眾號。