近期做單點登錄，看了一些CAS資料，做下總結
一、cas簡介
全名：Central Authentication Service
特點：
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.1 CAS Server
完成認證工作，對用戶名、密碼進行校驗，需要獨立部署，如集團SSO中的sso項目。
2.2 CAS Client
使用Filter將請求攔截下來，當請求中含票據時，重定向到CAS Server進行驗證，不含票據時，到CAS Server登錄頁面進行登錄，如集團中的esmp項目。
2.3 協議圖
1. 訪問服務： SSO 客戶端發送請求訪問應用系統提供的服務資源。
2. 定向認證： SSO 客戶端會重定向用戶請求到 SSO 服務器。
3. 用戶認證：用戶身份認證。
4. 發放票據： SSO 服務器會產生一個隨機的 Service Ticket 。
5. 驗證票據： SSO 服務器驗證票據 Service Ticket 的合法性，驗證通過后，允許客戶端訪問服務。
6. 傳輸用戶信息： SSO 服務器驗證票據通過后，傳輸用戶認證結果信息給客戶端。
2.4 時序圖
比如A、B兩個CAS客戶端，當A登錄后，A中保存session（流程這里不做重述，見上圖），那這個時候B再去請求，應該是不用再次輸入用戶名密碼認證的。具體流程：
瀏覽器拿着cookie到B（上圖1）；B發現沒有session，會到CAS服務端去認證，發現是已登錄用戶，所以返回ST重定向到瀏覽器（上圖2）；瀏覽器再重定向到B並發送ST參數（上圖4）；B再去CAS Server認證ST，確認已登錄（上圖5）；創建session （上圖6）；登錄成功（上圖7）