CAS學習筆記（一）

近期作單點登陸，看了一些CAS資料，作下總結

1、cas簡介

全名：Central Authentication Service

特色：

一、開源的、多協議的 SSO 解決方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。

二、支持多種認證機制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；

三、安全策略：使用票據（ Ticket ）來實現支持的認證協議；

四、支持受權：能夠決定哪些服務能夠請求和驗證服務票據（ Service Ticket ）；

五、高可用性：經過把認證過的狀態數據存儲在 TicketRegistry 組件中，這些組件有不少支持分佈式環境的實現，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等

六、支持多種客戶端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

 

2、原理

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）