cas登錄如何傳用戶名密碼
A. 關於 CAS單點登錄的不同資料庫的問題，謝謝
難道要判斷用戶輸入的用戶名和密碼是否正確還要每個資料庫都驗證一遍？
每套系統傳遞用戶和密碼給CAS的時候再帶一個參數（表示哪一個系統）， 這樣就可以根據這個來連接指定的資料庫去驗證了
B. 在cas server中登錄後怎麼取得當前的用戶名
多個web客戶端應用，那麼每個地方都做個注冊功能，還是所有客戶端都統一到某一個客戶注冊功能。
這兩種方式都可以，根據你的需要，如果所有系統的注冊數據都一樣的話就統一到一個客戶注冊功能
C. 在cas server中登錄後怎麼取得當前的用戶名
在server的org.jasig.cas.web.flow.AuthenticationViaFormAction類的doBind方法中
java代碼
UsernamePasswordCredentials credentials = (UsernamePasswordCredentials) binder.getTarget();
credentials里就有用戶名
在cas client上注冊時，把用戶和密碼再同步到cas server資料庫中
就是這個意思。
D. cas自定義登錄頁面的提交按鈕要怎麼改
1. 動機
用過 CAS 的人都知道 CAS-Server端是單獨部署的，作為一個純粹的認證中心。在用戶每次登錄時，都需要進入CAS-Server的登錄頁填寫用戶名和密碼登錄，但是如果存在多個子應用系統時，它們可能都有相應風格的登錄頁面，我們希望直接在子系統中登錄成功，而不是每次都要跳轉到CAS的登錄頁去登錄。
2. 開始分析問題
其實仔細想一想，為什麼不能直接在子系統中將參數提交至 cas/login 進行登錄呢？ 於是便找到了CAS在登錄認證時主要參數說明：
service [OPTIONAL] 登錄成功後重定向的URL地址；
username [REQUIRED] 登錄用戶名；
password [REQUIRED] 登錄密碼；
lt [REQUIRED] 登錄令牌；
主要有四個參數，其中的三個參數倒好說，最關鍵的就是 lt , 據官方說明該參數是login ticket id, 主要是在登錄前產生的一個唯一的「登錄門票」，然後提交登錄後會先取得"門票"，確定其有效性後才進行用戶名和密碼的校驗，否則直接重定向至 cas/login 頁。
於是，便打開CAS-Server的登錄頁，發現其每次刷新都會產生一個 lt, 其實就是 Spring WebFlow 中的 flowExecutionKey值。 那麼問題的關鍵就在於在子系統中如何獲取 lt 也就是登錄的ticket？
3. 可能的解決方案
一般對於獲取登錄ticket的解決方案可能大多數人都會提到兩種方法：
AJAX: 熟悉 Ajax 的可能都知道，它的請求方式是嚴格按照沙箱安全模型機制的，嚴格情況下會存在跨域安全問題。
IFrames: 這也是早期的 ajax 實現方式，在頁面中嵌入一個隱藏的IFrame，然後通過表單提交到該iframe來實現不刷新提交，不過使用這種方式同樣會帶來兩個問題：
a. 登錄成功之後如何擺脫登錄後的IFrame呢？如果成功登錄可能會導致整個頁面重定向，當然你能在form中使
用屬性target="_parent"，使之彈出，那麼你如何在父頁面顯示錯誤信息呢？
b. 你可能會受到布局的限止(不允許或不支持iframe)
- 對於以上兩種方案，並非說不能實現，只是說對於一個靈活的登錄系統來說仍然還是會存在一定的局限性的，我們堅信能有更好的方案來解決這個問題。
- 4. 通過JS重定向來獲取login ticket (lt)
- 當第一次進入子系統的登錄頁時，通過 JS 進行redirect到cas/login?get-lt=true獲取login ticket，然後在該login中的 flow 中檢查是否包含get-lt=true的參數,如果是的話則跳轉到lt生成頁，生成後，並將lt作為該redirect url 中的參數連接，如 remote-login.html?lt=e1s1,然後子系統再通過JS解析當前URL並從參數中取得該lt的值放置登錄表單中，即完成 lt 的獲取工作。其中進行了兩次 redirect 的操作。
- 5. 開始實踐
- 首先，在我們的子系統中應該有一個登錄頁面，通過輸入用戶名和密碼提交至cas認證中心。不過前提是先要獲取到 login tickt id. 也就是說當用戶第一次進入子系統的登錄頁面時，在該頁面中會通過js跳轉到 cas/login 中的獲取login ticket. 在 cas/login 的 flow 中先會判斷請求的參數中是否包含了 get-lt 的參數。
- 在cas的 login flow 中加入 ProvideLoginTicketAction 的流，主要用於判斷該請求是否是來獲取 lt，在cas-server端聲明獲取 login ticket action 類:
- com.denger.sso.web.ProvideLoginTicketAction
E. 在cas server中登錄後怎麼取得當前的用戶名
在client中可以在session中取得用戶名
CASReceipt receipt = (CASReceipt )session.getAttribute(CASFilter.CAS_FILTER_RECEIPT);
或者
CASReceipt receipt = (CASReceipt )session.getAttribute("e.yale.its.tp.cas.client.filter.receipt");
注冊這個功能（還有包括修改密碼）放到client中，server端只做認證
F. CAS單點登錄原理分析(一)
一，業務分析
在分布式系統架構中，假設把上述的三個子系統部署在三個不同的伺服器上。前提是用戶登錄之後才能訪問這些子系統。那麼使用傳統方式，可能會存在這樣的問題：
1.當訪問用戶中心，需要用戶登錄帳號
2.當訪問購物車，還需要用戶登錄帳號
3.當訪問商品結算，又一次需要用戶登錄帳號
訪問每一個子系統都需要用戶登錄帳號，這樣的體驗對於用戶來說是極差。而使用單點登錄就可以很好地解決上述的問題。
二，單點登錄
單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO 的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
我們目前的系統存在諸多子系統，而這些子系統是分別部署在不同的伺服器中，那麼使用傳統方式的 session 是無法解決的，我們需要使用相關的單點登錄技術來解決。
第一步 ：用戶訪問應用系統1。過濾器判斷用戶是否登錄，沒有登錄，則重定向（302）到認證系統去進行認證操作。
第二步 ：重定向到認證系統，顯示登錄界面，用戶輸入用戶名密碼。認證系統將用戶登錄的信息記錄到伺服器的session中。
第三步 ：認證系統給瀏覽器發送一個特殊的憑證ticket，瀏覽器將憑證交給應用系統1，應用系統1則拿著瀏覽器交給他的憑證ticket去認證系統驗證憑證ticket是否有效。憑證ticket若是有效，將用戶信息保存到應用系統1的session中一份，並告知應用系統1，用戶通過認證。
第四步 ：用戶通過認證，瀏覽器與網站之間進行正常的訪問。
第五步 ：當用戶再次訪問應用系統1，由於應用系統1的session中有用戶信息，所以就不用經過認證系統認證，就可以直接訪問應用系統1了。
第六步 ：當用戶再去訪問其他應用系統時，瀏覽器會帶著憑證ticket過去，其他應用系統到認證系統驗證憑證，憑證ticket若是有效，將用戶信息保存到其他應用系統的session中一份，並告知其他應用系統，用戶通過認證。
第七步 ：用戶通過認證，瀏覽器與網站之間進行正常的訪問。
第八步 ：當用戶再次訪問其他應用系統，由於其他應用系統的session中有用戶信息，所以就不用經過認證系統認證，就可以直接訪問其他應用系統了。
三、Yelu大學研發的CAS(Central Authentication Server)
1.什麼是CAS？
CAS 是 Yale 大學發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。CAS 具有以下特點：
【1】開源的企業級單點登錄解決方案。
【2】CAS Server 為需要獨立部署的 Web 應用。這個CAS框架已經提供
【3】CAS Client 支持非常多的客戶端(這里指單點登錄系統中的各個 Web 應用)，包括Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。下圖是 CAS 最基本的協議過程：
2.CAS的詳細登錄流程
該圖主要描述
1.第一次訪問http://shopping.xiaogui.com
2.在登錄狀態下第二次訪問http://shopping.xiaogui.com
3.在登錄狀態下第一次訪問http://pay.xiaogui.com
下面對圖中序號代表的操作進行說明
當用戶第一次訪問http://shopping.xiaogui.com
序號1: 用戶請求http://shopping.xiaogui.com，會經過AuthenticationFilter認證過濾器(在cas client 的web.xml中配置)
主要作用：判斷是否登錄，如果沒有登錄則重定向到認證中心。
大概知道這個就行，CAS的具體實現會在以後的博客中寫道
序號2: AuthenticationFilter發現用戶沒有登錄，則返回瀏覽器重定向地址。
重定向的地址就是認證伺服器CAS Server的地址，後面的參數是我們請求的客戶端地址，這個參數目的就是為了認證成功以後，根據這個參數的地址重定向回請求的客戶端
序號3: 瀏覽器根據響應回來的重定向地址，向cas.xiaogui.com認證系統發出請求
序號4: 認證系統cas.xiaogui.com接收請求，響應登陸頁面
序號5: ：用戶登陸頁面輸入用戶名密碼，提交請求
序號6: ：CAS Server 認證伺服器接收用戶名和密碼，就行驗證，驗證邏輯CAS Server 已經實現，並響應給瀏覽器信息
這里的用戶名，密碼不需要關心，後續會講到
圖中1，2部分表示序號5 輸入的用戶名，密碼，以及發出的請求。當認證伺服器驗證通過之後，根據請求參數service的值，進行重定向，其實就是回到了請求的客戶端，同時會攜帶一個ticket令牌參數。同時會在Cookie中設置一個TGC，該cookie是網站認證系統cas.xiaogui.com的cookie，只有訪問這個網站才會攜帶這個cookie過去。
*****注意：這個攜帶TGC的Cookie是實現CAS單點登錄的關鍵所在！
Cookie中的TGC：向cookie中添加該值的目的是當下次訪問cas.xiaogui.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生成的，默認是用一次就生效了。也就是上面數字3處的ticket值。
序號7: 客戶端拿到請求中的ticket信息，也就是圖中1的位置
然後經過一個ticket過濾器，去認證系統CAS Server判斷ticket是否有效
這個過濾器的主要工作就是校驗客戶端傳過來的ticket是否有效
CAS Client 客戶端 shopping.xiaogui.com 中web.xml的配置
序號8: 向CAS Server認證系統發出驗證ticket的請求，也就是圖中2的位置，然後執行ticket驗證
序號9: 通過校驗之後，把用戶信息保存到客戶端的session中，並把客戶端的SessionID設置在Cookie中，同時告知客戶端ticket有效。當用戶再次訪問該客戶端，就可以根據Cookie 中的SessionID找到客戶端的Session，獲取用戶信息，就不用再次進行驗證了。也就是圖中響應給瀏覽器的部分。
序號10: shopping.xiaogui.com客戶端接收到cas-server的返回，知道了用戶已經登錄，ticket有效，告知瀏覽器可以進行訪問。
至此，用戶第一次訪問流程結束。
當用戶第二次訪問http://shopping.xiaogui.com
序號11: 當用戶第二次訪問，仍然會經過AuthenticationFilter過濾器，但與第一次訪問不同的是此時客戶端session中已經存在用戶的信息，瀏覽器中的Cookie會根據SessionID找到Session，獲取用戶信息，所以不需要進行驗證，可以直接訪問。
序號12: 客戶端告知瀏覽器可以進行訪問。
當用戶第一次訪問http://pay.xiaogui.com
序號13: 用戶向pay.xiaogui.com CAS Client客戶端發出請求
序號14: ：pay.xiaogui.com接收到請求，發現第一次訪問，於是給他一個重定向的地址，讓他去找認證中心登錄。
序號15: 瀏覽器根據上面響應的地址，發起重定向，因為之前訪問過一次了，因此這次會攜帶上次返回的Cookie：TGC到認證中心。
序號16: 認證中心收到請求，發現TGC對應了一個TGT，於是用TGT簽發一個ticket，並且返回給瀏覽器，讓他重定向到pay.xiaogui.comCAS Client客戶端。
序號17: 根據上面響應回來的地址，進行重定向到pay.xiaogui.comCAS Client客戶端
序號18: pay.xiaogui.comCAS Client客戶端帶著ticket去認證中心驗證是否有效。
序號19: 認證成功，把用戶信息保存到客戶端的session中，並把客戶端的SessionID設置在Cookie中。當用戶下次訪問pay.xiaogui.comCAS Client客戶端，直接登錄，無需驗證。
序號20: 告知瀏覽器可以進行訪問
CAS單點登錄的原理分析大致就是上述的這些，至於CAS單點登錄的具體實現，將在下篇博客中寫道。
G. cas單點登錄怎麼在伺服器端獲得用戶信息
通過上述部署與配置，多個Web應用已經可以共用一個登錄服務。但是，上述過程中作為CAS Client端的Web應用只取得了用戶登錄名稱信息，而在實際應用中，Web應用往往需要獲得登錄用戶更多的信息，例如會員等級、性別、住址等。要達到此目的，只需對Server端稍做修改即可實現。
1. 服務端配置及修改
假定上述存儲用戶信息的數據表userinfo中還包含一個名為address的用於存儲用戶地址的欄位，而Web應用程序希望能夠從CAS Server處獲得當前登錄用戶的地址信息，則Server端需要按以下內容修改deployerConfigContext.xml。部分配置說明請參見注釋。
<!--將原有attributeRepository配置注釋 -->
<!--
<beanid="attributeRepository"
class="org.jasig.services.persondir.support.StubPersonAttributeDao">
<propertyname="backingMap">
<map>
<entrykey="uid" value="uid" />
<entrykey="ePersonAffiliation" value="ePersonAffiliation"/>
<entrykey="groupMembership" value="groupMembership" />
</map>
</property>
</bean>
-->
<!--新增attributeRepository配置(開始) -->
<bean class="org.jasig.services.persondir.support.jdbc."id="attributeRepository">
<!-- 指定使用的數據源，此處dataSource是已配置好的數據源 -->
<constructor-arg index="0"ref="dataSource"/>
<!-- 從資料庫中查詢信息的SQL語句，通常只需要修改表名即可 -->
<constructor-arg index="1" value="select * fromuserinfo where {0}"/>
<propertyname="queryAttributeMapping">
<map>
<!-- 上述查詢的參數，將userName替換為表中表示用戶名的欄位名稱 -->
<entrykey="username" value="userName"/>
</map>
</property>
<propertyname="resultAttributeMapping">
<map>
<!-- 需要返回給Web應用的其它信息，多個信息時可繼續增加entry節點-->
<!--key值為數據表中的欄位名稱，value值為Client端取值時的名稱標識-->
<entry key="address" value="address"/>
</map>
</property>
</bean>
<!--新增attributeRepository配置(結束) -->
<bean
id="serviceRegistryDao"
class="org.jasig.cas.services.">
<propertyname="registeredServices">
<list>
<beanclass="org.jasig.cas.services.RegexRegisteredService">
<propertyname="id" value="0" />
<propertyname="name" value="HTTP and IMAP" />
<propertyname="description" value="Allows HTTP(S) and IMAP(S)protocols" />
<propertyname="serviceId" value="^(https?|imaps?)://.*" />
<propertyname="evaluationOrder" value="10000001" />
<!--增加此項配置 -->
<property name="ignoreAttributes" value="true"/>
</bean>
… …
</list>
</property>
</bean>
CASServer要將額外的信息傳遞至Client端，還需要修改完成信息組裝的文件WEB-INF/view/jsp/protocol/2.0/casServiceValidationSuccess.jsp。casServiceValidationSuccess.jsp負責組裝包含用戶信息的XML，因此修改部分是將需要傳遞的額外信息加入到它最終生成的XML文件之中。具體修改如下：
<cas:serviceResponsexmlns:cas='http://www.yale.e/tp/cas'>
<cas:authenticationSuccess> <cas:user>${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.id)}</cas:user>
<!-- 新增額外信息(開始) -->
<c:iftest="${fn:length(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.attributes)> 0}">
<cas:attributes>
<c:forEachvar="attr"items="${assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.attributes}">
<!--注意此行的正確寫法，網上資料基本都是錯誤的--> <cas:${fn:escapeXml(attr.key)}>${fn:escapeXml(attr.value)}</cas:${fn:escapeXml(attr.key)}>
</c:forEach>
</cas:attributes>
</c:if>
<!-- 新增額外信息(結束) -->
<c:if test="${not emptypgtIou}">
<cas:proxyGrantingTicket>${pgtIou}</cas:proxyGrantingTicket>
</c:if>
<c:if test="${fn:length(assertion.chainedAuthentications)> 1}">
<cas:proxies>
<c:forEachvar="proxy" items="${assertion.chainedAuthentications}"varStatus="loopStatus" begin="0"end="${fn:length(assertion.chainedAuthentications)-2}"step="1">
<cas:proxy>${fn:escapeXml(proxy.principal.id)}</cas:proxy>
</c:forEach>
</cas:proxies>
</c:if>
</cas:authenticationSuccess>
</cas:serviceResponse>
2. Java Client端取得更多用戶信息
Java Client端不需要做任何修改就可以繼續正常使用CAS服務，如果需要取得用戶更多信息，可以通過AttributePrincipal對象取得Attribute列表(一個Map對象)後進行查詢。
修改前述Java Client的示例代碼，在最後追加取得address信息的代碼，重啟服務並重新訪問頁面，可以看到頁面上顯示了當前用戶的address信息。
<%@pageimport="org.jasig.cas.client.authentication.AttributePrincipal" %>
<%@pageimport="org.jasig.cas.client.validation.Assertion" %>
<%@page import="java.util.*" %>
<%
String loginName1 = request.getRemoteUser();
%>
request.getRemoteUser(): <%=loginName1%><br/>
<%
AttributePrincipal principal = (AttributePrincipal)request.getUserPrincipal();
String loginName2 = principal.getName();
%>
request.getUserPrincipal().getName():<%=loginName2%><br/>
<%
Object object =request.getSession().getAttribute("_const_cas_assertion_");
Assertion assertion =(Assertion)object;
String loginName3 =assertion.getPrincipal().getName();
%>
request.getSession().getAttribute("_const_cas_assertion_").getPrincipal().getName():<%=loginName3%><br/>
H. 登錄那點事
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()方法獲取即可