開發SSO單點登陸須要注意的問題

時間 2020-07-14

原文原文鏈接

1、單點登陸系統開發須要注意的問題

1.單點登陸系統須要支持jsonp請求？
單點登陸系統主要是向其餘系統提供用戶身份驗證服務，所以須要提供對外接口，而外部系統經過接口訪問時，必然涉及跨域問題，所以須要單點登陸系統支持jsonp消息轉換，即能正確處理跨域請求。不然，請求接收到的數據解析失敗，chrome debug中提示「Uncaught SyntaxError: Unexpected token <」。

2.超時問題

咱們提供的CAS開源單點登陸SSO組件，它部署節點主要有2個：SSO服務器(部署內容爲一個web應用)、應用系統客戶端(部署內容爲cas客戶端casclient.jar包和相關配置文件)。所以咱們根據SSO機制分析一下什麼狀況下會出現超時。多個應用系統進行SSO集成後，SSO單點登陸過程當中，登陸成功後，應用系統客戶端（如下用瀏覽器客戶端爲例）的session會保存認證後的用戶上下文，SSO服務器會生成一個用戶憑證票據(TGT)並緩存起來，瀏覽器客戶端會保存TGC（瀏覽器cookie中存儲的TGT），TGT是做爲發放SSO訪問服務的票據（ST）的一個憑證票據，發放ST票據後才能正常訪問。而瀏覽器客戶端的session會超時（如通常web應用客戶端能夠設置session的timeout值爲30分鐘或更長），超時後會讓session失效，清空用戶上下文，TGC由於仍然是保存在瀏覽器cookie中，只有關閉瀏覽器纔會清除。SSO服務器端的超時主要是TGT、ST超時，咱們通常會設置超時值TGT爲2小時，ST爲5分鐘。關於ST票據使用，通常在首次SSO訪問服務時攜帶着該票據參數，驗證票據後能正常訪問後，SSO服務器就將此ST銷燬失效了；關於TGT票據的使用，通常是正常訪問時一直保持爲超時時間（2小時），除非作單點退出會銷燬TGT。
基於以上分析，咱們能夠得出結論，SSO的超時主要涉及2個要素：瀏覽器的session超時值、TGT的超時值。通常系統設置TGT的超時值>瀏覽器的session超時值，那麼可能有2種超時狀況：1.TGT超時（瀏覽器session超時值小，天然也超時）；2.瀏覽器session超時，TGT不超時。

第一種「1.TGT超時」，這個處理很簡單，用戶的有效憑證票據都失效了，天然要從新取得有效憑證票據TGT，須要作的就是從新跳轉到登陸頁面從新登陸。

第二種」2.瀏覽器session超時，TGT不超時「，這時SSO服務器的TGT票據，以及瀏覽器客戶端的TGC（cookie中的TGT）仍然有效。瀏覽器客戶端再次SSO訪問時就能夠攜帶TGC（與服務器的TGT對應），向SSO服務器從新發送取得票據ST請求，取得票據ST後，攜帶着有效ST票據能夠正常訪問應用系統了。這個過程是瀏覽器客戶端與SSO服務器的一個通信交互，用戶可能感受不到，不會出現中斷，好像能連續訪問，這是爲了給用戶一個友好的訪問體驗。明白這個機制，就知道其實是SSO機制在後臺起做用了。

3.jsessionid問題
jsessionid是Java客戶端與應用服務器維持session的一個標識，其餘語言客戶端（如PHP）有其餘標識關鍵字，具體是什麼還不太瞭解。jsessionid通常存在於瀏覽器cookie中的（這個通常java客戶端鏈接到應用服務器會自動執行的），通常狀況下不會出如今url中，服務器會從客戶端的cookie中取出來，可是若是瀏覽器禁用了cookie的話，就要重寫url了，顯式的將jsessionid重寫到Url中，方便服務器來經過這個找到session的id。CAS開源單點登陸SSO組件就提供了這個機制。我研究了CAS源碼，基本明白了jsessionid的處理機制。大體原理以下：用戶訪問業務系統，SSO客戶端攔截，重定向到SSO服務器認證時，就將請求路徑uri中寫入";jsessionid=具體的session值"，SSO服務器能夠分辨出這個標識值與其餘客戶端請求不一樣，進行認證處理，返回的響應給客戶端cookie同時也設置了jsessionid的值，之因此在uri和cookie中都設置了jsessionid，是爲了雙重保障能設置jsessionid值。最後單點登陸成功後，返回業務系統訪問地址也帶有jsessionid參數，這個在uri地址中看起來很彆扭。

解決方法，以下：
（1）能夠在登陸頁面地址的請求地址參數中加入參數」&method=POST「(記住這裏要求POST大寫)，這樣就能夠在最後返回的訪問uri中不顯示jsessionid。

4.單點退出時有時子系統未能正常退出

咱們知道正常狀況下，以用戶A單點登陸系統，正常訪問各子系統，而後執行單點退出時，退出成功後通常跳轉回到登陸頁面要求從新登陸，這時各已登陸的子系統session被銷燬，再次以另外一個用戶B登陸進入後，各子系統顯示的應當是用戶B的數據信息。但是有時卻發現有些子系統仍然顯示的是用戶A的數據信息，這屬於偶發現象。如今分析一下產生這種狀況可能的緣由，找出解決辦法。

5.有些請求路徑不須要單點登陸過濾器攔截
業務系統web應用在使用單點登陸組件時，有些請求路徑不須要單點登陸過濾器攔截，好比公共開放的路徑，不須要認證均可以自由訪問的路徑，單點登陸過濾器配置的映射路徑通常以通配符匹配路徑，但要把這些路徑單獨提取出來，讓過濾器不攔截作單點登陸處理，就須要對原有過濾器進行擴展改造，才能實現這個功能。

6.不一樣應用服務實現要求SSO客戶端作適應性改造
不一樣應用服務，對請求的處理方式不一樣，SSO客戶端常規方法不能處理的須要進行適應性改造。咱們先看一下SSO客戶端常規方法處理請求，web應用中定義一個過濾器casfilter，並配置對安全資源攔截，首次登陸系統、或者訪問超時時，安全資源的請求被過濾器casfilter攔截，將安全資源路徑包裝爲service參數，並重定向（http狀態爲302）到SSO服務器地址進行認證，輸入憑證信息(用戶名、密碼等)，SSO服務器通過認證、驗證票據機制處理，認證成功後，登陸經過後繼續訪問安全資源，再次訪問安全資源時，過濾器casfilter攔截，根據用戶上下文判斷用戶已經登陸，就再也不攔截安全資源，直接正常訪問安全資源。而有些應用中使用其餘方式處理請求，按上述常規方法很差處理，下面舉實例來看看解決方案。

6.1.Ajax客戶端
公司有一個應用系統使用Ajax客戶端來處理請求並取得響應，在訪問超時時，Ajax客戶端請求因爲使用異步處理技術（只局部刷新頁面），不能將請求繼續302重定向到SSO服務器從新認證處理，不能繼續訪問安全資源，界面響應處於一直延遲狀態，很不友好。咱們針對此應用進行適應性改造。改造要點以下：

咱們約定應用系統的一個Ajax請求的標記（如ajaxRequestFlag=ajaxRequest），在安全資源ajax調用請求時攜帶此請求參數，還約定一個超時請求的響應狀態值（如555），SSO客戶端的過濾器casfilter的相應類程序對此約定進行了相應的改造。

應用系統的安全資源頁面中引入文件（HttpStatusSSO.js）SSO對Axax請求的http狀態的處理，其中有超時時的狀態處理、判斷是否登陸、驗證票據等的處理，都是經過ajax請求方式來處理的，其中依賴一個驗證票據的資源ticketValidate.jsp。

通過上述改造後，應用系統的安全資源發送攜帶ajax請求標記的請求，在超時請求時，SSO客戶端返回約定響應碼(555)，HttpStatusSSO.js文件判斷處理後轉發給相應的登陸頁面從新認證。單點登陸的訪問也可以正常的實現功能。這樣只擴展了SSO客戶端組件的實現，向下版本兼容，保證了SSO組件的統一完整性。

6.2.多域認證
有時咱們遇到，不一樣子系統的認證明現的數據源可能來自一個用戶數據庫。我公司就是這種狀況，採用Saas模式運營的軟件，認證的用戶來源於不一樣的租戶或者域，基於這樣的狀況，咱們對SSO進行了擴展，主要提供了認證接口，認證明現上，能夠在認證時動態取得租戶對應的數據源，對用戶進行認證處理。

6.3.SSO集中認證登陸頁面須要在業務子系統中定製
SSO集中認證的登陸頁面默認是放在SSO服務器端的，樣式也很很差看，用戶須要把登陸頁面放在業務子系統中自行定製，咱們對SSO進行了擴展，思路也很簡單，主要是將顯示默認登陸頁面的調用，變成了遠程調用業務子系統的頁面地址，這個地址能夠做爲配置參數來配置。

2、關於用戶註冊，須要注意的幾個問題
    1.避免用戶密碼泄露
    （1）在前端對密碼MD5加密後再傳給後臺。
    （2）後端：登陸時用戶信息存入redis緩存時，密碼禁止存儲，更要禁止傳到前端頁面。
    2.用戶註冊信息的校驗
    （1）前端校驗
    （2）後端校驗；前端

3、上線後可能遇到的問題
1.可能遇到Cookie沒法寫入的問題java

緣由：Nginx向Tomcat轉發請求時，丟失了域名。nginx

經過request對象獲取請求的域名時，沒有獲取到真實的請求域名，致使cookie寫入失敗。解決：web

分析：用戶--->Nginx-->Tomcatajax

在nginx作請求轉發時將請求的域名丟失了，致使在tomcat中沒法獲取真實的請求域名。redis

有須要交流的小夥伴能夠點擊這裏加本人QQ：luke
chrome