CAS(Central Authentication Service) 是 Yale 大學發起的一個開源項目，據統計，大概每 10
個採用開源構建 Web SSO 的 Java 項目，就有 8 個使用 CAS 。對這些統計，我雖然不以為然，但有一點可以肯定的是， CAS
是我認為最簡單實效，而且足夠安全的 SSO 選擇。
本節主要分析 CAS 的安全性，以及為什麼 CAS
被這樣設計，帶著少許密碼學的基礎知識，我希望有助於讀者對 CAS 的協議有更深層次的理解。 從結構體系看， CAS 包含兩部分： l
CAS Server CAS Server 負責完成對使用者的認證工作， CAS Server
需要獨立部署，有不止一種 CAS Server 的實現， Yale CAS Server 和 ESUP CAS Server 都是很不錯的選擇。 CAS Server 會處理使用者名稱 / 密碼等憑證 (Credentials)
，它可能會到資料庫檢索一條使用者帳號資訊，也可能在 XML 檔案中檢索使用者密碼，對這種方式， CAS 均提供一種靈活但同一的介面 /
實現分離的方式， CAS 究竟是用何種認證方式，跟 CAS 協議是分離的，也就是，這個認證的實現細節可以自己定製和擴充。 l
CAS Client CAS Client 負責部署在用戶端（注意，我是指 Web 應用程式），原則上，
CAS Client 的部署意味著，當有對本地 Web 應用程式的受保護資源的訪問請求，並且需要對請求方進行身份認證， Web
應用不再接受任何的使用者名稱密碼等類似的 Credentials ，而是重新導向到 CAS Server 進行認證。 目前， CAS Client 支援（某些在完善中）非常多的用戶端，包括 Java
、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript
等用戶端，幾乎可以這樣說， CAS 協議能夠適合任何語言編寫的用戶端應用。 剖析協議就像剖析設計模式，有些時候，協議讓人摸不著頭腦。 CAS
的代理模式要相對複雜一些，它引入了一些新的概念，我希望能夠在這裡描述一下其原理，有助於讀者在配置和調試 CAS SSO 有更清晰的思路。
如果沒記錯， CAS 協議應該是由 Drew Mazurek
負責可開發的，從 CAS v1
到現在的 CAS v3 ，整個協議的基礎思想都是基於 Kerberos 的票據方式。 CAS v1
非常原始，傳送一個使用者名稱居然是 ”yes/ndavid.turing” 的方式，
CAS v2 開始使用了 XML 規範，大大增強了可擴充性， CAS v3 開始使用 AOP 技術，讓 Spring 愛好者可以輕鬆配置
CAS Server 到現有的應用環境中。 CAS 是通過 TGT(Ticket Granting Ticket) 來擷取
ST(Service Ticket) ，通過 ST 來訪問服務，而 CAS 也有對應 TGT ， ST 的實體，而且他們在保護 TGT
的方法上雖然有所區別，但是，最終都可以實現這樣一個目的——免去多次登入的麻煩。
下面，我們看看 CAS 的基本協議架構： 基礎協議
CAS
基礎模式
是一個最基礎的 CAS 協議， CAS Client 以 Filter 方式保護 Web
應用的受保護資源，過濾從用戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 要求中是否包請求 Service
Ticket( 中的 Ticket) ，如果沒有，則說明該使用者是沒有經過認證的，於是， CAS Client 會重新導向使用者請求到 CAS
Server （ Step 2 ）。 Step 3 是使用者認證過程，如果使用者提供了正確的 Credentials ， CAS Server
會產生一個隨機的 Service Ticket ，然後，緩衝該 Ticket ，並且重新導向使用者到 CAS Client （附帶剛才產生的
Service Ticket ）， Service Ticket 是不可以偽造的，最後， Step 5 和 Step6 是 CAS Client
和 CAS Server 之間完成了一個對使用者的身份核實，用 Ticket 查到 Username ，因為 Ticket 是 CAS
Server 產生的，因此，所以 CAS Server 的判斷是毋庸置疑的。
該協議完成了一個很簡單的任務，就是 User(david.turing) 開啟 IE
，直接存取 helloservice 應用，它被立即重新導向到 CAS Server 進行認證， User 可能感覺到瀏覽器在
helloservcie 和 casserver 之間重新導向，但 User 是看不到， CAS Client 和 CAS Server 相互間的
Service Ticket 核實 (Validation) 過程。當 CAS Server 告知 CAS Client 使用者 Service
Ticket 對應確鑿身份， CAS Client 才會對當前 Request 的使用者進行服務。 CAS 如何? SSO
當我們的 Web 時代還處於初級階段的時候， SSO 是通過共用 cookies
來實現，比如，下面三個網域名稱要做 SSO ： http://www.blogjava.net http://www.matrix.org.cn http://www.csdn.net 如果通過 CAS 來整合這三個應用，那麼，這三個網域名稱都要做一些網域名稱映射， http://blogjava.cas.org http://matrix.cas.org http://csdn.cas.org 因為是同一個域，所以每個網站都能夠共用基於 cas.org 的 cookies
。這種方法原始，不靈活而且有不少安全隱患，已經被拋棄了。 CAS 可以很簡單的實現跨域的 SSO ，因為，單點被控制在 CAS
Server ，使用者最有價值的 TGC-Cookie 只是跟 CAS Server 相關， CAS Server 就只有一個，因此，解決了
cookies 不能跨域的問題。 回到 CAS 的基礎協議圖，當 Step3 完成之後， CAS Server
會向 User 發送一個 Ticket granting cookie (TGC) 給 User 的瀏覽器，這個 Cookie 就類似
Kerberos 的 TGT ，下次當使用者被 Helloservice2 重新導向到 CAS Server 的時候， CAS Server 會主動
Get 到這個 TGC cookie ，然後做下面的事情： 1，
如果
User 的持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果。 2，
如果 TGC
失效，那麼使用者還是要重新認證 ( 走基礎協議圖的 Step3) 。
CAS 的代理模式 模式 1 已經能夠滿足大部分簡單的 SSO
應用，現在，我們探討一種更複雜的情況，即使用者訪問 helloservice ， helloservice 又依賴於 helloservice2
來擷取一些資訊，如同：
User à
helloservice à
helloservice2 這種情況下，假設 helloservice2 也是需要對 User
進行身分識別驗證才能訪問，那麼，為了不影響使用者體驗（過多的重新導向導致 User 的 IE 視窗不停地 閃動 ) ， CAS 引入了一種 Proxy
認證機制，即 CAS Client 可以代理使用者去訪問其它 Web 應用程式。 代理的前提是需要 CAS Client 擁有使用者的身份資訊 ( 類似憑據 ) 。
與其說之前我們提到的 TGC 是使用者持有對自己身份資訊的一種憑據，則這裡的 PGT 就是 CAS Client
端持有的對使用者身份資訊的一種憑據。憑藉 TGC ， User 可以免去輸入密碼以擷取訪問其它服務的 Service Ticket
，所以，這裡，憑藉 PGT ， Web 應用程式可以代理使用者去實現後端的認證，而無需前端使用者的參與。 如下面的 CAS Proxy 圖所示， CAS Client
在基礎協議之上，提供了一個額外的 PGT URL 給 CAS Server, 於是， CAS Server 可以通過 PGT URL 提供一個
PGT 給 CAS Client 。
初學者可能會對的 PGT
URL 感到迷惑，或者會問，為什麼要這麼麻煩，要通過一個額外的 URL( 而且是 SSL 的入口 ) 去傳遞 PGT ？如果直接在 Step 6
返回，則連用來做對應關係的 PGTIOU 都可以省掉。 PGTIOU 設計是從安全性考慮的，非常必要， CAS
協議安全性問題我會在後面一節介紹。 於是， CAS Client 拿到了 PGT( PGTIOU-85…..ti2td
) ，這個
PGT 跟 TGC 同樣地關鍵， CAS Client 可以通過 PGT 向後端 Web 應用程式進行認證。如所示， Proxy
認證與普通的認證其實差別不大， Step1, 2 與基礎模式的 Step 1,2 幾乎一樣，唯一不同的是， Proxy 模式用的是 PGT
而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。 最終的結果是， helloservice2 明白 helloservice
所代理的客戶是 David. Turing 同學，同時，根據本地策略， helloservice2 有義務為
PGTURL=http://helloservice/proxy 服務 (PGTURL 用於表示一個 Proxy 服務 ) ，於是它傳遞資料給
helloservice 。這樣， helloservice 便完成一個代理者的角色，協助 User 返回他想要的資料。
代理認證模式非常有用，它也是 CAS 協議 v2
的一個最大的變化，這種模式非常適合在複雜的業務領域中應用 SSO 。因為，以前我們實施 SSO 的時候，都是假定以 IE User 為 SSO
的訪問者，忽視了業務系統作為 SSO 的訪問者角色。
