1 什么是單點(diǎn)登陸
單點(diǎn)登錄(Single Sign On),簡稱為 SSO,是目前比較流行的企業(yè)業(yè)務(wù)整合的解決方案之一。SSO的定義是在多個(gè)應(yīng)用系統(tǒng)中,用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。
較大的企業(yè)內(nèi)部,一般都有很多的業(yè)務(wù)支持系統(tǒng)為其提供相應(yīng)的管理和IT服務(wù)。例如財(cái)務(wù)系統(tǒng)為財(cái)務(wù)人員提供財(cái)務(wù)的管理、計(jì)算和報(bào)表服務(wù);人事系統(tǒng)為人事部門 提供全公司人員的維護(hù)服務(wù);各種業(yè)務(wù)系統(tǒng)為公司內(nèi)部不同的業(yè)務(wù)提供不同的服務(wù)等等。這些系統(tǒng)的目的都是讓
計(jì)算機(jī)來進(jìn)行復(fù)雜繁瑣的計(jì)算工作,來替代人力的手 工勞動,提高工作效率和質(zhì)量。這些不同的系統(tǒng)往往是在不同的時(shí)期建設(shè)起來的,運(yùn)行在不同的平臺上;也許是由不同廠商開發(fā),使用了各種不同的技術(shù)和標(biāo)準(zhǔn)。如 果舉例說國內(nèi)一著名的IT公司(名字隱去),內(nèi)部共有60多個(gè)業(yè)務(wù)系統(tǒng),這些系統(tǒng)包括兩個(gè)不同版本的SAP的ERP系統(tǒng),12個(gè)不同類型和版本的數(shù)據(jù)庫系 統(tǒng),8個(gè)不同類型和版本的操作系統(tǒng),以及使用了3種不同的防火墻技術(shù),還有數(shù)十種互相不能兼容的協(xié)議和標(biāo)準(zhǔn),你相信嗎?不要懷疑,這種情況其實(shí)非常普遍。 每一個(gè)應(yīng)用系統(tǒng)在運(yùn)行了數(shù)年以后,都會成為不可替換的企業(yè)IT架構(gòu)的一部分,如下圖所示。

隨著企業(yè)的發(fā)展,業(yè)務(wù)系統(tǒng)的數(shù)量在不斷的增加,老的系統(tǒng)卻不能輕易的替換,這會帶來很多的開銷。其一是管理上的開銷,需要維護(hù)的系統(tǒng)越來越多。很多系統(tǒng)的 數(shù)據(jù)是相互冗余和重復(fù)的,數(shù)據(jù)的不一致性會給管理工作帶來很大的壓力。業(yè)務(wù)和業(yè)務(wù)之間的相關(guān)性也越來越大,例如公司的計(jì)費(fèi)系統(tǒng)和財(cái)務(wù)系統(tǒng),財(cái)務(wù)系統(tǒng)和人事 系統(tǒng)之間都不可避免的有著密切的關(guān)系。
為了降低管理的消耗,最大限度的重用已有投資的系統(tǒng),很多企業(yè)都在進(jìn)行著企業(yè)應(yīng)用集成(EAI)。企業(yè)應(yīng)用集成可以在不同層面上進(jìn)行:例如在數(shù)據(jù)存儲層面 上的“數(shù)據(jù)大集中”,在傳輸層面上的“通用數(shù)據(jù)交換平臺”,在應(yīng)用層面上的“業(yè)務(wù)流程整合”,和用戶界面上的“通用企業(yè)門戶”等等。事實(shí)上,還用一個(gè)層面 上的集成變得越來越重要,那就是“身份認(rèn)證”的整合,也就是“單點(diǎn)登錄”。
通常來說,每個(gè)單獨(dú)的系統(tǒng)都會有自己的安全體系和身份認(rèn)證系統(tǒng)。整合以前,進(jìn)入每個(gè)系統(tǒng)都需要進(jìn)行登錄,這樣的局面不僅給管理上帶來了很大的困難,在安全方面也埋下了重大的隱患。下面是一些著名的調(diào)查公司顯示的統(tǒng)計(jì)數(shù)據(jù):
- 用戶每天平均16分鐘花在身份驗(yàn)證任務(wù)上 - 資料來源:IDS
- 頻繁的IT用戶平均有21個(gè)密碼 - 資料來源:NTA Monitor Password Survey
- 49%的人寫下了其密碼,而67%的人很少改變它們
- 每79秒出現(xiàn)一起身份被竊事件 - 資料來源:National Small Business Travel Assoc
- 全球欺騙損失每年約12B - 資料來源:Comm Fraud Control Assoc
- 到2007年,身份管理市場將成倍增長至$4.5B - 資料來源:IDS
使用“單點(diǎn)登錄”整合后,只需要登錄一次就可以進(jìn)入多個(gè)系統(tǒng),而不需要重新登錄,這不僅僅帶來了更好的用戶體驗(yàn),更重要的是降低了安全的風(fēng)險(xiǎn)和管理的消耗。請看下面的統(tǒng)計(jì)數(shù)據(jù):
- 提高IT效率:對于每1000個(gè)受管用戶,每用戶可節(jié)省$70K
- 幫助臺呼叫減少至少1/3,對于10K員工的公司,每年可以節(jié)省每用戶$75,或者合計(jì)$648K
- 生產(chǎn)力提高:每個(gè)新員工可節(jié)省$1K,每個(gè)老員工可節(jié)省$350 - 資料來源:Giga
- ROI回報(bào):7.5到13個(gè)月 - 資料來源:Gartner
另外,使用“單點(diǎn)登錄”還是
SOA時(shí)代的需求之一。在面向服務(wù)的架構(gòu)中,服務(wù)和服務(wù)之間,程序和程序之間的通訊大量存在,服務(wù)之間的安全認(rèn)證是SOA應(yīng)用的難點(diǎn)之一,應(yīng)此建立“單點(diǎn)登錄”的系統(tǒng)體系能夠大大簡化SOA的安全問題,提高服務(wù)之間的合作效率。
2 單點(diǎn)登陸的技術(shù)實(shí)現(xiàn)機(jī)制
隨著SSO技術(shù)的流行,SSO的產(chǎn)品也是滿天飛揚(yáng)。所有著名的軟件廠商都提供了相應(yīng)的解決方案。在這里我并不想介紹自己公司(
Sun Microsystems)的產(chǎn)品,而是對SSO技術(shù)本身進(jìn)行解析,并且提供自己開發(fā)這一類產(chǎn)品的方法和簡單演示。有關(guān)我寫這篇文章的目的,請參考我的博 客(
http://yuwang881.blog.sohu.com/3184816.html)。
單點(diǎn)登錄的機(jī)制其實(shí)是比較簡單的,用一個(gè)現(xiàn)實(shí)中的例子做比較。頤和園是北京著名的旅游景點(diǎn),也是我常去的地方。在頤和園內(nèi)部有許多獨(dú)立的景點(diǎn),例如“蘇州 街”、“佛香閣”和“德和園”,都可以在各個(gè)景點(diǎn)門口單獨(dú)買票。很多游客需要游玩所有德景點(diǎn),這種買票方式很不方便,需要在每個(gè)景點(diǎn)門口排隊(duì)買票,錢包拿 進(jìn)拿出的,容易丟失,很不安全。于是絕大多數(shù)游客選擇在大門口買一張通票(也叫套票),就可以玩遍所有的景點(diǎn)而不需要重新再買票。他們只需要在每個(gè)景點(diǎn)門 口出示一下剛才買的套票就能夠被允許進(jìn)入每個(gè)獨(dú)立的景點(diǎn)。
單點(diǎn)登錄的機(jī)制也一樣,如下圖所示,當(dāng)用戶第一次訪問應(yīng)用系統(tǒng)1的時(shí)候,因?yàn)檫€沒有登錄,會被引導(dǎo)到認(rèn)證系統(tǒng)中進(jìn)行登錄(1);根據(jù)用戶提供的登錄信息, 認(rèn)證系統(tǒng)進(jìn)行身份效驗(yàn),如果通過效驗(yàn),應(yīng)該返回給用戶一個(gè)認(rèn)證的憑據(jù)--ticket(2);用戶再訪問別的應(yīng)用的時(shí)候(3,5)就會將這個(gè)ticket 帶上,作為自己認(rèn)證的憑據(jù),應(yīng)用系統(tǒng)接受到請求之后會把ticket送到認(rèn)證系統(tǒng)進(jìn)行效驗(yàn),檢查ticket的合法性(4,6)。如果通過效驗(yàn),用戶就可 以在不用再次登錄的情況下訪問應(yīng)用系統(tǒng)2和應(yīng)用系統(tǒng)3了。
從上面的視圖可以看出,要實(shí)現(xiàn)SSO,需要以下主要的功能:
- 所有應(yīng)用系統(tǒng)共享一個(gè)身份認(rèn)證系統(tǒng)。
統(tǒng)一的認(rèn)證系統(tǒng)是SSO的前提之一。認(rèn)證系統(tǒng)的主要功能是將用戶的登錄信息和用戶信息庫相比較,對用戶進(jìn)行登錄認(rèn)證;認(rèn)證成功后,認(rèn)證系統(tǒng)應(yīng)該生成統(tǒng)一的認(rèn)證標(biāo)志(ticket),返還給用戶。另外,認(rèn)證系統(tǒng)還應(yīng)該對ticket進(jìn)行效驗(yàn),判斷其有效性。
- 所有應(yīng)用系統(tǒng)能夠識別和提取ticket信息
要實(shí)現(xiàn)SSO的功能,讓用戶只登錄一次,就必須讓應(yīng)用系統(tǒng)能夠識別已經(jīng)登錄過的用戶。應(yīng)用系統(tǒng)應(yīng)該能對ticket進(jìn)行識別和提取,通過與認(rèn)證系統(tǒng)的通訊,能自動判斷當(dāng)前用戶是否登錄過,從而完成單點(diǎn)登錄的功能。
上面的功能只是一個(gè)非常簡單的SSO架構(gòu),在現(xiàn)實(shí)情況下的SSO有著更加復(fù)雜的結(jié)構(gòu)。有兩點(diǎn)需要指出的是:
- 單一的用戶信息數(shù)據(jù)庫并不是必須的,有許多系統(tǒng)不能將所有的用戶信息都集中存儲,應(yīng)該允許用戶信息放置在不同的存儲中,如下圖所示。事實(shí)上,只要統(tǒng)一認(rèn)證系統(tǒng),統(tǒng)一ticket的產(chǎn)生和效驗(yàn),無論用戶信息存儲在什么地方,都能實(shí)現(xiàn)單點(diǎn)登錄。
- 統(tǒng)一的認(rèn)證系統(tǒng)并不是說只有單個(gè)的認(rèn)證服務(wù)器,如下圖所示,整個(gè)系統(tǒng)可以存在兩個(gè)以上的認(rèn)證服務(wù)器,這些服務(wù)器甚至可以是不同的產(chǎn)品。認(rèn)證服務(wù)器 之間要通過標(biāo)準(zhǔn)的通訊協(xié)議,互相交換認(rèn)證信息,就能完成更高級別的單點(diǎn)登錄。如下圖,當(dāng)用戶在訪問應(yīng)用系統(tǒng)1時(shí),由第一個(gè)認(rèn)證服務(wù)器進(jìn)行認(rèn)證后,得到由此 服務(wù)器產(chǎn)生的ticket。當(dāng)他訪問應(yīng)用系統(tǒng)4的時(shí)候,認(rèn)證服務(wù)器2能夠識別此ticket是由第一個(gè)服務(wù)器產(chǎn)生的,通過認(rèn)證服務(wù)器之間標(biāo)準(zhǔn)的通訊協(xié)議 (例如SAML)來交換認(rèn)證信息,仍然能夠完成SSO的功能。
3 WEB-SSO的實(shí)現(xiàn)
隨著互聯(lián)網(wǎng)的高速發(fā)展,
WEB應(yīng)用幾乎統(tǒng)治了絕大部分的軟件應(yīng)用系統(tǒng),因此WEB-SSO是SSO應(yīng)用當(dāng)中最為流行。WEB-SSO有其自身的特點(diǎn)和優(yōu) 勢,實(shí)現(xiàn)起來比較簡單易用。很多商業(yè)軟件和
開源軟件都有對WEB-SSO的實(shí)現(xiàn)。其中值得一提的是OpenSSO (
https://opensso.dev.java.net),為用
Java實(shí)現(xiàn)WEB-SSO提供架構(gòu)指南和服務(wù)指南,為用戶自己來實(shí)現(xiàn)WEB-SSO提供了理論的依據(jù)和實(shí)現(xiàn)的方法。
為什么說WEB-SSO比較容易實(shí)現(xiàn)呢?這是有WEB應(yīng)用自身的特點(diǎn)決定的。
眾所周知,Web協(xié)議(也就是HTTP)是一個(gè)無狀態(tài)的協(xié)議。一個(gè)Web應(yīng)用由很多個(gè)Web頁面組成,每個(gè)頁面都有唯一的URL來定義。用戶在瀏覽器的地 址欄輸入頁面的URL,瀏覽器就會向Web
Server去發(fā)送請求。如下圖,瀏覽器向Web服務(wù)器發(fā)送了兩個(gè)請求,申請了兩個(gè)頁面。這兩個(gè)頁面的請求是分別使用了兩個(gè)單獨(dú)的HTTP連接。所謂無狀 態(tài)的協(xié)議也就是表現(xiàn)在這里,瀏覽器和Web服務(wù)器會在第一個(gè)請求完成以后關(guān)閉連接通道,在第二個(gè)請求的時(shí)候重新建立連接。Web服務(wù)器并不區(qū)分哪個(gè)請求來 自哪個(gè)客戶端,對所有的請求都一視同仁,都是單獨(dú)的連接。這樣的方式大大區(qū)別于傳統(tǒng)的(Client/Server)C/S結(jié)構(gòu),在那樣的應(yīng)用中,客戶端 和服務(wù)器端會建立一個(gè)長時(shí)間的專用的連接通道。正是因?yàn)橛辛藷o狀態(tài)的特性,每個(gè)連接資源能夠很快被
其他客戶端所重用,一臺Web服務(wù)器才能夠同時(shí)服務(wù)于成 千上萬的客戶端。

但是我們通常的應(yīng)用是有狀態(tài)的。先不用提不同應(yīng)用之間的SSO,在同一個(gè)應(yīng)用中也需要保存用戶的登錄身份信息。例如用戶在訪問頁面1的時(shí)候進(jìn)行了登錄,但 是剛才也提到,客戶端的每個(gè)請求都是單獨(dú)的連接,當(dāng)客戶再次訪問頁面2的時(shí)候,如何才能告訴Web服務(wù)器,客戶剛才已經(jīng)登錄過了呢?瀏覽器和服務(wù)器之間有 約定:通過使用cookie技術(shù)來維護(hù)應(yīng)用的狀態(tài)。Cookie是可以被Web服務(wù)器設(shè)置的字符串,并且可以保存在瀏覽器中。如下圖所示,當(dāng)瀏覽器訪問了 頁面1時(shí),web服務(wù)器設(shè)置了一個(gè)cookie,并將這個(gè)cookie和頁面1一起返回給瀏覽器,瀏覽器接到cookie之后,就會保存起來,在它訪問頁 面2的時(shí)候會把這個(gè)cookie也帶上,Web服務(wù)器接到請求時(shí)也能讀出cookie的值,根據(jù)cookie值的內(nèi)容就可以判斷和恢復(fù)一些用戶的信息狀 態(tài)。

Web-SSO完全可以利用Cookie結(jié)束來完成用戶登錄信息的保存,將瀏覽器中的Cookie和上文中的Ticket結(jié)合起來,完成SSO的功能。
為了完成一個(gè)簡單的SSO的功能,需要兩個(gè)部分的合作:
- 統(tǒng)一的身份認(rèn)證服務(wù)。
- 修改Web應(yīng)用,使得每個(gè)應(yīng)用都通過這個(gè)統(tǒng)一的認(rèn)證服務(wù)來進(jìn)行身份效驗(yàn)。
3.1 Web SSO 的樣例
根據(jù)上面的原理,我用
J2EE的技術(shù)(
JSP和Servlet)完成了一個(gè)具有Web-SSO的簡單樣例。樣例包含一個(gè)身份認(rèn)證的服務(wù)器和兩個(gè)簡單的 Web應(yīng)用,使得這兩個(gè) Web應(yīng)用通過統(tǒng)一的身份認(rèn)證服務(wù)來完成Web-SSO的功能。此樣例所有的源代碼和二進(jìn)制代碼都可以從網(wǎng)站地址
http://gceclub.sun.com.cn/wangyu/下載。
樣例下載、安裝部署和運(yùn)行指南:
- Web-SSO的樣例是由三個(gè)標(biāo)準(zhǔn)Web應(yīng)用組成,壓縮成三個(gè)zip文件,從http://gceclub.sun.com.cn/wangyu/web-sso/中下載。其中SSOAuth(http://gceclub.sun.com.cn/wangyu/web-sso/SSOAuth.zip)是身份認(rèn)證服務(wù);SSOWebDemo1(http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo1.zip)和SSOWebDemo2(http://gceclub.sun.com.cn/wangyu/web-sso/SSOWebDemo2.zip) 是兩個(gè)用來演示單點(diǎn)登錄的Web應(yīng)用。這三個(gè)Web應(yīng)用之所以沒有打成war包,是因?yàn)樗鼈儾荒苤苯硬渴穑鶕?jù)讀者的部署環(huán)境需要作出小小的修改。樣例部 署和運(yùn)行的環(huán)境有一定的要求,需要符合Servlet2.3以上標(biāo)準(zhǔn)的J2EE容器才能運(yùn)行(例如Tomcat5,Sun Application Server 8, Jboss 4等)。另外,身份認(rèn)證服務(wù)需要JDK1.5的運(yùn)行環(huán)境。之所以要用JDK1.5是因?yàn)楣P者使用了一個(gè)線程安全的高性能的Java集合類 “ConcurrentMap”,只有在JDK1.5中才有。
- 這三個(gè)Web應(yīng)用完全可以單獨(dú)部署,它們可以分別部署在 不同的機(jī)器,不同的操作系統(tǒng)和不同的J2EE的產(chǎn)品上,它們完全是標(biāo)準(zhǔn)的和平臺無關(guān)的應(yīng)用。但是有一個(gè)限制,那兩臺部署應(yīng)用(demo1、demo2)的 機(jī)器的域名需要相同,這在后面的章節(jié)中會解釋到cookie和domain的關(guān)系以及如何制作跨域的WEB-SSO
解壓縮SSOAuth.zip文件,在/WEB-INF/下的web.xml中請修改“domainname”的屬性以反映實(shí)際的應(yīng)用部署情況, domainname需要設(shè)置為兩個(gè)單點(diǎn)登錄的應(yīng)用(demo1和demo2)所屬的域名。這個(gè)domainname和當(dāng)前SSOAuth服務(wù)部署的機(jī)器 的域名沒有關(guān)系。我缺省設(shè)置的是“.sun.com”。如果你部署demo1和demo2的機(jī)器沒有域名,請輸入IP地址或主機(jī)名(如 localhost),但是如果使用IP地址或主機(jī)名也就意味著demo1和demo2需要部署到一臺機(jī)器上了。設(shè)置完后,根據(jù)你所選擇的J2EE容器, 可能需要將SSOAuth這個(gè)目錄壓縮打包成war文件。用“jar -cvf SSOAuth.war SSOAuth/”就可以完成這個(gè)功能。
- 解壓縮SSOWebDemo1和SSOWebDemo2文件,分別在它們/WEB-INF/下找到web.xml文件,請修改其中的幾個(gè)初始化參數(shù)
<init-param>
<param-name>SSOServiceURL</param-name>
<param-value>http://wangyu.prc.sun.com:8080/SSOAuth/SSOAuth</param-value>
</init-param>
<init-param>
<param-name>SSOLoginPage</param-name>
<param-value>http://wangyu.prc.sun.com:8080/SSOAuth/login.jsp</param-value>
</init-param>
- 將其中的SSOServiceURL和SSOLoginPage修改成部署SSOAuth應(yīng)用的機(jī)器名、端口號以及根路徑(缺省是 SSOAuth)以反映實(shí)際的部署情況。設(shè)置完后,根據(jù)你所選擇的J2EE容器,可能需要將SSOWebDemo1和SSOWebDemo2這兩個(gè)目錄壓 縮打包成兩個(gè)war文件。用“jar -cvf SSOWebDemo1.war SSOWebDemo1/”就可以完成這個(gè)功能。
- 請輸入第一個(gè)web應(yīng)用的測試URL(test.jsp),例如http://wangyu.prc.sun.com:8080/SSOWebDemo1/test.jsp,如果是第一次訪問,便會自動跳轉(zhuǎn)到登錄界面,如下圖。
- 使用系統(tǒng)自帶的三個(gè)帳號之一登錄(例如,用戶名:wangyu,密碼:wangyu),便能成功的看到test.jsp的內(nèi)容:顯示當(dāng)前用戶名和歡迎信息。
- 請接著在同一個(gè)瀏覽器中輸入第二個(gè)web應(yīng)用的測試URL(test.jsp),例如http://wangyu.prc.sun.com:8080/SSOWebDemo2/test.jsp。你會發(fā)現(xiàn),不需要再次登錄就能看到test.jsp的內(nèi)容,同樣是顯示當(dāng)前用戶名和歡迎信息,而且歡迎信息中明確的顯示當(dāng)前的應(yīng)用名稱(demo2)。
3.2 WEB-SSO代碼講解
3.2.1身份認(rèn)證服務(wù)代碼解析
Web-SSO的源代碼可以從網(wǎng)站地址
http://gceclub.sun.com.cn/wangyu/web-sso/websso_src.zip下 載。身份認(rèn)證服務(wù)是一個(gè)標(biāo)準(zhǔn)的web應(yīng)用,包括一個(gè)名為SSOAuth的Servlet,一個(gè)login.jsp文件和一個(gè)failed.html。身份 認(rèn)證的所有服務(wù)幾乎都由SSOAuth的Servlet來實(shí)現(xiàn)了;login.jsp用來顯示登錄的頁面(如果發(fā)現(xiàn)用戶還沒有登錄過); failed.html是用來顯示登錄失敗的信息(如果用戶的用戶名和密碼與信息數(shù)據(jù)庫中的不一樣)。
SSOAuth的代碼如下面的列表顯示,結(jié)構(gòu)非常簡單,先看看這個(gè)Servlet的主體部分:
package DesktopSSO;
import java.io.*;
import java.net.*;
import java.text.*;
import java.util.*;
import java.util.concurrent.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class SSOAuth extends HttpServlet {
static private ConcurrentMap accounts;
static private ConcurrentMap SSOIDs;
String cookiename="WangYuDesktopSSOID";
String domainname;
public void init(ServletConfig config) throws ServletException {
super.init(config);
domainname= config.getInitParameter("domainname");
cookiename = config.getInitParameter("cookiename");
SSOIDs = new ConcurrentHashMap();
accounts=new ConcurrentHashMap();
accounts.put("wangyu", "wangyu");
accounts.put("paul", "paul");
accounts.put("carol", "carol");
}
protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
PrintWriter ut = response.getWriter();
String action = request.getParameter("action");
String result="failed";
if (action==null) {
handlerFromLogin(request,response);
} else if (action.equals("authcookie")){
String myCookie = request.getParameter("cookiename");
if (myCookie != null) result = authCookie(myCookie);
out.print(result);
out.close();
} else if (action.equals("authuser")) {
result=authNameAndPasswd(request,response);
out.print(result);
out.close();
} else if (action.equals("logout")) {
String myCookie = request.getParameter("cookiename");
logout(myCookie);
out.close();
}
}
.....
}
從代碼很容易看出,SSOAuth就是一個(gè)簡單的Servlet。其中有兩個(gè)靜態(tài)成員變量:accounts和SSOIDs,這兩個(gè)成員變量都使用了 JDK1.5中線程安全的MAP類: ConcurrentMap,所以這個(gè)樣例一定要JDK1.5才能運(yùn)行。Accounts用來存放用戶的用戶名和密碼,在init()的方法中可以看到我 給系統(tǒng)添加了三個(gè)合法的用戶。在實(shí)際應(yīng)用中,accounts應(yīng)該是去數(shù)據(jù)庫中或LDAP中獲得,為了簡單起見,在本樣例中我使用了 ConcurrentMap在內(nèi)存中用程序創(chuàng)建了三個(gè)用戶。而SSOIDs保存了在用戶成功的登錄后所產(chǎn)生的cookie和用戶名的對應(yīng)關(guān)系。它的功能顯 而易見:當(dāng)用戶成功登錄以后,再次訪問別的系統(tǒng),為了鑒別這個(gè)用戶請求所帶的cookie的有效性,需要到SSOIDs中檢查這樣的映射關(guān)系是否存在。
在主要的請求處理方法processRequest()中,可以很清楚的看到SSOAuth的所有功能。
- 如果用戶還沒有登錄過,是第一次登錄本系統(tǒng),會被跳轉(zhuǎn)到login.jsp頁面(在后面會解釋如何跳轉(zhuǎn))。用戶在提供了用戶名和密碼以后,就會用handlerFromLogin()這個(gè)方法來驗(yàn)證。
- 如果用戶已經(jīng)登錄過本系統(tǒng),再訪問別的應(yīng)用的時(shí)候,是不需要再次登錄的。因?yàn)闉g覽器會將第一次登錄時(shí)產(chǎn)生的cookie和請求一起發(fā)送。效驗(yàn)cookie的有效性是SSOAuth的主要功能之一。
- SSOAuth還能直接效驗(yàn)非login.jsp頁面過來的用戶名和密碼的效驗(yàn)請求。這個(gè)功能是用于非web應(yīng)用的SSO,這在后面的桌面SSO中會用到。
- SSOAuth還提供logout服務(wù)。
下面看看幾個(gè)主要的功能函數(shù):
private void handlerFromLogin(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");
String password = request.getParameter("password");
String pass = (String)accounts.get(username);
if ((pass==null)||(!pass.equals(password)))
getServletContext().getRequestDispatcher("/failed.html").forward(request, response);
else {
String gotoURL = request.getParameter("goto");
String newID = createUID();
SSOIDs.put(newID, username);
Cookie wangyu = new Cookie(cookiename, newID);
wangyu.setDomain(domainname);
wangyu.setMaxAge(60000);
wangyu.setValue(newID);
wangyu.setPath("/");
response.addCookie(wangyu);
System.out.println("login success, goto back url:" + gotoURL);
if (gotoURL != null) {
PrintWriter ut = response.getWriter();
response.sendRedirect(gotoURL);
out.close();
}
}
}
handlerFromLogin()這個(gè)方法是用來處理來自login.jsp的登錄請求。它的邏輯很簡單:將用戶輸入的用戶名和密碼與預(yù)先設(shè)定好的用 戶集合(存放在accounts中)相比較,如果用戶名或密碼不匹配的話,則返回登錄失敗的頁面(failed.html),如果登錄成功的話,需要為用 戶當(dāng)前的session創(chuàng)建一個(gè)新的ID,并將這個(gè)ID和用戶名的映射關(guān)系存放到SSOIDs中,最后還要將這個(gè)ID設(shè)置為瀏覽器能夠保存的cookie 值。
登錄成功后,瀏覽器會到哪個(gè)頁面呢?那我們回顧一下我們是如何使用身份認(rèn)證服務(wù)的。一般來說我們不會直接訪問身份服務(wù)的任何URL,包括 login.jsp。身份服務(wù)是用來保護(hù)其他應(yīng)用服務(wù)的,用戶一般在訪問一個(gè)受SSOAuth保護(hù)的Web應(yīng)用的某個(gè)URL時(shí),當(dāng)前這個(gè)應(yīng)用會發(fā)現(xiàn)當(dāng)前的 用戶還沒有登錄,便強(qiáng)制將也頁面轉(zhuǎn)向SSOAuth的login.jsp,讓用戶登錄。如果登錄成功后,應(yīng)該自動的將用戶的瀏覽器指向用戶最初想訪問的那 個(gè)URL。在handlerFromLogin()這個(gè)方法中,我們通過接收“goto”這個(gè)參數(shù)來保存用戶最初訪問的URL,成功后便重新定向到這個(gè)頁 面中。
另外一個(gè)要說明的是,在設(shè)置cookie的時(shí)候,我使用了一個(gè)setMaxAge(6000)的方法。這個(gè)方法是用來設(shè)置cookie的有效期,單位是 秒。如果不使用這個(gè)方法或者參數(shù)為負(fù)數(shù)的話,當(dāng)瀏覽器關(guān)閉的時(shí)候,這個(gè)cookie就失效了。在這里我給了很大的值(1000分鐘),導(dǎo)致的行為是:當(dāng)你 關(guān)閉瀏覽器(或者關(guān)機(jī)),下次再打開瀏覽器訪問剛才的應(yīng)用,只要在1000分鐘之內(nèi),就不需要再登錄了。我這樣做是下面要介紹的桌面SSO中所需要的功 能。
其他的方法更加簡單,這里就不多解釋了。
3.2.2具有SSO功能的web應(yīng)用源代碼解析 要實(shí)現(xiàn)WEB-SSO的功能,只有身份認(rèn)證服務(wù)是不夠的。這點(diǎn)很顯然,要想使多個(gè)應(yīng)用具有單點(diǎn)登錄的功能,還需要每個(gè)應(yīng)用本身的配合:將自己的身份認(rèn)證的 服務(wù)交給一個(gè)統(tǒng)一的身份認(rèn)證服務(wù)-SSOAuth。SSOAuth服務(wù)中提供的各個(gè)方法就是供每個(gè)加入SSO的Web應(yīng)用來調(diào)用的。
再轉(zhuǎn)載點(diǎn)內(nèi)容:
昨天和幾位朋友探討到了這個(gè)話題,發(fā)現(xiàn)雖然單點(diǎn)登錄,或者叫做獨(dú)立的passport登錄雖然已經(jīng)有了很多實(shí)現(xiàn)方法,但是能真正了解并實(shí)現(xiàn)的人卻并不太多,所以些下此文,希望從原理到實(shí)現(xiàn),能讓大家了解的多一些
至于什么是單點(diǎn)登錄,舉個(gè)例子,如果你登錄了msn messenger,訪問hotmail郵件就不用在此登錄。
一般單點(diǎn)登錄都需要有一個(gè)獨(dú)立的登錄站點(diǎn),一般具有獨(dú)立的域名,專門的進(jìn)行注冊,登錄,注銷等操作
我們?yōu)榱擞懻摲奖悖堰@個(gè)登錄站點(diǎn)叫做站點(diǎn)P,設(shè)其Url為http://passport.yizhu2000.com,需要提供服務(wù)的站點(diǎn)設(shè)為A和B,跨站點(diǎn)單點(diǎn)登錄是指你在A網(wǎng)站進(jìn)行登錄后,使用B網(wǎng)站的服務(wù)就不需要再登錄
從技術(shù)角度講單點(diǎn)登錄分為:
- 跨子域單點(diǎn)登錄
- 完全跨單點(diǎn)域登錄
跨子域單點(diǎn)登錄
所謂跨子域登錄,A,B站點(diǎn)和P站點(diǎn)位于同一個(gè)域下面,比如A站點(diǎn)為http://blog.yizhu2000.com B站點(diǎn)為 http://forum.yizhu2000.com,他們和登錄站點(diǎn)P的關(guān)系可以看到,都是屬于同一個(gè)父域,yizhu2000.com,不同的是子域不同,一個(gè)為blog,一個(gè)為forum,一個(gè)是passport
我們先看看最常用的非跨站點(diǎn)普通登錄的情況,一般登錄驗(yàn)證通過后,一般會將你的用戶名和一些用戶信息,通過某一密鑰進(jìn)行加密,寫在本地,也就是一個(gè)加密的cookie,我們把這個(gè)cookie叫做--票(ticket)。
需要判斷用戶是否登錄的頁面,需要讀取這個(gè)ticket,并從其中解密出用戶信息,如果ticket不存在,或者無法解密,意味著用戶沒有登錄,或者登錄信息不正確,這時(shí)就要跳轉(zhuǎn)到登錄頁面進(jìn)行登錄,在這里加密的作用有兩個(gè),一是防止用戶信息被不懷好意者看到,二是保證ticket不會被偽造,后者其實(shí)更為重要,加密后,各個(gè)應(yīng)用需要采用與加密同樣的密鑰進(jìn)行解密,如果不知道密鑰,就不能偽造出ticket,
(注:加密和解密的密鑰有可能不同,取決于采用什么加密算法,如果是對稱加密,則為同一密鑰,如果是非對稱,就不同了,一般用私鑰加密,公鑰解密,但是無論怎樣,密鑰都只有內(nèi)部知道,這樣偽造者既無法偽造也無法解密ticket)
跨子域的單點(diǎn)登錄,和上述普通登錄的過程沒有什么不同,唯一不同的是寫cookie時(shí),由于登錄站點(diǎn)P和應(yīng)用A處于不同的子域,P站寫入的cookie的域?yàn)閜assport.yizhu2000.net,而A站點(diǎn)為forum.yizhu2000.net,A在判斷用戶登錄時(shí)無法讀到P站點(diǎn)的ticket
解決方法非常簡單,當(dāng)Login完成后P站點(diǎn)寫ticket的時(shí)候,只需把cookie的域設(shè)為他們共同的父域,yizhu2000.net就可以了:cookie.domain="yizhu2000.net",A站點(diǎn)自然就可以讀到這個(gè)ticket了
ASP。Net的form驗(yàn)證本身實(shí)現(xiàn)了這個(gè)機(jī)制,大家可以參考http://blog.csdn.net/octverve/archive/2007/09/22/1796338.aspx
ASP.NET身份驗(yàn)證信息跨域共享狀態(tài)
在ASP.NET 2.0 中只需修改web.config文件即可,修改方法如下:
<authentication mode="Forms">
<forms name=".ASPNETFORM" domain="imneio.com" loginUrl="/login.aspx" defaultUrl="/default.aspx" protection="All" timeout="30" path="/" requireSSL="false" slidingExpiration="true" enableCrossAppRedirects="false" cookieless="UseDeviceProfile" />
</authentication>
domain指定了cookie保存的域,只要保存的是 abc.com形式或者.abc.com的形式,那么其二級域名都可以共享此cookie。
此外,web.config標(biāo)簽中的<sessionState >也做相應(yīng)修改,mode改為StateServer或者SqlServer,那么里面的session信息也就全部可以共享了。
StateServer需要在服務(wù)中開啟“asp.net狀態(tài)服務(wù)”的服務(wù)。
http://www.imneio.com/2007/11/17/aspnetnote1/,以上斜體內(nèi)容摘自此鏈接
完全跨單點(diǎn)域登錄
完全跨域登錄,是指A,B站點(diǎn)和P站點(diǎn)沒有共同的父域,比如A站點(diǎn)為forum.yizhu1999.net,B站點(diǎn)為blog.yizhu1998.net,大家可以參考微軟旗下的幾個(gè)站點(diǎn)http://www.live.com,www.hotmail.com,這兩個(gè)站點(diǎn)就沒有共同的父域,而仍然可以共用登錄,怎樣才能實(shí)現(xiàn)呢?請參考下圖,由于這種情況ticket比較復(fù)雜,我們暫時(shí)把P站點(diǎn)創(chuàng)建的的ticket叫做P-ticket,而A站點(diǎn)創(chuàng)建的ticket叫A-ticket,B的為B-ticket
由于站點(diǎn)A(forum.yizhu1999.com)不能讀取到由站點(diǎn)P(passport.yizhu2000.com)創(chuàng)建的加密ticket,所以當(dāng)用戶訪問A站點(diǎn)上需要登錄才能訪問的資源時(shí),A站點(diǎn)會首先查看是否有A-ticket,如果沒有,證明用戶沒有在A站點(diǎn)登錄過,不過并不保證用戶沒有在B站點(diǎn)登錄,(重復(fù)一下,既然是單點(diǎn)登錄,當(dāng)然無論你在A,B任意一個(gè)站點(diǎn)登錄過,另外一個(gè)站點(diǎn)都要可以訪問),請求會被重定向到p站點(diǎn)的驗(yàn)證頁面,驗(yàn)證頁面讀取P-ticket,如果沒有,或者解密不成功,就需要重定向登錄頁面,登錄頁面完成登錄后,寫一個(gè)加密cookie,也就是P-ticket,并且重定向到A站點(diǎn)的登錄處理頁,并把加密的用戶信息作為參數(shù)傳遞給這個(gè)頁面,這個(gè)頁面接收登錄頁的用戶信息,解密后也要寫一個(gè)cookie,也就是A-ticket,今后用戶再次訪問A站點(diǎn)上需要登錄權(quán)限才能訪問的資源時(shí),只需要檢查這個(gè)A-cookie是否存在就可以了
當(dāng)用戶訪問B站點(diǎn)時(shí),會重復(fù)上面的過程,監(jiān)測到?jīng)]有B-ticket,就會重定向到P站點(diǎn)的驗(yàn)證頁面,去檢查P-ticket,如果沒有,就登錄,有則返回B的登錄處理頁面寫B(tài)-ticket
注銷的時(shí)候需要刪除P-ticket和A-ticket
怎么刪除cookie:本來以為這個(gè)不是問題,不過還是有朋友問道,簡單的說其實(shí)是創(chuàng)建一個(gè)和你要刪除的cookie同名的cookie,并把cookie的expire設(shè)為當(dāng)前時(shí)間之前的某個(gè)時(shí)間,不過在跨子域的刪除cookie時(shí)有一點(diǎn)要注意:必須要把cookie的域設(shè)置為父域,在本文中為yizhu2000.com
為了保證各個(gè)環(huán)節(jié)的傳輸?shù)陌踩裕詈檬褂胔ttps連接
原文地址:
http://www.cnblogs.com/yizhu2000/archive/2008/04/01/1131976.html
本博客為學(xué)習(xí)交流用,凡未注明引用的均為本人作品,轉(zhuǎn)載請注明出處,如有版權(quán)問題請及時(shí)通知。由于博客時(shí)間倉促,錯(cuò)誤之處敬請諒解,有任何意見可給我留言,愿共同學(xué)習(xí)進(jìn)步。