簡(jiǎn)介
Cas介紹
CAS （ Central Authentication Service ）骆膝，最初由耶魯大學(xué)的Shawn Bayern 開發(fā)缅阳，后由Jasig社區(qū)維護(hù)含蓉，經(jīng)過十多年發(fā)展以政，目前已成為影響最大鞭执、廣泛使用的司顿、基于Java實(shí)現(xiàn)的、開源SSO解決方案兄纺。cas旨在為 Web 應(yīng)用系統(tǒng)提供一種可靠的單點(diǎn)登錄解決方法（屬于 Web SSO ）大溜。 CAS 開始于 2001 年， 并在 2004 年 12 月正式成為 JA-SIG 的一個(gè)項(xiàng)目估脆。
CAS的官方網(wǎng)址是： https://www.apereo.org/projects/cas
工程代碼網(wǎng)址：https://github.com/Jasig/cas
架構(gòu)
CAS應(yīng)用的整體架構(gòu)官方提供了一個(gè)比較清晰的架構(gòu)圖钦奋，如下所示：
主要特性
SSO英文全稱Single Sign On，單點(diǎn)登錄疙赠。SSO是在多個(gè)應(yīng)用系統(tǒng)中付材，用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。它包括可以將這次主要的登錄映射到其他應(yīng)用中用于同一個(gè)用戶的登錄的機(jī)制圃阳。它是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一厌衔。
一般場(chǎng)景下，我們不需要重新造輪子捍岳，直接在成熟技術(shù)框架基礎(chǔ)上開發(fā)使用即可富寿。這也是CAS在很多互聯(lián)網(wǎng)和企業(yè)應(yīng)用中廣泛使用的原因。當(dāng)然锣夹，對(duì)于某些場(chǎng)景页徐，如安全性因素、掃碼登錄银萍、更特殊更高效的應(yīng)用場(chǎng)景泞坦，在技術(shù)實(shí)力許可的情況下，通常都自己實(shí)現(xiàn)SSO砖顷，當(dāng)然贰锁，也可以自定義CAS赃梧。
我粗略的羅列一些CAS的優(yōu)勢(shì)：
1、 開源的豌熄、多協(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 ）來實(shí)現(xiàn)支持的認(rèn)證協(xié)議；
4类咧、 支持授權(quán)：可以決定哪些服務(wù)可以請(qǐng)求和驗(yàn)證服務(wù)票據(jù)（ Service Ticket ）馒铃；
5、 提 供高可用性：通過把認(rèn)證過的狀態(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 等。
單點(diǎn)登錄流程概述
協(xié)議過程
如 上圖： CAS Client 與受保護(hù)的客戶端應(yīng)用部署在一起，以 Filter 方式保護(hù) Web 應(yīng)用的受保護(hù)資源掸屡，過濾從客戶端過來的每一個(gè) Web 請(qǐng)求封寞，同 時(shí)， CAS Client 會(huì)分析 HTTP 請(qǐng)求中是否包含請(qǐng)求 Service Ticket( ST 上圖中的 Ticket) 仅财，如果沒有狈究，則說明該用戶是沒有經(jīng)過認(rèn)證的；于是 CAS Client 會(huì)重定向用戶請(qǐng)求到 CAS Server （ Step 2 ）盏求，并傳遞 Service （要訪問的目的資源地址）抖锥。 Step 3 是用戶認(rèn)證過程，如果用戶提供了正確的 Credentials 碎罚， CAS Server 隨機(jī)產(chǎn)生一個(gè)相當(dāng)長(zhǎng)度磅废、唯一、不可偽造的 Service Ticket 荆烈，并緩存以待將來驗(yàn)證拯勉，并且重定向用戶到 Service 所在地址（附帶剛才產(chǎn)生的 Service Ticket ） , 并為客戶端瀏覽器設(shè)置一個(gè) Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新產(chǎn)生的 Ticket 過后耙考，在 Step 5 和 Step6 中與 CAS Server 進(jìn)行身份核實(shí)谜喊，以確保 Service Ticket 的合法性潭兽。
在該協(xié)議中倦始，所有與 CAS Server 的交互均采用 SSL 協(xié)議，以確保 ST 和 TGC 的安全性山卦。協(xié)議工作過程中會(huì)有 2 次重定向 的過程鞋邑。但是 CAS Client 與 CAS Server 之間進(jìn)行 Ticket 驗(yàn)證的過程對(duì)于用戶是透明的（使用 HttpsURLConnection ）。
認(rèn)證時(shí)序圖
官方的用戶登錄時(shí)序圖非常詳細(xì)账蓉，直接引用如下：
所有的系統(tǒng)應(yīng)用都會(huì)引導(dǎo)到CAS Server認(rèn)證中心去登錄枚碗。登錄成功后，認(rèn)證中心會(huì)產(chǎn)生一個(gè)票據(jù)叫TGT(Ticket Granting Ticket)铸本，TGT即代表了用戶與認(rèn)證中心直接的全局會(huì)話肮雨。TGT存在，表明該用戶處于登錄狀態(tài)箱玷。
TGT并沒有放在Session中怨规，也就是說，CAS全局會(huì)話的實(shí)現(xiàn)并沒有直接使用Session機(jī)制锡足，而是利用了Cookie自己實(shí)現(xiàn)的波丰，這個(gè)Cookie叫做TGC(Ticket Granting Cookie)，它存放了TGT的id,認(rèn)證中心服務(wù)端實(shí)現(xiàn)了TGT舶得。
在認(rèn)證中心登錄下掰烟，看下登錄前后cookie的變化。顯然，在登錄后纫骑，多出一個(gè)叫CASTGC的Cookie,它來維持全局會(huì)話蝎亚。
如果是應(yīng)用系統(tǒng)登錄，客戶端會(huì)被引導(dǎo)到認(rèn)證中心進(jìn)行登錄先馆，登錄成功后再重定向回應(yīng)用系統(tǒng)颖对，這時(shí)會(huì)帶上一個(gè)登錄令牌，告知系統(tǒng)應(yīng)用登錄成功磨隘。
這個(gè)令牌缤底，在CAS中叫做ST(Service Ticket)服務(wù)票據(jù)，它的作用和Nebula的token類似番捂。當(dāng)然个唧，和Nebula一樣，應(yīng)用系統(tǒng)收到ST后设预，會(huì)直接向CAS Server去驗(yàn)證徙歼，驗(yàn)證通過后，應(yīng)用系統(tǒng)即可建立本地會(huì)話鳖枕，返回用戶訪問的受限資源魄梯。
其中第一個(gè)，我們看到宾符，登錄成功后酿秸，系統(tǒng)會(huì)設(shè)置CASTGC Cookie，同時(shí)重定向回應(yīng)用時(shí)帶上了一個(gè)ticket變量魏烫，這個(gè)就是ST辣苏。
小結(jié)
CAS 已經(jīng)有很多公司在實(shí)際項(xiàng)目中應(yīng)用，可以肯定它的可靠性哄褒，它可以解決項(xiàng)目中大部分單點(diǎn)登錄的場(chǎng)景稀蟋，由于他采用spring mvc, spring webflow方式開發(fā)，項(xiàng)目結(jié)構(gòu)是模塊化的呐赡，即使默認(rèn)提供的功能不能滿足業(yè)務(wù)場(chǎng)景退客，如掃碼登錄，我們也可以很方便的擴(kuò)展這個(gè)功能链嘀。后期我會(huì)寫一篇關(guān)于如何自定義的文章萌狂。
參考
cas Architecture
《SSO CAS單點(diǎn)系列》之 實(shí)操！輕松玩轉(zhuǎn)SSO CAS就這么簡(jiǎn)單(相遇篇)
《SSO CAS單點(diǎn)系列》之 實(shí)操管闷！輕松玩轉(zhuǎn)SSO CAS就這么簡(jiǎn)單(相識(shí)篇)
