❶ CAS TGC 安全性問題
CAS 的安全性是一個非常重要的 Topic 。 CAS 從 v1 到 v3 ，都很依賴於 SSL ，它假定了這樣一個事實，用戶在一個非常不安全的網路環境中使用 SSO ， Hacker 的 Sniffer 會很容易抓住所有的 Http Traffic ，包括通過 Http 傳送的密碼甚至 Ticket 票據。
TGC/PGT 安全性
對於一個 CAS 用戶來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然後冒充 CAS 用戶訪問所有授權資源。
SSO 的安全性問題比普通應用的安全性還要嚴重，因為 SSO 存在一種門檻效應。以前即使 Hacker 能夠截獲用戶在 Web 應用 A 的密碼，它也未必能知道用戶在 Web 應用 B 的密碼，但 SSO 讓 Hacker 只需要截獲 TGC( 突破了門檻 ) ，即能訪問所有與該用戶相關的所有應用系統。
PGT 跟 TGC 的角源寬冊色是一樣的，如果被 Hacker 獲得，後果可想而知。
從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。
因此，某些人認為 CAS 可以不使用 SSL 的想法需要更正一下， CAS 的傳輸安全性僅僅依賴與 SSL 。
跟 Kerberos 一樣 TGT ， TGC 也有自己的存活周期。下面是 CAS 的 web.xml 中，通過 grantingTimeout 來巧搜設置 CAS TGC 存活周期的參數，參數默認是 120 分鍾，在合適的范圍內設置最小值，太短，會影響 SSO 體驗，太長，會增加安全性風險。
<context-param>
<param-name>e.yale.its.tp.cas.grantingTimeout</param-name>
<param-value>7200</param-value>
</context-param>
TGC 面臨的風險主要並非傳輸竊取。比如你登陸了之後，沒有 Logout ，離開了電腦，別人就可以打開你的瀏覽器，直接訪問你授權訪問的應用 ) ，設置一個 TGC 的有效期，可以減少雹宏被別人盜用，或者被 Hacker 入侵你的電腦直接獲取你系統目錄下的 TGC Cookie 。
Service Ticket/Proxy Ticket 安全性
首要明白， Service Ticket 是通過 Http 傳送的，以為著所網路中的其他人可以 Sniffer 到其他人的 Ticket 。
CAS 協議從幾個方面讓 Service Ticket 變得更加安全。
l Service Ticket 只能使用一次。
CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會將服務端的緩存中清除該 Ticket ，從而可以確保一個 Service Ticket 被使用兩次。
l Service Ticket 在一段時間內失效。
假設用戶拿到 Service Ticket 之後，他請求 helloservice 的過程又被中斷了， Service Ticket 就被空置了，事實上，此時， Service Ticket 仍然有效。 CAS 規定 Service Ticket 只能存活一定的時間，然後 CAS Server 會讓它失效。通過在 web.xml 中配置下面的參數，可以讓 Service Ticket 在多少秒內失效。
<context-param>
<param-name>e.yale.its.tp.cas.serviceTimeout</param-name>
<param-value>300</param-value>
</context-param>
該參數在業務應用的條件范圍內，越小越安全。
l Service Ticket 是基於隨機數生成的。
Service Ticket 必須足夠隨機，如果 Service Ticket 生成規則被猜出（如果你使用了 ST+Helloservice+ 自增序列的方式， Hacker 就可以構造下一個 Ticket ）， Hacker 就等於繞過 CAS 認證，直接訪問所有服務。
❷ 登錄那點事
client：提供用戶名和密碼或者是其他的認證憑證
server：驗證client提供的認證憑證，記錄登錄狀態
過程：訪問系統時，client必須輸入用戶名和密碼，server進行驗證，驗證通過後server建立一個叫做session的東西，然後把sessionId通過cookie發送給瀏覽器，下次登錄的時候會帶著cookie一起發過來，server從cookie中拿到sessionId就知道已經登錄啦。
cookie和session的作用就是保持client和server的交互狀態，這樣一來可以將無狀態的通信轉化成有狀態的交互，也就是讓server有了「記憶」能力。
現在有三個服務，需要輸入三次用戶信息，但是如果有成百上千的服務呢？HOW???
參考上面簡單登錄的原理：服務端如何有了「記憶」能力呢：在client和server之間引入了一個中間層（cookie或者是session）。（題外話：計算機世界的99%的問題都可以通過一個引入一個中間層來解決）
所有我們可以想到一個可行的解決方案：對這個「中間層」做共享。
比如說先登錄了A，就有了一個cookie，然後在用cookie去登錄其他的系統。但是這樣明顯是有問題的：
1，cookie不能跨域，比如說a.com產生的cookie是不能傳遞給b.com的
2，就算cookie可以傳遞，但是其他系統並沒有session來校驗這個cookie。
解決方案：
1.cookie做共享可以掛到同一個一級域名下，比如A叫a.corp.com，B叫b.corp.com，C叫c.corp.com，這樣cookie不就能共享了嘛
2，將session也做共享，從內存裡面拿出來，放入一個大家都能訪問的中間層裡面，比如說redis。（題外話：又是中間層）
像下面這樣：
可以解決多系統登錄的問題么？可以解決！！！ 但是
1，要共享cookie就必須讓所有的系統都在同一個域名下
2，多用戶賬號的存在。比如張三登錄了A，然後去登錄B，通過這種方式的話B需要去校驗張三這個用戶的合法性，此張三可能未必是彼張三！各個業務系統必須自己去維護自己系統的用戶，而且用戶信息還不止一個。
HOW？？？？
Single Sign One ：單點登錄
消除多用戶信息的問題，不用各個業務系統自己去維護用戶信息，建立一個統一的用戶認證中心（中間層：又是我哈哈哈），所有用戶的認證工作都交給這個認證中心來完成。各個子業務只需要負責實現自己的業務即可，不在需要關心用戶、認證等細節。
大致流程如下：
用戶第一次訪問A系統：www.a.corp.com，這個時候如果A發現用戶沒有登錄的話，那他需要做的一項操作就是重定向認證中心：www.sso.com/login?redirect=www.a.corp.com。
其中www.sso.com/login就是認證中心的登錄地址，redirect=www.a.corp.com就是登錄完成後需要跳轉到的地址。在認證中心登錄之後認證中心會做以下幾件事情：
1，建立一個session
2，發放ticket
3，重定向到你的地址，並在瀏覽器種下cookie信息。注意這個cookie是認證中心伺服器的cookie哦。如：ssoid=1,domain=sso.com
需要注意的有兩點：
1，進行了兩次重定向。第一次是重定向到SSO的伺服器，第二次是重定向我們的後端伺服器。
2，流程完成後再瀏覽器種了兩個cookie，一個是sso伺服器的cookie，一個是子系統A的cookie。
接下來我們訪問B系統：
這個時候會有三個cookie：
1，認證中心的cookie domain: sso.com
2，A系統的cookie domain： a.corp.com
3, B系統的cookie domain： b.corp.com
本質上就是保存了一個認證中心的cookie和多個子系統的cookie。一般我們稱SSO的cookie的對應的會話成為全局會話，各自子系統cookie對應的會話稱為局部會話。
概述
CAS（Central Authentication Service） 是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的單點登錄解決方法（屬於 Web SSO）。
CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。
特性
1、 開源的、多協議的 SSO 解決方案；Protocols：Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0 等。
2、 支持多種認證機制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates 等；
3、 安全策略：使用票據（Ticket）來實現支持的認證協議；
4、 支持授權：可以決定哪些服務可以請求和驗證服務票據（Service Ticket）；
5、 提供高可用性：通過把認證過的狀態數據存儲在 TicketRegistry 組件中，這些組件有很多支持分布式環境的實現，如：BerkleyDB、Default 、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry 等；
6、 支持多種客戶端： Java、 .Net、 PHP、 Perl、 Apache, uPortal 等。
體系結構
從結構上看，CAS 包含兩個部分：CAS Server 和 CAS Client，CAS 需要獨立部署，主要負責對用戶的認證工作，CAS Server 會處理用戶名 / 密碼等憑證 (Credentials)。
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。CAS Client一般與 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。過濾從客戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 請求中是否包請求 Service Ticket
術語
Ticket Granting ticket (TGT) ：可以認為是CAS Server根據用戶名密碼生成的一張票，存在server端
Ticket-granting cookie (TGC) ：其實就是一個cookie，存放用戶身份信息，由server發給client端
Service ticket (ST) ：由TGT生成的一次性票據，用於驗證，只能用一次。相當於server發給client一張票，然後client拿著這是個票再來找server驗證，看看是不是server簽發的。就像是我給了你一張我的照片，然後你拿照片再來問我，這個照片是不是你。。。沒錯，就是這么無聊。
安全性
TGC安全性：
對於一個 CAS 用戶來說，最重要是要保護它的 TGC，如果 TGC 不慎被 CAS Server 以外的實體獲得，Hacker 能夠找到該 TGC，然後冒充 CAS 用戶訪問所有授權資源。從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。TGT 的存活周期默認為 120 分鍾。
ST安全性：
ST（Service Ticket）是通過 Http 傳送的，因此網路中的其他人可以 Sniffer 到其他人的 Ticket。CAS 通過以下幾方面來使 ST 變得更加安全：
1、 ST 只能使用一次
CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會清除服務端緩存中的該 Ticket，從而可以確保一個 Service Ticket 不被使用兩次。
2、 ST 在一段時間內失效
CAS 規定 ST 只能存活一定的時間，然後 CAS Server 會讓它失效。默認有效時間為 5 分鍾。
3、 ST 是基於隨機數生成的
ST 必須足夠隨機，如果 ST 生成規則被猜出，Hacker 就等於繞過 CAS 認證，直接訪問對應的服務。
流程
上圖是3個登錄場景，分別為：第一次訪問www.qian.com、第二次訪問、以及登錄狀態下第一次訪問mail.qian.com。
第一次訪問www.qian.com
標號1： 用戶訪問http://www.qian.com，經過他的第一個過濾器：org.jasig.cas.client.authentication.AuthenticationFilter（cas提供，在web.xml中配置）。主要作用：判斷是否登錄，如果沒有登錄則重定向到認證中心
標號2： www.qian.com發現用戶沒有登錄，則返回瀏覽器重定向地址。
首先可以看到我們請求www.qian.com，之後瀏覽器返回狀態碼302，然後讓瀏覽器重定向到cas.qian.com並且通過get的方式添加參數service，該參數目的是登錄成功之後會要重定向回來，因此需要該參數。並且你會發現，其實server的值就是編碼之後的我們請求www.qian.com的地址。
標號3： 瀏覽器接收到重定向之後發起重定向，請求cas.qian.com。
標號4： 認證中心cas.qian.com接收到登錄請求，返回登陸頁面。
上圖就是標號3的請求，以及標號4的響應。請求的URL是標號2返回的URL。之後認證中心就展示登錄的頁面，等待用戶輸入用戶名密碼。
標號5： 用戶在cas.qian.com的login頁面輸入用戶名密碼，提交。
標號6 ：伺服器接收到用戶名密碼，則驗證是否有效，驗證邏輯可以使用cas-server提供現成的，也可以自己實現。
上圖就是標號5的請求，以及標號6的響應了。當cas.qian.com即csa-server認證通過之後，會返回給瀏覽器302，重定向的地址就是Referer中的service參數對應的值。後邊並通過get的方式挾帶了一個ticket令牌，這個ticket就是ST（數字3處）。同時會在Cookie中設置一個CASTGC，該cookie是網站cas.qian.com的cookie，只有訪問這個網站才會攜帶這個cookie過去。
Cookie中的CASTGC：向cookie中添加該值的目的是當下次訪問cas.qian.com時，瀏覽器將Cookie中的TGC攜帶到伺服器，伺服器根據這個TGC，查找與之對應的TGT。從而判斷用戶是否登錄過了，是否需要展示登錄頁面。TGT與TGC的關系就像SESSION與Cookie中SESSIONID的關系。點擊這里了解Java如何操作Cookie。
TGT：Ticket Granted Ticket（俗稱大令牌，或者說票根，他可以簽發ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根據他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默認是用一次就生效了。也就是上面數字3處的ticket值。
標號7 ：瀏覽器從cas.qian.com哪裡拿到ticket之後，就根據指示重定向到www.qian.com，請求的url就是上面返回的url。
標號8 ：www.qian.com在過濾器中會取到ticket的值，然後通過http方式調用cas.qian.com驗證該ticket是否是有效的。
標號9 ：cas.qian.com接收到ticket之後，驗證，驗證通過返回結果告訴www.qian.com該ticket有效。
標號10 ：www.qian.com接收到cas-server的返回，知道了用戶合法，展示相關資源到用戶瀏覽器上。
第二次訪問www.qian.com
標號11 ：用戶發起請求，訪問www.qian.com。會經過cas-client，也就是過濾器，因為第一次訪問成功之後www.qian.com中會在session中記錄用戶信息，因此這里直接就通過了，不用驗證了。
標號12 ：用戶通過許可權驗證，瀏覽器返回正常資源。
訪問mail.qian.com
標號13 ：用戶在www.qian.com正常上網，突然想訪問mail.qian.com，於是發起訪問mail.qian.com的請求。
標號14 ：mail.qian.com接收到請求，發現第一次訪問，於是給他一個重定向的地址，讓他去找認證中心登錄。
上圖可以看到，用戶請求mail.qian.com，然後返回給他一個網址，狀態302重定向，service參數就是回來的地址。
標號15 ：瀏覽器根據14返回的地址，發起重定向，因為之前訪問過一次了，因此這次會攜帶上次返回的Cookie：TGC到認證中心。
標號16 ：認證中心收到請求，發現TGC對應了一個TGT，於是用TGT簽發一個ST，並且返回給瀏覽器，讓他重定向到mail.qian.com
可以發現請求的時候是攜帶Cookie：CASTGC的，響應的就是一個地址加上TGT簽發的ST也就是ticket。
標號17 ：瀏覽器根據16返回的網址發起重定向。
標號18 ：mail.qian.com獲取ticket去認證中心驗證是否有效。
標號19 ：認證成功，返回在mail.qian.com的session中設置登錄狀態，下次就直接登錄。
標號20 ：認證成功之後就反正用想要訪問的資源了。
配置filter
我們需要在應用的web.xml文件中配置四個Filter，這四個Filter必須按照固定的順序來進行配置，而且它們必須配置在應用的其它Filter之前。它們的先後順序要求如下：
1、AuthenticationFilter
casServerLoginUrl用來指定Cas Server登錄地址，serverName或service用來指定認證成功後需要跳轉地址。
2、TicketValidationFilter
請求通過AuthenticationFilter的認證之後，如果請求中攜帶了參數ticket則將會由TicketValidationFilter來對攜帶的ticket進行校驗。 TicketValidationFilter只是對驗證ticket的這一類Filter的統稱，其並不對應Cas Client中的一個具體類型。Cas Client中有多種驗證ticket的Filter，
都繼承自，它們的驗證邏輯都是一致的，都有實現，不同的是使用的TicketValidator不一樣。這里我們使用Cas10TicketValidationFilter，也可以使用或Saml11TicketValidationFilter。
3、
用於將每一個請求對應的HttpServletRequest封裝為其內部定義的CasHttpServletRequestWrapper，該封裝類將利用之前保存在Session或request中的Assertion對象重寫HttpServletRequest的getUserPrincipal()、getRemoteUser()和isUserInRole()方法。
這樣在我們的應用中就可以非常方便的從HttpServletRequest中獲取到用戶的相關信息
4、AssertionThreadLocalFilter
AssertionThreadLocalFilter可以在應用的其它地方獲取Assertion對象，找個過濾器會把Assertion對象存放到當前的線程變數中，我們在程序的任何地方都可以從線程變數中獲取當前Assertion，就不需要再從Session或request中進行解析了。這個線程變數是由AssertionHolder持有的，我們在獲取當前的 Assertion時也只需要通過AssertionHolder的getAssertion()方法獲取即可
❸ 終於搞明白了，CAS單點登錄原理解析！！
真的如老話所說，「沒有笨的人，只有懶得人」。前段時間時間需要和其他項目做cas集成，於是乎在網上找了幾篇教程看了一下，好了，很簡單，學會了，開搞（自以為研究明白）。集成完事了，登錄成功了，自以為這就過去了。然而，沒過幾天就出bug了，這下慘了，當初沒有好好學出了問題都不知道咋解決。無奈，只得靜下心來好好學習一番（當初太懶付出的代價）。原理其實很簡單的，只要耐下心來好好研究終會搞懂的。
先看下圖
那麼是如何驗證用戶是否登錄過呢？
如果session中包含「 const_cas_assertion 」屬性，說明已經登錄，跳過此過濾器執行配置的其他過濾器；
如果ticket參數不為空（可能是登陸後跳轉回來的），跳過此過濾器，執行TicketValidationFilter 驗證ticket；
如果前兩個條件都不滿足，重定向到cas服務端，返回登錄頁面進行登錄操作。
Cookie中的CASTGC：向cookie中添加該值的目的是當下次訪問 www.cas.server.com 時，瀏覽器將Cookie中的TGC攜帶到伺服器，伺服器根據這個TGC，查找與之對應的TGT。從而判斷用戶是否登錄過了，是否需要展示登錄頁面。TGT與TGC的關系就像SESSION與Cookie中SESSIONID的關系。
TGT：Ticket Granted Ticket（俗稱大令牌，或者說票根，他可以簽發ST）。
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根據他可以找到TGT。
ST：Service Ticket （小令牌），是虧吵喊TGT生成的，默認是用一次就生效了。也就是上面的銷野ticket值。
為了加深理解，也為了以後作參考，整理記錄。另外，還要說一句碰滑，不要偷懶，多動手多動腦！
❹ 為什麼有了tgt還要st
TGT是茄敬塵CAS為用戶簽發的登錄票據，擁有了TGT，用戶就可以證明自己在CAS成功登錄過。
TGT是CAS為用戶簽發的登錄ticket，也是顫禪用於驗證用戶登錄成功的唯一方式。TGT封裝了Cookie值以及Cookie值對應的用戶信息，CAS通過Cookie值（TGC）為key查詢緩存中有無TGT（TGC：TGT（key：value）），如果有的話就說明用戶稿旁已經登錄成。
ST是當用戶訪問某一服務時提供的ticket。用戶在訪問其他服務時，發現沒有cookie或ST，那麼就會302到CAS伺服器獲取ST。然後會攜帶著ST302回來。
❺ cas認證是什麼認證
CAS是CentralAuthenticationService的縮寫，中央認證服務，一種獨立開放指令協議。
CAS是Yale大學發起的一個開源項目，旨在為Web應用系統提供一種可靠的單點登錄方法，CAS在2004年12月正式成為JA-SIG的一個項目。
特點
1、開源的企業級單點登錄解決方案。
2、CASServer為需要獨立部署的Web應用。
3、CASClient支持非常多的客戶端(這里指單點登錄系統中的各個Web應用)，包括Java,.Net,PHP,Perl,Apache,uPortal,Ruby等。
原理和協議
從結構上看，CAS包含兩個部分：CASServer和CASClient。CASServer需要獨立部署，主要負責對用戶的認證工作；
CASClient負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到CASServer。圖是CAS最基本的協議過程：
CASClient與受保護的客戶端應用部署在一起，以Filter方式保護受保護的資源。對於訪問受保護資源的每個Web請求，CASClient會分析該請求的Http請求中是否包含ServiceTicket，
如果沒有，則說明當前用歲豎戶尚未登錄，於是將請求重定向到指定好的CASServer登錄地址，並傳遞Service（也就是要訪問的目的資源地址），以便登錄成功過後轉回該地址。
用戶在第3步中輸入認證信息，如果登錄成功，CASServer隨機產生一個相當長度、唯一、不可偽造的ServiceTicket，並緩存以待將來驗證，
之後系統自動重定向到Service所在地址，並為客戶端瀏覽器設置一個TicketGrantedCookie（TGC），
CASClient在拿到Service和新產生的Ticket過後，在第5，6步中與CASServer進行身份核實，以確保ServiceTicket的合法性。
在該協議中，所有與CAS的交互均採用SSL協議，確保，ST和TGC的安全性。協議工作過程中會有2次重定向的過程，但是CASClient與CASServer之間進行Ticket驗證的過程對於用戶是透明的。
另外，CAS協議中還提供了Proxy（代理）模式，以適應更加高級、復雜的應用場景，具體介紹可以參考CAS官方網站上的相關文檔。
(5)CAS50清除TGC緩存擴展閱讀
使用CAS在Tomcat中實現單點登錄中部署客戶端應用
單點登錄的目的是為了讓多個相關聯的應用使用相同的登錄過程，本文在講解過程中構造2個簡單的應用，分別以casTest1和casTest2來作為示例，它們均只有一個頁面，顯示歡迎信息和當前登錄用戶名。
這2個應用使用同一套登錄信息，並且只有登錄過的用戶才能訪問，通過本文的配置，實現單點登錄，即只需登錄一次就可以訪問這兩個應用。
與CASServer建立信任關系
假設CASServer單獨部署在一台機器A，而客戶端應用部署在機器B上，由於客戶端應用與CASServer的通信採用SSL，因此，需要在A與B的JRE之間建立信任關系。
首先與A機器一樣，要生成B機器上的證書，配置Tomcat的SSL協議。
其次，下載http://blogs.sun.com/andreas/entry/no_more_unable_to_find的InstallCert.java，運行「javaInstallCertcompA:8443」命令，
並且在接下來出現的詢問中輸入1。
這樣，就將A添加到了B的truststore中。如果多個客戶端應用分別部署在不同機器上，那麼每個機器都需要與CASServer所在機器建立信任關系。
配置CASFilter
准備好應用casTest1和casTest2過後，分別部署在B和C機器上，由於casTest1和casTest2，B和C完全等同，我們乎和大以casTest1在B機器上的配置做介紹，
假設A和B的域名分別為domainA和domainB。
將cas-client-java-2.1.1.zip改名為cas-client-java-2.1.1.jar並拷貝到casTest1/WEB-INF/lib目錄下，修棚春改web.xml文件，添加CASFilter，如清單10所示：
清單10.添加CASFilter
<web-app>...<filter><filter-name>CASFilter</filter-name>
<filter-class>e.yale.its.tp.cas.client.filter.CASFilter</filter-class><init-param>
<param-name>e.yale.its.tp.cas.client.filter.loginUrl</param-name><param-value>https://domainA:8443/cas/login</param-value>
</init-param><init-param>
<param-name>e.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://domainA:8443/cas/serviceValidate</param-value></init-param>
<init-param><param-name>e.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>domainB:8080</param-value></init-param>
</filter><filter-mapping>
<filter-name>CASFilter</filter-name>
<url-pattern>/protected-pattern/*</url-pattern></filter-mapping>
</web-app>
對於所有訪問滿足casTest1/protected-pattern/路徑的資源時，都要求到CASServer登錄，如果需要整個casTest1均受保護，可以將url-pattern指定為「/*」。
從清單10可以看到，我們可以為CASFilter指定一些參數，並且有些是必須的，表格1和表格2中分別是必需和可選的參數：
表格1.CASFilter必需的參數
表格2.CASFilter可選參數
傳遞登錄用戶名
CAS在登錄成功過後，會給瀏覽器回傳Cookie，設置新的到的ServiceTicket。但客戶端應用擁有各自的Session，我們要怎麼在各個應用中獲取當前登錄用戶的用戶名呢？
CASClient的Filter已經做好了處理，在登錄成功後，就可以直接從Session的屬性中獲取，如清單11所示：
清單11.在Java中通過Session獲取登錄用戶名
1//以下兩者都可以
2session.getAttribute(CASFilter.CAS_FILTER_USER);
3session.getAttribute("e.yale.its.tp.cas.client.filter.user");
在JSTL中獲取用戶名的方法如清單12所示：
清單12.通過JSTL獲取登錄用戶名
1<c:outvalue="${sessionScope[CAS:'e.yale.its.tp.cas.client.filter.user']}"/>
另外，CAS提供了一個CASFilterRequestWrapper類，該類繼承自HttpServletRequestWrapper，主要是重寫了getRemoteUser()方法，
只要在前面配置CASFilter的時候為其設置「e.yale.its.tp.cas.client.filter.wrapRequest」參數為true，就可以通過getRemoteUser（）方法來獲取登錄用戶名，具體方法如清單13所示：
清單13.通過CASFilterRequestWrapper獲取登錄用戶名
=newCASFilterRequestWrapper(request);2out.println("Thelogonuser:"+reqWrapper.getRemoteUser());
❻ 【單點登錄】CAS協議
CAS協議是專門為CAS開發的一種簡單而強大的基於票據的協議。
CAS涉及到一個或多個客戶端與一個服務端，客戶端嵌入CASified應用程序(稱為「CAS服務」)，而CAS伺服器是一個獨立組件:
1.CAS伺服器負責對用戶進行身份驗證並授予對應用程序的訪問權
2.CAS客戶端保護CAS應用程序，並從CAS伺服器檢索被授予用戶的標識。
關鍵概念：
1.存儲在CASTGC cookie中的 TGT (票據授予票據)表示用戶的一個SSO session。
2. ST (服務票證)作為url中的GET參數傳輸，表示由CAS伺服器為特定用戶授予認證應用程序的訪問許可權。
WEB流程：
1.用戶訪問目標應用程序，通過瀏覽器發送GET請求到目標應用
2.目標應用檢測到用戶未認證，則轉發請求到CAS服務端，帶上查詢參數service，值為目標應用地址。
3.CAS服務端檢測用戶發現沒有SSO session 則返回CAS登錄頁面。
4.用戶在CAS登錄頁面填寫登錄表單，提交進行認證。
5.認證成功後CAS服務端創建SSO session,並創態攜建TGT票據到Cookie中 （Set-Cookie:CASTGC=TGT-xxxxxx），並重定向到目標應用程序帶上查詢參數ticket=ST-xxxxx。
6.目標應用發送請求向CAS伺服器驗證ST票據，驗證成功後目標應用創建用戶訪問session,並把sessionID放入cookie中。
7.用戶訪敗閉悄問目標應用通過sessionID獲取到session,登陸成功。
8.用戶訪問其他CAS客戶端應用，其他CAS客戶端重定向請求到CAS伺服器，同步驟2。
9.CAS伺服器檢測到用戶TGT這個cookie,獲取到SSO session，直接認證成功，並重定向到目標應用程序帶上查詢參數ticket=ST-xxxxx。
10.同步驟6，察渣7，成功登陸其他CAS客戶端應用。
❼ 2022-03-10 CAS認證流程
CAS認證流程圖：
(1) 用戶通過瀏洞弊覽器訪問指定瞎和頁面；
(2) 頁面對應的後台進行安全校驗：檢查service-ticket和access token是否存在，若不存在，則 重定向 到CAS伺服器 /cas/login/；
(3) CAS服務納神族器要求用戶提供SSO登錄憑證；
(4) 用戶提供用戶名和密碼給CAS伺服器；
(5) CAS伺服器將service ticket和 service URL返回給後台；
(6) 後台發送驗證請求給CAS伺服器檢驗service ticket和service URL是否匹配；
(7) 若後台得到service ticket和service URL匹配，返回前台瀏覽器，TGC一並存儲到瀏覽器中；
(8) 瀏覽器訪問指定頁面；
❽ 從http驗證流程解析CAS單點登錄
JAVA單點登錄有好多種方式，譬如用cookie的domain做，用中間代理做等等，但都需要自行做許多開發工作。而其中耶魯大學的開源項目CAS提供了一個一站式解決方案，只需很少的擴展即可輕松實現企業級單點登錄。基礎知識網上其他挺多的，這里我就不詳述了。本文通過分析http請求過程中http header，cookie等數據剖析了cas（ 非代理模式，默認驗證邏輯。其他如restletAPI等可擴展邏輯本文不會覆蓋 ）的驗證流程，在開發調試中提供了另一種方便的方式掌控整個流程的關鍵點 。
TGT: cas服務端生成的每個用戶唯一的ticket。
TGC: cas服務端根據TGT生成的每個用戶的cookie,其value是TGT。
ST: cas服務端根據每個應用，每個用戶生成的一個ticket,驗證一次就銷毀。
Shiro: JAVA許可權管理框架
下面將通過兩個客戶端應用A、B分別跟cas server端交互來詳述整個交互流程。本文基於CAS 4.x。 CAS 5.X默認邏輯一致，只不過通過spring boot進行了重新模塊劃分。
Cas client攔截請求發現session中無cas assertion(其實就是用戶名和ticket)並且沒有ST則跳轉CAS server(本項目由於用了shiro重寫攔截邏輯所以是判斷shiro中有沒有保存驗證後的用戶信息), server端發現無TGC跳轉配置的CAS登陸URL
Response返回302指示重定向。同時可見response返回兩個cookie: CASPRIVACY=和CASTGC= TGT-1--cas01.example.org
也就是說：cas server端驗證通過後產生ST並在location URL後面賦給ticket。此時往客戶端瀏覽器寫入TGC,並且指示瀏覽器重定向到location位置，其正是客戶端應用驗證ST的路徑。
此步驟產生2個ticket: TGT,ST;產生一個cookie:TGC,此cookie是通過用戶私密信息與TGT加密生成。
此時客戶端應用由於受到shiro的保護，request cookie中就不是JSESSIONID而是shiro的SessionId：sid，uuid模式，其與第一步中的sid一致。
Response返回302指示重定向到另一個頁面(第一次訪問的頁面或者shiro配置的successful url)，同時可見生成了新的session和sessionID。同時可見response返回2個cookie: JSESSIONID,為servlet容器產生的session id，其為location中的jsessionid；rememberMe,為shiro為自動登錄配置的。
此步驟驗證ST後（通過url connection去cas server驗證ST）如果通過則重定向到新頁面(第一次訪問的頁面或者shiro配置的successful url)產生一個新的容器session id。（為何要重新創建session，因為其會在新的session中保存登陸了客戶端應用的憑證CAS Assertion,其為客戶端驗證ST後返回的）到了這步驟以後屬於客戶端自身的邏輯。CAS作用到此為止。
可以看到這次直接就訪問了，也沒有經過驗證ticket和與cas服務端交互。此是因為session中已經保存了cas assertion，所以算作登陸了。
可見產生了新的shiro session，並提示跳轉CAS服務端登陸URL。
可見並沒有要求登陸而是直接就提示跳轉到location的URL做驗證並產生了一個新的ST。這是因為CAS服務端讀取了A應用登陸後在瀏覽器生成的TGC, request cookie中帶入了（下圖可以看到），從而認為用戶已經登陸，所以直接生成ST，並要求重定向到客戶端應用B去驗證。
步驟同A應用。
如圖
如下圖：
可見登出時發生四次請求。
直接訪問CAS server端的登出url。Cookie中有CASTGC和server端的JSESSIONID。
返回中CASTGC清空，CASPRIVACY清空。 此時說明server端已經清除了A應用的ST和瀏覽器的CASTGC
跳轉到了客戶端應用，發現新創建了shiro session（sid）和servlet容器session（JSESSIONID）
並且發現rememberMe和SID的cookie都被換成deleteMe啦。 此為shiro的loginout攔截器乾的好事。
正常訪問首頁，但是因為沒登陸所以提示要重定向到CAS服務端去登陸。（如果有了首頁就改為跳轉到首頁）
同原來步驟。
總的來說，cas （非代理模式，默認驗證邏輯） 是用一個cookie(TGC), N個session(N個子系統session，其中存儲了cas receipt)來保證各應用的統一登錄。