1. CAS 簡介
1.1. What is CAS ？
CAS （ Central Authentication Service ） 是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的單點登錄解決方法（屬於 Web SSO ）。
CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。
1.2. 主要特性
1、 開源的、多協議的 SSO 解決方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
2、 支持多種認證機制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；
3、 安全策略：使用票據（ Ticket ）來實現支持的認證協議；
4、 支持授權：可以決定哪些服務可以請求和驗證服務票據（ Service Ticket ）；
5、 提供高可用性：通過把認證過的狀態數據存儲在 TicketRegistry 組件中，這些組件有很多支持分布式環境的實現， 如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；
6、 支持多種客戶端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。
2. SSO 單點登錄原理
本文內容主要針對 Web SSO 。
2.1. 什么是SSO
單點登錄（ Single Sign-On , 簡稱 SSO ）是目前比較流行的服務於企業業務整合的解決方案之一， SSO 使得在多個應用系統中，用戶只需要 **登錄一次 **就可以訪問所有相互信任的應用系統。
2.2. SSO 原理
2.2.1. SSO 體系中的角色
一般 SSO 體系主要角色有三種：
1、 User （多個）
2、 Web 應用（多個）
3、 SSO 認證中心（ **1 個 **）
2.2.2. SSO 實現模式的原則
SSO 實現模式一般包括以下三個原則：
1、 所有的認證登錄都在 SSO 認證中心進行；
2、 SSO 認證中心通過一些方法來告訴 Web 應用當前訪問用戶究竟是不是已通過認證的用戶；
3、 SSO 認證中心和所有的 Web 應用建立一種信任關系，也就是說 web 應用必須信任認證中心。（單點信任）
2.2.3. SSO 主要實現方式
SSO 的主要實現方式有：
1、 共享 cookies
基 於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞 cookies 機制，實現兩個域名之間系統令牌 傳遞問題；另外，關於跨域問題，雖然 cookies本身不跨域，但可以利用它實現跨域的 SSO 。如：代理、暴露 SSO 令牌值等。
缺點：不靈活而且有不少安全隱患，已經被拋棄。
2、 Broker-based( 基於經紀人 )
這 種技術的特點就是，有一個集中的認證和用戶帳號管理的服務器。經紀人給被用於進一步請求的電子身份存取。中央數據庫的使用減少了管理的代價，並為認證提供 一個公共和獨立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （憑證庫思想 ) 等。 Kerberos是由麻省理工大學發明的安全認證服務，已經被 UNIX 和 Windows 作為 默認的安全認證服務集成進操作系統。
3、 Agent-based （基於代理人）
在 這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將 認證的負擔從用戶移開。代理人被放在服務器上面，在服務器的認證系統和客戶端認證方法之間充當一個 " 翻譯 "。例如 SSH 等。
4、 Token-based
例如 SecureID,WebID ，現在被廣泛使用的口令認證，比如 FTP 、郵件服務器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。
5、 基於網關
6、 基於 SAML
SAML(Security Assertion Markup Language ，安全斷言標記語言）的出現大大簡化了 SSO ，並被 OASIS 批准為 **SSO 的執行標准 **。開源組織 OpenSAML 實現了 SAML 規范。
3. CAS 的基本原理
3.1. 結構體系
從結構體系看， CAS 包括兩部分： CAS Server 和 CAS Client 。
3.1.1. CAS Server
CAS Server 負責完成對用戶的認證工作 , 需要獨立部署 , CAS Server 會處理用戶名 / 密碼等憑證(Credentials) 。
3.1.2. CAS Client
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。（原則上，客戶端應用不再接受任何的用戶名密碼等 Credentials ）。
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。
3.2. CAS 原理和協議
3.2.1. 基礎模式
基礎模式 SSO 訪問流程主要有以下步驟：
- 訪問服務： SSO 客戶端發送請求訪問應用系統提供的服務資源。
- 定向認證： SSO 客戶端會重定向用戶請求到 SSO 服務器。
- 用戶認證：用戶身份認證。
- 發放票據： SSO 服務器會產生一個隨機的 Service Ticket 。
- 驗證票據： SSO 服務器驗證票據 Service Ticket 的合法性，驗證通過后，允許客戶端訪問服務。
- 傳輸用戶信息： SSO 服務器驗證票據通過后，傳輸用戶認證結果信息給客戶端。
下面是 CAS 最基本的協議過程：
CAS實現SSO單點登錄原理
基礎協議圖
如 上圖： CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 請求，同 時， CAS Client 會分析 HTTP 請求中是否包含請求 Service Ticket( ST 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經過認證的；於是 CAS Client 會重定向用戶請求到 CAS Server （ Step 2 ），並傳遞 Service （要訪問的目的資源地址）。 Step 3 是用戶認證過程，如果用戶提供了正確的 Credentials ， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並緩存以待將來驗證，並且重定向用戶到 Service 所在地址（附帶剛才產生的 Service Ticket ） , **並為客戶端瀏覽器設置一個 Ticket Granted Cookie （ TGC ） **； CAS Client 在拿到 Service 和新產生的 Ticket 過后，在 Step 5 和 Step6 中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS Server 的交互均采用 SSL 協議，以確保 ST 和 TGC 的安全性。協議工作過程中會有 **2 次重定向 **的過程。但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的（使用 HttpsURLConnection ）。
CAS 請求認證時序圖如下：
CAS實現SSO單點登錄原理
3.2.1. CAS 如何實現 SSO
當用戶訪問另一個應用的服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然后做下面的事情：
- 如果 User 持有 TGC 且其還沒失效，那么就走基礎協議圖的 Step4 ，達到了 SSO 的效果；
- 如果 TGC 失效，那么用戶還是要重新認證 ( 走基礎協議圖的 Step3) 。
3.2.2. CAS 代理模式
該模式形式為用戶訪問 App1 ， App1 又依賴於 App2 來獲取一些信息，如： User -->App1 -->App2。
這 種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那么，為了不影響用戶體驗（過多的重定向導致 User 的 IE 窗口不停地 閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理用戶去訪問其它 Web 應用。
代 理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據 ) 。之前我們提到的 TGC 是用戶持有對自己身份信息的一種憑據，這里的 PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據。憑借TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket ，所以，這里憑借 PGT ， Web應用可以代理用戶去實現后端的認證，而 **無需前端用戶的參與 **。
下面為代理應用（ helloService ）獲取 PGT 的過程： （注： PGTURL 用於表示一個 Proxy 服務，是一個回調鏈接； PGT 相當於代理證； PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關系；）
CAS實現SSO單點登錄原理
如上面的 CAS Proxy 圖所示， **CAS Client **在基礎協議之上，在驗證 ST 時提供了一個額外的PGT URL( 而且是 SSL 的入口 ) 給 CAS Server ，使得 CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通過 PGT 向后端 Web 應用進行認證。
下面是代理認證和提供服務的過程：
CAS實現SSO單點登錄原理
如 上圖所示， Proxy 認證與普通的認證其實差別不大， Step1 ， 2 與基礎模式的 Step1,2 幾乎一樣，唯一不同的 是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。
3.2.3. 輔助說明
CAS 的 SSO 實現方式可簡化理解為： 1 個 Cookie 和 N 個 Session 。 CAS Server 創建 cookie，在所有應用認證時使用，各應用通過創建各自的 Session 來標識用戶是否已登錄。
用 戶在一個應用驗證通過后，以后用戶在同一瀏覽器里訪問此應用時，客戶端應用中的過濾器會在 session 里讀取到用戶信息，所以就不會去 CAS Server 認證。如果在此瀏覽器里訪問別的 web 應用時，客戶端應用中的過濾器在 session 里讀取不到用戶信息，就會去 CAS Server 的 login 接口認證，但這時CAS Server 會讀取到瀏覽器傳來的 cookie （ TGC ），所以 CAS Server 不會要求用戶去登錄頁面登錄，只是會根據 service 參數生成一個 Ticket ，然后再和 web 應用做一個驗 證 ticket 的交互而已。
3.3. 術語解釋
CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放用戶身份認證憑證的 cookie ，在瀏覽器和 CAS Server 間通訊時使用，並且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確用戶身份的憑證；
Ø Service ticket(ST) ：服務票據，服務的惟一標識碼 , 由 CAS Server 發出（ Http 傳送），通過客戶端瀏覽器到達業務服務器端；一個特定的服務只能有一個惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 綁定一個用戶的特定服務，使其擁有向 CAS Server 申請，獲得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是將通過憑證校驗時的應答信息由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將通過回調鏈接傳給 Web 應用。 Web 應用負責維護 PGTIOU 與 PGT 之 間映射關系的內容表；
Ø Proxy Ticket (PT) ：是應用程序代理用戶身份對目標程序進行訪問的憑證；
其它說明如下：
Ø Ticket Granting ticket(TGT) ：票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據后，以后申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證信息 (Credentials) ；
Ø Authentication service(AS) --------- 認證用服務，索取 Credentials ，發放 TGT ；
Ø Ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST ；
Ø KDC( Key Distribution Center ) ---------- 密鑰發放中心；
4. CAS 安全性
CAS 的安全性僅僅依賴於 SSL 。使用的是 secure cookie 。
4.1. TGC/PGT 安全性
對於一個 CAS 用戶來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然后冒充 CAS 用戶訪問 **所有 **授權資源。 PGT 的角色跟 TGC 是一樣的。
從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。
TGT 的存活周期默認為 120 分鍾。
4.2. ST/PT 安全性
ST （ Service Ticket ）是通過 Http 傳送的，因此網絡中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通過以下幾方面來使 ST 變得更加安全（事實上都是可以配置的）：
1、 ST 只能使用一次
CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會清除服務端緩存中的該Ticket ，從而可以確保一個 Service Ticket 不被使用兩次。
2、 ST 在一段時間內失效
CAS 規定 ST 只能存活一定的時間，然后 CAS Server 會讓它失效。默認有效時間為 5 分鍾。
3、 ST 是基於隨機數生成的
ST 必須足夠隨機，如果 ST 生成規則被猜出， Hacker 就等於繞過 CAS 認證，直接訪問 對應的服務。