通用Ｗｅｂ跨域認證構架研究與實現

（解放軍信息工程大學 電子技術學院 河南省信息安全重點實驗室 鄭州 450004）

摘 要：分析了目前主要的Web跨域認證技術特點和不足，設計了一種新的基于URL重定向的Web跨域認證構架，給出了典型協議實現并進行了安全性分析。它對信息系統改動極少，且不易受NAT網關和防火墻的限制，具有良好的應用前景。

關鍵詞：跨域認證；認證構架；地址重定向；認證協議；形式化分析密碼協議

中圖分類號：TP393.08文獻標志碼：A

文章編號：1001-3695(2009)05-1796-03

Research and implementation of allpurpose structure ofWeb crossrealm authentication

ZHANG Hongqi，YANG Zhi，WANG Xia，SHEN Changxiang，ZHANG Bin

(Henan Province Key Laboratory of Information Security School of Electronic Technology PLA Information Engineering University Zhengzhou 450004 China)Abstract:This paper analyzed the current main Web crossrealm authentication technologies，designed a new structure based on URL redirection and offerd its typical implementation finally analyzed its security. The structure demands for very few changes in Web systems and also isn’t confined to NAT gateway and firewall. Many Web system can adopt it successfully.

Key words:crossrealm authentication; authentication structure; URL redirect; authentication protocol; formal analysis of cryptographic protocol

隨著互聯網技術和信息技術的發展，現在的企業應用越來越趨向于分布式的、相互合作的形式，傳統的緊耦合結構分布式應用正逐步向基于Web服務構架的松耦合結構分布式應用發展，企業應用已不再僅僅局限于企業內部各應用之間的互操作，而是需要在合作伙伴的不同企業、不同應用之間進行互操作。在傳統的應用系統中，不同的企業、甚至不同的應用都有自己獨立的信任域，用戶的身份也只能在某一特定的信任域中使用。跨信任域的分布式應用的發展使不同企業與應用之間實現跨信任域的身份認證顯得尤為重要。

1 Web跨域認證技術分析

Web跨域認證技術按照認證消息傳遞方式不同，通常有兩種形式，即通過Web協議傳遞認證消息和通過獨立于數據流的安全通信協議傳遞認證消息。

1.1 在Web流中傳遞認證消息

在這種方式中，認證消息流與數據流融合到一起，瀏覽器在頁面請求中攜帶身份認證信息，Web服務器通過讀取和分析Cookie、URI參數或隱藏字段中的認證信息（如票據）來鑒別用戶身份，這種方式通常實現基于Web請求代理的SSO。目前幾種利用聯盟身份實現跨域認證的XML標準，如安全聲明標記語言(SAML)^[1]、自由聯盟(liberty alliance)^[2]計劃和Web服務聯盟語言(WS．federation)^[3]均屬于這種形式。

這種形式實現簡單靈活，不需要瀏覽器特殊支持，而且由于是以Web流通信，容易跨越防火墻和NAT網關，是較流行的一種形式。但是從實際情況來看，它更適用于安全級較低的應用環境中。一方面為了實現跨域認證，客戶端需要具有密碼運算和處理跨域認證消息等功能。目前大多數密碼服務如簽名、加密服務主要是由客戶端本地操作系統以API形式提供，如Windows操作系統提供的密碼服務函數CryptoAPI，而且在我國商用密碼算法大都注入智能設備中，通過設備訪問方式實現密碼調用，極少以軟算法形式出現，這要求客戶端認證程序有較高權限訪問本地資源。另一方面在Web方式中，客戶端認證功能主要是由客戶端腳本程序如JavaScript、VBScript和小程序Java Applet來完成的，這些程序被限制了權限，它們在瀏覽器容器中或在JVM中受限執行而難以訪問本地系統，而且像消息傳遞載體Cookie等載體的防重放和可用性等問題也需要考慮^[4]。這兩方面的原因造成Web認證方式在實現高安全等級的跨域認證時有較大困難，因此像微軟的單點登錄系統.NET Passport目前只支持用戶/口令的簡單認證方式。雖然SSL協議通過公鑰證書實現身份認證，而且瀏覽器廣泛支持SSL，但是它只是實現端到端的安全認證與安全傳輸，而且認證方式限于X.509證書單一認證，如果要實現跨域單點登錄，還有很多問題要解決。

1.2 獨立的認證流

在這種方式中，跨域認證由專門的認證系統（如Kerberos）完成，認證協議的執行獨立于使用它的Web協議環境，認證消息在特定連接中傳遞，不再是通過捎帶形式在Web流中傳遞，通信方式大都是C/S構架，主流操作系統通常會實現常見跨域認證系統的部分或全部，也有些認證系統需要專用認證客戶端。這種方式通常實現基于ticket憑證的SSO。Web應用程序不直接參與認證協議交互，它通過訪問跨域認證服務獲取來訪者身份信息。認證服務大都以認證API形式存在。 一個例子是通用安全服務應用接口 GSSAPI^[5]，它定義了一套編程接口，抽象了身份驗證、消息源驗證和完整性服務，它的一個主要的認證安全機制Kerberos被大部分 GSSAPI 產品所支持。

根據認證發起方不同，可分為推模式和拉模式兩種形式。推模式指用戶訪問Web服務器時，認證客戶端主動完成憑證和鑒別碼的提交。拉模式指認證客戶端被動接收到Web服務器出示憑證要求時，才提交相應認證信息。實現推模式時，認證客戶端需要監視用戶訪問情況，為此認證客戶端或者實現Web訪問代理，目前很多瀏覽器均支持Web代理方式；或者實現對訪問的監聽，這可借助嗅聽技術如WinCap實現。但是這兩個方法均要在認證客戶端增加很多額外功能。拉模式由Web應用程序調用認證接口，然后Web服務器的認證組件向認證客戶端索要鑒別信息，認證客戶端只負責認證交互，相對容易實現，這是比較常見的一種形式。

對于因特網環境，拉模式的實施會受到環境的制約。Web服務器的認證組件連接認證客戶端時，需要知道用戶的網絡位置，雖然Web服務器可以通過用戶HTTP請求解析出用戶的IP地址，但是使用這個地址可能無法連接到認證客戶端，因為如果用戶是通過Intranet連接互聯網時（如小區寬帶上網），用戶的實際IP可能是私有地址，此時Web服務器看到的地址是用戶內部網絡接入因特網的地址翻譯（NAT）網關的地址，通常NAT被設置成支持外出連接，而不支持反向的接入連接，這時認證系統無法正常工作。

本文在分析上述跨域認證技術的優缺點基礎上，提出了一種新的可穿越NAT的通用跨域認證構架。

2 一種通用跨域認證構架設計

跨域認證構架建立在域內實現單點登錄^[6，7]的基礎上，每個信任域內設立認證服務器(authentication server，AS)，它是域內認證權威，用戶可通過認證代理(authentication agent)登錄AS獲取票據實現對域內應用服務器的訪問權。認證代理和Web瀏覽器的同步通過URL重定向實現，Web應用程序通過URL重定向和URL參數來告知認證代理認證其信任源和認證參數。Web應用程序在域內注冊后，調用認證接口(authentication APIs)獲得認證服務，通過認證組件(authentication components)完成和用戶的雙向認證，以減輕其自身的認證負擔和保證認證模塊的通用性與透明性，認證服務形式如Web service、COM等。跨域訪問時兩個域的認證服務器之間需要建立信任關系，為了對跨域訪問進行監控和避免異構域間票據差異導致驗證失敗，需要通過認證服務器間的協商進行票據頒發與轉換。構架如圖1所示。

這種構架有如下特點：a)跨域認證系統對Web瀏覽器沒有改動。b)有關認證的通信容易穿越NAT網關。客戶端認證代理可實時地感知用戶的訪問情況，它會主動連接外界認證實體實現認證功能，而不會出現反向連接。c)對Web應用程序改動較小。Web應用程序發現訪問請求者的身份未知時，通過URL重定向和URL參數傳遞自己的相關信息，誘使對方認證代理向自己發起認證，然后在登錄頁面中調用認證接口，完成對用戶的認證。這使得認證系統可以應用于較多的Web信息系統中，更多時候只是改變認證接口形式，而且認證系統的認證協議及認證機制可靈活擴展和定制，這體現了通用性。

3 基于跨域認證構架的典型實現

3.1 基于該構架的認證協議實現

該構架被成功應用于信息工程大學信息門戶系統項目中，該項目基于該構架設計和實現了跨域認證協議，協議描述如下：協議運行前，密鑰分配情況是：每個應用服務、認證服務器都有自己的X.509公鑰證書；用戶通過登錄域內認證服務器而與其共享一個會話密鑰(登錄方式不限)；兩個域的認證服務器已通過證書進行了雙向認證而共享了一個域間密鑰，這是比較常見的情況。協議運行結果：用戶與其他域內的應用服務器之間實現了雙向認證，由于跨域訪問涉及四個實體之間雙向認證，交互消息較多。

符號說明：假設X和Y代表兩個實體，M代表一條消息，則IDX表示實體X的身份標志，certX表示X的公鑰證書，rX表示X產生的隨機數，KX表示X的公鑰，KX_Y表示X和Y的共享密鑰，{M}KX_Y代表用X和Y的共享密鑰K對消息M進行對稱算法加密，{M}KX代表用X的公鑰加密消息M。這里用戶以C表示，認證服務器用AS表示，應用服務器用App表示。

消息A1 App→C：IDAS，certApp

當C訪問App時，App首先發給C消息A1，告訴自己信任的認證服務器標志IDAS，以及自己的證書certApp。

消息A2 C→App：{IDC，rC}KApp

客戶C收到消息A1后，用公鑰KApp加密自己標志IDC和用于挑戰App的隨機數rC，將密文作為消息A2發給App。

消息A3 App→C:{IDApp，rC，rApp，no}KAS

App解密A2后，用自己信任的AS證書certAS加密IDApp，rC，rApp，no，作為消息A3發給C，看C能否獲得App所信任的AS的服務以幫助解開A3，從而回答App的挑戰。其中，no為認證連接號，它是App用于區分認證連接請求的序號。

消息A4 C→AS：IDAS，M，{sn，H(M)}KAS_C；M＝{IDApp，rC，rApp，no}KAS

C收到消息A3后，它沒有別的辦法，只能將App的挑戰A3發給自己登錄時的認證服務器。它將該App信任的認證服務器標志IDAS，App的挑戰A3，以及一條密文鏈接后，作為消息A4發給自己登錄時的認證服務器，密文是用KAS_C對流水號sn(認證服務器和認證代理之間的會話次數，用于保證訪問請求的新鮮性)和A3的散列值H(M)鏈接的加密。

消息A5 AS→C:{rC，rApp，no，{KAS_App}KApp}KAS_C，{rApp，IDC，userinfo}KAS_App

AS收到消息A4后，解開密文{sn，H(M)}KAS_C，通過比較自己計算得出的H′(M)和傳來的H（M）是否相同以及sn值是否正確來驗證消息是否由C新發來的。若驗證正確，且App聲稱所信任的認證服務器正是自己，則解密{IDApp，rC，rApp，no}KAS，認證服務器到庫中查看App是否注冊。若該App未注冊，則退出協議執行；若App注冊了，產生消息A5。AS將rApp，IDC，user info用臨時密鑰KAS_App加密保護；KAS_App由KApp加密保護；KAS_C加密保護rC，rApp，{KAS_App}KApp后與{rApp，IDC，useinfo}KAS_App一起發給C。

消息A6 C→App：no，{KAS_App}KApp ，{rApp，IDC，userinfo}KAS_App

C收到消息A5后，解密前半部分，看到rc則確認S和App的合法性，并將票據{KAS_App}KApp，{userinfo，rApp，c}KAS_App作為響應發給App。

App解密{KAS_App}KApp得到KAS_App，然后用KAS_App解密{rApp，userinfo}KAS_App。若能看到自己產生的rApp挑戰和C的標志IDC，則確認了C的合法性，并讀取用戶信息串userinfo，App隨后據此信息進行訪問控制。

在訪問請求協議執行中，當認證服務器在處理客戶發來的訪問請求消息A4中，若發現App信任的AS并不是自己，則執行跨域訪問協議。這里設客戶登錄的認證服務器為ASL，應用服務器信任的認證服務器為ASR。ASL根據ASR的標志到配置庫中查找其與自己是否有信任關系，若無信任關系，退出協議執行；若有信任關系，則ASL向ASR發起跨域訪問請求，ASL和ASR共享密鑰KASL_ASR。協議描述如下：

消息C1 ASL→ASR：IDASL，M，{userinfo，H(M)}KASL_ASR，M={IDApp，rC，rApp，no}KASR

其中：M就是消息A3，ASL用KASL_ASR加密userinfo，H(M)，H(M)是M的散列值，ASL將自己的標志、M和該密文作為消息C1發給ASR。

消息C2 ASR→ASL：{rC，no，{KAS_App}KApp}KASL_ASR {rApp，IDC，userinfo}KAS_App

ASR收到消息C1后根據標志IDASL，到庫中查找共享密鑰KASL_ASR，若未找到，退出協議執行；若找到KASL_ASR，解密{userinfo，H(M)}KASL_ASR后，通過H(M)驗證消息C1是否是ASL發來的。若驗證通過，則解開M，并驗證App是否注冊。若注冊則用KASL_ASR加密保護rC，{KAS_App}KApp，并用KASL_ASR加密rApp，IDC，userinfo兩條密文作為消息C2發給ASL，這樣ASL和C就得到了可被App接受的票據。后面的步驟回到訪問請求中 消息A5和A6的處理，從而實現跨域訪問。



上述跨域訪問在該框架下的認證流程如圖2所示。在第13次通信時，如果消息長度超過規定的URL長度，則將A6其放在Cookie中，并在URL參數中說明。認證組件對消息A6的成功驗證只進行一次，以防止重放攻擊。

3.2 基于該構架的認證協議的安全性分析

下面利用廣泛使用的BAN邏輯對認證協議進行形式化分析。BAN邏輯是基于知識和信仰的形式邏輯分析方法，它是通過認證協議運行過程中消息的接收和發送來從最初的信仰逐漸發展為協議運行要達到的目的主體的最終信仰，類BAN邏輯是認證協議分析的一個主要方向。BAN邏輯分析認證協議的步驟包括協議理想化，確定初始假設，邏輯推理過程，得到結論幾個過程。

1)協議理想化

消息A5 AS→C:{〈rc，C←→rAppApp〉，{rAppC←→rAppApp}KApp}KAS_C

消息A6 C→App: {〈C←→rCApp，rApp〉rApp}KApp

2)協議初始化假設

(1)App|≡|KAppApp (2)App|≡|

C←→rAppApp

(3)C|≡#(rC)(4)C|≡C←→KAS_CAS

(5)C|≡App|C←→rAppApp(6)App|≡#(rApp)

(7)App|≡C|C←→rCApp(8)C|≡C←→rCApp

3）邏輯推理

由消息A5和假設(4)，應用接收規則得

C〈rC C←→rAppApp〉rC(A5.1) 

由(A5.1)和假設(8)，應用消息含義規則可得

C|≡App|~{rC，C←→rAppApp}(A5.2) 

由假設(3)，應用新鮮性規則可得

C|≡#{rC，C←→rAppApp}(A5.3) 

由(A5.2)(A5.3)，應用臨時值驗證規則可得

C|≡App|≡{rC，C←→rAppApp}(A5.4) 

由(A5.4)，應用信仰規則可得

C|≡App|≡{C←→rAppApp}(A5.5)a 

由(A5.5)和假設(5)，應用仲裁規則得

C|≡{C←→rAppApp}(A5.6)b 

由消息A6和假設(1)，應用接收規則可得

App〈C←→rC〉App，rApp〉rApp}(A6.1) 

由(A6.1)和假設(2)，應用消息含義規則可得

App|≡C|~{C←→rCApp，rApp}(A6.2) 

由(A6.2)和假設(6)，應用新鮮性規則可得

App|≡#{C←→rCApp，rApp}(A6.3) 

由(A6.3)(A6.2)，應用臨時值驗證規則可得

App|≡C|≡{C←→rCApp，rApp}(A6.4) 

由(A6.4)，應用信仰規則可得

App|≡C|≡{C←→rCApp}(A6.5)c

由(A6.5)和假設(7)，應用仲裁規則得

App|≡{C←→rCApp}(A6.6)d

由以上分析可知該協議符合最終的目標，