1. SSO 原理淺談

       SSO 是一個非常大的主題，我對這個主題有著深深的感受，自從廣州 UserGroup 的論壇成立以來，無數(shù)網(wǎng)友都在嘗試使用開源的 CAS ， Kerberos 也提供另外一種方式的 SSO ，即基于 Windows 域的 SSO ，還有就是從 2005 年開始一直興旺不衰的 SAML 。

       如果將這些免費的 SSO 解決方案與商業(yè)的 Tivoli 或 Siteminder 或 RSA Secure SSO 產(chǎn)品做對比，差距是存在的。畢竟，商業(yè)產(chǎn)品的安全性和用戶體驗都是無與倫比的，我們現(xiàn)在提到的 SSO ，僅僅是 Web SSO ，即 Web-SSO 是體現(xiàn)在客戶端；另外一種 SSO 是桌面 SSO ，例如，只需要作為 Administrator 登錄一次 windows 2000 ，我便能夠在使用 MSN/QQ 的時候免去登錄的環(huán)節(jié) ( 注意，這不是用客戶端軟件的密碼記憶功能 ) ，是一種代理用戶輸入密碼的功能。因此，桌面 SSO 是體現(xiàn)在 OS 級別上。

       今天，當(dāng)我們提起 SSO 的時候，我們通常是指 Web SSO ，它的主要特點是， SSO 應(yīng)用之間走 Web 協(xié)議 ( 如 HTTP/SSL) ，并且 SSO 都只有一個登錄入口。

       簡單的 SSO 的體系中，會有下面三種角色：

       1 ， User （多個）

       2 ， Web 應(yīng)用（多個）

       3 ， SSO 認(rèn)證中心（ 1 個）

       雖然 SSO 實現(xiàn)模式千奇百怪，但萬變不離其宗：

l         Web 應(yīng)用不處理 User 的登錄，否則就是多點登陸了，所有的登錄都在 SSO 認(rèn)證中心進(jìn)行。

l         SSO 認(rèn)證中心通過一些方法來告訴 Web 應(yīng)用當(dāng)前訪問用戶究竟是不是張三 / 李四。

l         SSO 認(rèn)證中心和所有的 Web 應(yīng)用建立一種信任關(guān)系， SSO 認(rèn)證中心對用戶身份正確性的判斷會通過某種方法告之 Web 應(yīng)用，而且判斷結(jié)果必須被 Web 應(yīng)用信任。

2. CAS 的基本原理

       CAS(Central Authentication Service) 是 Yale 大學(xué)發(fā)起的一個開源項目，據(jù)統(tǒng)計，大概每 10 個采用開源構(gòu)建 Web SSO 的 Java 項目，就有 8 個使用 CAS 。對這些統(tǒng)計，我雖然不以為然，但有一點可以肯定的是， CAS 是我認(rèn)為最簡單實效，而且足夠安全的 SSO 選擇。

       本節(jié)主要分析 CAS 的安全性，以及為什么 CAS 被這樣設(shè)計，帶著少許密碼學(xué)的基礎(chǔ)知識，我希望有助于讀者對 CAS 的協(xié)議有更深層次的理解。

2.1 CAS 的結(jié)構(gòu)體系

從結(jié)構(gòu)體系看， CAS 包含兩部分：

l         CAS Server

CAS Server 負(fù)責(zé)完成對用戶的認(rèn)證工作， CAS Server 需要獨立部署，有不止一種 CAS Server 的實現(xiàn)， Yale CAS Server 和 ESUP CAS Server 都是很不錯的選擇。

CAS Server 會處理用戶名 / 密碼等憑證 (Credentials) ，它可能會到數(shù)據(jù)庫檢索一條用戶賬號信息，也可能在 XML 文件中檢索用戶密碼，對這種方式， CAS 均提供一種靈活但同一的接口 / 實現(xiàn)分離的方式， CAS 究竟是用何種認(rèn)證方式，跟 CAS 協(xié)議是分離的，也就是，這個認(rèn)證的實現(xiàn)細(xì)節(jié)可以自己定制和擴展。

l         CAS Client

CAS Client 負(fù)責(zé)部署在客戶端（注意，我是指 Web 應(yīng)用），原則上， CAS Client 的部署意味著，當(dāng)有對本地 Web 應(yīng)用的受保護(hù)資源的訪問請求，并且需要對請求方進(jìn)行身份認(rèn)證， Web 應(yīng)用不再接受任何的用戶名密碼等類似的 Credentials ，而是重定向到 CAS Server 進(jìn)行認(rèn)證。

目前， CAS Client 支持（某些在完善中）非常多的客戶端，包括 Java 、 .Net 、 ISAPI 、 Php 、 Perl 、 uPortal 、 Acegi 、 Ruby 、 VBScript 等客戶端，幾乎可以這樣說， CAS 協(xié)議能夠適合任何語言編寫的客戶端應(yīng)用。

2.2 CAS 協(xié)議

       剖析協(xié)議就像剖析設(shè)計模式，有些時候，協(xié)議讓人摸不著頭腦。 CAS 的代理模式要相對復(fù)雜一些，它引入了一些新的概念，我希望能夠在這里描述一下其原理，有助于讀者在配置和調(diào)試 CAS SSO 有更清晰的思路。

如果沒記錯， CAS 協(xié)議應(yīng)該是由 Drew Mazurek 負(fù)責(zé)可開發(fā)的，從 CAS v1 到現(xiàn)在的 CAS v3 ，整個協(xié)議的基礎(chǔ)思想都是基于 Kerberos 的票據(jù)方式。

       CAS v1 非常原始，傳送一個用戶名居然是 ”yes\ndavid.turing” 的方式， CAS v2 開始使用了 XML 規(guī)范，大大增強了可擴展性， CAS v3 開始使用 AOP 技術(shù)，讓 Spring 愛好者可以輕松配置 CAS Server 到現(xiàn)有的應(yīng)用環(huán)境中。

CAS 是通過 TGT(Ticket Granting Ticket) 來獲取 ST(Service Ticket) ，通過 ST 來訪問服務(wù)，而 CAS 也有對應(yīng) TGT ， ST 的實體，而且他們在保護(hù) TGT 的方法上雖然有所區(qū)別，但是，最終都可以實現(xiàn)這樣一個目的——免去多次登錄的麻煩。

       下面，我們看看 CAS 的基本協(xié)議框架：

<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /?> 2.1.1 基礎(chǔ)協(xié)議

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /?> <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /?>

                                                 CAS 基礎(chǔ)模式

       上圖是一個最基礎(chǔ)的 CAS 協(xié)議， CAS Client 以 Filter 方式保護(hù) Web 應(yīng)用的受保護(hù)資源，過濾從客戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 請求中是否包請求 Service Ticket( 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經(jīng)過認(rèn)證的，于是， CAS Client 會重定向用戶請求到 CAS Server （ Step 2 ）。 Step 3 是用戶認(rèn)證過程，如果用戶提供了正確的 Credentials ， CAS Server 會產(chǎn)生一個隨機的 Service Ticket ，然后，緩存該 Ticket ，并且重定向用戶到 CAS Client （附帶剛才產(chǎn)生的 Service Ticket ）， Service Ticket 是不可以偽造的，最后， Step 5 和 Step6 是 CAS Client 和 CAS Server 之間完成了一個對用戶的身份核實，用 Ticket 查到 Username ，因為 Ticket 是 CAS Server 產(chǎn)生的，因此，所以 CAS Server 的判斷是毋庸置疑的。

       該協(xié)議完成了一個很簡單的任務(wù)，就是 User(david.turing) 打開 IE ，直接訪問 helloservice 應(yīng)用，它被立即重定向到 CAS Server 進(jìn)行認(rèn)證， User 可能感覺到瀏覽器在 helloservcie 和 casserver 之間重定向，但 User 是看不到， CAS Client 和 CAS Server 相互間的 Service Ticket 核實 (Validation) 過程。當(dāng) CAS Server 告知 CAS Client 用戶 Service Ticket 對應(yīng)確鑿身份， CAS Client 才會對當(dāng)前 Request 的用戶進(jìn)行服務(wù)。

2.2.2 CAS 如何實現(xiàn) SSO

       當(dāng)我們的 Web 時代還處于初級階段的時候， SSO 是通過共享 cookies 來實現(xiàn)，比如，下面三個域名要做 SSO ：

http://www.

http://www.

http://www.csdn.net

如果通過 CAS 來集成這三個應(yīng)用，那么，這三個域名都要做一些域名映射，

http://blogjava.

http://matrix.

http://csdn.

因為是同一個域，所以每個站點都能夠共享基于 的 cookies 。這種方法原始，不靈活而且有不少安全隱患，已經(jīng)被拋棄了。

CAS 可以很簡單的實現(xiàn)跨域的 SSO ，因為，單點被控制在 CAS Server ，用戶最有價值的 TGC-Cookie 只是跟 CAS Server 相關(guān)， CAS Server 就只有一個，因此，解決了 cookies 不能跨域的問題。

回到 CAS 的基礎(chǔ)協(xié)議圖，當(dāng) Step3 完成之后， CAS Server 會向 User 發(fā)送一個 Ticket granting cookie (TGC) 給 User 的瀏覽器，這個 Cookie 就類似 Kerberos 的 TGT ，下次當(dāng)用戶被 Helloservice2 重定向到 CAS Server 的時候， CAS Server 會主動 Get 到這個 TGC cookie ，然后做下面的事情：

1，              如果 User 的持有 TGC 且其還沒失效，那么就走基礎(chǔ)協(xié)議圖的 Step4 ，達(dá)到了 SSO 的效果。

2，              如果 TGC 失效，那么用戶還是要重新認(rèn)證 ( 走基礎(chǔ)協(xié)議圖的 Step3) 。

2.2.2 CAS 的代理模式

       模式 1 已經(jīng)能夠滿足大部分簡單的 SSO 應(yīng)用，現(xiàn)在，我們探討一種更復(fù)雜的情況，即用戶訪問 helloservice ， helloservice 又依賴于 helloservice2 來獲取一些信息，如同：

User à helloservice à helloservice2

這種情況下，假設(shè) helloservice2 也是需要對 User 進(jìn)行身份驗證才能訪問，那么，為了不影響用戶體驗（過多的重定向?qū)е?/span> User 的 IE 窗口不停地 閃動 ) ， CAS 引入了一種 Proxy 認(rèn)證機制，即 CAS Client 可以代理用戶去訪問其它 Web 應(yīng)用。

代理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據(jù) ) 。 與其說之前我們提到的 TGC 是用戶持有對自己身份信息的一種憑據(jù)，則這里的 PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據(jù)。憑借 TGC ， User 可以免去輸入密碼以獲取訪問其它服務(wù)的 Service Ticket ，所以，這里，憑借 PGT ， Web 應(yīng)用可以代理用戶去實現(xiàn)后端的認(rèn)證，而無需前端用戶的參與。

如下面的 CAS Proxy 圖所示， CAS Client 在基礎(chǔ)協(xié)議之上，提供了一個額外的 PGT URL 給 CAS Server, 于是， CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。

       初學(xué)者可能會對上圖的 PGT URL 感到迷惑，或者會問，為什么要這么麻煩，要通過一個額外的 URL( 而且是 SSL 的入口 ) 去傳遞 PGT ？如果直接在 Step 6 返回，則連用來做對應(yīng)關(guān)系的 PGTIOU 都可以省掉。 PGTIOU 設(shè)計是從安全性考慮的，非常必要， CAS 協(xié)議安全性問題我會在后面一節(jié)介紹。

于是， CAS Client 拿到了 PGT( PGTIOU-85…..ti2td ) ，這個 PGT 跟 TGC 同樣地關(guān)鍵， CAS Client 可以通過 PGT 向后端 Web 應(yīng)用進(jìn)行認(rèn)證。如下圖所示， Proxy 認(rèn)證與普通的認(rèn)證其實差別不大， Step1, 2 與基礎(chǔ)模式的 EN-