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