簡介
Cas介紹
CAS （ Central Authentication Service ），最初由耶魯大學的Shawn Bayern 開發(fā)，后由Jasig社區(qū)維護，經(jīng)過十多年發(fā)展，目前已成為影響最大、廣泛使用的、基于Java實現(xiàn)的、開源SSO解決方案。cas旨在為 Web 應用系統(tǒng)提供一種可靠的單點登錄解決方法（屬于 Web SSO ）。 CAS 開始于 2001 年， 并在 2004 年 12 月正式成為 JA-SIG 的一個項目。
CAS的官方網(wǎng)址是： https://www.apereo.org/projects/cas
工程代碼網(wǎng)址：https://github.com/Jasig/cas
架構
CAS應用的整體架構官方提供了一個比較清晰的架構圖，如下所示：
主要特性
SSO英文全稱Single Sign On，單點登錄。SSO是在多個應用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統(tǒng)。它包括可以將這次主要的登錄映射到其他應用中用于同一個用戶的登錄的機制。它是目前比較流行的企業(yè)業(yè)務整合的解決方案之一。
一般場景下，我們不需要重新造輪子，直接在成熟技術框架基礎上開發(fā)使用即可。這也是CAS在很多互聯(lián)網(wǎng)和企業(yè)應用中廣泛使用的原因。當然，對于某些場景，如安全性因素、掃碼登錄、更特殊更高效的應用場景，在技術實力許可的情況下，通常都自己實現(xiàn)SSO，當然，也可以自定義CAS。
我粗略的羅列一些CAS的優(yōu)勢：
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、 支持授權：可以決定哪些服務可以請求和驗證服務票據(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 等。
單點登錄流程概述
協(xié)議過程
如 上圖： CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 請求，同 時， CAS Client 會分析 HTTP 請求中是否包含請求 Service Ticket( ST 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經(jīng)過認證的；于是 CAS Client 會重定向用戶請求到 CAS Server （ Step 2 ），并傳遞 Service （要訪問的目的資源地址）。 Step 3 是用戶認證過程，如果用戶提供了正確的 Credentials ， CAS Server 隨機產(chǎn)生一個相當長度、唯一、不可偽造的 Service Ticket ，并緩存以待將來驗證，并且重定向用戶到 Service 所在地址（附帶剛才產(chǎn)生的 Service Ticket ） , 并為客戶端瀏覽器設置一個 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 ）。
認證時序圖
官方的用戶登錄時序圖非常詳細，直接引用如下：
所有的系統(tǒng)應用都會引導到CAS Server認證中心去登錄。登錄成功后，認證中心會產(chǎn)生一個票據(jù)叫TGT(Ticket Granting Ticket)，TGT即代表了用戶與認證中心直接的全局會話。TGT存在，表明該用戶處于登錄狀態(tài)。
TGT并沒有放在Session中，也就是說，CAS全局會話的實現(xiàn)并沒有直接使用Session機制，而是利用了Cookie自己實現(xiàn)的，這個Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,認證中心服務端實現(xiàn)了TGT。
在認證中心登錄下，看下登錄前后cookie的變化。顯然，在登錄后，多出一個叫CASTGC的Cookie,它來維持全局會話。
如果是應用系統(tǒng)登錄，客戶端會被引導到認證中心進行登錄，登錄成功后再重定向回應用系統(tǒng)，這時會帶上一個登錄令牌，告知系統(tǒng)應用登錄成功。
這個令牌，在CAS中叫做ST(Service Ticket)服務票據(jù)，它的作用和Nebula的token類似。當然，和Nebula一樣，應用系統(tǒng)收到ST后，會直接向CAS Server去驗證，驗證通過后，應用系統(tǒng)即可建立本地會話，返回用戶訪問的受限資源。
其中第一個，我們看到，登錄成功后，系統(tǒng)會設置CASTGC Cookie，同時重定向回應用時帶上了一個ticket變量，這個就是ST。
小結
CAS 已經(jīng)有很多公司在實際項目中應用，可以肯定它的可靠性，它可以解決項目中大部分單點登錄的場景，由于他采用spring mvc, spring webflow方式開發(fā)，項目結構是模塊化的，即使默認提供的功能不能滿足業(yè)務場景，如掃碼登錄，我們也可以很方便的擴展這個功能。后期我會寫一篇關于如何自定義的文章。
參考
cas Architecture
《SSO CAS單點系列》之 實操！輕松玩轉SSO CAS就這么簡單(相遇篇)
《SSO CAS單點系列》之 實操！輕松玩轉SSO CAS就這么簡單(相識篇)
