基礎模式

1. 訪問服務： 客戶端發送請求訪問應用系統提供的服務資源。

2. 定向認證： 客戶端會重定向用戶請求到 服務器。

3. 用戶認證：用戶身份認證。

4. 發放票據： 服務器會產生一個隨機的 Service Ticket 。

5. 驗證票據：服務器驗證票據 Service Ticket 的合法性，驗證通過後，允許客戶端訪問服務。

6. 傳輸用戶信息： 服務器驗證票據通過後，傳輸用戶認證結果信息給客戶端。

代理模式

該模式形式為用戶訪問 App1 ， App1 又依賴於 App2 來獲取一些信息。這種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那麽，為了不影響用戶體驗（過多的重定向導致 User 的 瀏覽器 窗口不停地閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理用戶去訪問其它 Web 應用。

代理的前提是需要 CAS Client 擁有用戶的身份信息 。PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據。憑借 TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket 。

PGTURL 用於表示一個 Proxy 服務，是一個回調鏈接

PGT 相當於代理證

PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關系

獲取 PGT 的過程：

在驗證 ST 時提供了一個額外的 PGTURL 給 CAS Server CAS Client 拿到了 PGT(PGTIOU-85 … )，就可以通過 PGT 向後端 Web 應用進行認證。

TGT、ST、PGT、PT之間關系

1）ST是TGT簽發的。用戶在CAS上認證成功後，CAS生成TGT，用TGT簽發一個ST, 然後把ST的值redirect到客戶端應用。

2）PGT是ST簽發的。用戶憑借ST去訪問Proxy service，Proxy service去CAS驗證ST（同時傳遞PGTURL參數給CAS），如果ST驗證成功，則CAS用ST簽發一個PGT。

3）PT是PGT簽發的。CAS根據傳來的PGT生成一個PT對象

為什麽要PGTURL呢？為什麽不是驗證St時直接返回PGT？

假如hacker獲取了ST，就可以通過ST到Server驗證並獲取PGT，這樣導致所有應用都可以訪問，而不只是ST所對應的服務了。 CAS要求PGTURL必須為Https。

CAS中的PGTIOU(Proxy Granting Ticket I Owe You )作用：

CAS調用PGTURL返回 PGTIOU和PGT

參考

CAS原理

jasig wiki: Proxy CAS Walkthrough

CAS 原理