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