SSO的解決方案很多，比如收費的有UTrust、惠普靈動等，開源的有CAS、Smart SSO等，其中應用最爲廣泛的是CAS。
CAS （Central Authentication Service）中央認證服務。CAS(Central Authentication Service)是一款不錯的針對 Web 應用的單點登錄框架。
CAS 具有以下特點：
開源的企業級單點登錄解決方案。
CAS Server 爲需要獨立部署的 Web 應用。
CAS Client 支持非常多的客戶端(這裏指單點登錄系統中的各個 Web 應用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
CAS 原理和協議
結構上： CAS 包含兩部分
1、CAS Server
CAS Server 負責完成對用戶的認證工作， CAS Server 需要獨立部署，有不止一種 CAS Server 的實現。
CAS Server 會處理用戶名 / 密碼等憑證 (Credentials) ，它可能會到數據庫檢索一條用戶帳號信息，也可能在 XML 文件中檢索用戶密碼，對這種方式， CAS 均提供一種靈活但同一的接口 / 實現分離的方式， CAS 究竟是用何種認證方式，跟 CAS 協議是分離的，也就是，這個認證的實現細節可以自己定製和擴展。
2、CAS Client
CAS Client 負責部署在客戶端（指 Web 應用），原則上， CAS Client 的部署意味着，當有對本地 Web 應用的受保護資源的訪問請求，並且需要對請求方進行身份認證， Web 應用不再接受任何的用戶名密碼等類似的 Credentials ，而是重定向到 CAS Server 進行認證。
目前， CAS Client 支持（某些在完善中）非常多的客戶端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客戶端，幾乎可以這樣說， CAS 協議能夠適合任何語言編寫的客戶端應用。
協議：
整個協議的基礎思想都是基於票據方式。下面，我們看看CAS的基本協議框架：
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。對於訪問受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket，如果沒有，則說明當前用戶尚未登錄，於是將請求重定向到指定好的 CAS Server 登錄地址，並傳遞 Service （也就是要訪問的目的資源地址），以便登錄成功過後轉回該地址。用戶在第 3 步中輸入認證信息，如果登錄成功，CAS Server 隨機產生一個相當長度、唯一、不可僞造的 Service Ticket，並緩存以待將來驗證，之後系統自動重定向到 Service 所在地址，併爲客戶端瀏覽器設置一個 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新產生的 Ticket 過後，在第 5，6 步中與 CAS Server 進行身份合適，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS 的交互均採用 SSL 協議，確保，ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向的過程，但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的。
另外，CAS 協議中還提供了 Proxy （代理）模式，以適應更加高級、複雜的應用場景