CAS單點登陸原理解析

CAS單點登陸原理解析

    SSO英文全稱Single Sign On，單點登陸。SSO是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。CAS是一種基於http協議的B/S應用系統單點登陸實現方案，認識CAS以前首先要熟悉http協議、Session與Cookie等Web開發基本知識。

1.http協議

    HTTP是一個客戶端和服務器端請求和應答的標準，咱們全後端開發對接的Rest接口就是基於http協議。http協議包含http請求消息（HttpRequest）和http應答消息（HttpResponse）兩部分。參考內容：https://www.cnblogs.com/rayray/p/3729533.html

• 理解http協議是無狀態協議的含義
• 熟記常見的http協議狀態碼，其中302等與cas相關
• 熟記常見的http請求頭，其中Cookie等與cas相關
• 熟記常見的http應答頭，其中Set-Cookie、Location等與cas相關

2.Session與Cookie會話機制

    http協議自己是無狀態的，但有時候咱們須要http請求保持狀態，咱們引入Session與Cookie。
Session用在服務端，用於存儲當前全部客戶端須要保持的狀態值，併爲每個客戶端生成一個惟一編碼，而後經過http響應頭Set-Cookie將這個編碼發送給客戶端。

    Cookie用在客戶端，用於記錄後端發來過的惟一編碼，該編碼與服務端上的對應的狀態值對應，在下一次請求的時候經過http請求頭Cookie帶上這個編碼，服務端就能根據這個編碼獲取該客戶端以前記錄的全部狀態值。

 

3.普通登陸

    登陸成功後，在Session中寫入登陸用戶的信息，退出時清空Session中的用戶信息。能夠經過filter實現。

4.CAS單點登陸| 兩次前端跳轉、一次後端驗證

4.1首次訪問（訪問第一個應用系統App1）

    CAS首次登陸會通過兩次前端跳轉、一次後端驗證。在應用系統端須要集成CasClient的jar包，把其中的filter配置到站點web.xml中，用於攔截請求、判斷登陸、發起跳轉或發起驗證等。在SSO服務器上部署CasServer的war包，須要配置用戶數據源，根據需求修改登陸頁面。

   第一次前端跳轉：客戶端訪問應用系統，應用系統判斷Session發現未登陸，返回302跳轉到sso登陸頁面，並傳遞service參數給sso，該service參數有兩個做用：

1. service通常傳遞應用系統url地址，用於sso認證經過後回跳到應用系統；
2. service參數同時會被cas服務端的做爲cas客戶端的惟一標記記錄下來，用於後期匹配相應的認證憑據；

   第二次前端跳轉：瀏覽器顯示登陸頁面，用戶輸入帳號密碼登陸成功後，sso會返回302跳轉回到原來請求的應用系統頁面，並攜帶ticket參數，做爲認證票據，同時經過Set-Cookie向瀏覽器記錄TGT，（TGT的做用將在下一個應用系統須要登陸的時候體現出做用，是避免重複登陸的關鍵）

    一次後臺驗證：應用系統接收到帶有ticket的請求後，從後臺直接向sso服務器發起一個http請求，將service和ticket做爲參數，用於驗證ticket的有效性；若是ticket有效，sso服務器將返回該ticket對應的登陸用戶名。

4.2再次訪問（訪問第二個應用系統app2）

    當用戶已經登陸過一個應用系統之後，在同一個瀏覽器上訪問第二個應用系統，根據單點登陸的要求此時不該該再登陸，而是直接進入第二個系統。可是實際上仍是須要通過兩次前端跳轉、一次後端驗證，只不過此時的兩次跳轉是連續的，中間不會再出現登錄頁面，用戶感覺不到。判斷的依據就是前面第4步經過Set-Cookie保存到客戶端的TGT（Ticket Granted Cookie ）。

    相比首次訪問，少了以前的第3步(不須要再出現登陸頁面)，由於此時在第二步跳轉時，攜帶了以前保存的TGT，cas服務端經過TGT能夠得知用戶信息，所以直接生成ticket返回給應用系統。因此此時是兩次連續的302跳轉，用戶看到的效果就是直接進入第二個應用系統了。

5. 案例講解

5.1 循環跳轉異常案例

    異常現象說明：某項目先後端分開部署出現這樣一個現象，前端映射域名爲http://xxx.abc.cn/gl，後端映射域名爲http://xxx.abc.cn/gl/rest，單獨訪問後端登陸沒有任何問題，可是訪問前端登錄後界面出現反覆跳轉不停刷新的問題。

    異常排查：循環跳轉原理，SSO登陸後返回應用系統，應用系統後臺認證獲取用戶信息存入Session，因爲某種緣由形成Session信息丟失，致使應用系統認爲還未登陸，因而又跳轉SSO，此時SSO已經登陸不會再出登錄頁面，直接生成ticket返回應用系統，應用系統Session再次丟失，進入反覆跳轉認證的死循環，前端界面表現爲不停的刷新。

    所以關鍵問題在於分析Session信息丟失的緣由，通常來說有兩種可能：1是系統自己邏輯問題把以前寫入Session的登陸信息清空了，2是兩個站點的cookie做用域相同而相互覆蓋，從而致使後臺Session被重置。

    分析發現該項目屬於第二種狀況，先後端cookie都在http://xxx.abc.cn/域下面，解決辦法修改cookie做用域或者修改cookie中Jsessionid的命名，防止相互覆蓋。