1、什麼是單點登陸（SSO）
單點登陸主要用於多系統集成，即在多個系統中，用戶只須要到一箇中央服務器登陸一次便可訪問這些系統中的任何一個，無須屢次登陸。html
單點登陸（Single Sign On），簡稱爲 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。java
2、web系統如何實現單點登陸
目前已經有了成熟的單點登陸實現方案，好比CAS，咱們只要在web系統中應用單點登陸方案CAS便可。(主要涉及到註冊登陸驗證等模塊的改動)。git
3、什麼是CAS
CAS (Central Authentication Service) 是耶魯 Yale 大學發起的一個java開源項目，旨在爲 Web應用系統提供一種可靠的 單點登陸 解決方案（ Web SSO ）， CAS 具備如下特色：github
-
- 開源的企業級單點登陸解決方案；
- CAS Server 爲須要獨立部署的 Web 應用----一個獨立的Web應用程序(cas.war)。 ；
- CAS Client 支持很是多的客戶端 ( 指單點登陸系統中的各個 Web 應用 ) ，包括 Java, .Net, PHP, Perl, 等。
CAS在2004年12月成立Jasig項目，因此也叫JA-SIG CAS。web
官網1：https://apereo.github.io/cas/5.2.x/index.html
官網2： https://www.apereo.org/projects/cas/about-casspring
論壇：http://jasig.275507.n4.nabble.com/Jasig-CAS-f275508.html數據庫
github：https://github.com/apereo/cas瀏覽器
開發者快捷資源：http://developer.jasig.org/緩存
下載連接：https://www.apereo.org/projects/cas/download-cas
官網開發文檔：https://apereo.github.io/cas/5.2.x/installation/Configuring-Commandline-Shell.html
中文開發文檔：http://www.cassso-china.cn/apereo_github_cas_5.2//apereo.github.io/cas/5.2.x/安全
4、CAS原理
從結構上看， CAS 包含兩個部分： CAS Server 和 CAS Client 。
一、CAS Server
CAS Server 須要獨立部署，主要負責對用戶的認證工做， 它會處理用戶名 / 密碼等憑證 (Credentials) 。
CAS Server 負責完成對用戶的認證工做， 須要獨立部署。而且有不止一種 CAS Server 的實現， Yale CAS Server 和 ESUP CAS Server 都是很不錯的選擇。
CAS Server 會處理用戶名 / 密碼等憑證 (Credentials) ，它可能會到數據庫檢索一條用戶賬號信息，也可能在 XML 文件中檢索用戶密碼，對這種方式， CAS 均提供一種靈活但同一的接口 / 實現分離的方式， CAS 到底是用何種認證方式，跟 CAS 協議是分離的，也就是，這個認證的實現細節能夠本身定製和擴展。
二、CAS Client
CAS Client 部署在客戶端， 負責處理本地 Web 應用（客戶端）受保護資源的訪問請求，而且當須要對請求方進行身份認證時，重定向到 CAS Server 進行認證 。
CAS Client 負責部署在客戶端（注意，是指 Web 應用），原則上， CAS Client 的部署意味着，當有對本地 Web 應用的受保護資源的訪問請求，而且須要對請求方進行身份認證， Web 應用再也不接受任何的用戶名密碼等相似的 Credentials ，而是重定向到 CAS Server 進行認證。
目前， CAS Client 支持（某些在完善中）很是多的客戶端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客戶端，幾乎能夠這樣說， CAS 協議可以適合任何語言編寫的客戶端應用。
三、CAS相關詞彙和概念
(後面代碼小節會詳細介紹，這裏初步瞭解便可)
TGC(ticket-granting cookie) —— 受權的票據證實，由 CAS Server 經過 SSL 方式發送給終端用戶；
KDC( Key Distribution Center ) —— 密鑰發放中心；
ST (Service ticket) —— 服務票據， 由 KDC 的 TGS 發放， ST 只能被嘗試驗證一次。 任何一臺 Workstation 都須要擁有一張有效的 Service Ticket 才能訪問域內部的應用 (Applications) 。 若是能正確接收 Service Ticket ，說明在 CASClient-CASServer 之間的信任關係已經被正確創建起來，一般爲一張數字加密的證書；
Ticket Granting tieckt(TGT) —— 票據受權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，之後申請各類其餘服務票據 (ST) 便沒必要再向 KDC 提交 Credentials （憑證或身份認證信息 ) ；
Authentication Service (AS) —— 認證服務，索取 Crendential ，發放 TGT ；
Ticket-Granting Service (TGS) —— 票據受權服務，索取 TGT ，發放 ST 。
四、CAS協議和工做流程
下圖是 CAS 基礎協議：
（1）CAS Client 與受保護的客戶端應用部署在一塊兒，以 Filter 方式保護受保護的資源。對於訪問受保護資源的每一個 Web 請求， CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket （ ST ）和 Ticket Granting tieckt(TGT) ，若是沒有，則說明當前用戶還沒有登陸，因而將請求重定向到指定好的 CAS Server 登陸地址，並傳遞 Service （也就是要訪問的目的資源地址），以便登陸成功事後轉回該地址。用戶在第 3 步中輸入認證信息，若是登陸成功， CAS Server 隨機產生一個至關長度、惟1、不可僞造的 Service Ticket ，並緩存以待未來驗證，以後系統自動重定向到 Service 所在地址，併爲客戶端瀏覽器設置一個 Ticket Granted Cookie （ TGC ）， CAS Client 在拿到 Service 和新產生的 Ticket 事後，在第 5 ， 6 步中與 CAS Server 進行身份覈實，以確保 Service Ticket 的合法性。
（2）在該協議中，全部與 CAS 的交互均採用 SSL 協議確保 ST 和 TGC 的安全性。協議工做過程當中會有 2 次重定向的過程，可是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的。
（3）CAS 如何實現 SSO
當用戶訪問另外一服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，而後作下面的事情：
1) 若是 User 的持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果；
2) 若是 TGC 失效，那麼用戶仍是要從新認證 ( 走基礎協議圖的 Step3) 。
另外，CAS 協議中還提供了 Proxy （代理）模式，以適應更加高級、複雜的應用場景，具體介紹能夠參考 CAS 官方網站上的相關文檔。
五、cas的驗證流程
（1）用戶瀏覽受系統保護的URL。
（2）CAS Client服務端收到請求，Filter攔截該請求，在Filter中判斷該用戶是否已經登錄，若是已經登錄，就直接進入系統，不然，將請求轉發到CAS Server服務端的LoginURL。
（3）在LoginURL中會獲取到用戶的Cookie，檢驗用戶是否已經在其餘相關使用SSO的系統登錄成功。若是已經在其餘的系統登錄了，則將請求轉回 CAS Client，而且帶回一個ticket, CAS Client再次發送請求到ValidateURL。不然，系統提示用戶輸入ID和PASSWORD。
（4）提交後請求到ValidateURL，CAS Server驗證ticket的有效性。而後返回結果給CAS Client。若是ticket有效，則CAS Client應讓該用戶瀏覽受保護的資源。不然，重定向到登錄頁面，提示用戶輸入ID和PASSWORD。
（5）校驗ID和Password是否匹配。如不匹配，再次要求用戶輸入ID和PASSWORD。不然，CAS Server記錄用戶登錄成功。並向瀏覽器回送Cookie，記錄用戶已經登錄成功。若是瀏覽器不支持Cookie，則沒法實現單點登錄。
六、用戶訪問流程實例
用戶第一次訪問一個CAS 服務的客戶web 應用時（例如訪問URL ：http://192.168.1.90:8081/web1 ），部署在客戶web 應用的cas AuthenticationFilter ，會截獲此請求，生成service 參數，而後redirect 到CAS 服務的login 接口，url爲https://cas:8443/cas/login?service=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2F ，認證成功後，CAS 服務器會生成認證cookie ，寫入瀏覽器，同時將cookie 緩存到服務器本地，CAS 服務器還會根據service 參數生成ticket，ticket 會保存到服務器，也會加在url 後面，而後將請求redirect 回客戶web 應用，url 爲http://192.168.1.90:8081/web1/?ticket=ST-5-Sx6eyvj7cPPCfn0pMZuMwnbMvxpCBcNAIi6-20 。
這時客戶端的AuthenticationFilter 看到ticket 參數後，會跳過，由其後面的TicketValidationFilter 處理，TicketValidationFilter 會利用httpclient 工具訪問cas 服務的/serviceValidate 接口, 將ticket 、service 都傳到此接口，由此接口驗證ticket 的有效性，TicketValidationFilter 若是獲得驗證成功的消息，就會把用戶信息寫入web 應用的session裏。
至此爲止，SSO 會話就創建起來了，之後用戶在同一瀏覽器裏訪問此web 應用時，AuthenticationFilter 會在session 裏讀取到用戶信息，因此就不會去CAS 認證，若是在此瀏覽器裏訪問別的web 應用時，AuthenticationFilter 在session 裏讀取不到用戶信息，會去CAS 的login 接口認證，但這時CAS 會讀取到瀏覽器傳來的cookie ，因此CAS 不會要求用戶去登陸頁面登陸，只是會根據service 參數生成一個ticket ，而後再和web 應用作一個驗證ticket 的交互。
5、代碼層次如何實現CAS
知道工做原理和流程以後咱們來看看應該怎麼在代碼上實現CAS
通常來講，咱們寫Web應用只須要熟悉這幾個Filter就能夠了，若是不須要https鏈接，連第一個也不用熟悉。可是有人確定會想，這些 Filter怎麼和個人數據庫聯繫起來呢？不用着急，這些Filter並不直接處理用戶的認證，也不直接處理用戶的受權，而是把它們交給了認證管理器和決 策管理器。
對於這兩種管理器，那也是不須要咱們寫代碼的，Acegi也提供了現成的類。那麼你們又奇怪了：又是現成的，那怎麼和個人數據庫關聯起來呢？別 着急，其實這兩個管理器本身也不作事，認證管理器把任務交給了Provider，而決策管理器則把任務交給了Voter，以下圖：
如今我要告訴大家，這裏的Provider和Voter也是不須要咱們寫代碼的。不要崩潰，快到目標了。Acegi提供了多個Provider 的實現類，也就是說CAS的認證方式有不少種，咱們能夠到數據庫檢索一條用戶賬號信息，也可能在 XML 文件中檢索用戶密碼， 對於不少種方式，CAS 均提供一種靈活但同一的接口 / 實現分離的方式， CAS 到底是用何種認證方式，能夠由咱們本身來決定，也就是，這個認證的實現細節能夠本身定製和擴展。例如若是咱們想用數據庫來儲存用戶的認證數據，那麼咱們就選擇DaoAuthenticationProvider。對於Voter，咱們通常選擇 RoleVoter就夠用了，它會根據咱們配置文件中的設置來決定是否容許某一個用戶訪問制定的Web資源。
而DaoAuthenticationProvider也是不直接操做數據庫的，它把任務委託給了UserDetailService，以下圖：
而咱們要作的，就是實現這個UserDetailService。說了這麼多總算是引出了咱們開發中的關鍵，那就是咱們要實現本身的UserDetailService，它就是鏈接咱們的數據庫和Acegi的橋樑。UserDetailService的要求也很簡 單，只須要一個返回org.springframework.security.userdetails.User對象的 loadUserByUsername(String userName)方法。所以，怎麼設計數據庫均可以，無論咱們是用一個表仍是兩個表仍是三個表，也無論咱們是用戶-受權，仍是用戶-角色-受權，仍是用 戶-用戶組-角色-受權，這些具體的東西Acegi通通不關心，它只關心返回的那個User對象，至於怎麼從數據庫中讀取數據，那就是咱們本身的事了。
反過來再看看上面的過程，咱們發現，即便咱們要作的只是實現本身的UserDetailService類，可是咱們不得不在Spring中配置那一 大堆的Bean，包括幾個Filter，幾個Manager，幾個Provider和Voter，而這些配置每每都是重複的無謂的。好在Acegi 2.0也認識到了這個問題，因此，它設計了一個<http>標籤，讓Acegi的配置獲得了簡化。
在後面具體的部署實施中咱們再來詳細講這些細節。
6、CAS的相關接口和處理邏輯
一、Ticket介紹
概念介紹
CAS的核心就是其Ticket，及其在Ticket之上的一系列處理操做。CAS的主要票據有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0協議中就有的票據，PGT、PGTIOU、PT是CAS2.0協議中有的票據。
TGT（Ticket Grangting Ticket）
TGT是CAS爲用戶簽發的登陸票據，擁有了TGT，用戶就能夠證實本身在CAS成功登陸過。TGT封裝了Cookie值以及此Cookie值對應的用戶信息。用戶在CAS認證成功後，CAS生成cookie，寫入瀏覽器，同時生成一個TGT對象，放入本身的緩存，TGT對象的ID就是cookie的值。當HTTP再次請求到來時，若是傳過來的有CAS生成的cookie，則CAS以此cookie值爲key查詢緩存中有無TGT ，若是有的話，則說明用戶以前登陸過，若是沒有，則用戶須要從新登陸。
ST（Service Ticket）
ST是CAS爲用戶簽發的訪問某一service的票據。用戶訪問service時，service發現用戶沒有ST，則要求用戶去CAS獲取ST。用戶向CAS發出獲取ST的請求，若是用戶的請求中包含cookie，則CAS會以此cookie值爲key查詢緩存中有無TGT，若是存在TGT，則用此TGT簽發一個ST，返回給用戶。用戶憑藉ST去訪問service，service拿ST去CAS驗證，驗證經過後，容許用戶訪問資源。
PGT（Proxy Granting Ticket）
Proxy Service的代理憑據。用戶經過CAS成功登陸某一Proxy Service後，CAS生成一個PGT對象，緩存在CAS本地，同時將PGT的值（一個UUID字符串）回傳給Proxy Service，並保存在Proxy Service裏。Proxy Service拿到PGT後，就能夠爲Target Service（back-end service）作代理，爲其申請PT。
PGTIOU（Proxy Granting Ticket IOU）
PGTIOU是CAS協議中定義的一種附加票據，它加強了傳輸、獲取PGT的安全性。
PGT的傳輸與獲取的過程：Proxy Service調用CAS的serviceValidate接口驗證ST成功後，CAS首先會訪問pgtUrl指向的https url，將生成的 PGT及PGTIOU傳輸給proxy service，proxy service會以PGTIOU爲key，PGT爲value，將其存儲在Map中；而後CAS會生成驗證ST成功的xml消息，返回給Proxy Service，xml消息中含有PGTIOU，proxy service收到Xml消息後，會從中解析出PGTIOU的值，而後以其爲key，在map中找出PGT的值，賦值給表明用戶信息的Assertion對象的pgtId，同時在map中將其刪除。
PT（Proxy Ticket）
PT是用戶訪問Target Service（back-end service）的票據。若是用戶訪問的是一個Web應用，則Web應用會要求瀏覽器提供ST，瀏覽器就會用cookie去CAS獲取一個ST，而後就能夠訪問這個Web應用了。若是用戶訪問的不是一個Web應用，而是一個C/S結構的應用，由於C/S結構的應用得不到cookie，因此用戶不能本身去CAS獲取ST，而是經過訪問proxy service的接口，憑藉proxy service的PGT去獲取一個PT，而後才能訪問到此應用。
類和方法
CAS Ticket類圖 以下：
TicketGrantingTicket 的 grantServiceTicket方法
方法聲明：public synchronized ServiceTicket grantServiceTicket(final String id,final Service service, final ExpirationPolicy expirationPolicy, final boolean credentialsProvided)
方法描述：
1）生成SerivceTicketImpl
2）更新屬性：
this.previousLastTimeUsed = this.lastTimeUsed;
this.lastTimeUsed = System.currentTimeMillis();
this.countOfUses++;
3）給service對象的principal屬性賦值
4）將service對象放入map services
ServiceTicket 的 grantTicketGrantingTicket方法
方法聲明：
public TicketGrantingTicket grantTicketGrantingTicket(final String id, final Authentication authentication,final ExpirationPolicy expirationPolicy)
方法描述：在CAS3.3對CAS2.0協議的實現中，PGT是由ST簽發的，調用的就是ServiceTicket的grantTicketGrantingTicket方法。方法返回的TicketGrantingTicket對象，表徵的是一個PGT對象，其中的ticketGrantingTicket屬性的值是簽發ST的TGT對象。
TicketGrantingTicket 的 expire方法
方法聲明：void expire()
方法描述：
在CAS的logout接口實現中，要調用TGT對象的expire方法，而後會在緩存中清除此TGT對象。
expire方法的內容：循環遍歷 services 中的Service對象，調用其logoutOfService方法。具體Service實現類中的logoutOfService方法的實現，要通知具體的應用，客戶要退出。
TGT、ST、PGT、PT關係
（1）ST是TGT簽發的。用戶在CAS上認證成功後，CAS生成TGT，用TGT簽發一個ST，ST的ticketGrantingTicket屬性值是TGT對象，而後把ST的值redirect到客戶應用。
（2）PGT是ST簽發的。用戶憑藉ST去訪問Proxy service，Proxy service去CAS驗證ST（同時傳遞PgtUrl參數給CAS），若是ST驗證成功，則CAS用ST簽發一個PGT，PGT對象裏的ticketGrantingTicket是簽發ST的TGT對象。
（3）PT是PGT簽發的。Proxy service代理back-end service去CAS獲取PT的時候，CAS根據傳來的pgt參數，獲取到PGT對象，而後調用其grantServiceTicket方法，生成一個PT對象。
二、認證相關的類和流程
Credentials
用戶提供的用於登陸用的憑據信息，如用戶名/ 密碼、證書、IP 地址、Cookie 值等。好比 UsernamePasswordCredentials ，封裝的是用戶名和密碼。CAS 進行認證的第一步，就是把從UI 或request 對象裏取到的用戶憑據封裝成Credentials 對象，而後交給認證管理器去認證。
AuthenticationHandler
認證Handler, 每種AuthenticationHandler 只能處理一種Credentials ，如AbstractUsernamePasswordAuthenticationHandler 只負責處理 UsernamePasswordCredentials 。
Principal
封裝用戶標識，好比 SimplePrincipal, 只是封裝了用戶名。認證成功後， credentialsToPrincipalResolvers 負責由Credentials 生成 Principal 對象。
CredentialsToPrincipalResolvers
負責由 Credentials 生成 Principal 對象，每種 CredentialsToPrincipalResolvers 只處理 一種Credentials ，好比 UsernamePasswordCredentialsToPrincipalResolver 負責從UsernamePasswordCredentials 中取出用戶名，而後將其賦給生成的 SimplePrincipal 的 ID 屬性。
AuthenticationMetaDataPopulators
負責將 Credentials 的一些屬性賦值給 Authentication 的 attributes 屬性。
Authentication
Authentication是認證管理器的最終處理結果， Authentication 封裝了 Principal ，認證時間，及其餘一些屬性（可能來自 Credentials ）。
AuthenticationManager
認證管理器獲得 Credentials 對象後，負責調度AuthenticationHandler 去完成認證工做，最後返回的結果是 Authentication 對象。
CentralAuthenticationService
CAS 的服務類，對 Web 層提供了一些方法。該類還負責調用 AuthenticationManager 完成認證邏輯。
認證類的序列圖以下：
認證的相關類圖以下：
三、cas server的接口
CAS 服務端總共對外定義了9 個接口，客戶端經過訪問這9 個接口與服務端交互，這9個接口爲：
| 接口 | 說明 |
| /login | 認證接口 |
| /logout | 退出接口，負責銷燬認證cookie |
| /validate | 驗證ticket 用的接口，CAS1.0 定義 |
| /serviceValidate | 驗證ticket 用的接口，CAS2.0 定義，返回xml 格式的數據 |
| /proxy | 支持代理認證功能的接口 |
| /proxyValidate | 支持代理認證功能的接口 |
| /CentralAuthenticationService | 用於和遠程的web services 交互 |
| /remoteLogin（新增） | 認證接口 |
| /directLogin（新增） | 認證接口 |
詳細說明：
/login
錄流程這部分要考慮到不一樣種類用戶憑證的獲取方案，以及客戶應用傳來的service 、gateway 、renew 參數的不一樣取值組合，CAS 爲了實現流程的高度可配置性，採用了spring Web Flow 技術。經過CAS 發佈包裏的login-webflow.xml 、cas-servlet.xml 、applicationContext.xml 這3 個文件能夠進行相關配置。
CAS 默認的登陸處理流程圖以下：
說明：
（1） InitialFlowSetupAction: 是流程的入口。用 request.getContextPath() 的值來設置 cookie 的 Path 值， Cookie 的 path 值是在配置文件裏定義的，但這個 Action 負責將 request.getContextPath() 的值設置爲 Cookie 的 path 值，這是在 cas 部署環境改變的狀況下，靈活地設置 cookie path 的方式；把 cookie 的值以及 service 參數的值放入 requestContext 的 flowscope 裏。
（2）GenerateServiceTicketAction 此 Action 負責根據 service 、 GTC cookie 值生成 ServiceTicket 對象， ServiceTicket 的 ID 就是返回給客戶應用的 ticket 參數，若是成功建立 ServiceTicket ，則轉發到 WarnAction ，若是建立失敗，且 gateway 參數爲 true ，則直接redirect 到客戶應用， 不然則須要從新認證。
（3）viewLoginForm 這是登陸頁面， CAS 在此收集用戶憑證。 CAS 提供的默認實現是 /WEB-INF/view/jsp/simple/ui/casLoginView.jsp 。
（4）bindAndValidate 對應 AuthenticationViaFormAction 的 doBind 方法，該方法負責蒐集登陸頁面上用戶錄入的憑證信息（用戶名、密碼等），而後把這些信息封裝到 CAS 內部的 Credentials 對象中。用戶在 casLoginView.jsp 頁面上點擊提交後，會觸發此方法。
（5）submit 對應 AuthenticationViaFormAction 的 submit 方法 , 若是 doBind 方法成功執行完， 則觸發 submit 方法，此方法負責調用centralAuthenticationService 的 grantServiceTicket 方法，完成認證工做，若是認證成功，則生成 TicketGrantingTicket 對象，放在緩存裏， TicketGrantingTicket 的 ID 就是 TGC Cookie 的 value 值。
（6） warn CAS 提供了一個功能：用戶在一個 web 應用中跳到另外一個 web 應用時， CAS 能夠跳轉到一個提示頁面，該頁面提示用戶要離開一個應用進入另外一個應用，可讓用戶本身選擇。用戶在登陸頁面 viewLoginForm 上選中了 id=」warn」 的複選框，才能開啓這個功能。
WarnAction 就檢查用戶有沒有開啓這個功能，若是開啓了，則轉發到showWarnView, 若是沒開啓，則直接redirect 到客戶應用。
（7）SendTicketGrantingTicketAction 此Action 負責爲response 生成TGC Cookie ，cookie 的值就是 AuthenticationViaFormAction 的submit 方法生成的 TicketGrantingTicket 對象的 ID 。
（8）viewGenerateLoginSuccess 這是 CAS 的認證成功頁面。
第一次訪問Web 應用的流程走向圖以下：
已經登陸web1 後，訪問web1 的資源（web1 沒有啓動session ），或訪問web2 的資源走向圖以下：
/logout
（ 對應實現類 org.jasig.cas.web.LogoutController ）
處理邏輯：
1） removeCookie
2）在服務端刪除TicketGrantingTicket 對象（此對象封裝了cookie 的value 值）
3）redirect 到退出頁面，有2 種選擇：
if(LogoutController 的followServiceRedirects 屬性爲true 值，且url 裏的service 參數非空){
redirect 到 sevice 參數標識的url
} else {
redirect 到內置的casLogoutView （cas/WEB-INF/view/jsp/default/ui/casLogoutView.jsp ），若是url 裏有url 參數，則此url 參數標識的連接會顯示在casLogoutView 頁面上。
}
/serviceValidate
（對應實現類 org.jasig.cas.web.ServiceValidateController ）
處理邏輯：
若是service 參數爲空或ticket 參數爲空，則轉發到failureView （/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationFailure.jsp ）
驗證ticket 。以ticket 爲參數，去緩存裏找ServiceTicketImpl 對象，若是能找到，且沒有過時，且ServiceTicketImpl 對象對應的service 屬性和service 參數對應，則驗證經過，驗證經過後，請求轉發至casServiceSuccessView （cas/WEB-INF/view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp ），驗證不經過，則轉發到failureView 。
四、CAS Client配置參數
CASFilter 參數說明：
| 參數 | 是否必須 | 說明 |
| com.olymtech.cas.client.filter.loginUrl | 是 | 指定 CAS 提供登陸頁面的 URL |
| com.olymtech.cas.client.filter.validateUrl | 是 | 指定 CAS 提供 service ticket 或 proxy ticket 驗證服務的 URL |
| com.olymtech.cas.client.filter.serverName | 是 | 指定客戶端的域名和端口，是指客戶端應用所在機器而不是 CAS Server 所在機器，該參數或 serviceUrl 至少有一個必須指定 |
| com.olymtech.cas.client.filter.serviceUrl | 否 | 該參數指定事後將覆蓋 serverName 參數，成爲登陸成功事後重定向的目的地址 |
| com.olymtech.cas.client.filter.wrapRequest | 否 | 若是指定爲 true，那麼 CASFilter 將從新包裝 HttpRequest,而且使 getRemoteUser() 方法返回當前登陸用戶的用戶名 |
| com.olymtech.cas.client.filter.noFilter | 否 | 設置不過濾的路徑，語法以下：/name1/,/name2 |
| com.olymtech.cas.client.filter.proxyCallbackUrl | 否 | 用於當前應用須要做爲其餘服務的代理(proxy)時獲取 Proxy Granting Ticket 的地址 |
| com.olymtech.cas.client.filter.authorizedProxy | 否 | 用於容許當前應用從代理處獲取 proxy tickets，該參數接受以空格分隔開的多個 proxy URLs，但實際使用只須要一個成功便可。當指定該參數事後，須要修改 validateUrl 到 proxyValidate，而再也不是 serviceValidate |
| com.olymtech.cas.client.filter.renew | 否 | 若是指定爲 true，那麼受保護的資源每次被訪問時均要求用戶從新進行驗證，而無論以前是否已經經過 |
| com.olymtech.cas.client.filter.gateway | 否 | 指定 gateway 屬性 |
7、CAS安全性
CAS 的安全性從 v1 到 v3 ，都很依賴於 SSL ，全部與 CAS 的交互均採用 SSL 協議，確保，ST 和 TGC 的傳輸安全性。
一、TGC 安全性
對於一個 CAS 用戶來講，最重要是要保護它的 TGC ，若是 TGC 不慎被 CAS Server 之外的實體得到， Hacker 可以找到該 TGC ，而後冒充 CAS 用戶訪問全部受權資源。
TGC 是 CAS Server 經過 SSL 方式發送給終端用戶，所以，要截取 TGC 難度很是大，從而確保CAS 的安全性。但 CAS 的傳輸安全性僅僅依賴於 SSL 。
TGC 面臨的風險 主要並不是傳輸竊取，而是存活週期內（ logout 前）被使用（如：離開了電腦）或竊取。
TGC 有本身的存活週期。能夠在 web.xml 中，經過 grantingTimeout 來設置 CAS TGC 存活週期的參數，參數默認是 120 分鐘，在合適的範圍內設置最小值，過短，會影響 SSO 體驗，太長，會增長安全性風險。
二、ST 安全性
ST （ Service Ticket ）是經過 Http 傳送的，網絡中的其餘人能夠 Sniffer 到其餘人的 Ticket 。CAS 協議從幾個方面讓 Service Ticket 變得更加安全：
1） ST 只能使用一次： CAS 協議規定，不管 ST 驗證是否成功， CAS Server 都會將服務端的緩存中清除該 Ticket ，從而能夠確保一個 Service Ticket 不被使用兩次；
2） ST 在一段時間內失效：假設用戶拿到 ST 以後，他請求服務的過程又被中斷了， ST 就被空置了，事實上，此時 TS 仍然有效。 CAS 規定 Service Ticket 只能存活必定的時間，而後 CAS Server 會讓它失效。可經過在 web.xml 中配置參數，讓 ST 在多少秒內失效。
3） ST 是基於隨機數生成的。
8、實現單點登陸的開發流程
經過上面的學習咱們已經對單點登陸以及CAS有了必定的瞭解，那麼咱們怎麼入手搭建集羣的單點登陸呢?
步驟以下：
一、搭建部署cas server
首先咱們確定是要下載cas server的代碼，而後進行用戶名密碼驗證認證方式的選型，選型結束後進行相應配置以及登陸界面的修改等等。
而後把cas server的war包發佈到服務器上，運行便可。
二、web項目中集成cas client
cas server搭建完成後登陸認證模塊已經有了，那麼怎麼跟咱們的web項目關聯起來呢? 這就須要在web 項目中集成cas的client客戶端了，集成了以後，對cas client的配置文件進行配置，對應到cas server的地址，這樣它們就能聯繫起來了。
9、cas server認證方式的選型
咱們以前已經說過了cas支持不少種認證方式，咱們便可把用戶名密碼寫在xml中，而後cas來讀取以後跟用戶輸入的賬號密碼對比，也能夠把用戶名密碼存在數據庫中。
目前cas提供給瞭如下認證方式：
-
- GENERIC
- JAAS
- JDBC —— 關係型數據庫
- MongoDB —— 非關係數據庫
- LDAP
- LEGACY
- RADIUS
- SPNEGO
- TRUSTED
- X509
- OAUTH
- OPENID
在cas server的默認配置中，能夠修改認證管理器中的認證處理器屬性鏈表，增長或者修改相應的認證方式。
有些認證方式對於web開發，基本上不太好用或者不經常使用，由於他們的配置太不靈活或者太專業化。在此之因此列舉了那麼多關於cas的認證處理器，主要爲了讓你們知道，cas支持這種認證方式。好比如今新浪微博就對外開通了oauth認證接口，若是哪一天公司進行戰略轉形，但願用cas接新浪微博帳號認證，那麼就能夠直接在此基礎上進行好好研究。
通常LDAP和數據庫比較經常使用，咱們接下來會着重講這兩種的運用。