CAS大體原理我就不說了，網上一大把，不過具體交互流程沒說清楚，所以有這篇文章，如果有錯誤，請多多指教
登錄過程
用戶第一次訪問一個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&logoutUrl=http%3A%2F%2F192.168.1.90%3A8081%2Fweb1%2Flogout%2F，
這個URL中有2個地址，一個是登錄完成后的跳轉地址，另外一個是用戶登出時 訪問的當前服務登出URL地址，后面這個地址保存在Cas server中，用戶登出的時候使用
認證成功后，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 的交互。
登出過程
用戶執行登出操作，當前應用服務器會把這個登出請求重定向到CAS server，CAS server接受登出請求后，會檢測用戶的TCG Cookie，把對應的session清除，同時會找到所有通過該TGC sso登錄的應用服務器URL提交請求,所有的回調請求中，包含一個參數logoutRequest,訪問這個登出URL，
所有收到請求的應用服務器(就是是CAS client)會解析這個參數，取得sessionId，根據這個Id取得session后，把session刪除。這樣就實現單點登出的功能，用戶無法在這個具體應用上繼續操作了，只能重新登錄才行。
注：以上內容根據網絡內容整理而成，如果侵犯到您的權益，請聯系我
參考文檔：
http://www.blogjava.net/xmatthew/archive/2008/07/09/213808.html
http://blog.csdn.net/feng27156/article/details/38060099