cas工做原理淺析與總結

CAS（ Central Authentication Service ）是 Yale 大學發起的一個企業級的、開源的項目，旨在爲 Web 應用系統提供一種可靠的單點登陸解決方法（屬於 Web SSO ）。
其流程用時序圖描述以下：

1. 請求app地址http://www.app.com
2. app端(cas client)AuthenticationFilter中校驗session中_const_cas_assertion_，不爲空，直接放過url；不然獲取request中的ticket參數，request中無ticket，302重定向到cas server地址，url中帶上service參數http://www.casserver.com/?ser...://www.app.com
3. cas server先判斷context中是否有service對應的TGT
4. 判斷沒有TGT，返回login form（客戶端跳轉至cas server登陸頁地址）
5. 用戶輸入登陸信息，form提交至cas server
6. cas server驗證登陸信息，生成TGT和ST
7. 設置TGC至cookie，url中顯式帶上ticket（STid）參數，重定向Browser至App
8. App中AbstractTicketValidationFilter 會向cas server請求校驗ticket，帶上ticket（STid）和service（回調地址）參數
9. cas server經過ServiceValidateController校驗ticket
10. 確認有效後返回校驗成功
11. 此時App中會根據成功結果，在session中設置_const_cas_assertion_屬性
12. 重定向到app，此時url中不帶有ticket參數
13. 這時再通過AuthenticationFilter時，session中有_const_cas_assertion_屬性，放行；再通過AbstractTicketValidationFilter時，request中沒有ticket參數，放行，訪問目標資源
14. 返回目標資源給browser

要點以下：

1. 如若第4步中，判斷結果爲有service對應的TGT，先驗證ticket（TGTid）、service是否合法，再根據renew參數看是否要從新建立service ticket，若要從新建立，則須要從新登陸；不然從新轉向service地址
2. 如若app端想使用本身的自定義登陸界面，能夠在第4步中不跳轉cas server的登陸頁地址，轉而跳轉至自定義登陸頁面。但須要向cas server端請求login ticket，在用戶填寫登陸表單後，連同login ticket一同傳參至cas server去作校驗
3. 第6步中，TGT和ST的生成規則（這裏指TGTid和STid的生成規則，TGT和ST均爲類）："TGT_XX_RandomStr" "ST_XXX_RandomStr"。XX、XXX爲AtomicLong.getAndIncrement()方法自增Long類型數字（最大值時，調用AtomicLong.compareAndSet()方法置0）；RandomStr爲隨機字符串
4. 步驟12中再已校驗完用戶信息的狀況下，再次進行重定向的目的，是爲了隱藏第7步重定向時url中的ticket入參
5. 單點登陸的目的，是讓用戶登陸App1後，若有權限，可免登陸，直接訪問App二、App3等。cas的實現方式，是在訪問其餘App時，使用Cas Proxy。實現原理是App1先經過Cas Server的認證，而後向Cas Server申請一個針對於App2的proxy ticket，以後在訪問App2時把申請到的針對於App2的proxy ticket以參數ticket傳遞過去。後面的流程與上述cas流程步驟8及之後步驟相似