SAML簡介：安全地共享數字身份信息

簡介

安全是所有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示例

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

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

圖1:一個SAML示例場景

圖2:另一個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 。請求的准確時間也包括在內。

該請求中最有趣的部分是標記中令人費解的字符串。目標站點從用戶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: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>

應答的關鍵部分是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中的安全弱點可能危及用戶在目標站點的個人信息 。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協同工作。