CAS

原文地址：http://blog.csdn.net/javaloveiphone/article/details/52439613

一、背景介紹

單點登陸：Single Sign On,簡稱SSO，SSO使得在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

CAS框架：CAS（Central Authentication Service）是實現SSO單點登陸的框架。

二、盜一張學習CAS絕大多都看過的圖以及執行部分分析

注：已分不清原創，此處就不給出地址了。

從結構上看，CAS包含兩個部分：CAS Server 和CAS Client須要獨立部署，主要負責對用戶的認證工做；CAS 
Client負責處理對客戶端受保護資源的訪問請求，須要登陸時，重定向到CAS Server.圖1是CAS最基本的協議過程：

CAS Client 與受保護的客戶端應用部署在一塊兒，以Filter方式保護 Web 應用的受保護資源，過濾從客戶端過來的每個 Web 
請求，同時， CAS Client會分析HTTP 請求中是否包請求 Service Ticket( 上圖中的 Ticket) 
，若是沒有，則說明該用戶是沒有通過認證的，因而，CAS Client會重定向用戶請求到CAS Server（ Step 2 ）。 Step 
3是用戶認證過程，若是用戶提供了正確的Credentials， CAS Server 會產生一個隨機的 Service Ticket 
，而後，緩存該 Ticket ，而且重定向用戶到CAS Client（附帶剛纔產生的Service Ticket）， Service 
Ticket 是不能夠僞造的，最後， Step 5 和 Step6是 CAS Client 和 CAS 
Server之間完成了一個對用戶的身份覈實，用Ticket查到 Username ，由於 Ticket是 CAS Server 
產生的，所以，因此 CAS Server 的判斷是毋庸置疑的。

該協議完成了一個很簡單的任務，全部與CAS的交互均採用SSL協議，確保ST和TGC的安全性。協議工做過程會有2此重定向過程，可是CAS 
Client與CAS Server之間進行ticket驗證的過程對於用戶是透明的。

總結一下，以下：

訪問服務： SSO 客戶端發送請求訪問應用系統提供的服務資源。

定向認證： SSO 客戶端會重定向用戶請求到 SSO 服務器。

用戶認證：用戶身份認證。

發放票據： SSO 服務器會產生一個隨機的 Service Ticket 。

驗證票據： SSO 服務器驗證票據 Service Ticket 的合法性，驗證經過後，容許客戶端訪問服務。

傳輸用戶信息： SSO 服務器驗證票據經過後，傳輸用戶認證結果信息給客戶端。

2、在雲裏霧裏進一步搜索、探究

先給出此部份內容出處： 《SSO CAS單點系列》之 實現一個SSO認證服務器是這樣的，如下標紅部分爲本身的疑問。

一、登陸信息傳遞

 
用戶首次登陸時流程以下：

1)、用戶瀏覽器訪問系統A需登陸受限資源，此時進行登陸檢查，發現未登陸，而後進行獲取票據操做，發現沒有票據。

2)、系統A發現該請求須要登陸，將請求重定向到認證中心，獲取全局票據操做，沒有，進行登陸。

3)、認證中心呈現登陸頁面，用戶登陸，登陸成功後，認證中心重定向請求到系統A，並附上認證經過令牌，此時認證中心同時生成了全局票據。

4)、此時再次進行登陸檢查，發現未登陸，而後再次獲取票據操做，此時能夠得到票據(令牌)，系統A與認證中心通訊，驗證令牌有效,證實用戶已登陸。

5)、系統A將受限資源返給用戶。

 
已登陸用戶首次訪問應用羣中系統B時：

1)、瀏覽器訪問另外一應用B需登陸受限資源，此時進行登陸檢查，發現未登陸，而後進行獲取票據操做，發現沒有票據。

2)、系統B發現該請求須要登陸，將請求重定向到認證中心，獲取全局票據操做，獲取全局票據，能夠得到，認證中心發現已經登陸。

3)、認證中心發放臨時票據(令牌)，並攜帶該令牌重定向到系統B。

4)、此時再次進行登陸檢查，發現未登陸，而後再次獲取票據操做，此時能夠得到票據(令牌)，系統B與認證中心通訊，驗證令牌有效,證實用戶已登陸。

5)、系統B將受限資源返回給客戶端。

二、登陸狀態判斷

用戶到認證中心登陸後，用戶和認證中心之間創建起了會話，咱們把這個會話稱爲全局會話。當用戶後續訪問系統應用時，咱們不可能每次應用請求都到認證中心去斷定是否登陸，這樣效率很是低下，這也是單Web應用不須要考慮的。

咱們能夠在系統應用和用戶瀏覽器之間創建起局部會話，局部會話保持了客戶端與該系統應用的登陸狀態，局部會話依附於全局會話存在，全局會話消失，局部會話必須消失。

用戶訪問應用時，首先判斷局部會話是否存在，如存在，即認爲是登陸狀態，無需再到認證中心去判斷。如不存在，就重定向到認證中心判斷全局會話是否存在，如存在，按1提到的方式通知該應用，該應用與客戶端就創建起它們之間局部會話，下次請求該應用，就不去認證中心驗證了。

三、登出

用戶在一個系統登出了，訪問其它子系統，也應該是登出狀態。要想作到這一點，應用除結束本地局部會話外，還應該通知認證中心該用戶登出。

認證中心接到登出通知，便可結束全局會話，同時須要通知全部已創建局部會話的子系統，將它們的局部會話銷燬。這樣，用戶訪問其它應用時，都顯示已登出狀態。

整個登出流程以下：

1)、客戶端嚮應用A發送登出Logout請求。 
2)、應用A取消本地會話，同時通知認證中心，用戶已登出。 
3)、應用A返回客戶端登出請求。 
4)、認證中心通知全部用戶登陸訪問的應用，用戶已登出。

3、撥開雲霧見青天

一、對上面全部標紅疑問一一解釋

1)、問：系統A是如何發現該請求須要登陸重定向到認證中心的？ 
答：用戶經過瀏覽器地址欄訪問系統A，系統A(也能夠稱爲CAS客戶端)去Cookie中拿JSESSION，即在Cookie中維護的當前回話session的id，若是拿到了，說明用戶已經登陸，若是未拿到，說明用戶未登陸。

2)、問：系統A重定向到認證中心，發送了什麼信息或者地址變成了什麼？ 
答：假如系統A的地址爲http://a:8080/，CAS認證中心的服務地址爲http://cas.server:8080/，那麼重點向先後地址變化爲：http://a:8080/————>ttp://cas.server:8080/?service=http://a:8080/，由此可知，重點向到認證中心，認證中心拿到了當前訪問客戶端的地址。

3)、問：登陸成功後，認證中心重定向請求到系統A，認證經過令牌是如何附加發送給系統A的？ 
答：重定向以後的地址欄變成：http://a:8080/?ticket=ST-XXXX-XXX，將票據以ticket爲參數名的方式經過地址欄發送給系統A

4)、問：系統A驗證令牌，怎樣操做證實用戶登陸的？ 
答：系統A經過地址欄獲取ticket的參數值ST票據，而後從後臺將ST發送給CAS server認證中心驗證，驗證ST有效後，CAS server返回當前用戶登陸的相關信息，系統A接收到返回的用戶信息，併爲該用戶建立session會話，會話id由cookie維護，來證實其已登陸。

5)、問：登陸B系統，認證中心是如何判斷用戶已經登陸的？ 
答：在系統A登陸成功後，用戶和認證中心之間創建起了全局會話，這個全局會話就是TGT(Ticket Granting Ticket)，TGT位於CAS服務器端，TGT並無放在Session中，也就是說，CAS全局會話的實現並無直接使用Session機制，而是利用了Cookie本身實現的，這個Cookie叫作TGC(Ticket Granting Cookie)，它存放了TGT的id,保存在用戶瀏覽器上。 
相關內容分析能夠查看：《SSO CAS單點系列》之 實操！輕鬆玩轉SSO CAS就這麼簡單(相識篇)

用戶發送登陸系統B的請求，首先會去Cookie中拿JSESSION，由於系統B並未登陸過，session會話還未建立，JSESSION的值是拿不到的，而後將請求重定向到CAS認證中心，CAS認證中心先去用戶瀏覽器中拿TGC的值，也就是全局會話id，若是存在則表明用戶在認證中心已經登陸，附帶上認證令牌重定向到系統B。

上面登陸狀態判斷也是這個邏輯。

6)、問：登出的過程，各個系統對當前用戶都作了什麼？ 
答：認證中心清除當前用戶的全局會話TGT，同時清掉cookie中TGT的id：TGC； 
而後是各個客戶端系統，好比系統A、系統B，清除局部會話session，同時清掉cookie中session會話id：jsession

二、對系統A登陸流程圖添加註釋，查看