單點登錄SSO（Single Sign On）想必大家都耳熟能詳，企業信息化過程中會不斷的衍生出不同技術平臺、不同業務範圍、不同場景的應用或支持系統，與此同時我們也有可能會因爲高層架構的決策會採用SSO這種模式來組織、細化不同職責的子系統登錄；總的來說SSO的好處如下：
1、從擴展性層面上，提供了統一的標準，便於不同時期APP的部署與接入
2、從兼容性方面，便於不同技術平臺的應用系統無縫接入
3、從數據共享層面，便於用戶、賬號信息的集中存儲與統一管理，便於賬戶安全性的管理
4、從開發成本層面上，提高了開發的效率，減少了維護量
5、從友好性層面上，便於終端用戶的賬號管理與維護
提高了終端用戶使用不同平臺的便捷與高效性
當然如能確保在很長一段時期內，系統不會有多個登錄應用出現或者每個應用不需要支持一鍵登錄，那麼可以簡單原則不必考慮SSO。
SSO的實現分兩種機制SESSION、COOKIE，絕大大部分的企業應用一般都採用後者，例如：盛大的sdo.com、www.shengpay.com，其實現原理大致如下：
1、登錄
主要過程：
在實施過程中，往往可能有以下特殊情況：由SSO服務端提供登錄嵌入頁面，APP增加判斷用戶是否爲變更登錄
2、註銷
略
目前CAS被認爲是最好的單點登錄開源產品，大部分的公司也都在用，雖然CAS是JAVA語言開發的，但它提供了不少的接入支持組件，有關CAS的相關描述請見：
2、CAS協議：http://www.jasig.org/cas/protocol
一般來說，搭建CAS驗證需要兩個步驟：
1、搭建CAS服務器
一般來說，應該可以滿足需要，如有特殊邏輯，可以考慮適當修改CAS代碼。
另外，一般服務驗證都會採用SSL協議來保證SSO的安全性機制，具體請參見SSL實現：http://blog.csdn.net/webwalker/article/details/5658155
結合CAS的實現請參加上述的step by step
2、實現應用端驗證模塊
客戶端應用程序可以通過三個URL路徑來使用，分別是登錄URL（login URL），校驗URL（validation URL）和登出URL（logout URL）
當然除了SSO之外，現在很多線上應用大都已提供開放平臺，向外部應用平臺提供內部用戶登錄的標識驗證，大大的增加了終端用戶賬號管理的方便性、統一性，似乎可以把這類模型的互聯看成是基於SOA的驗證架構的，那麼大膽的假想下一步是不是可以考慮每個互聯網用戶只有唯一的互聯網賬號？這或許這是個有意思的但是又不太可能的問題。