CAS是Central Authentication Service的首字母縮寫，Apereo CAS 是由耶魯大學(xué)實(shí)驗(yàn)室2002年出的一個開源的統(tǒng)一認(rèn)證服務(wù)练链。旨在為 Web 應(yīng)用系統(tǒng)提供一種可靠的單點(diǎn)登錄解決方法沃但。

CAS Architecture

Architecture

從這個圖可以看到可款，CAS服務(wù)器端和各種語言的客戶端組成了CAS系統(tǒng)體系結(jié)構(gòu)的兩個物理組件，它們通過各種協(xié)議進(jìn)行通信逼庞。

CAS Server

The CAS server is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user’s request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.【CAS服務(wù)器是構(gòu)建在Spring框架上的Java servlet蛇更，其主要職責(zé)是通過發(fā)出和驗(yàn)證票據(jù)，對用戶進(jìn)行身份驗(yàn)證并授予對啟用了CAS的服務(wù)(通常稱為CAS客戶端)的訪問權(quán)赛糟。當(dāng)服務(wù)器向成功登錄的用戶發(fā)出授予票據(jù)(TGT)時(shí)派任，將創(chuàng)建SSO會話。服務(wù)票證(ST)在用戶的請求下通過使用TGT作為令牌的瀏覽器重定向發(fā)送給服務(wù)璧南。ST隨后在CAS服務(wù)器上通過反向通道通信進(jìn)行驗(yàn)證掌逛。這些交互在CAS協(xié)議文檔中有詳細(xì)的描述∷疽校】

CAS Client

The term “CAS client” has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). CAS clients supporting a number of software platforms and products have been developed.【術(shù)語“CAS客戶端”在通常的使用中有兩個不同的含義豆混。CAS客戶端是任何啟用了CAS的應(yīng)用程序，可以通過受支持的協(xié)議與服務(wù)器通信动知。CAS客戶端也是一個軟件包皿伺，它可以與各種軟件平臺和應(yīng)用程序集成，以便通過某些身份驗(yàn)證協(xié)議(如CAS盒粮、SAML心傀、OAuth)與CAS服務(wù)器通信。支持多個軟件平臺和產(chǎn)品的CAS客戶端已經(jīng)開發(fā)完成拆讯≈校】

Supported Protocols

通過任何一種受支持的協(xié)議客戶端和服務(wù)端進(jìn)行通信。所有這些受支持的協(xié)議概念上都是相似的种呐，然后一些協(xié)議具有某些特殊的特征宰翅，使他們適用于特定的應(yīng)用或?qū)嵗１热缢遥珻AS協(xié)議支持委托（代理）身份驗(yàn)證汁讼，而SAML協(xié)議支持attribute release 和單點(diǎn)登出。

CAS proxy 原理圖

cas-flow-diagram

1. 用戶輸入GET https://app.example.com/想要訪問app系統(tǒng)嘿架，由于app系統(tǒng)是需要驗(yàn)證才能范文的，但是app系統(tǒng)在收到該請求的時(shí)候并沒有發(fā)現(xiàn)請求中帶有JSESSIONID字段啸箫，因此app系統(tǒng)判斷發(fā)送該請求的用戶沒有登錄認(rèn)證耸彪，最后app系統(tǒng)做出的操作是，重定向該請求忘苛，讓用戶去訪問SSO系統(tǒng)蝉娜，因此我們從圖上看到302 Location:https://cas.example.com/cas/login?service=https%3A%2F...這里加上？service=https:%3A%2F... 就是為了方便用戶在SSO認(rèn)證登錄后能夠再定向到app系統(tǒng)扎唾。
2. 用戶（或者這里叫Browser）在收到app系統(tǒng)的重定向后召川，去訪問SSO，這個時(shí)候SSO發(fā)現(xiàn)該用戶的請求中沒有ticket信息胸遇，因此SSO判定該用戶還沒有在SSO中登錄荧呐，因此SSO出示login頁面，讓用戶去輸入username纸镊、password信息倍阐。
3. 用戶填寫username、password信息薄腻，SSO系統(tǒng)對其進(jìn)行認(rèn)證后收捣，會生成一個ST（Service Ticket）供url上傳輸 , 并將該用戶信息寫入SSO的session（session中的用戶登錄信息是被TGT封裝起來的），而這個SSO系統(tǒng)的session的保存是key庵楷，value形式的罢艾，這個session的key叫做TGC，對應(yīng)的value值叫做TGT尽纽。當(dāng)重定向回用戶時(shí)附帶ST信息咐蚯，并且把TGC的值存儲到用戶的Cookie中。
4. 接下來用戶有了ST信息弄贿，就拿著這個ST+app系統(tǒng)鏈接地址（GET https://app.example.com/?ticket=ST-12345678）去訪問app系統(tǒng)春锋。
5. 當(dāng)app系統(tǒng)收到用戶的請求時(shí)發(fā)現(xiàn)，該request中包含ST信息差凹，app系統(tǒng)會去拿著ST信息到SSO進(jìn)行驗(yàn)證期奔，如果驗(yàn)證通過侧馅，SSO返回給app系統(tǒng)success消息（圖上是xml信息，還包含其它的可選參數(shù)字段信息）呐萌。
6. app系統(tǒng)在得到SSO的肯定回答后馁痴，將用戶的登錄信息存入app系統(tǒng)的session中，此時(shí)app系統(tǒng)并沒有直接給用戶展示要訪問的信息肺孤，而是把request重定向回用戶罗晕，只不過redirect 地址中夾帶了app系統(tǒng)的session 信息，目的是為了讓瀏覽器存儲該session信息到Cookies中赠堵，方便后續(xù)的二次小渊、三次訪問情況。
7. 用戶再次根據(jù)app系統(tǒng)的redirect 地址（Cookie：JESESSIONID=ABC-1234567 GET https://app.example.com）去請求app系統(tǒng)茫叭。
8. app系統(tǒng)此時(shí)收到用戶的request是包含JESESSIONID字段的酬屉，app系統(tǒng)會在自己的Cookie中驗(yàn)證，如果成功就返回給用戶資源信息杂靶。

Notes：

- The TGT (Ticket Granting Ticket), stored in the TGC cookie, represents a SSO session for a user.
- The ST (Service Ticket), transmitted as a GET parameter in urls, stands for the access granted by the CAS server to the CASified application for a specific user.

TGC：Ticket Granting Cookie
CAS 會將生成的 TGT 放在 session 中梆惯，而 TGC 就是這個 session 的唯一標(biāo)識(sessionId)，
可以認(rèn)為是 TGT 的key吗垮，為 TGT 就是 TGC 的 value垛吗，TGC 以 cookie 的形式保存在瀏覽器中，
每個請求都會嘗試攜帶 TGC烁登。（每個服務(wù)都會在 session 和 cookie 中保存對應(yīng)的 TGT 和 TGC）

TGT：Ticket Granting Ticket
TGT 是CAS 為用戶簽發(fā)的登錄 ticket怯屉，也是用于驗(yàn)證用戶登錄成功的唯一方式。 
TGT 封裝了 Cookie 值以及 Cookie 值對應(yīng)的用戶信息饵沧，CAS 通過 Cookie 值（TGC）
為 key 查詢緩存中有無 TGT（TGC:TGT（key:value））锨络，如果有的話就說明用戶已經(jīng)登錄成。

ST：Service Ticket
ST 是當(dāng)用戶訪問某一服務(wù)時(shí)提供的 ticket狼牺。用戶在訪問其他服務(wù)時(shí)羡儿，
發(fā)現(xiàn)沒有 cookie 或 ST ，那么就會302到 CAS 服務(wù)器獲取 ST是钥。然后會攜帶著 ST 302 回來掠归。

用戶再次訪問app系統(tǒng)的流程：

1. 用戶請求app系統(tǒng)鏈接地址，帶上JSESSIONID悄泥。
2. app系統(tǒng)收到帶有JSESSIONID的request后虏冻，會在app系統(tǒng)的session中查找對應(yīng)的value，查找成功后向用戶發(fā)送相應(yīng)的資源文件弹囚。

這個過程比較簡單厨相，和普通的請求訪問一樣，檢查服務(wù)端是否有存在session值，如果有就直接允許訪問相應(yīng)的資源蛮穿。

用戶第一次訪問 與 app系統(tǒng)相互信任的系統(tǒng)流程：

1. 用戶直接請求app2系統(tǒng)地址鏈接庶骄。https://app2.example.com/
2. app2系統(tǒng)收到request后發(fā)現(xiàn)這個request既沒有ST也沒有cookie，就會重定向到CAS服務(wù)器践磅。
3. 用戶的請求被重定向后瓢姻，去訪問CAS服務(wù)器，這個時(shí)候是帶著cookie的音诈。
4. CAS服務(wù)器收到用戶帶有cookie的request后，根據(jù)這個cookie（也就是TGC）去CAS的session中找TGT绎狭，如果查找成功细溅，為該用戶的請求頒發(fā)一個ST，并且更新TGC的值重寫回瀏覽器端儡嘶，當(dāng)然CAS服務(wù)器端也是需要更新的哈喇聊。最后CAS把請求再重定向到app2系統(tǒng)。
5. 用戶按照CAS的重定向蹦狂，攜帶ST去訪問app2系統(tǒng)誓篱，app2系統(tǒng)這次發(fā)現(xiàn)request帶有ST，趕緊去找CAS驗(yàn)證凯楔，CAS驗(yàn)證通過后窜骄，給app2系統(tǒng)發(fā)送確認(rèn)消息，最后app2系統(tǒng)才給用戶返回要訪問的資源信息摆屯。

老子有個問題哈：CAS是如何驗(yàn)證ST的邻遏？看有效期？還是看啥虐骑？

參考文章

1. 單點(diǎn)登錄（SSO）看這一篇就夠了