從結構上看cas包括兩個部分，CAS server 和CAS client 需要獨立部署，主要負責用戶的認證工作，CAS負責處理對客戶端受保護資源的訪問請求，需要登錄時，重新定向到CAS Server
CAS Client 與受保護的客戶端應用部署在一起，以Filter方式保護web應用的受保護資源，過濾從客戶端過來的每一個web請求，同時CAS client會分析HTTP請求中是否包含請求service Ticket, 如果沒有，則說明該用戶是沒有經過認證的，於是CAS Client會重定向用戶請求到CAS server
3) 用戶認證過程，如果用戶提供了正確的Credentials，CAS Server會產生一個隨機的Server Ticket ，然后，緩存該Ticket。並且重定向用戶到CAS Client(附帶剛才產生的Service Ticket)Service Ticket是不可以偽造的
5) CAS Client 和CAS Server之間完成了一個對用戶的身份核實，用Ticket 查找userName，因為Ticket是CAS Server產生的。
總結如下：
訪問服務： sso客戶端發送請求訪問應用系統提供的服務資源
定向認證：sso客戶端會重定向用戶請求到SSO服務器
用戶認證：用戶身份認證
發放票據：sso服務器會產生一個隨機的service ticket
驗證票據：sso服務器驗證票據service ticket 的合法性，驗證通過后，允許客戶端訪問服務
傳輸用戶信息：sso服務器驗證票據通過后，傳輸用戶認證結果信息給客戶端
用戶首次登錄時流程
1）用戶瀏覽器訪問系統A需要登錄受限資源，此時進行登錄檢查，發現未登錄，然后進行獲取票據操作，發現沒有票據
2）系統A發現請求需要登錄，將請求重定向到認證中心獲取全局票據操作，沒有，進行登錄操作。
3）認證中心呈現登錄頁面，用戶登錄，登錄成功后，認證中心重定下請求到系統A，並附上認證通過令牌，此時認證中心同時生成了全局票據
4）此時再次進行登錄檢查，發現未登錄，然后再次獲取票據操作，此時可以獲得票據(令牌)，系統A與認證中心通信，驗證令牌有效，證明用戶已經登錄
5）系統A將受限資源返回給用戶
已登錄用戶首次訪問應用群中系統B
1) 瀏覽器訪問另一個應用B，需登錄受限資源，此時進行登錄檢查，發現未登錄，然后進行獲取票據操作，發現沒有票據
2）系統B發現該請求需要登錄，將請求重定向到認證中心，獲取全局票據操作，獲取全局票據，可以獲得，認證中心發現已經登錄
3）認證中心發放臨時票據(令牌)，並攜帶該令牌重定向到系統B
4）此時再次進行登錄檢查，發現未登錄，然后再次獲取票據操作，此時可以獲取票據(令牌)，系統B與認證中心通信，驗證令牌有效，證明用戶已經登錄
5）系統B將受限資源返回給客戶端
登錄狀態判斷
用戶到認證中心登錄后，用戶和認證中心之間建立起了回話，我們把這個會話成為全局會話。
當用戶后續訪問系統應用時，我們不可能每次應用請求都到認證中心去判定是否登錄，這樣效率非現低下，這樣也是單web應用不需要考慮的
可以在系統應用和用戶瀏覽器之間建立局部會話
局部會話保持了客戶端與該系統應用的登錄狀態，局部會話依附於全局會話存在，全局會話消失，局部會話必須消失
用戶訪問應用時，首先判斷局部會話是否存在
，如果存在，即認為是登錄狀態，無需再到認證中心判斷。
如不存在，就重定向到認證中心判斷全局會話是否存在。
如果存在，按1提到的方式通知該應用，該應用與客戶端就建立起他們之間局部會話，下次請求該應用，就不再去認證中心驗證了。
系統登出
用戶在一個系統登出了，訪問其他子系統，也應該是登出狀態。要想做到這一點，應用除結束本地局部會話外，還應該通知認證中心該用戶登出。
認證中心接到登出通知，即可結束全局會話，同時需要通知所有已建立局部會話的子系統，將它們的局部會話銷毀。這樣用戶訪問其他應用時，都顯示已登出狀態。
整個登出流程
1）客戶端向應用A發出登出logout請求
2）應用A取消本地會話，同時通知認證中心用戶已登出
3）應用A返回客戶端登出請求
4）認證中心通知所有用戶登錄訪問的應用，用戶已登出
疑問解答
系統A是如何發現該請求需要登錄重定向到認證中心的
用戶通過瀏覽器地址訪問系統A，系統A(也可以稱為CAS客戶端)去Cookie中拿JSESSION，即在Cookie中維護的當前會話session的ID，如果拿到了說明用戶已經登錄，如果沒有拿到，說明用戶未登錄
系統A重定向到認證中心，發送了什么信息或者地址變成了什么
登錄成功后，認證中心重定向請求到系統A，認證通過令牌是如何附加發送給系統A的
重定向之后的地址欄變成：http://a:8080/?ticket=ST-XXX-XXXX,票據以ticket為參數名的方式通過地址欄發送給系統A
系統A驗證令牌，怎樣操作證明用戶登錄的
系統A通過地址欄獲取ticket的參數值ST票據，然后從后台將ST發送給CAS server認證中心驗證，驗證ST有效后，CAS server返回當前用戶登錄的相關信息，系統A接收到返回的用戶信息，並為該用戶創建session會話，會話id由cookie維護，來證明其已經登錄
登錄B系統，認證中心是如何判斷用戶已經登錄的
在系統A登錄成功后，用戶和認證中心之間建立起了全局會話，這個全局會話就是TGT(Ticket Granting Ticket)，TGT位於CAS服務器端，TGT並沒有放在sesssion中，也就是說，CAS全局會話的實現並沒有直接使用session機制，而是利用cookie自己實現的，這個cookie叫做TGC(ticket granting cookie)，它存在了TGT的id，保存在用戶瀏覽器器。
用戶發送登錄系統B的請求，首先回去cookie中拿JSESSION，因為系統B並未登錄過，session會話還未創建，JESSION的值是拿不到的，然后請求重新定向到CAS認證中心，CAS認證中心先去用戶瀏覽器中拿TGC，也就是全局會話id，如果存在則代表用戶在認證中心已經登錄，附帶上認證令牌重定向到系統B
登出的過程，各個系統對當前用戶都做了什么
認證中心清除當前用戶的全局TGT，同時清掉cookie中的TGT的id:TGC
然后是各個客戶端系統，比如系統A，系統B，清除局部會話session，同時清掉cookie中session會話id，jession
系統A登錄流程圖，添加注釋
