Cas的全稱是Centeral Authentication Service，是對單點登錄SSO（Single Sign On）的一種實現。其由Cas Server和Cas Client兩部分組成，Cas Server是核心，而Cas Client通常就對應於我們的應用。一個Cas Server可以對應於多個Cas Client。它允許我們在一個Client進行登錄以後無需再讓用戶輸入用戶名和密碼進行認證即可訪問其它Client應用。
Cas Server的主要作用是通過發行和驗證Ticket（票）來對用戶進行認證和授權訪問Client應用，用於認證的憑證信息都是由Cas Server管理的。而Cas Client就對應於我們真正的應用，當然其中會使用到Cas相關的類，用於與Cas Server進行交互。官網有兩張圖最能體現Cas的架構和原理。
如你所見，在第一次訪問應用app1時，由於沒有登錄會直接跳轉到Cas Server去進行登錄認證，此時將附帶查詢參數service在Cas Server的登錄地址上，表示登錄成功後將要跳轉的地址。此時Cas Server檢查到沒有之前成功登錄後生成的SSO Session信息，那麼就會引導用戶到登錄頁面進行登錄。用戶輸入信息提交登錄請求，Cas Server認證成功後將生成對應的SSO Session，以及名爲CASTGC的cookie，該cookie包含用來確定用戶SSO Session的Ticket Granting Ticket（TGT）。之後會生成一個Service Ticket（ST），並將以ticket作爲查詢參數名，以該ST作爲查詢參數值跳轉到登錄時service對應的URL。如：
http(s)://domain/app1?ticket=ST-2-59fS6KxvmykibRXyoPJE
之後的操作對用戶來說都是透明的，即不可見的。app1之後將以service和ticket作爲查詢參數請求Cas Server對service進行驗證，驗證通過後Cas Server將返回當前用戶的用戶名等信息。app1就會給當前用戶生成其自身的Session，以後該用戶以該Session都可以成功的訪問app1，而不需要再去請求Cas Server進行認證。當該用戶再去訪問app2的時候，由於其在app2上沒有對應的Session信息，將會跳轉到Cas Server的登錄地址，Cas Server此時發現其包含名爲CASTGC的cookie，將獲取其中包含的TGT來獲取對應的SSO Session，然後會將用戶重定向到app2對應的地址，以Service Ticket作爲查詢參數。之後app2會向Cas Server發送請求校驗該Service Ticket，校驗成功後app2將建立該用戶對應的Session信息，以後該用戶以該Session就可以自由的訪問app2了。
綜上所述，我們知道，各系統之間的單點登錄是通過Cas Server生成的SSO Session來交流的，而用戶與實際的應用系統進行交互的時候，各應用系統將建立單獨的Session，以滿足用戶與該系統的交互需求。
（注：本文是基於cas 3.5.2所寫）
（注：原創文章，轉載請註明出處。原文地址：http://haohaoxuexi.iteye.com/blog/2128728）
