安全是所有Web項目在設計時(shí)都要考慮的一個(gè)重要因素。無(wú)論是選擇最短口令，決定何時(shí)使用SSL加密HTTP會(huì )話(huà)，還是通過(guò)自動(dòng)登錄cookie來(lái)識別用戶(hù)，都經(jīng)常要付出重大的設計努力，以保護用戶(hù)的身份信息和他們可能存放于Web站點(diǎn)的其他資料。糟糕的安全性可能帶來(lái)公關(guān)災難。當最終用戶(hù)努力保持對其個(gè)人信息的控制時(shí)，他們要面臨令人迷惑的隱私政策，需要牢記眾多站點(diǎn)的不同口令，以及遭遇“釣魚(yú)式攻擊”事件。
在宏觀(guān)層次上，數字身份引起了許多復雜的技術(shù)和社會(huì )問(wèn)題，業(yè)界一些團體如Liberty Alliance和IdentityGang都正試圖通過(guò)開(kāi)發(fā)新的技術(shù)標準來(lái)解決它們。 在較小的規模上，可以使用一些工具來(lái)為用戶(hù)提供更好的安全性。請考慮口令管理問(wèn)題。用戶(hù)訪(fǎng)問(wèn)他們保存個(gè)人資料的Web站點(diǎn)，在可以存取他們的資料之前必須經(jīng)過(guò)驗證。通過(guò)驗證來(lái)鑒別用戶(hù)，確保他們是所聲稱(chēng)的用戶(hù)。進(jìn)行驗證最簡(jiǎn)單方式是使用口令。然而，若每個(gè)站點(diǎn)都需要各自的一套口令，用戶(hù)將有難以控制的大量口令。1998年微軟首先嘗試通過(guò)其Passport network提供該問(wèn)題的全球解決方案。Passport使得任意Web站點(diǎn)使用用戶(hù)提交給Passport的個(gè)人資料(如用戶(hù)名、地址、信用卡號)成為可能。Passport是單點(diǎn)登錄(single sign-on，SSO)的第一次電子商務(wù)嘗試。它沒(méi)有流行起來(lái)，部分原因是由于人們對系統封閉性的擔心。然而，SSO的理念非常引人注目，許多開(kāi)放標準和商業(yè)計劃都追隨Passport其后。通過(guò)SSO，某個(gè)Web站點(diǎn)可以與其他站點(diǎn)共享用戶(hù)身份信息。
SSO對于使用應用服務(wù)提供商(Application Service Provider，ASP)軟件服務(wù)的企業(yè)特別有用。ASP在自己的服務(wù)器上宿主應用程序，出售其訪(fǎng)問(wèn)權作為服務(wù)。公司可以在它的標準目錄服務(wù)器里管理自己的用戶(hù)和口令，然后通過(guò)SSO授予用戶(hù)訪(fǎng)問(wèn)ASP應用程序的權限。SSO允許公司管理自己用戶(hù)的信息，不必為每一員工維護多個(gè)用戶(hù)賬號。對用戶(hù)來(lái)說(shuō)，SSO的好處在于他們可以在多個(gè)應用程序中使用一個(gè)用戶(hù)名和口令，并且在應用程序之間切換時(shí)無(wú)需重新驗證。SSO不僅僅用于Web應用程序，它可用于任何類(lèi)型的應用程序，只要有安全地傳送身份信息的協(xié)議。這種通信方式的開(kāi)放標準就是安全性斷言標記語(yǔ)言(SAML)。
關(guān)于SAML
SAML為SSO提供了一個(gè)安全的協(xié)議。SAML(讀作“sam-ell”)是允許Web站點(diǎn)安全地共享身份信息的一個(gè)規范，它來(lái)自ebXML和其他XML標準背后的國際性聯(lián)盟OASIS。站點(diǎn)使用SAML的XML詞匯表和請求/應答模式，通過(guò)HTTP交換身份信息。這種信息共享標準化能幫助Web站點(diǎn)與多個(gè)合作伙伴集成，避免由于為不同合作伙伴設計和維護各自私有的集成通道而引起的爭論。SAML1.0于2002年11月亮相。本文介紹最終于2003年完成的SAML1.1。雖然于2005年完成的SAML 2.0引入了支持身份聯(lián)邦的一些重要新功能，但BEA WebLogic Server 9.x支持的是SAML1.1，因此本文將重點(diǎn)介紹SAML1.1。
一個(gè)基本的SAML示例
我們來(lái)看一個(gè)非?；镜腟AML示例。顧名思義，SAML的核心元素是安全性斷言。斷言即無(wú)需證明的語(yǔ)句。安全性斷言是關(guān)于用戶(hù)身份的語(yǔ)句，只能通過(guò)接收斷言發(fā)布者的站點(diǎn)信任獲得支持。在SAML中，發(fā)布斷言的站點(diǎn)叫“發(fā)布者”、“斷言方”、或“源站點(diǎn)”。接收斷言并信任它們的站點(diǎn)叫“信任方”或“目標站點(diǎn)”。
在本示例場(chǎng)景中，用戶(hù)使用用戶(hù)名和口令登錄源站點(diǎn)。然后，用戶(hù)希望無(wú)需再次驗證即可訪(fǎng)問(wèn)目標站點(diǎn)。圖1顯示了源站點(diǎn)和目標站點(diǎn)之間能使用戶(hù)通過(guò)單點(diǎn)登錄訪(fǎng)問(wèn)雙方站點(diǎn)的交互。
| <!-- This request would be wrapped in a SOAP envelope --> <samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion="1" MinorVersion="1" RequestID="_216.27.61.137.103896224111" IssueInstant="2005-03-19T17:04:21.022Z"> <samlp:AssertionArtifact> AAGZE1RNQJEFzYNCGAGPjWvtDIRSZ4 </samlp:AssertionArtifact> </samlp:Request> |
該請求把自己標識為來(lái)自SAML請求-應答協(xié)議名稱(chēng)空間的SAML 1.1請求(MajorVersion和MinorVersion)。SAML為請求-應答協(xié)議元素定義了一個(gè)名稱(chēng)空間，為斷言定義了另一個(gè)單獨的名稱(chēng)空間。Request擁有基于請求者IP地址的惟一ID。請求的準確時(shí)間也包括在內。
該請求中最有趣的部分是標記中令人費解的字符串。目標站點(diǎn)從用戶(hù)HTTP請求的查詢(xún)字符串中得到該值。由于它用于標識瀏覽器，所以也叫“瀏覽器憑證”。注意，該請求沒(méi)有要求提交特定用戶(hù)的驗證。該請求創(chuàng )建時(shí)，目標方并沒(méi)有用于提交請求的用戶(hù)名。該信息將在應答中得到。瀏覽器憑證告訴可能正在同時(shí)向目標站點(diǎn)發(fā)送很多用戶(hù)的源站點(diǎn)，應該在此應答中發(fā)送哪個(gè)用戶(hù)的斷言。下面是一個(gè)應答示例:
| <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0protocol" ResponseID="huGxcDQc4cNdDyocphmi6CxEMngaÓ InResponseTo="_216.27.61.137.103896224111"? MajorVersion="1" MinorVersion="1" IssueInstant="2004-06-19T17:05:37.795Z"> <samlp:Status> <samlp:StatusCode Value="samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa" Issuer="www.example.com" IssueInstant="2004-06-19T17:05:37.795Z"> <saml:Conditions NotBefore="2004-06-19T17:00:37.795Z" NotOnOrAfter="2004-06-19T17:10:37.795Z"/> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2004-06-19T17:05:17.706Z"> <saml:Subject> <saml:NameIdentifier>JSmith</saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact-01 </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> |
假設源站點(diǎn)是JSmith的老板MegaBank。JSmith使用他在MegaBank的賬號訪(fǎng)問(wèn)他工作必需的三個(gè)不同外部宿主的應用程序。一天，MegaBank雇傭的安全顧問(wèn)建議在JSmith所在部門(mén)啟用指紋驗證。如果沒(méi)有SSO和SAML，MegaBank就必須到三個(gè)應用程序提供商那里請求他們支持指紋驗證。應用程序提供商不得不權衡提供該支持的成本和不提供該支持可能丟失客戶(hù)的風(fēng)險。MegaBank可能必須等待提供商發(fā)布他們軟件的新版本，所有的改動(dòng)或許將昂貴又費時(shí)。通過(guò)SAML，MegaBank只需改變自己的驗證過(guò)程，在JSmith和其同事登錄時(shí)檢查指紋即可。作為SAML目標站點(diǎn)的宿主應用程序無(wú)需清楚在MegaBank所做的更改，因為底層的SAML斷言是保持不變的。
使用SAML對用戶(hù)Web站點(diǎn)或Web服務(wù)的設計與實(shí)現有一些影響，但僅限于在處理Web窗口中的用戶(hù)名和口令時(shí)，或在處理方法簽名時(shí)。例如，下面的Web services API方法不能與SAML很好地協(xié)同工作:
| public void makeSomeSystemChange(String username, String password, String[] params); |
該方法假設用戶(hù)能夠提供用戶(hù)名和口令。如果Web服務(wù)的宿主是SAML目標站點(diǎn)，就沒(méi)有Web服務(wù)實(shí)現可以驗證的口令。有少數方式可以改進(jìn)或擴展這些接口，使其與SAML協(xié)同工作，這取決于所需的向后兼容性的水平。同樣，如果在Web頁(yè)包含了具有用戶(hù)名和口令字段的表單，那么為經(jīng)過(guò)SAML驗證的用戶(hù)禁用口令字段是非常重要的。
安全的SAML
由于SAML在兩個(gè)擁有共享用戶(hù)的站點(diǎn)間建立了信任關(guān)系，所以安全性是需考慮的一個(gè)非常重要的因素。SAML中的安全弱點(diǎn)可能危及用戶(hù)在目標站點(diǎn)的個(gè)人信息。SAML依靠一批制定完善的安全標準，包括SSL和X.509，來(lái)保護SAML源站點(diǎn)和目標站點(diǎn)之間通信的安全。源站點(diǎn)和目標站點(diǎn)之間的所有通信都經(jīng)過(guò)了加密。為確保參與SAML交互的雙方站點(diǎn)都能驗證對方的身份，還使用了證書(shū)。
BEA WebLogic Server中的SAML
BEA WebLogic Server 9.0是第一個(gè)包含了對SAML支持的WebLogic Server版本。WebLogic Server 9.1中進(jìn)一步加強了對SAML的支持。WebLogic Server把SAML作為WebLogic Security Service的一部分使用。SAML用來(lái)為WebLogic Web services和跨WebLogic域共享驗證信息提供SSO支持。除SAML外，WebLogic Server也為Windows桌面SSO支持Simple and Protected Negotiate (SPNEGO)協(xié)議。SAML可用來(lái)提供訪(fǎng)問(wèn)Web應用程序和Web service的權限。
對于一些應用程序，您僅需付出很少甚至無(wú)需付出額外的程序設計努力，就能使用WebLogic Server中的SAML支持。如果用戶(hù)應用程序使用配置為WebLogic 安全域一部分的安全設置，那么集成SAML是一個(gè)首要的系統管理任務(wù)。WebLogic server可配置作為SAML源站點(diǎn)或SAML目標站點(diǎn)。要使服務(wù)器成為SAML源站點(diǎn)，需配置一個(gè)SAML Credential Mapper。要使服務(wù)器成為SAML目標站點(diǎn)，需配置一個(gè)SAML Identity Asserter.
如果用戶(hù)應用程序安全模式為與WebLogic Security Service進(jìn)行交互，包含了自己的特定于WebLogic的代碼，可以使用WebLogic的SAML API把該定制擴展到SAML。該API提供對WebLogic SAML服務(wù)主要組件的編程式訪(fǎng)問(wèn)。用戶(hù)可以使用應用程序自身的業(yè)務(wù)邏輯來(lái)擴展諸如SAMLCredentialNameMapper和SAMLIdentityAssertionNameMapper這樣的類(lèi)。一旦用戶(hù)有了自己的定制類(lèi)，WebLogic管理控制臺就允許用戶(hù)配置其SAML Credential Mapper(源站點(diǎn))或SAML Identity Asserter(目標站點(diǎn))，以便使用那些類(lèi)。惟一的要求是用戶(hù)的定制類(lèi)需要在系統類(lèi)路徑中，非常類(lèi)似于WebLogic啟動(dòng)類(lèi)，這可能對用戶(hù)部署策略產(chǎn)生影響。
最后，如果應用程序安全模式完全獨立于WebLogic Security Service，用戶(hù)將不能從WebLogic的SAML工具中獲益。用戶(hù)要使其應用程序支持SAML就需要做更多工作，要么實(shí)現WebLogic所提供的某些服務(wù)的簡(jiǎn)化版本，要么集成那些服務(wù)的第三方版本。但是，用戶(hù)仍將受益于可在任何J2EE應用服務(wù)器或在如Tomcat這樣的Java Web服務(wù)器應用程序上使用SAML。有商業(yè)和開(kāi)源的SAML支持可供選擇。開(kāi)源的選擇中有OpenSAML和相關(guān)的Shibboleth項目。OpenSAML是一個(gè)SAML工具包，可用來(lái)建立用戶(hù)自己的SAML源站點(diǎn)和目標站點(diǎn)。Shibboleth更進(jìn)一步，它提供了一個(gè)構建在OpenSAML之上的“基于SAML 1.1的跨域Web單點(diǎn)登錄平臺”。SourceID為Java 和.NET中的SAML 1.1提供了一套開(kāi)源工具包。在A(yíng)pache項目下沒(méi)有完整的SAML工具包，但WSS4J項目包含了對OpenSAML的一些支持。
結束語(yǔ)
SAML對企業(yè)應用程序開(kāi)發(fā)越來(lái)越重要。隨著(zhù)大公司內部系統的不斷擴展，合并身份信息對系統的成功管理來(lái)說(shuō)非常關(guān)鍵。SAML也為依賴(lài)外部宿主應用程序的企業(yè)提供了巨大好處。對最終用戶(hù)來(lái)說(shuō)，單點(diǎn)登錄能同時(shí)提供安全性和便利性。WebLogic Server 9.x的SAML支持是對WebLogic Security Service最重要的新補充之一。無(wú)論它是否為用戶(hù)應用程序安全模式的一部分，用戶(hù)都有許多選擇以使其應用程序與SAML協(xié)同工作。
聯(lián)系客服
