CAS系統體系結構由兩個物理組件組成，CAS服務端和CAS客戶端，它們通過各種協議進行通信，CAS服務端負責完成對用戶的認證工作 , 需要獨立部署。CAS客戶端負責處理受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS服務端進行認證
cas 的登陸流程如圖
Ticket Granting Ticket(TGT) ：
TGT是CAS爲用戶簽發的登錄票據，擁有了TGT，用戶就可以證明自己在CAS成功登錄過。TGT封裝了Cookie值以及此Cookie值對應的用戶信息。用戶在CAS認證成功後，CAS生成cookie（叫TGC），寫入瀏覽器，同時生成一個TGT對象，放入自己的緩存，TGT對象的ID就是cookie的值。當HTTP再次請求到來時，如果傳過來的有CAS生成的cookie，則CAS以此cookie值爲key查詢緩存中有無TGT，如果有的話，則說明用戶之前登錄過，如果沒有，則用戶需要重新登錄
Ticket-granting cookie(TGC)：
存放用戶身份認證憑證的cookie，在瀏覽器和CAS Server間通訊時使用，並且只能基於安全通道傳輸（Https），是CASServer用來明確用戶身份的憑證。
Service ticket(ST) ：
服務票據，服務的惟一標識碼 , 由 CASServer 發出（ Http 傳送），用戶訪問Service時，service發現用戶沒有ST，則要求用戶去CAS獲取ST.用戶向CAS發出獲取ST的請求，CAS發現用戶有TGT，則簽發一個ST，返回給用戶。用戶拿着ST去訪問service，service拿ST去CAS驗證，驗證通過後，允許用戶訪問資源
CAS登錄流程![]()
![]()
步驟 1：用戶請求cas客戶端（Protected App）受保護的資源，第一次訪問，cas客戶端發現它沒有認證，就把請求重定向到cas服務端進行認證，但是在重定向的時候會把訪問的受保護資源地址作爲參數拼接到後面如下圖抓包
步驟2：瀏覽器請求重定向地址（cas服務端的登陸地址），由於還沒有登陸過，cas server 彈出登陸界面讓用戶進行登陸,用戶輸入用戶名密碼，提交 CAS認證成功後，CAS生成cookie（叫TGC），寫入瀏覽器，同時生成一個TGT對象，放入自己的緩存，TGT對象的ID就是cookie的值。之後CAS Server 將瀏覽器請求重定向到剛纔作爲參數傳入的受保護資源地址（cas client），並將ST作爲參數拼接到後面
步驟3： 瀏覽器請求重定向地址(cas client) ,cas client 拿到ST參數後去 cas server 端進行ST的有效性驗證，如果驗證成功，cas server 會返回cas client 有關用戶信息（可以在server端定義後面在講）,登陸成功後，CAS客戶端應該在會話中保存登陸狀態信息，並設置會話cookie並將瀏覽器轉發迴應用程序
步驟4：瀏覽器再次請求cas client ,並且在請求頭中帶有剛纔設置的cookie，cas client 驗證cookie ，驗證通過，返回資源
步驟5： 當瀏覽器再次請求相同的cas client 資源的時候，在請求時瀏覽器就會帶着上次保存的cookie ,cas client 驗證cookie,如果沒過時則返回資源，如果過時則重複以上登陸步驟
步驟6：當瀏覽器請求不同的cas client 資源的時候，會帶着之前的cookie，cas client 驗證不通過，重定向到cas server ,cas server驗證發現在server 端已經登陸過，就把請求重定向到app2,app2 向 server 驗證ST，然後重複 步驟3和步驟4
步驟7：登出
在cas client 和cas server 相互驗證成功後就會建立連接，瀏覽器或CAS客戶端向“登出URL”發起GET請求，CAS服務器銷燬TGT和ST，並向所有已登陸的業務系統發出登出通知請求
結束
