聊聊單點登錄(SSO)中的CAS認證
SSO介紹
背景
- 隨著企業的發展，一個大型系統里可能包含 n 多子系統, 用戶在操作不同的系統時，需要多次登錄，很麻煩，我們需要一種全新的登錄方式來實現多系統應用群的登錄，這就是單點登錄。
- web 系統 由單系統發展成多系統組成的應用群，複雜性應該由系統內部承擔，而不是用戶。無論 web 系統內部多麼複雜，對用戶而言，都是一個統一的整體，也就是說，用戶訪問 web 系統的整個應用群與訪問單個系統一樣，登錄/註銷 只要1次就夠了
SSO 定義
- SSO（Single sign-on） 即單點登錄，一種對於許多相互關聯，但是又是各自獨立的軟體系統，提供訪問控制的方法
- SSO（Single sign-on） 是比較流行的企業業務整合的解決方案之一。SSO（Single sign-on） 定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統
以遊樂場的通票為例：
我們只要買一次通票，就可以玩所有遊樂場內的設施，而不需要在過山車或者摩天輪那裡重新買一次票。在這裡，買票就相當於登錄認證，遊樂場就相當於使用一套 SSO 的公司，各種遊樂設施就相當於公司的各個產品。
類比到各個子系統認證，如圖
SSO 三種類型
-
各子系統在同一個站點下
-
各子系統在相同的頂級域名下
同一個站點和相同頂級域下的單點登錄是利用了 Cookie 頂域共享的特性。目前數棧都是只需要在 UIC 的登錄頁面進行一次登錄就可以在各個子應用之間進行跳轉，這種操作源於根據設置 Cookie 中的 domain 為頂級域名。
-
各子系統屬於不同的頂級域
如果屬於不同的域，不同域之間的 Cookie 是不共享的。怎麼辦？接下來就要說一說 CAS (Central Authentication Service) 流程了，這個流程是單點登錄的標準流程
CAS (Central Authentication Service)
CAS 是什麼
Central Authentication Service ——— 中央認證服務，是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的 SSO 解決方案。只是 SSO 解決方案的一種，它的流程其實跟 Cookie-session 模式是一樣的，單點登錄等於說是每個子系統都擁有一套完整的 Cookie-session 模式，再加上一套 Cookie-session 模式的 SSO 系統。
第一次訪問 APP1:
- 用戶訪問 APP1，需要登錄的時候會重定向到 CAS Server
- 在 CAS Server 進行帳號密碼認證，CAS Server 會保存 session，並生成 sessionId 返回給 SSO Client，SSO Client 寫入當前域的 Cookie，同時根據 TGT 簽發1個 ST 傳入 APP1
- APP1 攜帶 ST 向 CAS Server 請求校驗
- CAS Server 校驗成功後，返回 登錄態給 APPI 服務端
- APPI 服務端 將 登陸態寫入 session 並生成 sessionId 返回給 APPI Client
- 之後再做登錄認證，就是同域下的認證了
第一次訪問 APP2:
- 用戶訪問系統 APP2，當跳到 SSO 里準備登錄的時候發現 SSO 已經登錄了，那 SSO 生成一個 ST，攜帶該 ST 傳入 APP2
- APP2 攜帶 ST 向 CAS Server 請求校驗
- CAS Server 校驗成功後，返回 登錄態給 APP2 服務端
- APP2 服務端 將 登陸態寫入 session 並生成 sessionId 返回給 APPI Client
- 在這個流程里，APP2 就不用走登錄流程了
CAS 票據
TGT
CAS Server 創建TGT，存在 CAS Server 的 Session 裡面，根據用戶資訊簽發的
TGC
創建 TGT 的同時，生成 TGC。通過 CAS Server 的 response header 的 set-cookie 欄位設置 TGC，唯一標識用戶身份（sessionId) ST
ST
根據 TGT 簽發的 ST，是 CAS 為用戶簽發的訪問某一 service 的票據
CAS 單點登錄(SSO) & 單點登出(SLO)
單點登錄(SSO)
第一次訪問 APP1:
- 訪問 APP1 服務地址，APP1 請求未通過認證，重定向至 CAS Server 地址。
- 訪問 CAS Server 地址，發送認證請求，帶上 Cookie。
- CAS Server 識別出用戶沒有 Cookie 資訊，沒有登錄，返回 CAS 登陸頁地址。
- 用戶輸入正確的賬戶密碼，CAS Server 用戶認證通過，創建 SSO Session。
- 重定向回 APP1 的服務地址，並在 cookie 中創建了 CASTGC，TGC 中包含了 Ticket（TGT），TGT 就是 SSO Session 的 key。
- 訪問 APP1 的服務地址，並帶上 ST，客戶端拿到 ST 向CAS Server進行認證。
- CAS Server 認證成功，返迴響應資訊給 APPI
- APPI 拿到成功的響應後，設置 Session，並重定向回 APP1 的地址，並設置 Cookie JSESSIONID。
- APPI 發起請求，帶上 Cookie 中的資訊，其中 JSESSIONID 用來確定當前用戶所對應的 session 資訊，發送給客戶端進行校驗。
- 客戶端使用 JSESSIONID 與 Session 中存儲的數據進行校驗。
- 校驗通過，返回正確的內容，展示 APP1
第二次訪問 APP1:
- APPI 發起請求，並帶上 Cookie 中的 JSESSIONID 給 APPI 服務端。
- APPI 服務端 使用 JSESSIONID 與 Session 中存儲的數據進行校驗。
- 校驗通過，返回正確的內容，展示 APP1 。
在 APP1 登陸成功的情況下，第一次訪問 APP2:
- 訪問 APP2 服務地址，APP2 請求未通過認證，重定向至 CAS Server 地址。
- 訪問 CAS Server 地址，發送認證請求，帶上 TGT 資訊。
- CAS Server 通過 TGT 去查找 SSO 的資訊進行認證。
- 認證通過，生成票據 ST 重定向至 APP2 的服務地址。
- APP2 服務 攜帶 ST 向 CAS Server 進行認證。
- CAS Server 認證成功，返回客戶端通過的響應。
- 客戶端拿到成功的響應後，設置 Session，並重定向至 APP2 的地址，並設置 Cookie MOD_AUTH_CAS_S。
- APP2 發起請求，帶上 Cookie 中的 MOD_AUTH_CAS_S ，發送給客戶端進行校驗。
- 客戶端使用 MOD_AUTH_CAS_S 與 Session 中存儲的數據進行校驗。
- 校驗通過，返回正確的內容，展示 APP2。
單點登出(SLO)
- 在 APP1 平台 請求退出登錄後, 先在 query 中 攜帶 service 欄位 重定向 CAS 登出地址
- 用戶攜帶 service query 欄位和 CASTGC 請求到 CAS Server
- CAS Server 根據 CASTGC 找到 TGT的資訊，刪除 TGT 完成 CAS 的註銷
- CAS Server 可以在 TGT 中拿到關聯的所有 ST, 根據 ST 找到對應的應用註冊資訊，調用其中的 logoutUrl，把 ST 包裝到 logoutRequest 發送給 APP1
- APP1 根據 logoutRequest 找到 ST ，查找 Session 中以 ST 為鍵的值刪除，清除登陸狀態
- APP1 登出成功
- APP2 根據 logoutRequest 找到 ST ，查找 Session 中以 ST 為鍵的值刪除，清除登陸狀態
- APP2 登出成功
