1. SSO 原理淺談
SSO 是一個(gè)非常大的主題，我對這個(gè)主題有著深深的感受，自從廣州 UserGroup 的論壇成立以來，無數(shù)網(wǎng)友都在嘗試使用開源的 CAS ， Kerberos 也提供另外一種方式的 SSO ，即基于 Windows 域的 SSO ，還有就是從 2005 年開始一直興旺不衰的 SAML 。
如果將這些免費(fèi)的 SSO 解決方案與商業(yè)的 Tivoli 或 Siteminder 或 RSA Secure SSO 產(chǎn)品做對比，差距是存在的。畢竟，商業(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 級別上。
今天，當(dāng)我們提起 SSO 的時(shí)候，我們通常是指 Web SSO ，它的主要特點(diǎn)是， SSO 應(yīng)用之間走 Web 協(xié)議 ( 如 HTTP/SSL) ，并且 SSO 都只有一個(gè)登錄入口。
簡單的 SSO 的體系中，會有下面三種角色：
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)證中心對用戶身份正確性的判斷會通過某種方法告之 Web 應(yīng)用，而且判斷結(jié)果必須被 Web 應(yīng)用信任。
2. CAS 的基本原理
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 。對這些統(tǒng)計(jì)，我雖然不以為然，但有一點(diǎn)可以肯定的是， CAS 是我認(rèn)為最簡單實(shí)效，而且足夠安全的 SSO 選擇。
本節(jié)主要分析 CAS 的安全性，以及為什么 CAS 被這樣設(shè)計(jì)，帶著少許密碼學(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 需要獨(dú)立部署，有不止一種 CAS Server 的實(shí)現(xiàn)， Yale CAS Server 和 ESUP CAS Server 都是很不錯的選擇。
CAS Server 會處理用戶名 / 密碼等憑證 (Credentials) ，它可能會到數(shù)據(jù)庫檢索一條用戶賬號信息，也可能在 XML 文件中檢索用戶密碼，對這種方式， 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)有對本地 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è)計(jì)模式，有些時(shí)候，協(xié)議讓人摸不著頭腦。 CAS 的代理模式要相對復(fù)雜一些，它引入了一些新的概念，我希望能夠在這里描述一下其原理，有助于讀者在配置和調(diào)試 CAS SSO 有更清晰的思路。
如果沒記錯， 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 也有對應(yīng) TGT ， ST 的實(shí)體，而且他們在保護(hù) TGT 的方法上雖然有所區(qū)別，但是，最終都可以實(shí)現(xiàn)這樣一個(gè)目的——免去多次登錄的麻煩。
下面，我們看看 CAS 的基本協(xié)議框架：
2.1.1 基礎(chǔ)協(xié)議
CAS 基礎(chǔ)模式
上圖是一個(gè)最基礎(chǔ)的 CAS 協(xié)議， CAS Client 以 Filter 方式保護(hù) Web 應(yīng)用的受保護(hù)資源，過濾從客戶端過來的每一個(gè) Web 請求，同時(shí)， 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)生一個(gè)隨機(jī)的 Service Ticket ，然后，緩存該 Ticket ，并且重定向用戶到 CAS Client （附帶剛才產(chǎn)生的 Service Ticket ）， Service Ticket 是不可以偽造的，最后， Step 5 和 Step6 是 CAS Client 和 CAS Server 之間完成了一個(gè)對用戶的身份核實(shí)，用 Ticket 查到 Username ，因?yàn)?Ticket 是 CAS Server 產(chǎn)生的，因此，所以 CAS Server 的判斷是毋庸置疑的。
該協(xié)議完成了一個(gè)很簡單的任務(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 對應(yīng)確鑿身份， CAS Client 才會對當(dāng)前 Request 的用戶進(jìn)行服務(wù)。
2.2.2 CAS 如何實(shí)現(xiàn) SSO
當(dāng)我們的 Web 時(shí)代還處于初級階段的時(shí)候， SSO 是通過共享 cookies 來實(shí)現(xiàn)，比如，下面三個(gè)域名要做 SSO ：
http://www.blogjava.nethttp://www.matrix.org.cnhttp://www.csdn.net如果通過 CAS 來集成這三個(gè)應(yīng)用，那么，這三個(gè)域名都要做一些域名映射，
http://blogjava.cas.orghttp://matrix.cas.orghttp://csdn.cas.org因?yàn)槭峭粋€(gè)域，所以每個(gè)站點(diǎn)都能夠共享基于 cas.org 的 cookies 。這種方法原始，不靈活而且有不少安全隱患，已經(jīng)被拋棄了。
CAS 可以很簡單的實(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 會向 User 發(fā)送一個(gè) Ticket granting cookie (TGC) 給 User 的瀏覽器，這個(gè) Cookie 就類似 Kerberos 的 TGT ，下次當(dāng)用戶被 Helloservice2 重定向到 CAS Server 的時(shí)候， CAS Server 會主動 Get 到這個(gè) 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)行身份驗(yàn)證才能訪問，那么，為了不影響用戶體驗(yàn)（過多的重定向?qū)е?User 的 IE 窗口不停地 閃動 ) ， CAS 引入了一種 Proxy 認(rèn)證機(jī)制，即 CAS Client 可以代理用戶去訪問其它 Web 應(yīng)用。
代理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據(jù) ) 。 與其說之前我們提到的 TGC 是用戶持有對自己身份信息的一種憑據(jù)，則這里的 PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據(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é)者可能會對上圖的 PGT URL 感到迷惑，或者會問，為什么要這么麻煩，要通過一個(gè)額外的 URL( 而且是 SSL 的入口 ) 去傳遞 PGT ？如果直接在 Step 6 返回，則連用來做對應(yīng)關(guān)系的 PGTIOU 都可以省掉。 PGTIOU 設(shè)計(jì)是從安全性考慮的，非常必要， CAS 協(xié)議安全性問題我會在后面一節(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ǔ)模式的 Step 1,2 幾乎一樣，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。
最終的結(jié)果是， helloservice2 明白 helloservice 所代理的客戶是 David. Turing 同學(xué)，同時(shí)，根據(jù)本地策略， helloservice2 有義務(wù)為 PGTURL=http://helloservice/proxy 服務(wù) (PGTURL 用于表示一個(gè) Proxy 服務(wù) ) ，于是它傳遞數(shù)據(jù)給 helloservice 。這樣， helloservice 便完成一個(gè)代理者的角色，協(xié)助 User 返回他想要的數(shù)據(jù)。
代理認(rèn)證模式非常有用，它也是 CAS 協(xié)議 v2 的一個(gè)最大的變化，這種模式非常適合在復(fù)雜的業(yè)務(wù)領(lǐng)域中應(yīng)用 SSO 。因?yàn)?，以前我們?shí)施 SSO 的時(shí)候，都是假定以 IE User 為 SSO 的訪問者，忽視了業(yè)務(wù)系統(tǒng)作為 SSO 的訪問者角色。
2.3 CAS 安全性
CAS 的安全性是一個(gè)非常重要的 Topic 。 CAS 從 v1 到 v3 ，都很依賴于 SSL ，它假定了這樣一個(gè)事實(shí)，用戶在一個(gè)非常不安全的網(wǎng)絡(luò)環(huán)境中使用 SSO ， Hacker 的 Sniffer 會很容易抓住所有的 Http Traffic ，包括通過 Http 傳送的密碼甚至 Ticket 票據(jù)。
2.3.1 TGC/PGT 安全性
對于一個(gè) CAS 用戶來說，最重要是要保護(hù)它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實(shí)體獲得， Hacker 能夠找到該 TGC ，然后冒充 CAS 用戶訪問所有授權(quán)資源。
SSO 的安全性問題比普通應(yīng)用的安全性還要嚴(yán)重，因?yàn)?SSO 存在一種門檻效應(yīng)。以前即使 Hacker 能夠截獲用戶在 Web 應(yīng)用 A 的密碼，它也未必能知道用戶在 Web 應(yīng)用 B 的密碼，但 SSO 讓 Hacker 只需要截獲 TGC( 突破了門檻 ) ，即能訪問所有與該用戶相關(guān)的所有應(yīng)用系統(tǒng)。
PGT 跟 TGC 的角色是一樣的，如果被 Hacker 獲得，后果可想而知。
從基礎(chǔ)模式可以看出， TGC 是 CAS Server 通過 SSL 方式發(fā)送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。
因此，某些人認(rèn)為 CAS 可以不使用 SSL 的想法需要更正一下， CAS 的傳輸安全性僅僅依賴與 SSL 。
跟 Kerberos 一樣 TGT ， TGC 也有自己的存活周期。下面是 CAS 的 web.xml 中，通過 grantingTimeout 來設(shè)置 CAS TGC 存活周期的參數(shù)，參數(shù)默認(rèn)是 120 分鐘，在合適的范圍內(nèi)設(shè)置最小值，太短，會影響 SSO 體驗(yàn)，太長，會增加安全性風(fēng)險(xiǎn)。
<context-param>
<param-name>edu.yale.its.tp.cas.grantingTimeout</param-name>
<param-value>7200</param-value>
</context-param>
TGC 面臨的風(fēng)險(xiǎn)主要并非傳輸竊取。比如你登陸了之后，沒有 Logout ，離開了電腦，別人就可以打開你的瀏覽器，直接訪問你授權(quán)訪問的應(yīng)用 ) ，設(shè)置一個(gè) TGC 的有效期，可以減少被別人盜用，或者被 Hacker 入侵你的電腦直接獲取你系統(tǒng)目錄下的 TGC Cookie 。
2.3.2 Service Ticket/Proxy Ticket 安全性
首要明白， Service Ticket 是通過 Http 傳送的，以為著所網(wǎng)絡(luò)中的其他人可以 Sniffer 到其他人的 Ticket 。
CAS 協(xié)議從幾個(gè)方面讓 Service Ticket 變得更加安全。
l Service Ticket 只能使用一次。
CAS 協(xié)議規(guī)定，無論 Service Ticket 驗(yàn)證是否成功， CAS Server 都會將服務(wù)端的緩存中清除該 Ticket ，從而可以確保一個(gè) Service Ticket 被使用兩次。
l Service Ticket 在一段時(shí)間內(nèi)失效。
假設(shè)用戶拿到 Service Ticket 之后，他請求 helloservice 的過程又被中斷了， Service Ticket 就被空置了，事實(shí)上，此時(shí)， Service Ticket 仍然有效。 CAS 規(guī)定 Service Ticket 只能存活一定的時(shí)間，然后 CAS Server 會讓它失效。通過在 web.xml 中配置下面的參數(shù)，可以讓 Service Ticket 在多少秒內(nèi)失效。
<context-param>
<param-name>edu.yale.its.tp.cas.serviceTimeout</param-name>
<param-value>300</param-value>
</context-param>
該參數(shù)在業(yè)務(wù)應(yīng)用的條件范圍內(nèi)，越小越安全。
l Service Ticket 是基于隨機(jī)數(shù)生成的。
Service Ticket 必須足夠隨機(jī)，如果 Service Ticket 生成規(guī)則被猜出（如果你使用了 ST+Helloservice+ 自增序列的方式， Hacker 就可以構(gòu)造下一個(gè) Ticket ）， Hacker 就等于繞過 CAS 認(rèn)證，直接訪問所有服務(wù)。
3. CAS 以外的其他開源 SSO 方案
除了 CAS 之外，還有很多開源的 SSO 方案，采用何種方案跟用戶的應(yīng)用環(huán)境有比較大的關(guān)系。 SSO 的優(yōu)劣一般要考慮易用性，安全性，性能，擴(kuò)展性等因素。
3.1 JOSSO
經(jīng)常聽到別人討論 JOSSO ， JOSSO （ www.josso.org ）是我很早就用過的 SSO 開源項(xiàng)目，我后來拋棄了它，因?yàn)樗嬖诒容^多缺點(diǎn)，下面我們來看看：
1， 沒有將后臺認(rèn)證與 SSO 分離，過分強(qiáng)調(diào) JAAS ， Axis 等
JOSSO 官方網(wǎng)站發(fā)布了 JOSSO 三個(gè)基準(zhǔn)：
Standard Based
JOSSO security infrastructure is based on JAAS (Java Authentication and Authorization Service) JOSSO uses web services implementing Axis as the distributed infrastructure. JOSSO uses Struts and JSP standards
這些標(biāo)準(zhǔn)可以看到 JOSSO 的適應(yīng)性存在較大的限制，因?yàn)?SSO 其實(shí)并不關(guān)心認(rèn)證細(xì)節(jié)，作為一個(gè)開源項(xiàng)目，不應(yīng)該引用過多的技術(shù)，如 Axis ，因?yàn)檫@個(gè)世界還有很多人用 Xfire 。
2， 沒有描述 SSO 協(xié)議的 UseCase 圖
從 JOSSO 的網(wǎng)站，似乎都看不到一個(gè) SSO 的 UseCase ，容易讓那些關(guān)注安全性的大型項(xiàng)目負(fù)責(zé)人感到憂慮。
3， 缺乏廣泛的 SSO 客戶端支持
JOSSO 的支持的客戶端比較少，這個(gè)跟他的 Memember Team 、 Contributor Team 有比較大的關(guān)系。
4， 缺乏成功案例
讀者使用任何 SSO 開源方案之前，有必要先了解次方案的成功案例， CAS 全球有 50 多個(gè)大學(xué)在使用 ( 大學(xué)對 SSO 的要求往往更復(fù)雜 ) 成功案例，這方面， JOSSO 跟 CAS 存在很大的差距。
5， 不支持跨域的落后設(shè)計(jì)
當(dāng)然， JOSSO 不支持跨域是因?yàn)樗褂昧斯蚕?cookie ，下面的話截取于 JOSSO 的官方文檔：
JOSSO uses a session HTTP cookie to keep track of the SSO session identifier. This cookie lives as long as the browser window is open, being sent only in requests associated with the domain that generated it. This means that all JOSSO partner applications must be accessed using the same domain.
這段話給我們一個(gè)提示，如果設(shè)計(jì) SSO 的時(shí)候，使用了 cookie 來在 SSO Server 和 SSO Agent( 相當(dāng)于 CAS 的 CAS Client) 之間共享用戶信息，那么這個(gè)協(xié)議是無法突破跨域限制的。因?yàn)楫?dāng)多個(gè) SSO Agent 如果不使用同一個(gè)域名，也就是 Microsoft.com 和 IBM.com 無法共享同一個(gè) cookie ， JOSSO 采用了一種 DNS 技巧，即使用 Microsoft.sso.com 和 ibm.sso.com 來共享 cookie ，但這帶來的問題同樣很多，尤其是業(yè)務(wù)系統(tǒng)本身存在一些對域名限制的業(yè)務(wù)邏輯的時(shí)候，需要改動原來業(yè)務(wù)系統(tǒng)，這不是一件好受的事情。
3.2 CoSign
CoSign 原先是 Michigan 大學(xué)的一個(gè) SSO 項(xiàng)目， CoSign 是一個(gè)很不錯的設(shè)計(jì)，但是它跟 CAS 比較相似，都是基于 Kerberos 方式的協(xié)議，一個(gè)最大的不同是 CoSign 的 SSO Server 是基于 CGI(Java Fans 更多會選擇 CAS) ，對 C/C++ 的群體應(yīng)該是一個(gè)不錯的選擇。 CoSign 協(xié)議的 UseCase 跟 CAS 很相似， CoSign 的客戶端雖然也支持 J2EE/Apache/MSAPI(IIS) ，但它的 Server 端使用 C 來編寫，影響了在 Java 群體中的使用。 CoSign 是一個(gè)不錯的選擇，可能是因?yàn)楸救吮容^喜歡 Kerberos Model 的原因吧。
3.3 WebAuth
WebAuth 是一種早期的 SSO 方案，它的 WebServer 是用 perl 來編寫的，客戶端支持 Apache ， C++ ， Perl 等，當(dāng)然， WebAuth 推出的時(shí)候， Java 并不是很流行，現(xiàn)在，要讓 WebAuth 跟眾多的 Java 產(chǎn)品結(jié)合不是一件容易的事情。
WebAuth 的協(xié)議適用了 Share Secret ，即 SSO Server 和 SSO Client 之間存在一個(gè)對稱密鑰 (symmetric key ) 。 SSO Server 和 SSO Client 之間的信任關(guān)系通過這個(gè) Key 來保障。
上圖中展示了一個(gè) WebAuth 的基本模式， Client 就是瀏覽器用戶， Generic Web Service 是 SSO Client ， WebAuth Service 和 Auth Service 可以看作是 SSO Server 。
當(dāng)瀏覽器發(fā)起一個(gè)對 Web 應(yīng)用的訪問請求時(shí)，這個(gè)請求未授權(quán)，因此被重定向到 WebAuth Service 進(jìn)行認(rèn)證，認(rèn)證的結(jié)果是獲得一個(gè)經(jīng)過 symmetric key 加密的 token ，而這個(gè) Token 只有 Generic Web Service 能夠解密，因此， Web 應(yīng)用能夠知道瀏覽器用戶的身份。使用對稱加密來共享用戶身份信息存在一定的安全隱患，首先是 WebAuth Service 如何保護(hù)這些對稱密鑰 ( 保護(hù)密鑰安全本身是一件很困難的事情 ) ，一旦這些對稱密鑰被泄漏了， Token 就可以被隨意篡改。另外，由于 Token 本身是基于 Cookie 方式發(fā)送，因此，只要 Hacker 能夠復(fù)制這個(gè) Token ，他同樣可以訪問其他應(yīng)用。
如果不考慮安全性問題， WebAuth 的效率應(yīng)該比其他 SSO 方案要高，因?yàn)樗膮f(xié)議沒有 CAS/CoSign 那么復(fù)雜， WebAuth 中， SSO Server 不需要跟 SSO Client 通訊以確認(rèn)用戶的身份，用戶的身份就放在 Token 中。
4. SAML
SAML 是 OASIS 制定的一種安全性斷言標(biāo)記語言，它用于在復(fù)雜的環(huán)境下交換用戶的身份識別信息。在 SAML 誕生之前，如果想在 Websphere 、 Weblogic 和 SunONE 等之間實(shí)現(xiàn) SSO ，我們必須分別實(shí)現(xiàn)一個(gè)適配層，來達(dá)成一種相互理解的協(xié)議，在該協(xié)議上，產(chǎn)品能夠共享各自的用戶認(rèn)證 / 授權(quán)信息。 SAML 誕生之后，我們免去了這種煩惱?？梢灶A(yù)計(jì)，將來大部分產(chǎn)品都可以實(shí)現(xiàn)基于 SAML 的聯(lián)邦服務(wù)。
事實(shí)傷， SAML 已經(jīng)在很多商業(yè) / 開源產(chǎn)品中得到實(shí)現(xiàn)，包括：
l IBM Tivoli Access Manager
l
BEA Weblogic
l Oblix NetPoint
l SunONE Identity Server
l Baltimore, SelectAccess
l Entegrity Solutions AssureAccess
l Internet2 OpenSAML
l Yale CAS 3
l Netegrity SiteMinder
l Sigaba Secure Messaging Solutions
l RSA Security ClearTrust
l VeriSign Trust Integration Toolkit
l Entrust GetAccess 7
SAML 背后是強(qiáng)大的商業(yè)聯(lián)盟和開源聯(lián)盟，盡管 Microsoft 遲遲未能在 SAML 2.0 觀點(diǎn)上達(dá)成一致，但它也正努力跟進(jìn)SAML標(biāo)準(zhǔn)化過程，由此可見SAML協(xié)議已經(jīng)是勢在必行。
4.1 SAML 的基本概念
理解 SAML 的概念很重要，個(gè)人認(rèn)為 SAML 協(xié)議的原理跟 CAS/Kerberos 很類似，理解上不存在困難，但 SAML 引入了一些新的概念名詞，因此要先把握清楚這些概念。
斷言，這個(gè)在 SAML 的 ”A” ，是整個(gè) SAML 協(xié)議中出現(xiàn)的最多的字眼，我們可以將斷言看作是一種判斷，并且我們相信這種判斷，因此，做出斷言的一方必須被信賴。校驗(yàn)來自斷言方的斷言必須通過一些手段，比如數(shù)字簽名，以確保斷言的確實(shí)來自斷言方。
SAML 目標(biāo)是讓多個(gè)應(yīng)用間實(shí)現(xiàn)聯(lián)邦身份 (Identity Federation) ，提起聯(lián)邦，大家可以想象一下歐盟，歐盟國家之間的公民都具有一個(gè)聯(lián)邦身份，比如 Peter 是法國公民， John 是比利時(shí)公民，這兩個(gè)公民的身份都能夠互相被共享，恰好，張三是一個(gè)中國公民，但他能像 Peter 和 Jhhn 那樣隨意進(jìn)入歐盟國家，顯然不能，因?yàn)樗痪哂袣W盟聯(lián)邦身份。
理解了聯(lián)邦的概念，我們就可以回到 SAML 上， SAML 解決了聯(lián)邦環(huán)境中如何識別身份信息共享的標(biāo)準(zhǔn)化問題，比如，法國的 Peter 進(jìn)入比利時(shí)，他如何證明自己的身份呢？
SAML 就是為了解決這個(gè)問題。
在聯(lián)邦環(huán)境中，通常有下面的 3 種實(shí)體：
l Subject ( 主題 ) ： Subject 是 SAML 實(shí)體中的第一個(gè)重要的概念， Subject 包括了 User 、 Entity 、 Workstation 等能夠象征一個(gè)參與信息交換的實(shí)體。
l Relying Party ( 信任方 ) ： SAML 中的 Service Provider 角色，也就是提供服務(wù)的一方。
l Asserting Party ( 斷言方 ) ： SAML 中的 Identity Provider 角色，用于提供對主題的身份信息的正確的斷言，類似一個(gè)公證機(jī)構(gòu)。
我們看看聯(lián)邦環(huán)境的一個(gè)場景：
假設(shè)有一個(gè) Peter(Subject) 的法國公民，他需要訪問比利時(shí) (Service Provider) ，他在比利時(shí)機(jī)場被要求提供身份信息， Peter 提供了歐盟 (Federation) 的通行證件，隨即，這個(gè)通行證件在比利時(shí)機(jī)場被審核，或通過計(jì)算機(jī)送到歐盟身份認(rèn)證中心 (Identity Provider) ，該中心有一個(gè)由所有歐盟國家共同建立的公民數(shù)據(jù)庫，中心審核了 Peter 的身份信息，并斷言“ Yes ， He is Peter From France ”，于是， Peter 得到禮貌的回應(yīng)“歡迎光臨比利時(shí)”。
如果你將歐盟看作是一個(gè)聯(lián)邦環(huán)境，你會發(fā)現(xiàn)上面的場景跟在聯(lián)邦環(huán)境應(yīng)用 SAML 很相似。
在聯(lián)邦環(huán)境下，任何需要授權(quán)訪問的服務(wù)都需要知道服務(wù)請求方的身份主題信息 (Who are you) ，服務(wù)提供方 (Service Provider) 不負(fù)責(zé)審核用戶的身份信息，但它依賴于 1 個(gè)甚至多個(gè) Identity Provider 來完成此任務(wù)，見下圖。
1 個(gè) Idnetity Provider 可以被多個(gè) Service Provider 共享，當(dāng)然，共享的前提是建立信任關(guān)系 ( 即 Service Provider 要信任 Idnetity Provider) ，就好比如，如果比利時(shí) (Service Provider) 需要開放對歐盟國家成員訪問，它信任歐盟的 Idnetity Provider ，它信任歐盟的 Idnetity Provider 的任何判斷，包括 ”He is Peter From France” 。至于是否讓 Peter 入境，那是受權(quán)限策略的控制 ( 注意 SAML 同樣對 Authorization 斷言做了標(biāo)準(zhǔn)化，此處，我們僅僅關(guān)注 Authentication) 。
4.2 SAML 的 2 種典型模式
在協(xié)議的角度， SAML 原理非常類似 CAS 和 Kerberos ， CAS 協(xié)議依賴于 CAS Server ， Kerberos 依賴于 KDC ，而 SAML 則依賴于 Identity Provider 。
根據(jù) Service Provider( 以下簡稱 SP) 和 Identity Provider( 以下簡稱 IDP) 的交互方式， SAML 可以分為以下幾種模式：一種是 SP 拉方式，一種是 IDP 推方式。
在 SAML 中，最重要的環(huán)節(jié)是 SP 如何獲取對 Subject 的斷言， SP 拉方式是 SP 主動到 IDP 去了解 Subject 的身份斷言，而 IDP 推方式則是 IDP 主動把 Subject 的身份斷言通過某種途徑告訴 SP 。
2.2.1 SAML 的 POST/Artifact Bindings 方式（即 SP 拉方式）
該方式的主要特點(diǎn)是， SP 獲得客戶端的憑證 ( 是 IDP 對 Subject 的一種身份認(rèn)可 ) 之后，主動請求 IDP 對 Subject 的憑證的斷言。如下圖所示： Subject 是根據(jù)憑證去訪問 SP 的。憑證代表了 Subject 的身份，它類似于“來自 IDP 證明：我就是 Peter ，法國公民”。
現(xiàn)在，讓我們看看 SP 拉方式是如何進(jìn)行的：
Subject 訪問 SP 的受保護(hù)資源， SP 發(fā)現(xiàn) Subject 的請求中沒有包含任何的授權(quán)信息，于是它重定向用戶訪問 IDP.
協(xié)議執(zhí)行：
1， Subject 向 IDP 請求憑證 ( 方式是提交用戶名 / 密碼 )
2， IDP 通過驗(yàn)證 Subject 提供的信息，來確定是否提供憑證給 Subject
3， 假如 Subject 的驗(yàn)證信息正確，他將獲取 IDP 的憑證以及將服務(wù)請求同時(shí)提交給 SP 。
4， SP 接受到 Subject 的憑證，它是提供服務(wù)之前必須驗(yàn)證次憑證，于是，它產(chǎn)生了一個(gè) SAML 請求，要求 IDP 對憑證斷言
5， 憑證是 IDP 產(chǎn)生的，它當(dāng)然知道憑證的內(nèi)容，于是它回應(yīng)一個(gè) SAML 斷言給 SP
6， SP 信任 IDP 的 SAML 斷言，它會根據(jù)斷言結(jié)果確定是否為 Subject 提供服務(wù)。
4.2.1 SAML 的 Redirect/POST Bindings 方式 ( 即 IDP 推方式 )
該方式的主要特點(diǎn)是， IDP 交給 Subject 的不是憑證，而是斷言。
過程如下圖所示：
1 ， Subject 訪問 SP 的授權(quán)服務(wù)， SP 重定向 Subject 到 IDP 獲取斷言。
2 ， IDP 會要求 Subject 提供能夠證明它自己身份的手段 (Password ， X.509 證書等 )
3 ， Subject 向 IDP 提供了自己的賬號密碼。
4 ， IDP 驗(yàn)證密碼之后，會重訂向 Subject 到原來的 SP 。
5 ， SP 校驗(yàn) IDP 的斷言 ( 注意， IDP 會對自己的斷言簽名， SP 信任 IDP 的證書，因此，通過校驗(yàn)簽名，能夠確信從 Subject 過來的斷言確實(shí)來自 IDP 的斷言 ) 。
6 ，如果簽名正確， SP 將向 Subject 提供該服務(wù)。
4.3 SAML 的優(yōu)勢所在
SAML 協(xié)議仍在不斷的發(fā)展， SAML1.0, SAML1.1 到現(xiàn)在的 SAML2.0 ，都是 IT 商業(yè)巨頭協(xié)商后，由 OASIS 發(fā)布的產(chǎn)物，另外， OASIS SAML 實(shí)驗(yàn)室得到擁有美國政府 GSA 的大力資助。
SAML 在 SOA 中扮演了一個(gè)關(guān)鍵角色，由于用戶要求將企業(yè)資源從原有的面向數(shù)據(jù) / 接口轉(zhuǎn)變?yōu)槊嫦蚍?wù)，而建立在眾多 Vendor 產(chǎn)品下的服務(wù)存在這種種鴻溝，最大的鴻溝是如何識別身份，如何能夠讓網(wǎng)易 163 郵件的 VIP 用戶享受免費(fèi)參加 Dev2dev 廣州 UserGroup 的活動？
讀者可能已經(jīng)聽聞很多身份管理軟件， IBM Tivoli ， SiteMinder ， RSA SecureID 等，雖然身份管理軟件都非常強(qiáng)，但成本同時(shí)也很高。身份管理并不適合于那種構(gòu)建是 B2B 之上的商業(yè)環(huán)境（聯(lián)邦環(huán)境）。
但對用戶來說，根本問題是，網(wǎng)易和 Dev2dev 是兩個(gè)不同的公司 / 組織，它們都嚴(yán)格保護(hù)自己的用戶身份信息，一般極少可能會共享身份數(shù)據(jù)，因此，做法是雙方都提供一個(gè)服務(wù)入口，對身份信息做斷言，例如只告訴 Dev2dev 該用戶確實(shí)是網(wǎng)易的 VIP 用戶。
SAML 提供了一個(gè)安全標(biāo)記規(guī)范，并且給出了一些的 UseCase ，這些 usecase 足以滿足我們絕大部分的 SSO 需求。
我喜歡這種規(guī)范，很大原因是因?yàn)橐郧坝?SSO 實(shí)在很累，配置要花去大半天時(shí)間， SAML 讓這一切變得非常靈活簡單，因?yàn)閺S商一旦在其產(chǎn)品中提供 SAML 支持，我們就可以將其產(chǎn)品作為聯(lián)邦服務(wù)納入 SSO 環(huán)境。
我喜歡 SAML 的另一個(gè)原因是因?yàn)?，它?SOAP 一樣，不考慮傳輸協(xié)議，事實(shí)上， SAML 可以跟 HTTP/SSL/JMS 等任何傳輸協(xié)議捆綁。在 SOA 環(huán)境中，這個(gè)特性非常重要，因?yàn)槲覀円延械脑S多服務(wù)（來自各個(gè)不同 IT Vendors ）都可能有各自的傳輸協(xié)議，即如果在這種復(fù)雜的環(huán)境下實(shí)現(xiàn) SSO ，傳統(tǒng) Yale CAS 已經(jīng)無能為力，因?yàn)?CAS SSO 實(shí)現(xiàn)在 HTTP/SSL 之上，只有 SAML 能夠完成這項(xiàng)任務(wù)，因?yàn)樗c傳輸協(xié)議無關(guān)。
最后，應(yīng)該提一下， SAML 是一種 SSO 標(biāo)準(zhǔn)而 CAS 是一種 SSO 的實(shí)現(xiàn)，從 CAS 的 Roadmap 可以看出， CAS 很快會提供對其他 SAML 的支持。
