簡介

　　安全是所有Web項目在設計時都要考慮的一個重要因素。無論是選擇最短口令，決定何時使用SSL加密HTTP會話，還是通過自動登錄cookie來識別用戶，都經常要付出重大的設計努力，以保護用戶的身份信息和他們可能存放于Web站點的其他資料。糟糕的安全性可能帶來公關災難。當最終用戶努力保持對其個人信息的控制時，他們要面臨令人迷惑的隱私政策，需要牢記眾多站點的不同口令，以及遭遇“釣魚式攻擊”事件。在宏觀層次上，數字身份引起了許多復雜的技術和社會問題，業界一些團體如Liberty Alliance和IdentityGang都正試圖通過開發新的技術標準來解決它們。 在較小的規模上，可以使用一些工具來為用戶提供更好的安全性。請考慮口令管理問題。用戶訪問他們保存個人資料的Web站點，在可以存取他們的資料之前必須經過驗證。通過驗證來鑒別用戶，確保他們是所聲稱的用戶。進行驗證最簡單方式是使用口令。然而，若每個站點都需要各自的一套口令，用戶將有難以控制的大量口令。1998年微軟首先嘗試通過其Passport network提供該問題的全球解決方案。Passport使得任意Web站點使用用戶提交給Passport的個人資料（如用戶名、地址、信用卡號）成為可能。Passport是單點登錄（single sign-on，SSO）的第一次電子商務嘗試。它沒有流行起來，部分原因是由于人們對系統封閉性的擔心。然而，SSO的理念非常引人注目，許多開放標準和商業計劃都追隨Passport其后。通過SSO，某個Web站點可以與其他站點共享用戶身份信息。 SSO對于使用應用服務提供商（application Service PRovider，asp）軟件服務的企業特別有用。ASP在自己的服務器上宿主應用程序，出售其訪問權作為服務。公司可以在它的標準目錄服務器里管理自己的用戶和口令，然后通過SSO授予用戶訪問ASP應用程序的權限。SSO允許公司管理自己用戶的信息，不必為每一員工維護多個用戶賬號。對用戶來說，SSO的好處在于他們可以在多個應用程序中使用一個用戶名和口令，并且在應用程序之間切換時無需重新驗證。SSO不僅僅用于Web應用程序，它可用于任何類型的應用程序，只要有安全地傳送身份信息的協議。這種通信方式的開放標準就是安全性斷言標記語言（SAML）。

關于SAML

　　SAML為SSO提供了一個安全的協議。SAML（讀作“sam-ell”）是允許Web站點安全地共享身份信息的一個規范，它來自ebxml和其他XML標準背后的國際性聯盟OASIS。站點使用SAML的XML詞匯表和請求/應答模式，通過HTTP交換身份信息。這種信息共享標準化能幫助Web站點與多個合作伙伴集成，避免由于為不同合作伙伴設計和維護各自私有的集成通道而引起的爭論。SAML1.0于2002年11月亮相。本文介紹最終于2003年完成的SAML1.1。雖然于2005年完成的SAML 2.0引入了支持身份聯邦的一些重要新功能，但BEA WebLogic Server 9.x支持的是SAML1.1，因此本文將重點介紹SAML1.1。

一個基本的SAML示例

　　我們來看一個非?；镜腟AML示例。顧名思義，SAML的核心元素是安全性斷言。斷言即無需證明的語句。安全性斷言是關于用戶身份的語句，只能通過接收斷言發布者的站點信任獲得支持。在SAML中，發布斷言的站點叫“發布者”、“斷言方”、或“源站點”。接收斷言并信任它們的站點叫“信任方”或“目標站點”。

　　在本示例場景中，用戶使用用戶名和口令登錄源站點。然后，用戶希望無需再次驗證即可訪問目標站點。圖1顯示了源站點和目標站點之間能使用戶通過單點登錄訪問雙方站點的交互。

　　 圖1：一個SAML示例場景

　　上面第4步中的SAML請求將通過HTTP作為從目標站點到源站點的SOAP消息發送。消息體將類似于：

<!-- 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>

　　該請求把自己標識為來自SAML請求-應答協議名稱空間的SAML 1.1請求（MajorVersion和MinorVersion）。SAML為請求-應答協議元素定義了一個名稱空間，為斷言定義了另一個單獨的名稱空間。Request擁有基于請求者ip地址的惟一ID。請求的準確時間也包括在內。

　　該請求中最有趣的部分是<AssertionArtifact>標記中令人費解的字符串。目標站點從用戶HTTP請求的查詢字符串中得到該值。由于它用于標識瀏覽器，所以也叫“瀏覽器憑證”。注意，該請求沒有要求提交特定用戶的驗證。該請求創建時，目標方并沒有用于提交請求的用戶名。該信息將在應答中得到。瀏覽器憑證告訴可能正在同時向目標站點發送很多用戶的源站點，應該在此應答中發送哪個用戶的斷言。下面是一個應答示例：

<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:Assertionxmlns: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>

　　應答的關鍵部分是Assertion元素。斷言使用了SAML Assertion名稱空間定義的一個詞匯表。它由一個驗證語句組成，該語句告訴我們用戶JSmith已通過口令驗證。它還包含了支配目標站點斷言使用的一系列條件。在本例中，這些條件指定一個10分鐘的時間窗（time window），在時間窗之內斷言有效。時間窗用來防止重放攻擊。沒有它，中途截取斷言的惡意用戶可以明天再次發送斷言來冒充JSmith，并獲得訪問目標站點的權限。確認方法元素是指上面描述的瀏覽器憑證。

　　接受斷言后，目標站點視為JSmith已直接通過其用戶名和口令登錄。注意，驗證（鑒別用戶身份）和授權（授予用戶訪問資源的權限）之間的分離在此是非常重要的。源站點負責驗證JSmith，但不提供關于JSmith在目標站點特權的任何信息。這種安排對雙方站點都有益處：源站點無需了解目標站點的資源或特權，目標站點也可忽略源站點管理用戶和驗證的細節。這種分離提供了非常重要的靈活性。

　　假設源站點是JSmith的老板MegaBank。JSmith使用他在MegaBank的賬號訪問他工作必需的三個不同外部宿主的應用程序。一天，MegaBank雇傭的安全顧問建議在JSmith所在部門啟用指紋驗證。如果沒有SSO和SAML，MegaBank就必須到三個應用程序提供商那里請求他們支持指紋驗證。應用程序提供商不得不權衡提供該支持的成本和不提供該支持可能丟失客戶的風險。MegaBank可能必須等待提供商發布他們軟件的新版本，所有的改動或許將昂貴又費時。通過SAML，MegaBank只需改變自己的驗證過程，在JSmith和其同事登錄時檢查指紋即可。作為SAML目標站點的宿主應用程序無需清楚在MegaBank所做的更改，因為底層的SAML斷言是保持不變的。

　　使用SAML對用戶Web站點或Web服務的設計與實現有一些影響，但僅限于在處理Web窗口中的用戶名和口令時，或在處理方法簽名時。例如，下面的Web services API方法不能與SAML很好地協同工作：

public void makeSomeSystemChange(String username, String password, String[] params);

　　該方法假設用戶能夠提供用戶名和口令。如果Web服務的宿主是SAML目標站點，就沒有Web服務實現可以驗證的口令。有少數方式可以改進或擴展這些接口，使其與SAML協同工作，這取決于所需的向后兼容性的水平。同樣，如果在Web頁包含了具有用戶名和口令字段的表單，那么為經過SAML驗證的用戶禁用口令字段是非常重要的。

　　由于SAML在兩個擁有共享用戶的站點間建立了信任關系，所以安全性是需考慮的一個非常重要的因素。SAML中的安全弱點可能危及用戶在目標站點的個人信息。SAML依靠一批制定完善的安全標準，包括SSL和X.509，來保護SAML源站點和目標站點之間通信的安全。源站點和目標站點之間的所有通信都經過了加密。為確保參與SAML交互的雙方站點都能驗證對方的身份，還使用了證書。

BEA WebLogic Server中的SAML

　　 BEA WebLogic Server 9.0是第一個包含了對SAML支持的WebLogic Server版本。WebLogic Server 9.1中進一步加強了對SAML的支持。WebLogic Server把SAML作為WebLogic Security Service的一部分使用。SAML用來為WebLogic Web services和跨WebLogic域共享驗證信息提供SSO支持。除SAML外，WebLogic Server也為Windows桌面SSO支持Simple and Protected Negotiate (SPNEGO)協議。SAML可用來提供訪問Web應用程序和Web service的權限。

　　對于一些應用程序，您僅需付出很少甚至無需付出額外的程序設計努力，就能使用WebLogic Server中的SAML支持。如果用戶應用程序使用配置為WebLogic 安全域一部分的安全設置，那么集成SAML是一個首要的系統管理任務。WebLogic server可配置作為SAML源站點或SAML目標站點。要使服務器成為SAML源站點，需配置一個SAML Credential Mapper。要使服務器成為SAML目標站點，需配置一個SAML Identity Asserter.

　　 如果用戶應用程序安全模式為與WebLogic Security Service進行交互，包含了自己的特定于WebLogic的代碼，可以使用WebLogic的SAML API把該定制擴展到SAML。該API提供對WebLogic SAML服務主要組件的編程式訪問。用戶可以使用應用程序自身的業務邏輯來擴展諸如SAMLCredentialNameMapper和SAMLIdentityAssertionNameMapper這樣的類。一旦用戶有了自己的定制類，WebLogic管理控制臺就允許用戶配置其SAML Credential Mapper（源站點）或SAML Identity Asserter（目標站點），以便使用那些類。惟一的要求是用戶的定制類需要在系統類路徑中，非常類似于WebLogic啟動類，這可能對用戶部署策略產生影響。

　　 最后，如果應用程序安全模式完全獨立于WebLogic Security Service，用戶將不能從WebLogic的SAML工具中獲益。用戶要使其應用程序支持SAML就需要做更多工作，要么實現WebLogic所提供的某些服務的簡化版本，要么集成那些服務的第三方版本。但是，用戶仍將受益于可在任何J2EE應用服務器或在如Tomcat這樣的java Web服務器應用程序上使用SAML。有商業和開源的SAML支持可供選擇。開源的選擇中有OpenSAML和相關的Shibboleth項目。OpenSAML是一個SAML工具包，可用來建立用戶自己的SAML源站點和目標站點。Shibboleth更進一步，它提供了一個構建在OpenSAML之上的“基于SAML 1.1的跨域Web單點登錄平臺”。SourceID為Java 和.NET中的SAML 1.1提供了一套開源工具包。在Apache項目下沒有完整的SAML工具包，但WSS4J項目包含了對OpenSAML的一些支持。

結束語

　　SAML對企業應用程序開發越來越重要。隨著大公司內部系統的不斷擴展，合并身份信息對系統的成功管理來說非常關鍵。SAML也為依賴外部宿主應用程序的企業提供了巨大好處。對最終用戶來說，單點登錄能同時提供安全性和便利性。WebLogic Server 9.x的SAML支持是對WebLogic Security Service最重要的新補充之一。無論它是否為用戶應用程序安全模式的一部分，用戶都有許多選擇以使其應用程序與SAML協同工作。

（出處：http://www.49028c.com）