一、CAS單點登入詳解
1. CAS 簡介
簡單的 SSO 的體系中，會有下面三種角色：
1 ， User （多個）
2 ， Web 應用（多個）
3 ， SSO 認證中心（ 1 個）
雖然 SSO 實現模式千奇百怪，但萬變不離其宗：
1 Web 應用不處理 User 的登入，否則就是多點登陸了，所有的登入都在 SSO 認證中心進行。
2 SSO 認證中心通過一些方法來告訴 Web 應用當前訪問使用者究竟是不是張三 / 李四。
3 SSO 認證中心和所有的 Web 應用建立一種信任關係， SSO 認證中心對使用者身份正確性的判斷會通過某種方法告之 Web 應用，而且判斷結果必須被 Web 應用信任。
1.1. What is CAS ？
CAS （ Central Authentication Service ） 是 Yale 大學發起的一個企業級的、開源的專案，旨在為 Web 應用系統提供一種可靠的單點登入解決方法（屬於 Web SSO ）。
CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個專案。
1.2. 主要特性
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 等。
2. SSO 簡介
本文內容主要針對 Web SSO 。
2.1. 什麼是SSO
單點登入（ Single Sign-On , 簡稱 SSO ）是目前比較流行的服務於企業業務整合的解決方案之一， SSO 使得在多個應用系統中，使用者只需要 登入一次 就可以訪問所有相互信任的應用系統。
2.2. SSO 原理
2.2.1. SSO 體系中的角色
一般 SSO 體系主要角色有三種：
1、 User （多個）
2、 Web 應用（多個）
3、 SSO 認證中心（ 1 個 ）
2.2.2. SSO 實現模式的原則
SSO 實現模式一般包括以下三個原則：
1、 所有的認證登入都在 SSO 認證中心進行；
2、 SSO 認證中心通過一些方法來告訴 Web 應用當前訪問使用者究竟是不是已通過認證的使用者；
3、 SSO 認證中心和所有的 Web 應用建立一種信任關係，也就是說 web 應用必須信任認證中心。（單點信任）
2.2.3. SSO 主要實現方式
SSO 的主要實現方式有：
1、 共享 cookies
基 於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞 cookies 機制，實現兩個域名之間系統令牌 傳遞問題；另外，關於跨域問題，雖然 cookies本身不跨域，但可以利用它實現跨域的 SSO 。如：代理、暴露 SSO 令牌值等。
缺點：不靈活而且有不少安全隱患，已經被拋棄。
2、 Broker-based( 基於經紀人 )
這 種技術的特點就是，有一個集中的認證和使用者帳號管理的伺服器。經紀人給被用於進一步請求的電子身份存取。中央資料庫的使用減少了管理的代價，併為認證提供 一個公共和獨立的 "第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （憑證庫思想 ) 等。 Kerberos是由麻省理工大學發明的安全認證服務，已經被 UNIX 和 Windows 作為 預設的安全認證服務整合進作業系統。
3、 Agent-based （基於代理人）
在 這種解決方案中，有一個自動地為不同的應用程式認證使用者身份的代理程式。這個代理程式需要設計有不同的功能。比如，它可以使用口令表或加密金鑰來自動地將 認證的負擔從使用者移開。代理人被放在伺服器上面，在伺服器的認證系統和客戶端認證方法之間充當一個 " 翻譯 "。例如 SSH 等。
4、 Token-based
例如 SecureID,WebID ，現在被廣泛使用的口令認證，比如 FTP 、郵件伺服器的登入認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。
5、 基於閘道器
6、 基於 SAML
SAML(Security Assertion Markup Language ，安全斷言標記語言）的出現大大簡化了 SSO ，並被 OASIS 批准為 SSO 的執行標準 。開源組織 OpenSAML 實現了 SAML 規範。
3. CAS 的基本原理
3.1. 結構體系
從結構體系看， CAS 包括兩部分： CAS Server 和 CAS Client 。
3.1.1. CAS Server
CAS Server 負責完成對使用者的認證工作 , 需要獨立部署 , CAS Server 會處理使用者名稱 / 密碼等憑證(Credentials) 。
3.1.2. CAS Client
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。（原則上，客戶端應用不再接受任何的使用者名稱密碼等 Credentials ）。
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。
3.2. CAS 原理和協議
3.2.1. 基礎模式
基礎模式 SSO 訪問流程主要有以下步驟：
1. 訪問服務： SSO 客戶端傳送請求訪問應用系統提供的服務資源。
2. 定向認證： SSO 客戶端會重定向使用者請求到 SSO 伺服器。
3. 使用者認證：使用者身份認證。
4. 發放票據： SSO 伺服器會產生一個隨機的 Service Ticket 。
5. 驗證票據： SSO 伺服器驗證票據 Service Ticket 的合法性，驗證通過後，允許客戶端訪問服務。
6. 傳輸使用者資訊： SSO 伺服器驗證票據通過後，傳輸使用者認證結果資訊給客戶端。
下面是 CAS 最基本的協議過程：
基礎協議圖
如 上圖： CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 請求，同 時， CAS Client 會分析 HTTP 請求中是否包含請求 Service Ticket( ST 上圖中的 Ticket) ，如果沒有，則說明該使用者是沒有經過認證的；於是 CAS Client 會重定向使用者請求到 CAS Server （ Step 2 ），並傳遞 Service （要訪問的目的資源地址）。 Step 3 是使用者認證過程，如果使用者提供了正確的 Credentials ， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並快取以待將來驗證，並且重定向使用者到 Service 所在地址（附帶剛才產生的 Service Ticket ） , 併為客戶端瀏覽器設定一個 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新產生的 Ticket 過後，在 Step 5 和 Step6 中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS Server 的互動均採用 SSL 協議，以確保 ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向 的過程。但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於使用者是透明的（使用 HttpsURLConnection ）。
CAS 請求認證時序圖如下：
3.2.1. CAS 如何實現 SSO
當用戶訪問另一個應用的服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然後做下面的事情：
1) 如果 User 持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果；
2) 如果 TGC 失效，那麼使用者還是要重新認證 ( 走基礎協議圖的 Step3) 。
3.2.2. CAS 代理模式
該模式形式為使用者訪問 App1 ， App1 又依賴於 App2 來獲取一些資訊，如： User -->App1 -->App2。
這 種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那麼，為了不影響使用者體驗（過多的重定向導致 User 的 IE 視窗不停地 閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理使用者去訪問其它 Web 應用。
代 理的前提是需要 CAS Client 擁有使用者的身份資訊 ( 類似憑據 ) 。之前我們提到的 TGC 是使用者持有對自己身份資訊的一種憑據，這裡的 PGT 就是 CAS Client 端持有的對使用者身份資訊的一種憑據。憑藉TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket ，所以，這裡憑藉 PGT ， Web應用可以代理使用者去實現後端的認證，而 無需前端使用者的參與 。
下面為代理應用（ helloService ）獲取 PGT 的過程： （注： PGTURL 用於表示一個 Proxy 服務，是一個回撥連結； PGT 相當於代理證； PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關係；）
如上面的 CAS Proxy 圖所示， CAS Client 在基礎協議之上，在驗證 ST 時提供了一個額外的PGT URL( 而且是 SSL 的入口 ) 給 CAS Server ，使得 CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通過 PGT 向後端 Web 應用進行認證。
下面是代理認證和提供服務的過程：
如 上圖所示， Proxy 認證與普通的認證其實差別不大， Step1 ， 2 與基礎模式的 Step1,2 幾乎一樣，唯一不同的 是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。
3.2.3. 輔助說明
CAS 的 SSO 實現方式可簡化理解為： 1 個 Cookie 和 N 個 Session 。 CAS Server 建立 cookie，在所有應用認證時使用，各應用通過建立各自的 Session 來標識使用者是否已登入。
用 戶在一個應用驗證通過後，以後使用者在同一瀏覽器裡訪問此應用時，客戶端應用中的過濾器會在 session 裡讀取到使用者資訊，所以就不會去 CAS Server 認證。如果在此瀏覽器裡訪問別的 web 應用時，客戶端應用中的過濾器在 session 裡讀取不到使用者資訊，就會去 CAS Server 的 login 介面認證，但這時CAS Server 會讀取到瀏覽器傳來的 cookie （ TGC ），所以 CAS Server 不會要求使用者去登入頁面登入，只是會根據 service 引數生成一個 Ticket ，然後再和 web 應用做一個驗 證 ticket 的互動而已。
3.3. 術語解釋
CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放使用者身份認證憑證的 cookie ，在瀏覽器和 CAS Server 間通訊時使用，並且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確使用者身份的憑證；
Ø Service ticket(ST) ：服務票據，服務的惟一標識碼 , 由 CAS Server 發出（ Http 傳送），通過客戶端瀏覽器到達業務伺服器端；一個特定的服務只能有一個惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 繫結一個使用者的特定服務，使其擁有向 CAS Server 申請，獲得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是將通過憑證校驗時的應答資訊由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將通過回撥連結傳給 Web 應用。 Web 應用負責維護 PGTIOU 與 PGT 之 間對映關係的內容表；
Ø Proxy Ticket (PT) ：是應用程式代理使用者身份對目標程式進行訪問的憑證；
其它說明如下：
Ø Ticket Granting ticket(TGT) ：票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證資訊 (Credentials) ；
Ø Authentication service(AS) --------- 認證用服務，索取 Credentials ，發放 TGT ；
Ø Ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST ；
Ø KDC( Key Distribution Center ) ---------- 金鑰發放中心；
4. 登入流程
１. 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提交請求,所有收到請求的應用伺服器application會解析這個引數，取得sessionId，根據這個Id取得session後，把session刪除。
這樣就實現單點登出的功能。
5. CAS 安全性
CAS 的安全性僅僅依賴於 SSL 。使用的是 secure cookie 。
5.1. TGC/PGT 安全性
對於一個 CAS 使用者來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然後冒充 CAS 使用者訪問 所有 授權資源。 PGT 的角色跟 TGC 是一樣的。
從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式傳送給終端使用者，因此，要擷取 TGC 難度非常大，從而確保 CAS 的安全性。
TGT 的存活週期預設為 120 分鐘。
5.2. ST/PT 安全性
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 認證，直接訪問 對應的服務。
客戶端訊息流程
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驗證票據，允許使用者訪問