安全性：
用戶只須在cas錄入用戶名和密碼，之后通過ticket綁定用戶，在cas客戶端與cas校驗是通過ticket，並不會在網上傳輸密碼，所以可以保證安全性，密碼不被竊取
原理：１個cookie+Ｎ個session
ＣＡＳ創建cookie在所有應用中登錄時cas使用,各應用通過在ＩＥ創建各自的session來標識應用是否已經登錄。
Cookie:在cas為各應用登錄時使用，實現了只須一次錄入用戶密碼
Session:各應用會創建自己的session表示是否登錄
登錄
１. CAS 登錄時處理：
第一步：cas往瀏覽器增加cookie（ＴＧＣ）
CAS向瀏覽器送回一個所謂的“內存cookie”。這種cookie並不是真的保存在內存中，而只是瀏覽器一關閉，cookie就自動過期。這個cookie稱為“ticket-granting cookie”，用來表明用戶已經成功地登錄。
這個Cookie是一個加密的Cookie，其中保存了用戶登錄的信息。用於以后其它應用客戶端登錄。
第二步：cas同時創建一個ticket重定向到原來的cas客戶端
認證成功后，CAS服務器創建一個很長的、隨機生成的字符串，稱為“Ticket”。隨后，CAS將這個ticket和成功登錄的用戶，以及服務聯系在一起。這個ticket是一次性使用的一種憑證，它只對登錄成功的用戶及其服務使用一次。使用過以后立刻失效。
２. Cas 客戶端應用Ａ的處理
第一步：收到ticket后，向cas提交驗證ticket
Cas客戶端收到ticket之后，應用程序需要驗證ticket。這是通過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是CAS服務器提供的。CAS通過校驗路徑獲得了ticket之后，通過內部的數據庫對其進行判斷。如果判斷是有效性，則返回一個NetID給應用程序。隨后CAS將ticket作廢，並且在客戶端留下一個cookie。（誰來創建cookie？），
第二步：ticket驗證后創建session
以后登錄此應用時，沒有ticket，但ＩＥ能提供session,從session中取得CASReceipt,並驗證如果有效說明已經在此應用認證過，允許訪問此應用，
到此為止，ＣＡＳ會記錄用戶已在應用Ａ已經登錄
３. 用戶登錄到應用Ｂ是如何處理
用戶進入應用Ｂ時，首先仍然會重定向到CAS服務器。不過此時CAS服務器不再要求用戶輸 入用戶名和密碼，而是首先自動尋找Cookie，根據Cookie中保存的信息，進行登錄。然后，CAS同樣給出新的ticket重定向應用Ｂ給cas驗證（流程同應用Ａ驗證方式），如果驗證成功則應用Ｂ創建session記錄CASReceipt信息到session中，以后憑此session登錄應用Ｂ。
到此為止，ＣＡＳ會記錄用戶已在應用A和應用B進行登錄，但是當用戶在應用B退出cas登錄時，要通知應用Ａ進行退出，如何通知應用Ａ呢？
登出
CAS server接受請求后，會檢測用戶的TCG Cookie，把對應的session清除，同時會找到所有通過該TGC sso登錄的應用服務器URL提交請求,所有的回調請求中，包含一個參數logoutRequest,內容格式如下：
<saml:NameID>@NOT_USED@</saml:NameID>
<samlp:SessionIndex>[SESSION IDENTIFIER]</samlp:SessionIndex>
</samlp:LogoutRequest>
所有收到請求的應用服務器application會解析這個參數，取得sessionId，根據這個Id取得session后，把session刪除。
這樣就實現單點登出的功能。
客戶端實現：
首先，要實現single sign out在 應用服務器application端的web.xml要加入以下配置
<filter-name>CAS Single Sign Out Filter</filter-name>
<filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CAS Single Sign Out Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class>
</listener>
注：如果有配置CAS client Filter,則CAS Single Sign Out Filter 必須要放到CAS client Filter之前。
配置部分的目的是在CAS server回調所有的application進行單點登出操作的時候，需要這個filter來實現session清楚。
服務器端實現
看了下面的瀏覽器cookie變化，會對cas有更深的理解
下載個httpwatch監控一下cookie的變化
客戶端消息流程
1. 第一次訪問http://localhost:8080/a,
CLIENT：沒票據且SESSION中沒有消息所以跳轉至CAS
CAS：拿不到TGC故要求用戶登錄
2. 認證成功后回跳
CAS：通過TGT生成ST發給客戶端，客戶端保存TGC，並重定向到http://localhost:8080/a
CLIENT：帶有票據所以不跳轉只是后台發給CAS驗證票據（瀏覽器中無法看到這一過程）
3. 第一次訪問http://localhost:8080/b
CLIENT：沒票據且SESSION中沒有消息所以跳轉至CAS
CAS：從客戶端取出TGC，如果TGC有效則給用戶ST並后台驗證ST，從而SSO。【如果失效重登錄或注銷時，怎么通知其它系統更新SESSION信息呢？？TicketGrantingTicketImpl類grantServiceTicket方法里this.services.put(id,service);可見CAS端已經記錄了當前登錄的子系統】
4. 再次訪問http://localhost:8080/a
CLIENT：沒票據但是SESSION中有消息故不跳轉也不用發CAS驗證票據，允許用戶訪問