一，SSO以及CAS實現SSO原理

前言

單點登錄（Single Sign-On ,簡稱SSO）是目前比較流行的服務於企業業務整合的解決方案之一，SSO 使得在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。

sso角色

一般SSO體系主要角色有三種：

1、 User（多個）

2、 Web應用（多個）

3、 SSO認證中心（1個）

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 規範。

CAS原理

Cas的全稱是Centeral Authentication Service，是對單點登錄SSO（Single Sign On）的一種實現。其由Cas Server和Cas Client兩部分組成，Cas Server是核心，而Cas Client通常就對應於我們的應用。一個Cas Server可以對應於多個Cas Client。它允許我們在一個Client進行登錄以後無需再讓用戶輸入用戶名和密碼進行認證即可訪問其它Client應用。

CAS Server負責完成對用戶的認證工作, 需要獨立部署, CAS Server 會處理用戶名 / 密碼等憑證 (Credentials)。

CAS Client負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到CAS Server進行認證。（原則上，客戶端應用不再接受任何的用戶名密碼等 Credentials）。CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。

上面是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單點登錄的實現過程：

如你所見，在第一次訪問應用app1時，由於沒有登錄會直接跳轉到Cas Server去進行登錄認證，此時將附帶查詢參數service在Cas Server的登錄地址上，表示登錄成功後將要跳轉的地址。此時Cas Server檢查到沒有之前成功登錄後生成的SSO Session信息，那麼就會引導用戶到登錄頁面進行登錄。用戶輸入信息提交登錄請求，Cas Server認證成功後將生成對應的SSO Session，以及名爲CASTGC的cookie，該cookie包含用來確定用戶SSO Session的Ticket Granting Ticket（TGT）。之後會生成一個Service Ticket（ST），並將以ticket作爲查詢參數名，以該ST作爲查詢參數值跳轉到登錄時service對應的URL。如：

http(s)://domain/app1?ticket=ST-2-59fS6KxvmykibRXyoPJE

之後的操作對用戶來說都是透明的，即不可見的。app1之後將以service和ticket作爲查詢參數請求Cas Server對service進行驗證，驗證通過後Cas Server將返回當前用戶的用戶名等信息。app1就會給當前用戶生成其自身的Session，以後該用戶以該Session都可以成功的訪問app1，而不需要再去請求Cas Server進行認證。當該用戶再去訪問app2的時候，由於其在app2上沒有對應的Session信息，將會跳轉到Cas Server的登錄地址，Cas Server此時發現其包含名爲CASTGC的cookie，將獲取其中包含的TGT來獲取對應的SSO Session，然後會將用戶重定向到app2對應的地址，以Service Ticket作爲查詢參數。之後app2會向Cas Server發送請求校驗該Service Ticket，校驗成功後app2將建立該用戶對應的Session信息，以後該用戶以該Session就可以自由的訪問app2了。

綜上所述，我們知道，各系統之間的單點登錄是通過Cas Server生成的SSO Session來交流的，而用戶與實際的應用系統進行交互的時候，各應用系統將建立單獨的Session，以滿足用戶與該系統的交互需求。

這有一篇關於CAS實現的文章：http://blog.csdn.net/frinder/article/details/7969925