Believe it,do it!

 java/vc單點(diǎn)登錄的簡單實(shí)現(xiàn)

在門戶項目中，經(jīng)常會遇到如何實(shí)現(xiàn)單點(diǎn)登錄的問題，下面就本人的經(jīng)驗做個總結(jié)。歡迎大家進(jìn)行補(bǔ)充討論。 單點(diǎn)登錄的具體實(shí)現(xiàn)有很多種選擇，包括：

1. 采用專門的SSO商業(yè)軟件： 主要有：Netgrity的Siteminder，已經(jīng)被CA收購。Novell 公司的iChain。RSA公司的ClearTrust等。
2. 采用門戶產(chǎn)品供應(yīng)商自己的SSO產(chǎn)品，如：BEA的WLES，IBM 的Tivoli Access Manager，Sun 公司的identity Server，Oracle公司的OID等。
3. 這些商業(yè)軟件一般適用于客戶對SSO的需求很高，并且企業(yè)內(nèi)部采用COTS軟件如：Domino,SAP,Sieble的系統(tǒng)比較多的情況下采用。并結(jié)合身份管理。統(tǒng)一認(rèn)證等項目采用。采用這些軟件一般都要對要集成的系統(tǒng)做些改造，如在要集成的系統(tǒng)上安裝AGENT。現(xiàn)在一般只提供常見軟件如：Domino,SAP,Sieble，常見應(yīng)用服務(wù)器：weblogic,websphere等的AGENT。要先統(tǒng)一這些系統(tǒng)的認(rèn)證。一般采用LDAP或數(shù)據(jù)庫。然后才能實(shí)現(xiàn)SSO。比較麻煩。
4. 另外，如果不想掏銀子，也有OPEN SOURCE的SSO軟件可選：主要有：http://www.josso.org/ https://opensso.dev.java.net/ http://www.sourceid.org 等。具體怎么樣就不清楚了。

如果項目對SSO的要求比較低，又不想對要被集成的系統(tǒng)做任何改動，可采用下面介紹的方式簡單實(shí)現(xiàn)：下面我們通過一個例子來說明。假如一個門戶項目要對下面的幾個系統(tǒng)做SSO。

用戶在這些系統(tǒng)中的用戶名，密碼各不相同，如：員工號為001的員工在這些系統(tǒng)中的用戶名，密碼分別如下：

用戶	系統(tǒng)	用戶名	密碼
001	Portal系統(tǒng)	A	1234
001	郵件系統(tǒng)	B	2345
001	DOMINO系統(tǒng)	C	AAAA
001	報銷系統(tǒng)	D	CCCC
001	工資系統(tǒng)	E	BBBB

首先，建立員工在PORTAL系統(tǒng)中的用戶名和其他系統(tǒng)中的用戶名之間的對應(yīng)關(guān)系

首先，要建立員工在PORTAL系統(tǒng)中的用戶名和其他系統(tǒng)中的用戶名之間的對應(yīng)關(guān)系并保存。可保存在表中或LDAP中或文件系統(tǒng)中。當(dāng)然要考慮這些系統(tǒng)之間的數(shù)據(jù)同步問題。比較好的方式是找到用戶在這些系統(tǒng)中的都存在的唯一信息（如員工號，MAIL地址，姓名等）。通過唯一信息實(shí)時到各個系統(tǒng)中去取認(rèn)證所需要的信息。就不需要考慮數(shù)據(jù)同步問題。比較實(shí)用。可以建立類似下面的表：密碼可采用加密保存。如果是采用BEA的Weblogic Portal,可采用UUP來保存這些信息。

(

user

varchar2(20),

/*用戶名*/

app_name varchar2(20),

/*應(yīng)用系統(tǒng)*/

architect varchar2(4),

/*應(yīng)用系統(tǒng)的架構(gòu)BS或CS*/

app_company varchar2(50),

/*用戶所屬分公司*/ app_department varchar2(50),

/*用戶所在的部門*/ app_user varchar2(15),

/*在該系統(tǒng)中的用戶名*/

app_passwd varchar2(15),

/*在該系統(tǒng)中的密碼*/

app_cookie varchar2(30),

/*COOKIE名稱*/

form_user varchar2(20),

/*認(rèn)證頁面中FORM的用戶名字段*/

form_passwd varchar2(20),

/*認(rèn)證頁面中FORM的密碼字段*/

app_special varchar2(20)

/*其他*/ );

通過IFRAME或超連接方式集成目標(biāo)系統(tǒng)，并進(jìn)行SSO

通過IFRAME或超連接方式集成目標(biāo)系統(tǒng),并在URL中帶上用戶名和密碼。如集成DOMINO可采用如下方式：

width=" >

或：

Href src=“http:// host1/names.nsf?Login&Username=admin&Password=pass&RedirectTo=/names.nsf”

以上采用的是在HTTP中直接傳遞明碼，為提高安全性，可采用HTTPS來傳遞用戶名和密碼。另外采用這種方式被集成的系統(tǒng)必須支持FORM方式認(rèn)證。J2EE應(yīng)用，DOMINO等都支持FORM認(rèn)證。

這兩種方式如果SSO成功，就自動進(jìn)入目標(biāo)系統(tǒng)的界面，如果實(shí)現(xiàn)會顯示目標(biāo)系統(tǒng)的登錄界面。其效果圖如下：

這種方式，必須維護(hù)對應(yīng)關(guān)系表，如上面的sso_info。更好的方式是提供界面，讓最終用戶自己維護(hù)這種對應(yīng)關(guān)系，可模仿Compoze portlets for lotus的做法，在用戶第一次進(jìn)入要與之做SSO的系統(tǒng)時，如DOMINO系統(tǒng)，顯示一個界面，讓用戶自己輸入他在該系統(tǒng)中的用戶名/密碼等信息。并保存到表中或LDAP等其他數(shù)據(jù)源中。以后用戶要進(jìn)入這些系統(tǒng)時，就直接從表中或其他數(shù)據(jù)源中取用戶的用戶名/密碼等信息，幫助用戶做認(rèn)證。建議采用這種方式。如下圖所示。如果用戶改變了自己在DOMINO系統(tǒng)中的用戶名，密碼。從門戶系統(tǒng)進(jìn)入DOMINO系統(tǒng)時，認(rèn)證會失敗，就重新顯示類似下面的界面。讓用戶重新輸入他在DOMINO系統(tǒng)中新的用戶名，密碼并保存。

以上這種實(shí)現(xiàn)方式，一般需要瀏覽器支持COOKIE，所以要注意瀏覽器的配置，在開發(fā)階段，為方便調(diào)試，可設(shè)置IE，讓它顯示COOKIE的名稱。如下所示：

采用這種方式，對要集成的系統(tǒng)不需要做任何的改動。如果PORTAL系統(tǒng)中的用戶在被集成的系統(tǒng)中的權(quán)限都一樣，可采用建立一個通用用戶的做法。也就是所有在PORTAL系統(tǒng)中的用戶都采用這個通用用戶進(jìn)入目標(biāo)系統(tǒng)。這種方式等于是采用頁面集成方式做集成。比較方便使用。另外，有時候需要采用調(diào)用API，或配置Adapter等應(yīng)用集成方式來集成其他系統(tǒng)，一般也是通過定義一個連接專用的用戶。在API中或在配置Adapter的時候?qū)懰馈Ｈ绮捎肑AVA API方式集成DOMINO：

lotus.domino.Session dominoSession = NotesFactory.createSession(dominoServer, “admin”, “password”);

CS結(jié)構(gòu)實(shí)現(xiàn)方式

經(jīng)常有人問CS結(jié)構(gòu)的應(yīng)用如何實(shí)現(xiàn)SSO，本人的建議是對這種系統(tǒng)不要自己去實(shí)現(xiàn)SSO。很麻煩，其實(shí)輸個用戶名，密碼沒什么大不了的。如果要實(shí)現(xiàn)，一是采用商業(yè)軟件。另外也可以采用以下方式：在PORTAL的PORTLET上建立超連接。并通過APPLET方式啟動CS結(jié)構(gòu)的應(yīng)用系統(tǒng)的登錄界面。然后通過如下的方式把用戶名/密碼傳遞過去。

-不能做任何改動的客戶端- WIN消息（給登錄窗口發(fā)送用戶名，密碼等登錄所需要的信息）,模擬鍵盤（java有模擬鍵盤輸入的API）

-可以做改動的客戶端- 參數(shù)傳遞，并讓登錄的EXE文件讀取參數(shù)進(jìn)行認(rèn)證。

因為要讓APPLET執(zhí)行本地的EXE文件，所以必須對IE中的JRE的安全進(jìn)行設(shè)置。

其他：

在采用以上方式實(shí)現(xiàn)了SSO后，要注意LOGOUT，可采用與LOGIN相同的方式。也可以通過被集成系統(tǒng)的超時設(shè)置來實(shí)現(xiàn)。

單點(diǎn)登錄SSO技術(shù)資料收集

• 統(tǒng)一用戶認(rèn)證和單點(diǎn)登錄解決方案: 計算機(jī)世界網(wǎng)上的文章,比較全面的介紹統(tǒng)一用戶認(rèn)證和單點(diǎn)登錄解決方案
• 惠普靈動單點(diǎn)登錄(SSO)解決方案: 包括C/S結(jié)構(gòu)的系統(tǒng)單點(diǎn)登錄解決方案
• 網(wǎng)站用戶單點(diǎn)登錄系統(tǒng)解決方案: 通過令牌方式實(shí)現(xiàn)網(wǎng)站用戶單點(diǎn)登錄
• WebLogic平臺的Web SSO（SAML）解決方案: 在WebLogic 8.1SP4中，提供了用于和Microsoft Windows客戶端進(jìn)行SSO的Single Pass Negotiate Identity Assertion Provider。本文對其做了詳細(xì)的介紹。
• http://blog.beijingnet.com/index.php?blogId=4: 收錄了一些SSO方面的文章
• 應(yīng)用整合中SSO的技術(shù)實(shí)現(xiàn): 作者介紹了南京地稅進(jìn)行應(yīng)用整合SSO的技術(shù)實(shí)現(xiàn)方案

===============================================================================================================================
=================================================================================================================================

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

      通常來說，每個單獨(dú)的系統(tǒng)都會有自己的安全體系和身份認(rèn)證系統(tǒng)。整合以前，進(jìn)入每個系統(tǒng)都需要進(jìn)行登錄，這樣的局面不僅給管理上帶來了很大的困難，在安全方面也埋下了重大的隱患。下面是一些著名的調(diào)查公司顯示的統(tǒng)計數(shù)據(jù)：

• 用戶每天平均16分鐘花在身份驗證任務(wù)上 - 資料來源：IDS
• 頻繁的IT用戶平均有21個密碼 - 資料來源：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)入多個系統(tǒng)，而不需要重新登錄，這不僅僅帶來了更好的用戶體驗，更重要的是降低了安全的風(fēng)險和管理的消耗。請看下面的統(tǒng)計數(shù)據(jù)：

• 提高IT效率：對于每1000個受管用戶，每用戶可節(jié)省$70K
• 幫助臺呼叫減少至少1/3，對于10K員工的公司，每年可以節(jié)省每用戶$75，或者合計$648K
• 生產(chǎn)力提高：每個新員工可節(jié)省$1K，每個老員工可節(jié)省$350 - 資料來源：Giga
• ROI回報：7.5到13個月 - 資料來源：Gartner   

      另外，使用“單點(diǎn)登錄”還是SOA時代的需求之一。在面向服務(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í)是比較簡單的，用一個現(xiàn)實(shí)中的例子做比較。頤和園是北京著名的旅游景點(diǎn)，也是我常去的地方。在頤和園內(nèi)部有許多獨(dú)立的景點(diǎn)，例如“蘇州 街”、“佛香閣”和“德和園”，都可以在各個景點(diǎn)門口單獨(dú)買票。很多游客需要游玩所有德景點(diǎn)，這種買票方式很不方便，需要在每個景點(diǎn)門口排隊買票，錢包拿 進(jìn)拿出的，容易丟失，很不安全。于是絕大多數(shù)游客選擇在大門口買一張通票（也叫套票），就可以玩遍所有的景點(diǎn)而不需要重新再買票。他們只需要在每個景點(diǎn)門 口出示一下剛才買的套票就能夠被允許進(jìn)入每個獨(dú)立的景點(diǎn)。
      單點(diǎn)登錄的機(jī)制也一樣，如下圖所示，當(dāng)用戶第一次訪問應(yīng)用系統(tǒng)1的時候，因為還沒有登錄，會被引導(dǎo)到認(rèn)證系統(tǒng)中進(jìn)行登錄（1）；根據(jù)用戶提供的登錄信息， 認(rèn)證系統(tǒng)進(jìn)行身份效驗，如果通過效驗，應(yīng)該返回給用戶一個認(rèn)證的憑據(jù)－－ticket（2）；用戶再訪問別的應(yīng)用的時候（3，5）就會將這個ticket 帶上，作為自己認(rèn)證的憑據(jù)，應(yīng)用系統(tǒng)接受到請求之后會把ticket送到認(rèn)證系統(tǒng)進(jìn)行效驗，檢查ticket的合法性（4，6）。如果通過效驗，用戶就可 以在不用再次登錄的情況下訪問應(yīng)用系統(tǒng)2和應(yīng)用系統(tǒng)3了。
  
      從上面的視圖可以看出，要實(shí)現(xiàn)SSO，需要以下主要的功能：

• 所有應(yīng)用系統(tǒng)共享一個身份認(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ī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)登錄的功能。   

      上面的功能只是一個非常簡單的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)生和效驗，無論用戶信息存儲在什么地方，都能實(shí)現(xiàn)單點(diǎn)登錄。    

• 統(tǒng)一的認(rèn)證系統(tǒng)并不是說只有單個的認(rèn)證服務(wù)器，如下圖所示，整個系統(tǒng)可以存在兩個以上的認(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時，由第一個認(rèn)證服務(wù)器進(jìn)行認(rèn)證后，得到由此 服務(wù)器產(chǎn)生的ticket。當(dāng)他訪問應(yīng)用系統(tǒng)4的時候，認(rèn)證服務(wù)器2能夠識別此ticket是由第一個服務(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）是一個無狀態(tài)的協(xié)議。一個Web應(yīng)用由很多個Web頁面組成，每個頁面都有唯一的URL來定義。用戶在瀏覽器的地 址欄輸入頁面的URL，瀏覽器就會向Web Server去發(fā)送請求。如下圖，瀏覽器向Web服務(wù)器發(fā)送了兩個請求，申請了兩個頁面。這兩個頁面的請求是分別使用了兩個單獨(dú)的HTTP連接。所謂無狀 態(tài)的協(xié)議也就是表現(xiàn)在這里，瀏覽器和Web服務(wù)器會在第一個請求完成以后關(guān)閉連接通道，在第二個請求的時候重新建立連接。Web服務(wù)器并不區(qū)分哪個請求來 自哪個客戶端，對所有的請求都一視同仁，都是單獨(dú)的連接。這樣的方式大大區(qū)別于傳統(tǒng)的（Client/Server）C/S結(jié)構(gòu),在那樣的應(yīng)用中，客戶端 和服務(wù)器端會建立一個長時間的專用的連接通道。正是因為有了無狀態(tài)的特性，每個連接資源能夠很快被其他客戶端所重用，一臺Web服務(wù)器才能夠同時服務(wù)于成 千上萬的客戶端。

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

      Web-SSO完全可以利用Cookie結(jié)束來完成用戶登錄信息的保存，將瀏覽器中的Cookie和上文中的Ticket結(jié)合起來，完成SSO的功能。

      為了完成一個簡單的SSO的功能，需要兩個部分的合作：

• 統(tǒng)一的身份認(rèn)證服務(wù)。
• 修改Web應(yīng)用，使得每個應(yīng)用都通過這個統(tǒng)一的認(rèn)證服務(wù)來進(jìn)行身份效驗。

   3.1 Web SSO 的樣例
      根據(jù)上面的原理，我用J2EE的技術(shù)（JSP和Servlet）完成了一個具有Web-SSO的簡單樣例。樣例包含一個身份認(rèn)證的服務(wù)器和兩個簡單的 Web應(yīng)用，使得這兩個 Web應(yīng)用通過統(tǒng)一的身份認(rèn)證服務(wù)來完成Web-SSO的功能。此樣例所有的源代碼和二進(jìn)制代碼都可以從網(wǎng)站地址http://gceclub.sun.com.cn/wangyu/下載。

      樣例下載、安裝部署和運(yùn)行指南：

• Web-SSO的樣例是由三個標(biāo)準(zhǔn)Web應(yīng)用組成，壓縮成三個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） 是兩個用來演示單點(diǎn)登錄的Web應(yīng)用。這三個Web應(yīng)用之所以沒有打成war包，是因為它們不能直接部署，根據(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是因為筆者使用了一個線程安全的高性能的Java集合類 “ConcurrentMap”，只有在JDK1.5中才有。
• 這三個Web應(yīng)用完全可以單獨(dú)部署，它們可以分別部署在 不同的機(jī)器，不同的操作系統(tǒng)和不同的J2EE的產(chǎn)品上，它們完全是標(biāo)準(zhǔn)的和平臺無關(guān)的應(yīng)用。但是有一個限制，那兩臺部署應(yīng)用（demo1、demo2）的 機(jī)器的域名需要相同，這在后面的章節(jié)中會解釋到cookie和domain的關(guān)系以及如何制作跨域的WEB-SSO
  解壓縮SSOAuth.zip文件，在/WEB-INF/下的web.xml中請修改“domainname”的屬性以反映實(shí)際的應(yīng)用部署情況， domainname需要設(shè)置為兩個單點(diǎn)登錄的應(yīng)用（demo1和demo2）所屬的域名。這個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這個目錄壓縮打包成war文件。用“jar -cvf SSOAuth.war SSOAuth/”就可以完成這個功能。
• 解壓縮SSOWebDemo1和SSOWebDemo2文件，分別在它們/WEB-INF/下找到web.xml文件，請修改其中的幾個初始化參數(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這兩個目錄壓 縮打包成兩個war文件。用“jar -cvf SSOWebDemo1.war SSOWebDemo1/”就可以完成這個功能。
• 請輸入第一個web應(yīng)用的測試URL（test.jsp）,例如http://wangyu.prc.sun.com:8080/SSOWebDemo1/test.jsp，如果是第一次訪問，便會自動跳轉(zhuǎn)到登錄界面，如下圖。

• 使用系統(tǒng)自帶的三個帳號之一登錄（例如，用戶名：wangyu,密碼：wangyu），便能成功的看到test.jsp的內(nèi)容：顯示當(dāng)前用戶名和歡迎信息。

• 請接著在同一個瀏覽器中輸入第二個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ù)是一個標(biāo)準(zhǔn)的web應(yīng)用，包括一個名為SSOAuth的Servlet，一個login.jsp文件和一個failed.html。身份 認(rèn)證的所有服務(wù)幾乎都由SSOAuth的Servlet來實(shí)現(xiàn)了；login.jsp用來顯示登錄的頁面（如果發(fā)現(xiàn)用戶還沒有登錄過）； failed.html是用來顯示登錄失敗的信息（如果用戶的用戶名和密碼與信息數(shù)據(jù)庫中的不一樣）。
  
      SSOAuth的代碼如下面的列表顯示，結(jié)構(gòu)非常簡單，先看看這個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就是一個簡單的Servlet。其中有兩個靜態(tài)成員變量：accounts和SSOIDs，這兩個成員變量都使用了 JDK1.5中線程安全的MAP類： ConcurrentMap，所以這個樣例一定要JDK1.5才能運(yùn)行。Accounts用來存放用戶的用戶名和密碼，在init()的方法中可以看到我 給系統(tǒng)添加了三個合法的用戶。在實(shí)際應(yīng)用中，accounts應(yīng)該是去數(shù)據(jù)庫中或LDAP中獲得，為了簡單起見，在本樣例中我使用了 ConcurrentMap在內(nèi)存中用程序創(chuàng)建了三個用戶。而SSOIDs保存了在用戶成功的登錄后所產(chǎn)生的cookie和用戶名的對應(yīng)關(guān)系。它的功能顯 而易見：當(dāng)用戶成功登錄以后，再次訪問別的系統(tǒng)，為了鑒別這個用戶請求所帶的cookie的有效性，需要到SSOIDs中檢查這樣的映射關(guān)系是否存在。

      在主要的請求處理方法processRequest()中，可以很清楚的看到SSOAuth的所有功能。

• 如果用戶還沒有登錄過，是第一次登錄本系統(tǒng)，會被跳轉(zhuǎn)到login.jsp頁面（在后面會解釋如何跳轉(zhuǎn)）。用戶在提供了用戶名和密碼以后，就會用handlerFromLogin()這個方法來驗證。
• 如果用戶已經(jīng)登錄過本系統(tǒng)，再訪問別的應(yīng)用的時候，是不需要再次登錄的。因為瀏覽器會將第一次登錄時產(chǎn)生的cookie和請求一起發(fā)送。效驗cookie的有效性是SSOAuth的主要功能之一。
• SSOAuth還能直接效驗非login.jsp頁面過來的用戶名和密碼的效驗請求。這個功能是用于非web應(yīng)用的SSO，這在后面的桌面SSO中會用到。
• SSOAuth還提供logout服務(wù)。   

      下面看看幾個主要的功能函數(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()這個方法是用來處理來自login.jsp的登錄請求。它的邏輯很簡單：將用戶輸入的用戶名和密碼與預(yù)先設(shè)定好的用 戶集合（存放在accounts中）相比較，如果用戶名或密碼不匹配的話，則返回登錄失敗的頁面（failed.html），如果登錄成功的話，需要為用 戶當(dāng)前的session創(chuàng)建一個新的ID，并將這個ID和用戶名的映射關(guān)系存放到SSOIDs中，最后還要將這個ID設(shè)置為瀏覽器能夠保存的cookie 值。
      登錄成功后，瀏覽器會到哪個頁面呢？那我們回顧一下我們是如何使用身份認(rèn)證服務(wù)的。一般來說我們不會直接訪問身份服務(wù)的任何URL，包括 login.jsp。身份服務(wù)是用來保護(hù)其他應(yīng)用服務(wù)的，用戶一般在訪問一個受SSOAuth保護(hù)的Web應(yīng)用的某個URL時，當(dāng)前這個應(yīng)用會發(fā)現(xiàn)當(dāng)前的 用戶還沒有登錄，便強(qiáng)制將也頁面轉(zhuǎn)向SSOAuth的login.jsp，讓用戶登錄。如果登錄成功后，應(yīng)該自動的將用戶的瀏覽器指向用戶最初想訪問的那 個URL。在handlerFromLogin()這個方法中，我們通過接收“goto”這個參數(shù)來保存用戶最初訪問的URL，成功后便重新定向到這個頁 面中。
      另外一個要說明的是，在設(shè)置cookie的時候，我使用了一個setMaxAge(6000)的方法。這個方法是用來設(shè)置cookie的有效期，單位是 秒。如果不使用這個方法或者參數(shù)為負(fù)數(shù)的話，當(dāng)瀏覽器關(guān)閉的時候，這個cookie就失效了。在這里我給了很大的值（1000分鐘），導(dǎo)致的行為是：當(dāng)你 關(guān)閉瀏覽器（或者關(guān)機(jī)），下次再打開瀏覽器訪問剛才的應(yīng)用，只要在1000分鐘之內(nèi)，就不需要再登錄了。我這樣做是下面要介紹的桌面SSO中所需要的功 能。
      其他的方法更加簡單，這里就不多解釋了。

===============================================================================================================================
=================================================================================================================================
      前段時間為我們的系統(tǒng)做SSO(單點(diǎn)登錄)參考了很多資料,其中包括博客園二級域名的登錄.翻譯本文是由于作者的一句話:思想都是一樣的,只不過實(shí)現(xiàn)起來需要創(chuàng)造性思維. 

 Single Sign-On (SSO)是近來的熱門話題.很多和我交往的客戶中都有不止一個運(yùn)行在.Net框架中的Web應(yīng)用程序或者若干子域名.而他們甚至希望在不同的域名中也可以只登陸一次就可以暢游所有站點(diǎn).今天我們關(guān)注的是如何在各種不同的應(yīng)用場景中實(shí)現(xiàn) SSO. 我們由簡到繁,逐一攻破.

1. 虛擬目錄的主應(yīng)用和子應(yīng)用間實(shí)現(xiàn)SSO
2. 使用不同驗證機(jī)制實(shí)現(xiàn)SSO (username mapping)
3. 同一域名中,子域名下的應(yīng)用程序間實(shí)現(xiàn)SSO
4. 運(yùn)行在不同版本.NET下的應(yīng)用程序間實(shí)現(xiàn)SSO
5. 兩個不同域名下的Web應(yīng)用程序間實(shí)現(xiàn)SSO
6. 混合身份驗證方式模式 (Forms and Windows)下實(shí)現(xiàn)SSO

1. 虛擬目錄的主應(yīng)用和子應(yīng)用之間實(shí)現(xiàn)SSO

       假設(shè)有兩個.Net的Web應(yīng)用程序-Foo和Bar,Bar運(yùn)行在Foo虛擬目錄的子目錄(http://foo.com/bar).二者都實(shí)現(xiàn)了Forms認(rèn)證.實(shí)現(xiàn)Forms認(rèn)證需要我們重寫Application_AuthenticateRequest,在這個時機(jī)我們完成認(rèn)證一旦通過驗證就調(diào)用一下FormsAuthentication.RedirectFromLoginPage.這個方法接收的參數(shù)是用戶名或者其它的一些身份信息.在Asp.net中登錄用戶的狀態(tài)是持久化存儲在客戶端的cookie中.當(dāng)你調(diào)用RedirectFromLoginPage時就會創(chuàng)建一個包含加密令牌FormsAuthenticationTicket的cookie,cookie名就是登錄用戶的用戶名.下面的配置節(jié)在Web.config定義了這種cookie如何創(chuàng)建:

<authenticationmode="Forms">

   <formsname=".FooAuth"protection="All"timeout="60"loginUrl="login.aspx" />

</authentication>

 <authenticationmode="Forms">

   <formsname=".BarAuth"protection="All"timeout="60"loginUrl="login.aspx" />

</authentication>

比較重要的兩個屬性是name和protection. 按照下面的配置就可以讓Foo和Bar兩個程序在同樣的保護(hù)級別下讀寫Cookie,這就實(shí)現(xiàn)了SSO的效果:

<authenticationmode="Forms">

   <formsname=".SSOAuth"protection="All"timeout="60"loginUrl="login.aspx" />

</authentication>

當(dāng) protection屬性設(shè)置為 "All",通過Hash值進(jìn)行加密和驗證數(shù)據(jù)都存放在Cookie中.默認(rèn)的驗證和加密使用的Key都存儲在machine.config文件,我們可以在應(yīng)用程序的Web.Config文件覆蓋這些值.默認(rèn)值如下:

<machineKeyvalidationKey="AutoGenerate,IsolateApps"decryptionKey=" AutoGenerate,IsolateApps"validation="SHA1" />

IsolateApps表示為每個應(yīng)用程序生成不同的Key.我們不能使用這個.為了能在多個應(yīng)用程序中使用相同的Key來加密解密cookie,我們可以移除IsolateApps 選項或者更好的方法是在所有需要實(shí)現(xiàn)SSO的應(yīng)用程序的Web.Config中設(shè)置一個具體的Key值: 

<machineKeyvalidationKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902"decryptionKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902F8D923AC"validation="SHA1" />

如果你使用同樣的存儲方式,實(shí)現(xiàn)SSO只是改動一下Web.config而已.

2.使用不同認(rèn)證機(jī)制實(shí)現(xiàn)SSO (username mapping)

     要是FOO站點(diǎn)使用database來做認(rèn)證,Bar站點(diǎn)使用Membership API或者其它方式做認(rèn)證呢?這種情景中FOO站點(diǎn)創(chuàng)建的cookie對Bar站點(diǎn)毫無用處,因為cookie中的用戶名對Bar沒有什么意義.

   要想cookie起作用,你就需要再為Bar站點(diǎn)創(chuàng)建一個認(rèn)證所需的cookie.這里你需要為兩個站點(diǎn)的用戶做一下映射.假如有一個Foo站點(diǎn)的用戶"John Doe"在Bar站點(diǎn)需要識別成"johnd".在Foo站帶你你需要下面的代碼:

FormsAuthenticationTicket fat = new FormsAuthenticationTicket(1, "johnd", DateTime.Now, DateTime.Now.AddYears(1), true, "");

HttpCookie cookie = new HttpCookie(".BarAuth");

cookie.Value = FormsAuthentication.Encrypt(fat);

cookie.Expires = fat.Expiration;

HttpContext.Current.Response.Cookies.Add(cookie);

FormsAuthentication.RedirectFromLoginPage("John Doe");

為了演示用戶名硬編碼了.這個代碼片段為Bar站點(diǎn)創(chuàng)建了令牌FormsAuthenticationTicket ,這時令牌里的用戶名在Bar站點(diǎn)的上下文中就是有意義的了.這時再調(diào)用 RedirectFromLoginPage創(chuàng)建正確的認(rèn)證cookie.上面的例子你統(tǒng)一了了Forms 認(rèn)證的cookie名字,而這里你要確保他們不同--因為我們不需要兩個站點(diǎn)共享相同的cookie:

<authenticationmode="Forms">

   <formsname=".FooAuth"protection="All"timeout="60"loginUrl="login.aspx"slidingExpiration="true"/>

</authentication>

 <authenticationmode="Forms">

   <formsname=".BarAuth"protection="All"timeout="60"loginUrl="login.aspx"slidingExpiration="true"/>

</authentication>

現(xiàn)在當(dāng)用戶在Foo站點(diǎn)登錄,他就會被映射到到Bar站點(diǎn)的用戶并同時創(chuàng)建了Foo和Bar兩個站點(diǎn)的認(rèn)證令牌.如果你想在Bar站點(diǎn)登錄在Foo站點(diǎn)通行,那么代碼就會是這樣:

FormsAuthenticationTicket fat = new FormsAuthenticationTicket(1, "John Doe", DateTime.Now, DateTime.Now.AddYears(1), true, "");

HttpCookie cookie = new HttpCookie(".FooAuth");

cookie.Value = FormsAuthentication.Encrypt(fat);

cookie.Expires = fat.Expiration;

HttpContext.Current.Response.Cookies.Add(cookie);

FormsAuthentication.RedirectFromLoginPage("johnd");

同樣要保證兩個站點(diǎn)的Web.config的<machineKey>配置節(jié)有相同的加密和解密的Key!

3. 同一域名中,各子域名下應(yīng)用程序間實(shí)現(xiàn)SSO

        要是這樣的情況又將如何:Foo Bar兩個站點(diǎn)運(yùn)行在不同的域名下:http://foo.com and http://bar.foo.com. 上面的代碼又不起作用了:因為cookie會存儲在不同的文件中,各自的cookie對其它網(wǎng)站不可見.為了能讓它起作用我們需要創(chuàng)建域級cookie,因為域級cookie對子域名都是可見的!這里我們也不能再使用 RedirectFromLoginPage 方法了,因為它不能靈活的創(chuàng)建域級cookie我們需要手工完成這個過程!

FormsAuthenticationTicket fat = new FormsAuthenticationTicket(1, "johnd", DateTime.Now, DateTime.Now.AddYears(1), true, "");

HttpCookie cookie = new HttpCookie(".BarAuth");

cookie.Value = FormsAuthentication.Encrypt(fat);

cookie.Expires = fat.Expiration;

cookie.Domain = ".foo.com";

HttpContext.Current.Response.Cookies.Add(cookie);

FormsAuthenticationTicket fat = new FormsAuthenticationTicket(1, "John Doe", DateTime.Now, DateTime.Now.AddYears(1), true, "");

HttpCookie cookie = new HttpCookie(".FooAuth");

cookie.Value = FormsAuthentication.Encrypt(fat);

cookie.Expires = fat.Expiration;

cookie.Domain = ".foo.com";

HttpContext.Current.Response.Cookies.Add(cookie);

注意cookie.Domain = ".foo.com";注意這一行.這里明確指定了cookie的域名為".foo.com",這樣我們就保證了cookie對http://foo.com和http://bar.foo.com以及其它子域名都是可見的.(譯者注:cookie的域名匹配規(guī)則是從右到左).你可以通過設(shè)置Bar站點(diǎn)的認(rèn)證cookie的域名為"bar.foo.com".這樣對于其它子域名的站點(diǎn)它的cookie也是不可見的,這樣安全了.注意 RFC 2109 要求cookie前面有兩個周期所以我們添加了一個過期時間.(cookie值實(shí)際上是一個字符串,各參數(shù)用逗號隔開).

再次提醒,這里還是需要統(tǒng)一一下各個站點(diǎn)的Web.config的<machineKey>配置節(jié)的Key值.這種解決方案只有一種異常的情況,且看下節(jié)詳解.

4. 運(yùn)行在不同版本.Net下應(yīng)用程序間實(shí)現(xiàn)SSO

       要是Foo和Bar站點(diǎn)運(yùn)行在不同的.Net環(huán)境中上面的例子都行不通.這是由于Asp.net 2.0使用了不同于1.1的加密算法:1.1版本使用的是3DES,2.0是AES.萬幸,Asp.net2.0中有一個屬性可以兼容1.1:

<machineKeyvalidationKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902"decryptionKey="F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902F8D923AC"validation="SHA1"decryption="3DES" />

設(shè)置decryption="3DES"就會讓 ASP.NET 2.0使用舊版本的加密算法使cookie能夠正常使用.不要企圖在Asp.net1.1的Web.config文件中添加這個屬性,那會報錯.

5. 兩個不同域名下的應(yīng)用程序?qū)崿F(xiàn)SSO

        我們已經(jīng)成功的創(chuàng)建了可以共享的認(rèn)證Cookie,但是如果Foo站點(diǎn)和Bar站點(diǎn)在不同域名下呢,例如:http://foo.com和http://bar.com? 他們不能共享cookie也不能為對方在創(chuàng)建一個可讀的cookie.這種情況下每個站點(diǎn)需要創(chuàng)有各自的cookie,調(diào)用其它站點(diǎn)的頁面來驗證用戶是否登錄.其中一種實(shí)現(xiàn)方式就是使用一系列的重定向.

      為了實(shí)現(xiàn)上述目標(biāo),我們需要在每個站點(diǎn)都創(chuàng)建一個特殊的頁面(比如:sso.aspx).這個頁面的作用就是來檢查該域名下的cookie是否存在并返回已經(jīng)登錄用戶的用戶名.這樣其它站點(diǎn)也可以為這個用戶創(chuàng)建一個cookie了.下面是Bar.com的sso.aspx:

Bar.com:

<%@ Page Language="C#" %>

<script language="C#" runat="server">

void Page_Load()

{

   // this is our caller, we will need to redirect back to it eventually

   UriBuilder uri = new UriBuilder(Request.UrlReferrer);

   HttpCookie c = HttpContext.Current.Request.Cookies[".BarAuth"];

   if (c != null && c.HasKeys) // the cookie exists!

   {

      try

      {

         string cookie = HttpContext.Current.Server.UrlDecode(c.Value);

         FormsAuthenticationTicket fat = FormsAuthentication.Decrypt(cookie);         

         uri.Query = uri.Query + "&ssoauth=" + fat.Name; // add logged-in user name to the query

      }

      catch

      {

      }

   }

   Response.Redirect(uri.ToString()); // redirect back to the caller

}

</script>

這個頁面總是重定向回調(diào)用的站點(diǎn).如果Bar.com存在認(rèn)證cookie,它就解密出來用戶名放在ssoauth參數(shù)中.

另外一端(Foo.com),我們需要在HTTP Rquest處理的管道中添加一些的代碼.可以是Web應(yīng)用程序的 Application_BeginRequest 事件或者是自定義的HttpHandler或HttpModule.基本思想就是在所有Foo.com的頁面請求之前做攔截,盡早的檢查驗證cookie是否存在:

1. 如果Foo.com的認(rèn)證cookie已經(jīng)存在,就繼續(xù)處理請求,用戶在Foo.com登錄過

2. 如果認(rèn)證Cookie不存在就重定向到Bar.com/sso.aspx.

3. 如果現(xiàn)在的請求是從Bar.com/sso.aspx重定向回來的,分析一下ssoauth參數(shù)如果需要就創(chuàng)建認(rèn)證cookie.

路子很簡單,但是又兩個地方要注意死循環(huán):

// see if the user is logged in

HttpCookie c = HttpContext.Current.Request.Cookies[".FooAuth"];

if (c != null && c.HasKeys) // the cookie exists!

{

   try

   {

      string cookie = HttpContext.Current.Server.UrlDecode(c.Value);

      FormsAuthenticationTicket fat = FormsAuthentication.Decrypt(cookie);

      return; // cookie decrypts successfully, continue processing the page

   }

   catch

   {

   }

}

// the authentication cookie doesn't exist - ask Bar.com if the user is logged in there

UriBuilder uri = new UriBuilder(Request.UrlReferrer);

if (uri.Host != "bar.com" || uri.Path != "/sso.aspx") // prevent infinite loop

{

   Response.Redirect(http://bar.com/sso.aspx);

}

else

{

   // we are here because the request we are processing is actually a response from bar.com

   if (Request.QueryString["ssoauth"] == null)

   {

      // Bar.com also didn't have the authentication cookie

      return; // continue normally, this user is not logged-in 

   } else

   {

      // user is logged in to Bar.com and we got his name!

      string userName = (string)Request.QueryString["ssoauth"];

      // let's create a cookie with the same name

      FormsAuthenticationTicket fat = new FormsAuthenticationTicket(1, userName, DateTime.Now, DateTime.Now.AddYears(1), true, "");

      HttpCookie cookie = new HttpCookie(".FooAuth");

      cookie.Value = FormsAuthentication.Encrypt(fat);

      cookie.Expires = fat.Expiration;

      HttpContext.Current.Response.Cookies.Add(cookie);

   }

}

          同樣的代碼兩個站點(diǎn)都要有,確保你使用了正確的cookie名字(.FooAuth vs. .BarAuth) . 因為cookie并不是真正意義上的共享,因為Web應(yīng)用程序的有不同的<machineKey>配置節(jié).這里沒有必要統(tǒng)一加密和解密的Key.

         有些人把在url里面把用戶名當(dāng)作參數(shù)傳遞視為畏途.實(shí)際上有兩件事情可以做來保護(hù):首先我們可以檢查引用頁參數(shù)不接受bar.com/sso.aspx (or foo.com/ssp.aspx)以外的站點(diǎn).其次,用戶名可以可以通過相同的Key做一下加密.如果Foo和Bar使用不同的認(rèn)證機(jī)制,額外的用戶信息(比如email地址)同樣也可以傳遞過去.

6. 混合身份驗證模式下 (Forms and Windows)實(shí)現(xiàn)SSO

       上面我們都是處理的Forms認(rèn)證.要是我們這樣設(shè)計認(rèn)證過程呢:先做Forms認(rèn)證,如果沒有通過就檢查Intranet用戶是否已經(jīng)在NT域上登錄過了.這個思路我們需要檢查下面的參數(shù)來看和請求關(guān)聯(lián)的Windows logo信息:

Request.ServerVariables["LOGON_USER"]

      但是除非我們的站點(diǎn)都是禁用匿名登錄的,否則這個值總是空的.我們可以在IIS的控制面板禁用匿名登錄并為我們的站點(diǎn)啟用Windows集成認(rèn)證.這樣LOGON_USER 值就包含了NT域登錄用戶的名字.但是所有Internet用戶的都會遇到用戶名和密碼的難題,這就不好了,我們要讓Internet用戶使用Forms認(rèn)證要是這種方式失敗了再使用Windows域認(rèn)證.

       這個問題的解決方法之一就是為Intranet用戶設(shè)置一個特殊的入口頁面:Windows集成認(rèn)證方式可用,驗證域用戶,創(chuàng)建Forms cookie重定向到主站點(diǎn).我們甚至可以隱藏這樣一個事實(shí):由于Server.TransferIntranet用戶實(shí)際上訪問了不同的頁面.

     也有一個簡單的解決方法.這個方法的基礎(chǔ)是IIS掌控認(rèn)證處理.如果站點(diǎn)對匿名用戶可用,IIS就把請求傳遞給Asp.net運(yùn)行時.并試圖進(jìn)行認(rèn)證要是失敗了就引發(fā)一個401錯誤.IIS會試圖尋找另外該站點(diǎn)的其它認(rèn)證方式.你要設(shè)置匿名訪問和集成認(rèn)證可用并在Forms認(rèn)證失敗之后執(zhí)行下面的代碼:

if (System.Web.HttpContext.Current.Request.ServerVariables["LOGON_USER"] == "") { 

   System.Web.HttpContext.Current.Response.StatusCode = 401; 

   System.Web.HttpContext.Current.Response.End();

}

else

{

   // Request.ServerVariables["LOGON_USER"] has a valid domain user now!

}

這段代碼執(zhí)行時,它會檢查域用戶并取得一個空的初始值.這回終止當(dāng)前請求并返回認(rèn)證的401錯誤到IIS.這就讓IIS自動選擇另外的認(rèn)證機(jī)制,Windows集成認(rèn)證方式就是候選方式.如果用戶可以登錄到域,請求就可以繼續(xù),并附加上了NT域用戶的信息.如果用戶沒有在域中登錄會有三次輸入用戶名密碼的機(jī)會.如果三次失敗他就會得到一個403錯誤(AccessDenied).

結(jié)論

      我們考查了在各種場景中在兩個Asp.net應(yīng)用程序間實(shí)現(xiàn)SSO.我們也可以在不同系統(tǒng)不同平臺間實(shí)現(xiàn)SSO,思想都是一樣的,只不過實(shí)現(xiàn)起來需要創(chuàng)造性思維.