單點登陸系統構建之二——SSO原理及CAS架構

基本概念

SSO（Single Sign On）單點登陸，是在多個應用系統中，用戶只須要登陸一次就能訪問全部相互信任的應用系統。它包括將此次的主要登陸映射到其餘應用中用戶同一個用戶的登陸機制。

SSO能夠分爲Web SSO和桌面SSO，Web SSO體如今客戶端，桌面SSO則是操做系統級別的SSO（如登陸了Windows就可使用QQ）。

如今咱們所講的SSO，一般是Web SSO，也就是SSO應用間走Web協議（HTTP/SSL），而且多個應用共享一個SSO入口。

原理介紹

系統角色

User

User能夠有多個，User訪問Web應用並被SSO認證中心鑑權和受權。

Web應用

Web應用能夠有多個，而且受SSO認證中心的保護，是User訪問的目標。

SSO認證中心

僅包含一個，用戶未受權的訪問請求會被重定向到SSO認證中心。

CAS

CAS是耶魯（Yale）大學發起的一個開源項目，在Java Web SSO中，CAS佔據了大約八成的份額，簡單時效且足夠安全。

CAS的體系結構

CAS Server

CAS Server完成對用戶的認證工做，CAS Server須要獨立部署，有不止一種CAS Server實現。Yale CAS Server和ESUP CAS Server都是不錯的選擇。

CAS Server 會處理用戶名/密碼等憑證，並可能從數據庫或其餘來源檢索用戶名和密碼，對於這種方式，CAS提供靈活的接口/實現分離方式，意味着CAS Server能夠支持任何的認證方式，而且與CAS協議分離。

CAS Client

CAS Client負責部署在客戶端（Web應用側）。當有對本地受保護的Web資源的訪問請求，而且須要對請求方進行身份驗證，Web應用再也不接受任何用戶名/密碼等相似的Credentials，而是重定向到CAS Server進行認證。

目前CAS Client支持很是多的客戶端（Java/PHP/.Net）等。

CAS協議

CAS協議有從v1到v3的版本，在v2版本中開始支持了XML，在v3版本中支持了AOP，所以對於使用Spring開發的項目來講是很是友好的。

CAS協議的基礎思想都是基於Kerberos的票據方式。

基礎協議

 

                                      圖1 基礎模式

1. CAS Client以Filter的形式保護Web應用的受保護資源，過濾從客戶端過來的每個請求（Step 1）。
2. CAS Client分析HTTP請求中是否包含Service Ticket，若是沒有則重定向到CAS Server（Step 2）。
3. 用戶認證過程，若是用戶提供了正確的Credentials，CAS Server會產生隨機的Ticket，而後緩存該Ticket（Step3），並生成TGC（Ticket Grant Cookie）給User瀏覽器。
4. 並重定向用戶到CAS Client並攜帶剛纔產生的Ticket（Step4）。
5. CAS Client與CAS Server經過Ticket完成身份認真（Step4和Step5）。
6. 驗證成功後，CAS Client對當前Request用戶進行服務。
7. 用戶再次訪問時攜帶TGC，CAS Server會判斷該Cookie的有效性並決定是否再次驗證。

CAS代理模式

基礎協議已經可以知足絕大多數的場景，可是對於經過service1訪問service2這種場景就無能爲力了，若是咱們對service2也進行驗證，從用戶角度來講，將會看到頻繁的重定向，所以引入了Proxy（代理）模式，由CAS Client代理用戶去訪問其餘Web應用。

代理的前提是須要CAS Client擁有身份信息（相似憑據），用戶持有的TGC（Ticket Granted Cookie），而代理持有的是PGT（Proxy Granted Ticket），憑藉TGC用戶能夠免登錄獲取其餘應用的Service Ticket，一樣的，經過PGT，Web應用能夠代理用戶實現後端認真而無需前端的用戶參與。

如何獲取PGT？

以下圖示，CAS Client在基礎協議之上，提供了一個額外的PGT URL給CAS Server，CAS Server經過該接口提供PGT給CAS Client。

 

                                          圖2 Proxy模式

與基礎協議不一樣，在Proxy模式中起做用的是PT（Proxy Ticket），基礎模式使用的是ST（Service Ticket）。

 

                                   圖3 代理模式的訪問模式

當helloservice須要helloservice2的數據時，helloservice首先使用本身保存的PGT向CAS Server獲取PT。

當獲取到PT以後，helloservice攜帶該PT向helloservice2請求數據。

Helloservice2使用該PT向CAS Server驗證請求，CAS Server返回驗證結果。

Helloservice2此時知道能夠合法的爲Helloservice服務，從而返回數據。

業界方案

JA-SIG CAS

開源SSO實現中最爲成熟的一個，良好的安全性和易用性。

並且CAS客戶端有Java，.Net，以及PHP版本，良好支持了現有產品，SSO將會基於CAS進行開發。

http://www.jasig.org/cas 

JOSSO

較早的一個實現，但與技術綁定過深，缺少良好的適用性和文檔。

CoSign

相似於CAS的一個實現，CAS Server基於GCI，在C/C++項目中使用較多。

WebAuth

很是早期的SSO方案，使用Perl編寫，對Java的支持性不好。

OpenSSO

被甲骨文收購，再也不提供支持

CAS安全性

CAS的安全性是很是重要的，從CAS V1到V3，其都依賴與SSL，它假定了用戶在一個很是不安全的環境中使用SSO，HTTP傳送的密碼和Ticket票據都是不安全的。

TGC/PGT的安全性

對於一個CAS用戶來講，最重要的事情是保護他的TGC，若是TGC被黑客獲取，黑客就會使用該TGC訪問全部的應用。

對SSO來講，這種風險是巨大的，由於SSO具備一種門檻效應，一旦登陸就會獲取相關服務的全部權限。

TGC保存在客戶端，其安全性徹底有SSL保證。

TGC也有本身的存活週期，在CAS的web.xml中，能夠經過grantingTimeout來設置CAS TGC的存活週期。

該週期須要慎重設置，既不影響用戶體驗，不能帶來太高的安全風險（避免被盜用）。

Service Ticket/Proxy Ticket的安全性

Service Ticket/Proxy Ticket是經過HTTP傳送的，所以網絡中的其餘人是能夠嗅探到他人的Ticket的。

CAS協議從如下幾個方面讓ST/PT更加安全。

1. Service Ticket只能使用一次
2. Service Ticket一段時間後失效

經過在web.xml中配置以下參數。

<context-param>
<param-name>edu.yale.its.tp.cas.serviceTimeout</param-name>
<param-value>300</param-value>
</context-param>

1. ST/PT的生成必須足夠隨機

避免被猜出生成規則

SAML

SAML是OASIS制定的安全性斷言標記語言，用於在複雜環境下交互用戶的身份識別信息，正在被愈來愈多的商用產品支持。

SAML與SOAP同樣，不考慮具體的傳輸協議，實際上能夠與HTTP/SSL/JMS等任何傳輸協議捆綁。對於複雜的服務構型，因爲不一樣服務可能有不一樣的協議，使用CAS將沒法完成，由於CAS是基於HTTP/SSL上的，只有SAML能完成這項任務，由於其與傳輸協議無關。

最後，SAML是一種SSO標準而CVS是一種SSO實現，從CAS的RoadMap中能夠看出，其也將很快支持SAML。