SSO 是一個(gè)非常大的主題，我對(duì)這個(gè)主題有著深深的感受，自從廣州 UserGroup 的論壇成立以來，無數(shù)網(wǎng)友都在嘗試使用開源的 CAS ， Kerberos 也提供另外一種方式的 SSO ，即基于 Windows 域的 SSO ，還有就是從 2005 年開始一直興旺不衰的 SAML 。
如果將這些免費(fèi)的 SSO 解決方案與商業(yè)的 Tivoli 或 Siteminder 或 RSA Secure SSO 產(chǎn)品做對(duì)比，差距是存在的。畢竟，商業(yè)產(chǎn)品的安全性和用戶體驗(yàn)都是無與倫比的，我們現(xiàn)在提到的 SSO ，僅僅是 Web SSO ，即 Web-SSO 是體現(xiàn)在客戶端；另外一種 SSO 是桌面 SSO ，例如，只需要作為 Administrator 登錄一次 windows 2000 ，我便能夠在使用 MSN/QQ 的時(shí)候免去登錄的環(huán)節(jié) ( 注意，這不是用客戶端軟件的密碼記憶功能 ) ，是一種代理用戶輸入密碼的功能。因此，桌面 SSO 是體現(xiàn)在 OS 級(jí)別上。
今天，當(dāng)我們提起 SSO 的時(shí)候，我們通常是指 Web SSO ，它的主要特點(diǎn)是， SSO 應(yīng)用之間走 Web 協(xié)議 ( 如 HTTP/SSL) ，并且 SSO 都只有一個(gè)登錄入口。
簡(jiǎn)單的 SSO 的體系中，會(huì)有下面三種角色：
1 ， User （多個(gè)）
2 ， Web 應(yīng)用（多個(gè)）
3 ， SSO 認(rèn)證中心（ 1 個(gè)）
雖然 SSO 實(shí)現(xiàn)模式千奇百怪，但萬變不離其宗：
l Web 應(yīng)用不處理 User 的登錄，否則就是多點(diǎn)登陸了，所有的登錄都在 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)證中心對(duì)用戶身份正確性的判斷會(huì)通過某種方法告之 Web 應(yīng)用，而且判斷結(jié)果必須被 Web 應(yīng)用信任。
CAS(Central Authentication Service) 是 Yale 大學(xué)發(fā)起的一個(gè)開源項(xiàng)目，據(jù)統(tǒng)計(jì)，大概每 10 個(gè)采用開源構(gòu)建 Web SSO 的 Java 項(xiàng)目，就有 8 個(gè)使用 CAS 。對(duì)這些統(tǒng)計(jì)，我雖然不以為然，但有一點(diǎn)可以肯定的是， CAS 是我認(rèn)為最簡(jiǎn)單實(shí)效，而且足夠安全的 SSO 選擇。
本節(jié)主要分析 CAS 的安全性，以及為什么 CAS 被這樣設(shè)計(jì)，帶著少許密碼學(xué)的基礎(chǔ)知識(shí)，我希望有助于讀者對(duì) CAS 的協(xié)議有更深層次的理解。
從結(jié)構(gòu)體系看， CAS 包含兩部分：
l CAS Server
CAS Server 負(fù)責(zé)完成對(duì)用戶的認(rèn)證工作， CAS Server 需要獨(dú)立部署，有不止一種 CAS Server 的實(shí)現(xiàn)， Yale CAS Server 和 ESUP CAS Server 都是很不錯(cuò)的選擇。
CAS Server 會(huì)處理用戶名 / 密碼等憑證 (Credentials) ，它可能會(huì)到數(shù)據(jù)庫檢索一條用戶賬號(hào)信息，也可能在 XML 文件中檢索用戶密碼，對(duì)這種方式， CAS 均提供一種靈活但同一的接口 / 實(shí)現(xiàn)分離的方式， CAS 究竟是用何種認(rèn)證方式，跟 CAS 協(xié)議是分離的，也就是，這個(gè)認(rèn)證的實(shí)現(xiàn)細(xì)節(jié)可以自己定制和擴(kuò)展。
l CAS Client
CAS Client 負(fù)責(zé)部署在客戶端（注意，我是指 Web 應(yīng)用），原則上， CAS Client 的部署意味著，當(dāng)有對(duì)本地 Web 應(yīng)用的受保護(hù)資源的訪問請(qǐng)求，并且需要對(duì)請(qǐng)求方進(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)用。
剖析協(xié)議就像剖析設(shè)計(jì)模式，有些時(shí)候，協(xié)議讓人摸不著頭腦。 CAS 的代理模式要相對(duì)復(fù)雜一些，它引入了一些新的概念，我希望能夠在這里描述一下其原理，有助于讀者在配置和調(diào)試 CAS SSO 有更清晰的思路。
如果沒記錯(cuò)， CAS 協(xié)議應(yīng)該是由 Drew Mazurek 負(fù)責(zé)可開發(fā)的，從 CAS v1 到現(xiàn)在的 CAS v3 ，整個(gè)協(xié)議的基礎(chǔ)思想都是基于 Kerberos 的票據(jù)方式。
CAS v1 非常原始，傳送一個(gè)用戶名居然是 ”yes\ndavid.turing” 的方式， CAS v2 開始使用了 XML 規(guī)范，大大增強(qiáng)了可擴(kuò)展性， CAS v3 開始使用 AOP 技術(shù)，讓 Spring 愛好者可以輕松配置 CAS Server 到現(xiàn)有的應(yīng)用環(huán)境中。
CAS 是通過 TGT(Ticket Granting Ticket) 來獲取 ST(Service Ticket) ，通過 ST 來訪問服務(wù)，而 CAS 也有對(duì)應(yīng) TGT ， ST 的實(shí)體，而且他們?cè)诒Ｗo(hù) TGT 的方法上雖然有所區(qū)別，但是，最終都可以實(shí)現(xiàn)這樣一個(gè)目的——免去多次登錄的麻煩。
下面，我們看看 CAS 的基本協(xié)議框架：
<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /?>
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /?>
CAS 基礎(chǔ)模式
上圖是一個(gè)最基礎(chǔ)的 CAS 協(xié)議， CAS Client 以 Filter 方式保護(hù) Web 應(yīng)用的受保護(hù)資源，過濾從客戶端過來的每一個(gè) Web 請(qǐng)求，同時(shí)， CAS Client 會(huì)分析 HTTP 請(qǐng)求中是否包請(qǐng)求 Service Ticket( 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經(jīng)過認(rèn)證的，于是， CAS Client 會(huì)重定向用戶請(qǐng)求到 CAS Server （ Step 2 ）。 Step 3 是用戶認(rèn)證過程，如果用戶提供了正確的 Credentials ， CAS Server 會(huì)產(chǎn)生一個(gè)隨機(jī)的 Service Ticket ，然后，緩存該 Ticket ，并且重定向用戶到 CAS Client （附帶剛才產(chǎn)生的 Service Ticket ）， Service Ticket 是不可以偽造的，最后， Step 5 和 Step6 是 CAS Client 和 CAS Server 之間完成了一個(gè)對(duì)用戶的身份核實(shí)，用 Ticket 查到 Username ，因?yàn)?/span> Ticket 是 CAS Server 產(chǎn)生的，因此，所以 CAS Server 的判斷是毋庸置疑的。
該協(xié)議完成了一個(gè)很簡(jiǎn)單的任務(wù)，就是 User(david.turing) 打開 IE ，直接訪問 helloservice 應(yīng)用，它被立即重定向到 CAS Server 進(jìn)行認(rèn)證， User 可能感覺到瀏覽器在 helloservcie 和 casserver 之間重定向，但 User 是看不到， CAS Client 和 CAS Server 相互間的 Service Ticket 核實(shí) (Validation) 過程。當(dāng) CAS Server 告知 CAS Client 用戶 Service Ticket 對(duì)應(yīng)確鑿身份， CAS Client 才會(huì)對(duì)當(dāng)前 Request 的用戶進(jìn)行服務(wù)。
當(dāng)我們的 Web 時(shí)代還處于初級(jí)階段的時(shí)候， SSO 是通過共享 cookies 來實(shí)現(xiàn)，比如，下面三個(gè)域名要做 SSO ：
如果通過 CAS 來集成這三個(gè)應(yīng)用，那么，這三個(gè)域名都要做一些域名映射，
因?yàn)槭峭粋€(gè)域，所以每個(gè)站點(diǎn)都能夠共享基于 cas.org 的 cookies 。這種方法原始，不靈活而且有不少安全隱患，已經(jīng)被拋棄了。
CAS 可以很簡(jiǎn)單的實(shí)現(xiàn)跨域的 SSO ，因?yàn)?，單點(diǎn)被控制在 CAS Server ，用戶最有價(jià)值的 TGC-Cookie 只是跟 CAS Server 相關(guān)， CAS Server 就只有一個(gè)，因此，解決了 cookies 不能跨域的問題。
回到 CAS 的基礎(chǔ)協(xié)議圖，當(dāng) Step3 完成之后， CAS Server 會(huì)向 User 發(fā)送一個(gè) Ticket granting cookie (TGC) 給 User 的瀏覽器，這個(gè) Cookie 就類似 Kerberos 的 TGT ，下次當(dāng)用戶被 Helloservice2 重定向到 CAS Server 的時(shí)候， CAS Server 會(huì)主動(dòng) Get 到這個(gè) TGC cookie ，然后做下面的事情：
1， 如果 User 的持有 TGC 且其還沒失效，那么就走基礎(chǔ)協(xié)議圖的 Step4 ，達(dá)到了 SSO 的效果。
2， 如果 TGC 失效，那么用戶還是要重新認(rèn)證 ( 走基礎(chǔ)協(xié)議圖的 Step3) 。
模式 1 已經(jīng)能夠滿足大部分簡(jiǎn)單的 SSO 應(yīng)用，現(xiàn)在，我們探討一種更復(fù)雜的情況，即用戶訪問 helloservice ， helloservice 又依賴于 helloservice2 來獲取一些信息，如同：
User à helloservice à helloservice2
這種情況下，假設(shè) helloservice2 也是需要對(duì) User 進(jìn)行身份驗(yàn)證才能訪問，那么，為了不影響用戶體驗(yàn)（過多的重定向?qū)е?/span> User 的 IE 窗口不停地 閃動(dòng) ) ， CAS 引入了一種 Proxy 認(rèn)證機(jī)制，即 CAS Client 可以代理用戶去訪問其它 Web 應(yīng)用。
代理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據(jù) ) 。 與其說之前我們提到的 TGC 是用戶持有對(duì)自己身份信息的一種憑據(jù)，則這里的 PGT 就是 CAS Client 端持有的對(duì)用戶身份信息的一種憑據(jù)。憑借 TGC ， User 可以免去輸入密碼以獲取訪問其它服務(wù)的 Service Ticket ，所以，這里，憑借 PGT ， Web 應(yīng)用可以代理用戶去實(shí)現(xiàn)后端的認(rèn)證，而無需前端用戶的參與。
如下面的 CAS Proxy 圖所示， CAS Client 在基礎(chǔ)協(xié)議之上，提供了一個(gè)額外的 PGT URL 給 CAS Server, 于是， CAS Server 可以通過 PGT URL 提供一個(gè) PGT 給 CAS Client 。
初學(xué)者可能會(huì)對(duì)上圖的 PGT URL 感到迷惑，或者會(huì)問，為什么要這么麻煩，要通過一個(gè)額外的 URL( 而且是 SSL 的入口 ) 去傳遞 PGT ？如果直接在 Step 6 返回，則連用來做對(duì)應(yīng)關(guān)系的 PGTIOU 都可以省掉。 PGTIOU 設(shè)計(jì)是從安全性考慮的，非常必要， CAS 協(xié)議安全性問題我會(huì)在后面一節(jié)介紹。
于是， CAS Client 拿到了 PGT( PGTIOU-85…..ti2td ) ，這個(gè) PGT 跟 TGC 同樣地關(guān)鍵， CAS Client 可以通過 PGT 向后端 Web 應(yīng)用進(jìn)行認(rèn)證。如下圖所示， Proxy 認(rèn)證與普通的認(rèn)證其實(shí)差別不大， Step1, 2 與基礎(chǔ)模式的 EN-
聯(lián)系客服
