架構介紹 系統組件 CAS伺服器和客戶端構成了CAS系統體繫結構的兩個物理組件，它們通過各種協議進行通信。 CAS伺服器 CAS伺服器是基於Spring Framework構建的Java servlet，其主要職責是通過簽發和驗證ticket來驗證用戶並授予對啟用CAS認證了的服務（通常稱為CAS客 ...
架構介紹
系統組件
CAS伺服器和客戶端構成了CAS系統體繫結構的兩個物理組件，它們通過各種協議進行通信。
CAS伺服器
CAS伺服器是基於Spring Framework構建的Java servlet，其主要職責是通過簽發和驗證ticket來驗證用戶並授予對啟用CAS認證了的服務（通常稱為CAS客戶端）的訪問許可權。當用戶成功登錄(即認證通過)時，CAS伺服器會向用戶簽發TGT(Ticket Granting Ticket)，並創建SSO會話。應用戶的請求，通過使用TGT作為令牌的瀏覽器重定向，向啟用CAS認證的服務簽發ST(Service Ticket）。ST隨後通過調用介面在CAS伺服器上進行驗證。這些交互作用在CAS協議文檔中有詳細描述。
CAS客戶端
術語“CAS客戶端”在其常見用法中有兩個不同的含義。CAS客戶端是任何啟用CAS認證的應用，可通過支持的協議與CAS伺服器通信。CAS客戶端也是一個軟體包，可以與各種軟體平臺和應用程式集成，以便通過某些身份驗證協議（例如CAS、SAML、OAuth）與CAS伺服器通信。CAS客戶端支持多種軟體平臺和並且已經開發了很多產品。
CAS協議
CAS協議是一種簡單而強大的基於票證(ticket)的協議。完整的協議規範可以查看這裡。
它涉及一個或多個客戶端和一個伺服器。客戶端嵌入在CAS化的(CASified)應用程式中（稱為“CAS服務”），而CAS伺服器則是一個獨立的組件：
關鍵概念：
TGT(Ticket Granting Ticket), 存儲在TGCcookie中，為SSO(Single Sign On， 單點登錄，)會話的Key，代表某個用戶的某個SSO會話。TGC(Ticket Granted Cookie)，以TGT為值的CookieST(Service Ticket，服務票證), 作為GETURL請求參數傳輸，表示由CAS伺服器授予給特定用戶對CAS服務的訪問許可權。
單點登錄：指在多個應用系統中，只需登錄一次，即可在多個應用系統之間共用登錄。
協議版本
3.0.3
當前的CAS協議版本是“3.0.3”。協議規範說明可參考連接 https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol-Specification.html，由Apereo CAS服務實現，作為官方參考實現。在CAS協議“2.0”之上增加了最常見的增強功能。在其他功能中，版本“2.0”和“3.0”之間最引人註目的更新是能夠通過新的/p3/serviceValidate端點返回身份驗證/用戶屬性。
2.0
協議規範說明，可參考連接 https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol-V2-Specification.html
Web流程圖
過程詳述
-
用戶通過瀏覽器訪問被保護的應用(暫且稱之為 應用服務)
GET https://app.example.com/ -
應用服務上的CAS客戶端檢測到用戶需要進行身份認證時，攜應用返回302響應狀態碼，指示瀏覽器重定向到CAS伺服器。
說明：CAS客戶端包含一個
AuthenticationFilter過濾器，該過濾器可以攔截所有的請求，用於判斷用戶是否需要通過Cas Server進行身份認證，如果需要則將跳轉到CAS伺服器登錄頁面，否則則請求會繼續往下執行關鍵響應頭
location: https://cas.example.com/cas/login?service=https%3A%2F%2Fapp.example.com%2F其中，
service指向用戶原訪問地址(註意，是經過URL編碼後的地址) -
瀏覽器根據302響應狀態碼及響應頭
location指示，自動重定向訪問CAS伺服器。GET https://cas.example.com/cas/login?service=https%3A%2F%2Fapp.example.com%2F -
CAS伺服器未檢測到SSO會話，向用戶返回CAS登錄表單頁面。
-
用戶手動輸入正確用戶名，密碼等認證信息後，提交表單
POST https://cas.example.com/cas/login?service=https%3A%2F%2Fapp.example.com%2F -
CAS伺服器接收到用戶名和密碼後，對用戶進行驗證（可使用CAS伺服器預設的驗證，也可以自定義實現驗證方法），如果驗證通過，則創建SSO會話，簽發一個
ST(作為location請求中URL參數傳輸) ， 返回302響應狀態碼，及location請求頭，提示瀏覽器重定向訪問應用服務。關鍵響應頭
Location: https://app.example.com/?ticket=ST-12345678 Set-Cookie: CASTGC=TGT-2345678說明：
Set-Cookie響應頭，提示瀏覽器存儲Cookie--將TGT(Ticket Granted Ticket)存儲為CASTGCCookie值，這是單點登錄的關鍵步驟，因為這樣以後，當前瀏覽器中訪問其它需要CAS認證的應用服務時，將自動攜帶CASTGCCookie重定向訪問CAS伺服器網站，而訪問CAS伺服器時，CAS服務會通過該Cookie值，即TGT來查找對應的SSO會話，如果存在會話，則表示已登錄CAS伺服器，簽發ST， 返回302響應狀態碼，提示瀏覽器重定向訪問應用服務，否則未登錄，返回CAS伺服器登錄頁。註意，
CASTGC也可能被命名為其它類似名稱，比如CASTGC-D，如果有對CAS伺服器進行相關改造的話。 -
瀏覽器根據302響應狀態碼及響應頭
location指示，自動重定向訪問 應用服務。GET https://app.example.com/?ticket=ST-12345678 -
應用服務收到請求後，請求CAS伺服器服務驗證介面，驗證
ST註意：每個
ST只能用一次，且存在有效期，這就是為啥需要二次訪問CAS伺服器進行驗證的原因。GET https://cas.example.com/serviceValidate?service=https%3A%2F%2Fapp.example.com%2F&ticket=ST-12345678 -
CAS伺服器對
ST進行驗證，生成XML響應報文，返回給應用服務，該XML響應報文包含是包含是否驗證成功、被認證的用戶信息、可選屬性。 -
應用服務收到響應報文後，可根據CAS伺服器驗證結果，為當前用戶生成會話，返回302響應狀態碼，
Set-Cookie及location響應頭，提示瀏覽器存儲會話Cookie，並再次通過重定向訪問應用服務。關鍵響應頭：
Set-Cookie: JSESSIONID=ABC1234567 Location: https://app.example.com/註意：上述
Location中的URL，沒有攜帶ticket參數，避免長時間將ST暴露在瀏覽器地址欄中 -
用戶瀏覽器收到響應後，根據提示重定向訪問應用服務
GET https://app.example.com/ Cookie: JSESSIONID=ABC1234567 -
應用服務收到上述請求後，驗證會話Cookie，如果存在對應會話，則表示用戶已登錄，返回用戶請求的資源
-
當用戶第二次訪問相同應用服務時，應用服務會再次驗證會話Cookie，如果存在對應會話，則表示用戶已登錄，返回用戶請求的資源
GET https://app.example.com/resource Cookie: JSESSIONID=ABC1234567
-
用戶通過瀏覽器訪問被保護的另一個應用(暫且稱之為 應用服務2)
GET https://app2.example.com/ -
應用服務2上的CAS客戶端檢測到用戶需要進行身份認證時，攜應用返回302響應狀態碼，指示瀏覽器重定向到CAS伺服器。
關鍵響應頭
location: https://cas.example.com/cas/login?service=https%3A%2F%2Fapp2.example.com%2F -
瀏覽器根據302響應狀態碼及響應頭
location指示，攜CASTGCCookie自動重定向訪問CAS伺服器。GET https://cas.example.com/cas/login?service=https%3A%2F%2Fapp2.example.com%2F Cookie: CASTGC=TGT-2345678 -
CAS伺服器根據
CASTGC檢測是否已存在SSO會話，發現已存在對應會話(即無需CAS登錄)，簽發一個ST， 返回302響應狀態碼，及location請求頭，提示瀏覽器重定向訪問應用服務。關鍵響應頭
Location: https://app2.example.com/?ticket=ST-345678 -
瀏覽器根據302響應狀態碼及響應頭
location指示，自動重定向訪問 應用服務2。GET https://app2.example.com/?ticket=ST-345678
-
應用服務2收到請求後，請求CAS伺服器服務驗證介面，驗證
STGET https://cas.example.com/serviceValidate?service=https%3A%2F%2Fapp2.example.com%2F&ticket=ST-345678 -
CAS伺服器對
ST進行驗證，生成XML響應報文，返回給應用服務，該XML響應報文包含是包含是否驗證成功、被認證的用戶信息、可選屬性。 -
應用服務2收到響應報文後，可根據CAS伺服器驗證結果，為當前用戶生成會話，返回302響應狀態碼，
Set-Cookie及location響應頭，提示瀏覽器存儲會話Cookie，並再次通過重定向訪問應用服務2。關鍵響應頭：
Set-Cookie: MOD_AUTH_CAS_S=XYZ1234567 Location: https://app.example.com/註意：上述
Location中的URL，沒有攜帶ticket參數，避免長時間將ST暴露在瀏覽器地址欄中 -
用戶瀏覽器收到響應後，根據提示重定向訪問應用服務2
GET https://app2.example.com/ Cookie: MOD_AUTH_CAS_S=XYZ1234567 -
應用服務2收到上述請求後，驗證會話Cookie，如果存在對應會話，則表示用戶已登錄，返回用戶請求的資源
CAS單點登出(SLO,Single Logout )
單點登出(註銷登錄)，意味著除了讓CAS伺服器自身SSO會話失效，還將使客戶端應用會話失效，如果CAS客戶端支持註銷協議的話。
只要TGT過期，就會啟動註銷協議。
使用警告！
預設情況下，啟用單點登出。
當CAS會話結束時，它會通知每個應用服務SSO會話不再有效，依賴方需要使自己的會話無效。記住，提交給每個CAS保護應用服務的回調僅是一個通知，沒有別的了。應用程式需要攔截該通知，並通過特定端點手動或更常見的是通過支持SLO的CAS客戶端類庫正確銷毀用戶身份驗證會話。
還要註意，由於SLO是一個全局事件，因此預設情況下，將聯繫具有CAS身份驗證記錄的所有應用程式，如果這些應用程式彼此不同，則可能會對用戶體驗造成負面影響。例如，如果用戶已登錄門戶應用程式和電子郵件應用程式，則通過SLO註銷其中一個應用程式也會破壞另一個的用戶會話，如果應用程式沒有仔細管理其會話和用戶活動，這可能意味著數據丟失。
流程如下：
通過訪問CAS伺服器logout API(如下)，可以註銷CAS登錄。
https://cas.example.com/cas/logout
如果希望註銷登錄後，跳轉到應用服務登錄頁，需要添加service參數，並設置跳轉目標URL，如下：
https://wcas.sit.sf-express.com/cas/logout?service=https%3A%2F%2Fcas.example.com%2Fcas%2Flogin%3F
參考連接
https://apereo.github.io/cas/6.6.x/planning/Architecture.html
https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol.html
https://apereo.github.io/cas/6.6.x/protocol/CAS-Protocol-Specification.html
https://cloud.tencent.com/developer/article/2141095
https://apereo.github.io/cas/6.6.x/installation/Logout-Single-Signout.html
作者：授客
微信/QQ：1033553122
全國軟體測試QQ交流群：7156436
Git地址：https://gitee.com/ishouke
友情提示：限於時間倉促，文中可能存在錯誤，歡迎指正、評論！
作者五行缺錢，如果覺得文章對您有幫助，請掃描下邊的二維碼打賞作者，金額隨意，您的支持將是我繼續創作的源動力，打賞後如有任何疑問，請聯繫我!!!
微信打賞
支付寶打賞 全國軟體測試交流QQ群
