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.qiandu.com、第二次訪問、以及登錄狀態下第壹次訪問mail.qiandu.com。
第壹次訪問www.qiandu.com
標號1： 用戶訪問，經過他的第壹個過濾器：org.jasig.cas.client.authentication.AuthenticationFilter（cas提供，在web.xml中配置）。主要作用：判斷是否登錄，如果沒有登錄則重定向到認證中心
標號2： www.qiandu.com發現用戶沒有登錄，則返回瀏覽器重定向地址。
首先可以看到我們請求www.qiandu.com，之後瀏覽器返回狀態碼302，然後讓瀏覽器重定向到cas.qiandu.com並且通過get的方式添加參數service，該參數目的是登錄成功之後會要重定向回來，因此需要該參數。並且妳會發現，其實server的值就是編碼之後的我們請求www.qiandu.com的地址。
標號3： 瀏覽器接收到重定向之後發起重定向，請求cas.qiandu.com。
標號4： 認證中心cas.qiandu.com接收到登錄請求，返回登陸頁面。
上圖就是標號3的請求，以及標號4的響應。請求的URL是標號2返回的URL。之後認證中心就展示登錄的頁面，等待用戶輸入用戶名密碼。
標號5： 用戶在cas.qiandu.com的login頁面輸入用戶名密碼，提交。
標號6 ：服務器接收到用戶名密碼，則驗證是否有效，驗證邏輯可以使用cas-server提供現成的，也可以自己實現。
上圖就是標號5的請求，以及標號6的響應了。當cas.qiandu.com即csa-server認證通過之後，會返回給瀏覽器302，重定向的地址就是Referer中的service參數對應的值。後邊並通過get的方式挾帶了壹個ticket令牌，這個ticket就是ST（數字3處）。同時會在Cookie中設置壹個CASTGC，該cookie是網站cas.qiandu.com的cookie，只有訪問這個網站才會攜帶這個cookie過去。
Cookie中的CASTGC：向cookie中添加該值的目的是當下次訪問cas.qiandu.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.qiandu.com哪裏拿到ticket之後，就根據指示重定向到www.qiandu.com，請求的url就是上面返回的url。
標號8 ：www.qiandu.com在過濾器中會取到ticket的值，然後通過驗證該ticket是否是有效的。
標號9 ：cas.qiandu.com接收到ticket之後，驗證，驗證通過返回結果告訴www.qiandu.com該ticket有效。
標號10 ：www.qiandu.com接收到cas-server的返回，知道了用戶合法，展示相關資源到用戶瀏覽器上。
第二次訪問www.qiandu.com
標號11 ：用戶發起請求，訪問www.qiandu.com。會經過cas-client，也就是過濾器，因為第壹次訪問成功之後www.qiandu.com中會在session中記錄用戶信息，因此這裏直接就通過了，不用驗證了。
標號12 ：用戶通過權限驗證，瀏覽器返回正常資源。
訪問mail.qiandu.com
標號13 ：用戶在www.qiandu.com正常上網，突然想訪問mail.qiandu.com，於是發起訪問mail.qiandu.com的請求。
標號14 ：mail.qiandu.com接收到請求，發現第壹次訪問，於是給他壹個重定向的地址，讓他去找認證中心登錄。
上圖可以看到，用戶請求mail.qiandu.com，然後返回給他壹個網址，狀態302重定向，service參數就是回來的地址。
標號15 ：瀏覽器根據14返回的地址，發起重定向，因為之前訪問過壹次了，因此這次會攜帶上次返回的Cookie：TGC到認證中心。
標號16 ：認證中心收到請求，發現TGC對應了壹個TGT，於是用TGT簽發壹個ST，並且返回給瀏覽器，讓他重定向到mail.qiandu.com
可以發現請求的時候是攜帶Cookie：CASTGC的，響應的就是壹個地址加上TGT簽發的ST也就是ticket。
標號17 ：瀏覽器根據16返回的網址發起重定向。
標號18 ：mail.qiandu.com獲取ticket去認證中心驗證是否有效。
標號19 ：認證成功，返回在mail.qiandu.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，
都繼承自AbstractTicketValidationFilter，它們的驗證邏輯都是壹致的，都有AbstractTicketValidationFilter實現，不同的是使用的TicketValidator不壹樣。這裏我們使用Cas10TicketValidationFilter，也可以使用Cas20ProxyReceivingTicketValidationFilter或Saml11TicketValidationFilter。
3、HttpServletRequestWrapperFilter
?HttpServletRequestWrapperFilter用於將每壹個請求對應的HttpServletRequest封裝為其內部定義的CasHttpServletRequestWrapper，該封裝類將利用之前保存在Session或request中的Assertion對象重寫HttpServletRequest的getUserPrincipal()、getRemoteUser()和isUserInRole()方法。
? 這樣在我們的應用中就可以非常方便的從HttpServletRequest中獲取到用戶的相關信息
4、AssertionThreadLocalFilter
AssertionThreadLocalFilter可以在應用的其它地方獲取Assertion對象，找個過濾器會把Assertion對象存放到當前的線程變量中，我們在程序的任何地方都可以從線程變量中獲取當前Assertion，就不需要再從Session或request中進行解析了。這個線程變量是由AssertionHolder持有的，我們在獲取當前的 Assertion時也只需要通過AssertionHolder的getAssertion()方法獲取即可