CAS 原理

基礎模式

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