CAS，Central Authentication Service—中央認證服務，是Yale 大學發起的一個企業級的、開源的專案，旨在為Web應用系統提供一種可靠的SSO解決方案。下面簡單介紹SSO，重點介紹CAS認證過程。

一、    SSO簡介

　　1.1   概念

　　SSO英文全稱Single Sign On，是目前比較流行的服務於企業業務整合的解決方案之一， SSO 使得在多個應用系統中，使用者只需要登入一次 就可以訪問所有相互信任的應用系統。

　　1.2  角色

　　一般 SSO 體系主要角色有三種：

　　＊  User （多個）

　　＊ Web 應用（多個）

　　＊ SSO 認證中心（ 一個 ）

　　1.3  原則

　　SSO 實現模式一般包括以下三個原則：

　　＊  所有的認證登入都在 SSO 認證中心進行；

　　＊  SSO 認證中心通過一些方法來告訴 Web 應用當前訪問使用者究竟是不是已通過認證的使用者；

　　＊  SSO 認證中心和所有的 Web 應用建立一種信任關係，也就是說 web 應用必須信任認證中心。（單點信任）

二、    CAS原理介紹

　　2.1  體系結構

　　　　從結構體系看，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—獨立部署

　　2.2  核心票據

　　　　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 不被使用兩次。

　　2.3  認證過程

　　這裡用一個終端，對兩個CAS—Client的三次請求來說明CAS的認證過程，主要是TGT、TGC、ST等票據的傳遞，以及如何實現的SSO。

　　如下圖，前兩次請求都是訪問的CAS—Client1，主要來說明TGT、TGC、ST等票據的作用；然後第三次請求訪問的是CAS—Client2，主要來說明如何實現的SSO。

　　Request1

　　　　【第一步】終端第一次訪問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 會話就建立起來了。

　　Request2

　　　　上面說了SSO 會話已經建立起來了，這時使用者在同一瀏覽器裡第二次訪問此web 應用（CAS—Client1）時，AuthenticationFilter會在session 裡讀取到使用者資訊，這就代表使用者已成功登入，所以就不會去CAS 認證了。

　　Request3

　　　　【第一步】與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等。認證過程，即是這幾個票據的傳遞與對比驗證的過程。