1.體系結(jié)構(gòu)
從結(jié)構(gòu)體系看谱煤，CAS 包括兩部分： CAS Server 和 CAS Client 谓厘。
CAS Server:
負責(zé)完成對用戶的認證工作 囚玫，會為用戶簽發(fā)兩個重要的票據(jù)：登錄票據(jù)（TGT）和服務(wù)票據(jù)（ST）來實現(xiàn)認證過程, CAS Server需要獨立部署 翻默。
CAS Client:
負責(zé)處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時宜咒，重定向到 CAS Server 進行認證。準確地來說把鉴，它以Filter 方式保護受保護的資源故黑。
對于訪問受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 ServiceTicket（服務(wù)票據(jù)庭砍，由 CAS Server發(fā)出用于標識目標服務(wù)）场晶。
CAS Client 與受保護的客戶端應(yīng)用部署在一起。
2.核心票據(jù)
CAS的核心就是其Ticket怠缸，及其在Ticket之上的一系列處理操作诗轻。
CAS的主要票據(jù)有TGT、ST揭北、PGT扳炬、PGTIOU、PT搔体，其中TGT鞠柄、ST是CAS1.0(基礎(chǔ)模式)協(xié)議中就有的票據(jù)，PGT嫉柴、PGTIOU厌杜、PT是CAS2.0(代理模式)協(xié)議中有的票據(jù)。
TGT（Ticket Grangting Ticket）：
- TGT是CAS為用戶簽發(fā)的登錄票據(jù)计螺，擁有了TGT夯尽，用戶就可以證明自己在CAS成功登錄過；
- TGT封裝了Cookie值以及此Cookie值對應(yīng)的用戶信息登馒；
- 用戶在CAS認證成功后匙握，生成一個TGT對象，放入自己的緩存（Session）陈轿。同時圈纺，CAS生成cookie（叫- TGC，個人理解麦射，其實就是TGT的SessionId）蛾娶，寫入瀏覽器；
- TGT對象的ID就是cookie的值潜秋，當HTTP再次請求到來時蛔琅，如果傳過來的有CAS生成的cookie，則CAS以此cookie值（SessionId）為key查詢緩存中有無TGT（Session）峻呛。 如果有的話罗售，則說明用戶之前登錄過辜窑，如果沒有，則用戶需要重新登錄寨躁。
TGC （Ticket-granting cookie）：
上面提到穆碎，CAS-Server生成TGT放入自己的Session中，而TGC就是這個Session的唯一標識（SessionId）职恳，以Cookie形式放到瀏覽器端所禀，是CAS Server用來明確用戶身份的憑證。
ST（ServiceTicket）：
- ST是CAS為用戶簽發(fā)的訪問某一服務(wù)票據(jù)话肖；
- 用戶訪問service時北秽，service發(fā)現(xiàn)用戶沒有ST葡幸，則要求用戶去CAS獲取ST最筒；
- 用戶向CAS發(fā)出獲取ST的請求，如果用戶的請求中包含cookie蔚叨，則CAS會以此cookie值為key查詢緩存中有無TGT床蜘，如果存在TGT，則用此TGT簽發(fā)一個ST蔑水，返回給用戶邢锯；
- 用戶憑借ST去訪問service，service拿ST去CAS驗證搀别，驗證通過后丹擎，允許用戶訪問資源。
- 為了保證ST的安全性：ST 是基于隨機生成的歇父，沒有規(guī)律性蒂培。而且，CAS規(guī)定 ST 只能存活一定的時間榜苫，然后 CAS Server 會讓它失效护戳。而且，CAS 協(xié)議規(guī)定ST只能使用一次垂睬，無論 Service Ticket 驗證是否成功媳荒， CASServer 都會清除服務(wù)端緩存中的該 Ticket ，從而可以確保一個 Service Ticket 不被使用兩次驹饺。
3.認證過程
這里用一個終端钳枕，對兩個CAS—Client的三次請求來說明CAS的認證過程，主要是TGT赏壹、TGC么伯、ST等票據(jù)的傳遞，以及如何實現(xiàn)的SSO卡儒。
前兩次請求都是訪問的CAS—Client1田柔，主要來說明TGT俐巴、TGC、ST等票據(jù)的作用硬爆；
然后第三次請求訪問的是CAS—Client2欣舵，主要來說明如何實現(xiàn)的SSO。
Request1：
【第一步】終端第一次訪問CAS—Client1缀磕，AuthenticationFilter會截獲此請求：
- 首先缘圈，檢測本地Session沒有緩存有用戶信息；
- 然后袜蚕，檢測到請求信息中沒有ST糟把；
- 所以，CAS—Client1將請求重定向到CAS—Server牲剃，并傳遞 Service （也就是要訪問的目的資源地址遣疯，以便登錄成功過后轉(zhuǎn)回該地址），
例：【https://cas:8443/cas/login?service=http0%3A8081%2F】
【第二步】終端第一次訪問CAS—Server：
- CAS—Server檢測到請求信息中沒有TGC凿傅，所以跳轉(zhuǎn)到自己的登錄頁缠犀；
- 終端輸入用戶名、密碼登錄CAS—Server聪舒，認證成功后辨液，CAS—Server會生成登錄票據(jù)—TGT（集成了用戶信息與ST），并隨機生成一個服務(wù)票據(jù)—ST與CAS會話標識—TGC箱残。
TGT實際上就是Session滔迈，而TGC就是這標識這個Session存到Cookie中的SessionID；ST即被辑，根據(jù)Service生成Ticket燎悍。 - 然后，CAS—Server會將Ticket加在url 后面敷待，然后將請求redirect 回客戶web 應(yīng)用间涵，例如URL為【http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZ】
【第三步】這時，終端攜帶ticket再次請求CAS—Client1：
- 這時客戶端的AuthenticationFilter看到ticket 參數(shù)后榜揖，會跳過勾哩，由其后面的TicketValidationFilter 處理；
- TicketValidationFilter 會利用httpclient工具訪問cas 服務(wù)的/serviceValidate 接口,
將ticket 举哟、service 都傳到此接口思劳，由此接口驗證ticket 的有效性，即向CAS—Server驗證ST的有效性妨猩。 - TicketValidationFilter如果得到驗證成功的消息潜叛，就會把用戶信息寫入web 應(yīng)用的session里。至此為止，SSO 會話就建立起來了威兜。
Request2：
上面說了SSO 會話已經(jīng)建立起來了销斟，這時用戶在同一瀏覽器里第二次訪問此web 應(yīng)用（CAS—Client1）時，
AuthenticationFilter會在session 里讀取到用戶信息椒舵，這就代表用戶已成功登錄蚂踊，所以就不會去CAS 認證了。
Request3：
【第一步】與Request1是完全一樣的笔宿，如下：終端第一次訪問CAS—Client2犁钟，AuthenticationFilter會截獲此請求：
- 首先，檢測本地Session沒有緩存有用戶信息泼橘；
- 然后涝动，檢測到請求信息中沒有ST，所以炬灭，CAS—Client1將請求重定向到CAS—Server醋粟，并傳遞 Service （也就是要訪問的目的資源地址，以便登錄成功過后轉(zhuǎn)回該地址）担败，
例：【https://cas:8443/cas/login?service=http0%3A8081%2F】
【第二步】然后昔穴，終端第二次訪問CAS—Server：此時镰官，Request中會帶有上次生成的TGC提前，然后根據(jù)TGC（SessionID）去查找是否有對應(yīng)的TGT（Session），如果有泳唠，代表此用戶已成功登錄過狈网，所以此時用戶不必再去登錄頁登錄（SSO的體現(xiàn)），而CAS—Server會直接用找到的TGT簽發(fā)一個ST笨腥，然后重定向到CAS—Client2拓哺，剩下的如Request1中的
【第三步】就完全一樣了。
