CAS，Central Authentication Service—中央認證服務，是Yale 大學發起的一個企業級的、開源的項目，旨在為Web應用系統提供一種可靠的SSO解決方案。下面簡單介紹SSO，重點介紹CAS認證過程。
SSO英文全稱Single Sign On，是目前比較流行的服務于企業業務整合的解決方案之一， SSO 使得在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
一般 SSO 體系主要角色有三種：
＊ ?User （多個）
＊ Web 應用（多個）
＊ SSO 認證中心（ 一個 ）
SSO 實現模式一般包括以下三個原則：
＊所有的認證登錄都在 SSO 認證中心進行；
＊SSO 認證中心通過一些方法來告訴 Web 應用當前訪問用戶究竟是不是已通過認證的用戶；
＊SSO 認證中心和所有的 Web 應用建立一種信任關系，也就是說 web 應用必須信任認證中心。（單點信任）
從結構體系看，CAS 包括兩部分： CAS Server 和 CAS Client 。
CAS Server負責完成對用戶的認證工作 ，會為用戶簽發兩個重要的票據：登錄票據（TGT）和服務票據（ST）來實現認證過程, CAS Server需要獨立部署。
CAS Client負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。準確地來說，它以Filter 方式保護受保護的資源。對于訪問受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 ServiceTicket（服務票據，由 CAS Server發出用于標識目標服務）。CAS Client與受保護的客戶端應用部署在一起。
由上可知，它符合SSO中的角色架構，如下：
＊? User （多個）
＊Web 應用（多個CAS Client—與Web應用部署在一起）
＊SSO 認證中心（ 一個CAS Server—獨立部署）
CAS的核心就是其Ticket，及其在Ticket之上的一系列處理操作。CAS的主要票據有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0(基礎模式)協議中就有的票據，PGT、PGTIOU、PT是CAS2.0(代理模式)協議中有的票據。這里主要介紹CAS1.0—基礎模式中的幾種票據。
TGT（Ticket Grangting Ticket）
TGT是CAS為用戶簽發的登錄票據，擁有了TGT，用戶就可以證明自己在CAS成功登錄過。TGT封裝了Cookie值以及此Cookie值對應的用戶信息。用戶在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用來明確用戶身份的憑證。（如果你理解Session的存放原理的話就很好理解）
ST（ServiceTicket）
ST是CAS為用戶簽發的訪問某一服務票據。用戶訪問service時，service發現用戶沒有ST，則要求用戶去CAS獲取ST。用戶向CAS發出獲取ST的請求，如果用戶的請求中包含cookie，則CAS會以此cookie值為key查詢緩存中有無TGT，如果存在TGT，則用此TGT簽發一個ST，返回給用戶。用戶憑借ST去訪問service，service拿ST去CAS驗證，驗證通過后，允許用戶訪問資源。
為了保證ST的安全性：ST 是基于隨機生成的，沒有規律性。而且，CAS規定 ST 只能存活一定的時間，然后 CAS Server 會讓它失效。而且，CAS 協議規定ST只能使用一次，無論 Service Ticket 驗證是否成功， CASServer 都會清除服務端緩存中的該 Ticket ，從而可以確保一個 Service Ticket 不被使用兩次。
這里用一個終端，對兩個CAS—Client的三次請求來說明CAS的認證過程，主要是TGT、TGC、ST等票據的傳遞，以及如何實現的SSO。
如下圖，前兩次請求都是訪問的CAS—Client1，主要來說明TGT、TGC、ST等票據的作用；然后第三次請求訪問的是CAS—Client2，主要來說明如何實現的SSO。
【第一步】終端第一次訪問CAS—Client1，AuthenticationFilter會截獲此請求：1、首先，檢測本地Session沒有緩存有用戶信息；2、然后，檢測到請求信息中沒有ST；3、所以，CAS—Client1將請求重定向到CAS—Server，并傳遞 Service （也就是要訪問的目的資源地址，以便登錄成功過后轉回該地址），例：【https://cas:8443/cas/login?service=http0%3A8081%2F】
【第二步】終端第一次訪問CAS—Server：1、CAS—Server檢測到請求信息中沒有TGC，所以跳轉到自己的登錄頁；2、終端輸入用戶名、密碼登錄CAS—Server，認證成功后，CAS—Server會生成登錄票據—TGT（集成了用戶信息與ST），并隨機生成一個服務票據—ST與CAS會話標識—TGC。TGT實際上就是Session，而TGC就是這標識這個Session存到Cookie中的SessionID；ST即，根據Service生成Ticket。3、然后，CAS—Server會將Ticket加在url 后面，然后將請求redirect 回客戶web 應用，例如URL為【http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZ】
【第三步】這時，終端攜帶ticket再次請求CAS—Client1：1、這時客戶端的AuthenticationFilter看到ticket 參數后，會跳過，由其后面的TicketValidationFilter 處理；2、TicketValidationFilter 會利用httpclient工具訪問cas 服務的/serviceValidate 接口, 將ticket 、service 都傳到此接口，由此接口驗證ticket 的有效性，即向CAS—Server驗證ST的有效性。3、TicketValidationFilter如果得到驗證成功的消息，就會把用戶信息寫入web 應用的session里。至此為止，SSO 會話就建立起來了。
上面說了SSO 會話已經建立起來了，這時用戶在同一瀏覽器里第二次訪問此web 應用（CAS—Client1）時，AuthenticationFilter會在session 里讀取到用戶信息，這就代表用戶已成功登錄，所以就不會去CAS 認證了。
【第一步】與Request1是完全一樣的，如下：終端第一次訪問CAS—Client2，AuthenticationFilter會截獲此請求：1、首先，檢測本地Session沒有緩存有用戶信息；2、然后，檢測到請求信息中沒有ST；3、所以，CAS—Client1將請求重定向到CAS—Server，并傳遞 Service （也就是要訪問的目的資源地址，以便登錄成功過后轉回該地址），例：【https://cas:8443/cas/login?service=http0%3A8081%2F】
【第二步】然后，終端第二次訪問CAS—Server：此時，Request中會帶有上次生成的TGC，然后根據TGC（SessionID）去查找是否有對應的TGT（Session），如果有，代表此用戶已成功登錄過，所以此時用戶不必再去登錄頁登錄（SSO的體現），而CAS—Server會直接用找到的TGT簽發一個ST，然后重定向到CAS—Client2，剩下的如Request1中的【第三步】就完全一樣了。
CAS認證過程中的核心概念即是幾個【票據】，實際上其實就是1個Cookie和N個Session。包括CAS1.0（基礎模式）的TGT、ST、TGC；以及CAS2.0（代理模式）的PGT、PT、PGTIOU等。認證過程，即是這幾個票據的傳遞與對比驗證的過程。
轉載http://blog.csdn.net/wang379275614/article/details/46337529
