單點登錄（SingleSign On , 簡稱 SSO ）是目前比較流行的服務於企業業務整合的解決方案之一， SSO使得在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
SSO的解決方案很多，比如收費的有UTrust、惠普靈動等，開源的有CAS、Smart SSO等，其中應用最爲廣泛的是CAS。
CAS 介紹
CAS(CentralAuthentication Service)是一款不錯的針對 Web 應用的單點登錄框架。
CAS從結構上看包括兩部分，CAS Server 爲需要獨立部署的 Web應用，CAS Client 爲非常多的客戶端提供支持，這個客戶端指單點登錄系統中的各個 Web 應用，包括 Java, .Net, PHP, Perl,Apache, uPortal, Ruby 等。
CAS 原理和協議
CAS Server需要獨立部署，主要負責對用戶的認證工作；
CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。圖是 CAS最基本的協議過程：
CAS Client 與受保護的客戶端應用部署在一起，以 Filter方式保護受保護的資源。對於訪問受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 ServiceTicket（服務票據，由 CASServer發出用於標識目標服務）
如果沒有，則說明當前用戶尚未登錄，於是將請求重定向到指定好的 CAS Server 登錄地址，並傳遞 Service（也就是要訪問的目的資源地址），以便登錄成功過後轉回該地址。
如果有，則說明當前用戶已經登錄，直接訪問目的資源地址。
用戶輸入認證信息，如果登錄成功，CAS Server 隨機產生一個相當長度、唯一、不可僞造的 ServiceTicket，並緩存以待將來驗證，之後系統自動重定向到 Service 所在地址，併爲客戶端瀏覽器設置一個 Ticket GrantedCookie（CAS會話標識）
CAS Client 在拿到 Service 和新產生的 Ticket 過後，在第 5，6 步中與 CAS Server進行身份合適，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS 的交互均採用 SSL 協議，確保，ST 和 TGC 的安全性。協議工作過程中會有 2次重定向的過程，但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的。
另外，CAS 協議中還提供了 Proxy （代理）模式，以適應更加高級、複雜的應用場景，具體介紹可以參考 CAS官方網站上的相關文檔。
瞭解CAS工作原理後，接下來會進行單點登錄的實例演示。
