跳至內容

安全斷言標記語言

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書

安全主張標記語言（英語：Security Assertion Markup Language，簡稱SAML，發音sam-el[1]）是一個基於XML的開源標準數據格式，它在當事方之間交換身份驗證和授權數據，尤其是在身份提供者（英語：Identity provider）和服務提供者之間交換。SAML是OASIS安全服務技術委員會的一個產品，始於2001年。其最近的主要更新發布於2005年，但協議的增強仍在通過附加的可選標準穩步增加。

SAML解決的最重要的需求是網頁瀏覽器單一登入（SSO）。單點登錄在內部網層面比較常見（例如使用Cookie），但將其擴展到內部網之外則一直存在問題，並使得不可互操作的專有技術激增。（另一種近日解決瀏覽器單點登錄問題的方法是OpenID Connect（英語：OpenID Connect）協議）[2]

原則

SAML規範定義了三個角色：委託人（通常為一名用戶）、身份提供者（英語：Identity provider）（IdP），服務提供者（SP）。在用SAML解決的使用案例中，委託人從服務提供者那裡請求一項服務。服務提供者請求身份提供者並從那裡並獲得一個身份主張。服務提供者可以基於這一主張進行存取控制的判斷——即決定委託人是否有權執行某些服務。

在將身份主張發送給服務提供者之前，身份提供者也可能向委託人要求一些信息——例如用戶名和密碼，以驗證委託人的身份。SAML規範了三方之間的主張，尤其是主張身份消息是由身份提供者傳遞給服務提供者。在SAML中，一個身份提供者可能提供SAML主張給許多服務提供者。同樣的，一個服務提供者可以依賴並信任許多獨立的身份提供者的主張。

SAML沒有規定身份提供者的身份驗證方法；他們大多使用用戶名和密碼，但也有其他驗證方式，包括採用多重要素驗證。諸如輕型目錄訪問協議、RADIUS和Active Directory等目錄服務允許用戶使用一組用戶名和密碼登錄，這是身份提供者使用身份驗證令牌的一個典型來源。[需要解釋][3]許多流行的互聯網社交網絡服務也提供身份驗證服務，理論上他們也可以支持SAML交換。

歷史

OASIS安全服務技術委員會（SSTC）於2001年1月首次舉行會議，提出「定義一個用於交換身份驗證和授權的XML框架。」[4]為完成此目標，下列知識產權在該年的頭兩個月內向SSTC進行了捐獻：

  • Security Services Markup Language（S2ML），來自Netegrity
  • AuthXML，來自Securant
  • XML Trust Assertion Service Specification（X-TASS），來自VeriSign
  • Information Technology Markup Language（ITML），來自Jamcracker

在這項工作的基礎上，OASIS於2002年11月宣布「安全主張標記語言」（SAML）V1.0規範成為一個OASIS標準。[5]

與此同時，大型企業、非營利及政府組織的聯盟Liberty Alliance（英語：Liberty Alliance）提出了一個擴展SAML標準的「自由聯盟統一聯合框架」（ID-FF）。與其前身SAML類似，Liberty ID-FF提出了一個標準化、跨域、基於Web的單點登錄框架。此外，Liberty描繪了一個「信任圈」（circle of trust），其中每個參與域被信任將準確記錄識別用戶的過程、所使用的身份驗證類型，以及任何與生成身份驗證憑據相關的策略。信任圈中的其他成員可以查驗這些策略，以決定是否信任此類信息。

雖然ID-FF開發了Liberty，SSTC已開始小規模升級到SAML規範。這使得SSTC在2003年9月批准了SAML V1.1規範。在同月，Liberty將ID-FF貢獻至OASIS，從而為SAML下一版本奠基。2005年3月，SAML V2.0被宣布成為一項OASIS標準。SAML V2.0意味着Liberty ID-FF及其他專有擴展的收斂，以及包括SAML本身的早期版本。大多數SAML實現支持V2.0，並也大多支持V1.1以實現向後兼容。截至2008年1月，SAML V2.0的開發已在政府、高等教育和全球商業企業中普遍存在。[6]

版本

SAML自V1.0以來已進行一次重大及一次次要修訂。

  • SAML 1.0於2002年11月獲准成為OASIS標準
  • SAML 1.1（英語：SAML 1.1）於2003年9月獲准為OASIS標準
  • SAML 2.0於2005年3月成為OASIS標準

Liberty Alliance在2003年9月將其自由聯盟統一聯合框架（ID-FF）貢獻至OASIS SSTC：

  • ID-FF 1.1於2003年4月發布
  • ID-FF 1.2於2003年11月完成

SAML的1.0和1.1版本很類似，僅存在微小差異。[7]

SAML 2.0與SAML 1.1 （頁面存檔備份，存於網際網路檔案館）則有着實質性的差異。雖然兩者都是解決相同的使用案例，但SAML 2.0與1.1並不兼容。

儘管ID-FF 1.2已作為SAML 2.0的基礎貢獻至OASIS，但在SAML 2.0與ID-FF 1.2之間 （頁面存檔備份，存於網際網路檔案館）有着一些重要的差異。尤其是儘管這兩個規範同根同源，但兩者並不兼容。

設計

SAML 建立在一些現有標準之上：

Extensible Markup Language (XML)
大多數SAML交換是以一個標準化的XML方言表示，這也是SAML的名稱（Security Assertion Markup Language）的根源。; XML Schema (XSD): SAML主張和協議部分採用XML Schema。
XML Signature
SAML 1.1（英語：SAML 1.1）和SAML 2.0都為身份驗證和消息完整性使用基於XML Signature標準的數字簽名。
XML Encryption
SAML 2.0使用XML Encryption為加密名稱標識符、加密屬性和加密主張提供元素（SAML 1.1沒有加密功能）。但XML加密據報有着嚴重的安全問題。[8][9]
Hypertext Transfer Protocol (HTTP)

SAML很大程度上依賴超文本傳輸協議作為其通信協議。

SOAP
SAML指定使用SOAP，尤其是SOAP 1.1 （頁面存檔備份，存於網際網路檔案館）。

SAML定義了基於XML的主張、協議、綁定和配置。術語SAML核心（SAML Core）指SAML主張的一般語法和語義，以及用於請求和在系統實體間傳輸這些主張的協議。SAML協議指誰來傳輸，而不是如何傳輸（後者由所選擇的綁定決定）。因此SAML核心只定義了「純粹的」SAML主張，以及SAML的請求和響應元素。

SAML綁定決定SAML請求和響應如何映射到標準的消息或通信協議。一個重要的、同步的綁定是SAML SOAP綁定。

SAML配置是使用特定主張、協議和綁定組成的適用於所定義使用情況的一個具體表現形式。

主張

一個SAML主張包含一個安全信息包： 

 <saml:Assertion ...>
   ..
 </saml:Assertion>

簡而言之，依賴方按下述方式解釋一個主張：

主張A是在條件C 有效的前提下由發布者R 關於主題S在時間t發布的 。

SAML主張通常從IdP傳送到SP。主張包括一些SP用來做權限控制的聲明（statements）。SAML提供如下三種語句：

  1. 身份驗證（Authentication）聲明
  2. 屬性（Attribute）聲明
  3. 授權決策（Authorization decision）聲明

身份驗證聲明會向SP主張，該委託人確實被IdP在一個特定的時間通過一個特定的認證方式成功認證。關於該被認證的委託人的其他信息（也叫身份驗證上下文）也可能會包含在一條身份驗證聲明中。

屬性聲明會主張，一個主題和一些屬性關聯。一個屬性是一個簡單的鍵值對。依賴方使用屬性來實現訪問控制。

授權決策聲明會主張，在證據E下一個主題是否被允許在資源R上執行動作A。SAML中的授權決策聲明的功能被有意的限制了，因為在更高級的使用場景中更推薦使用XACML。

協議

SAML協議響應

A SAML protocol describes how certain SAML elements (including assertions) are packaged within SAML request and response elements, and gives the processing rules that SAML entities must follow when producing or consuming these elements. For the most part, a SAML protocol is a simple request-response protocol.

The most important type of SAML protocol request is called a query. A service provider makes a query directly to an identity provider over a secure back channel. Thus query messages are typically bound to SOAP.

Corresponding to the three types of statements, there are three types of SAML queries:

  1. Authentication query
  2. Attribute query
  3. Authorization decision query

Of these, the attribute query is perhaps most important (and still the object of much research[來源請求]). The result of an attribute query is a SAML response containing an assertion, which itself contains an attribute statement. See the SAML 2.0 topic for an example of attribute query/response（英語：SAML 2.0#SAML Attribute Query）.

Beyond queries, SAML 1.1 specifies no other protocols.

SAML 2.0 expands the notion of protocol considerably. The following protocols are described in detail in SAML 2.0 Core:

  • Assertion Query and Request Protocol
  • Authentication Request Protocol
  • Artifact Resolution Protocol
  • Name Identifier Management Protocol
  • Single Logout Protocol
  • Name Identifier Mapping Protocol

Most of these protocols are completely new in SAML 2.0.

綁定

SAML over SOAP over HTTP

A SAML binding is a mapping of a SAML protocol message onto standard messaging formats and/or communications protocols. For example, the SAML SOAP binding specifies how a SAML message is encapsulated in a SOAP envelope, which itself is bound to an HTTP message.

SAML 1.1 specifies just one binding, the SAML SOAP Binding. In addition to SOAP, implicit in SAML 1.1 Web Browser SSO are the precursors of the HTTP POST Binding, the HTTP Redirect Binding, and the HTTP Artifact Binding. These are not defined explicitly, however, and are only used in conjunction with SAML 1.1 Web Browser SSO. The notion of binding is not fully developed until SAML 2.0.

SAML 2.0 completely separates the binding concept from the underlying profile. In fact, there is a brand new binding specification in SAML 2.0（英語：SAML 2.0#SAML 2.0 Bindings） that defines the following standalone bindings:

  • SAML SOAP Binding (based on SOAP 1.1)
  • Reverse SOAP (PAOS) Binding
  • HTTP Redirect (GET) Binding
  • HTTP POST Binding
  • HTTP Artifact Binding
  • SAML URI Binding

This reorganization provides tremendous flexibility: taking just Web Browser SSO alone as an example, a service provider can choose from four bindings (HTTP Redirect, HTTP POST and two flavors of HTTP Artifact), while the identity provider has three binding options (HTTP POST plus two forms of HTTP Artifact), for a total of twelve (12) possible deployments of the SAML 2.0 Web Browser SSO Profile.

配置

A SAML profile describes in detail how SAML assertions, protocols, and bindings combine to support a defined use case. The most important SAML profile is the Web Browser SSO Profile.

SAML 1.1 specifies two forms of Web Browser SSO, the Browser/Artifact Profile and the Browser/POST Profile. The latter passes assertions by value whereas Browser/Artifact passes assertions by reference. As a consequence, Browser/Artifact requires a back-channel SAML exchange over SOAP. In SAML 1.1, all flows begin with a request at the identity provider for simplicity. Proprietary extensions to the basic IdP-initiated flow have been proposed (by Shibboleth, for example).

The Web Browser SSO Profile was completely refactored for SAML 2.0. Conceptually, SAML 1.1 Browser/Artifact and Browser/POST are special cases of SAML 2.0 Web Browser SSO. The latter is considerably more flexible than its SAML 1.1 counterpart due to the new "plug-and-play" binding design of SAML 2.0. Unlike previous versions, SAML 2.0 browser flows begin with a request at the service provider. This provides greater flexibility, but SP-initiated flows naturally give rise to the so-called Identity Provider Discovery problem, the focus of much research today. In addition to Web Browser SSO, SAML 2.0 introduces numerous new profiles:

  • SSO Profiles
    • Web Browser SSO Profile
    • Enhanced Client or Proxy (ECP) Profile
    • Identity Provider Discovery Profile
    • Single Logout Profile
    • Name Identifier Management Profile
  • Artifact Resolution Profile
  • Assertion Query/Request Profile
  • Name Identifier Mapping Profile
  • SAML Attribute Profiles

Aside from the SAML Web Browser SSO Profile, some important third-party profiles of SAML include:

安全

SAML規範推薦、並在某些情況下要求各種安全機制：

Requirements are often phrased in terms of (mutual) authentication, integrity, and confidentiality, leaving the choice of security mechanism to implementers and deployers.

使用

SAML的主要用途是「網頁瀏覽器單點登錄（SSO）。A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML identity provider through the user agent. The resulting protocol flow is depicted in the following diagram.

1. Request the target resource at the SP (SAML 2.0 only)
The principal (via an HTTP user agent) requests a target resource at the service provider: 
https://sp.example.com/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.
2. Redirect to the SSO Service at the IdP (SAML 2.0 only)
The service provider determines the user's preferred identity provider (by unspecified means) and redirects the user agent to the SSO Service at the identity provider: 
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request
The value of the SAMLRequest parameter is the Base64 encoding of a deflated <samlp:AuthnRequest> element.
3. Request the SSO Service at the IdP (SAML 2.0 only)
The user agent issues a GET request to the SSO service at the identity provider where the value of the SAMLRequest parameter is taken from the URL query string at step 2. The SSO service processes the AuthnRequest and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
4. Respond with an XHTML form
The SSO service validates the request and responds with a document containing an XHTML form: 
  <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLResponse" value="response" />
    ...
    <input type="submit" value="Submit" />
  </form>
The value of the SAMLResponse parameter is the base64 encoding of a <samlp:Response> element.
5. Request the Assertion Consumer Service at the SP
The user agent issues a POST request to the assertion consumer service at the service provider. The value of the SAMLResponse parameter is taken from the XHTML form at step 4.
6. Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
7. Request the target resource at the SP again
The user agent requests the target resource at the service provider (again): 
https://sp.example.com/myresource
8. Respond with requested resource
Since a security context exists, the service provider returns the resource to the user agent.

In SAML 1.1, the flow begins with a request to the identity provider's inter-site transfer service at step 3.

In the example flow above, all depicted exchanges are front-channel exchanges, that is, an HTTP user agent (browser) communicates with a SAML entity at each step. In particular, there are no back-channel exchanges or direct communications between the service provider and the identity provider. Front-channel exchanges lead to simple protocol flows where all messages are passed by value using a simple HTTP binding (GET or POST). Indeed, the flow outlined in the previous section is sometimes called the Lightweight Web Browser SSO Profile.

Alternatively, for increased security or privacy, messages may be passed by reference. For example, an identity provider may supply a reference to a SAML assertion (called an artifact) instead of transmitting the assertion directly through the user agent. Subsequently, the service provider requests the actual assertion via a back channel. Such a back-channel exchange is specified as a SOAP message exchange (SAML over SOAP over HTTP). In general, any SAML exchange over a secure back channel is conducted as a SOAP message exchange.

On the back channel, SAML specifies the use of SOAP 1.1. The use of SOAP as a binding mechanism is optional, however. Any given SAML deployment will choose whatever bindings are appropriate.

參見

參考資料

  1. ^ What is SAML? - A Word Definition From the Webopedia Computer Dictionary. Webopedia.com. [2013-09-21]. （原始內容存檔於2020-08-05）. 
  2. ^ OpenID versus Single-Sign-On Server. alleged.org.uk. 2007-08-13 [2014-05-23]. （原始內容存檔於2014-09-16）. 
  3. ^ SAML: The Secret to Centralized Identity Management. InformationWeek.com. 2004-11-23 [2014-05-23]. （原始內容存檔於2020-11-28）. 
  4. ^ Maler, Eve. Minutes of 9 January 2001 Security Services TC telecon. security-services at oasis-open (郵件列表). 9 Jan 2001 [7 April 2011]. （原始內容存檔於2021-01-19）. 
  5. ^ History of SAML. SAMLXML.org. 2007-12-05 [2014-05-22]. （原始內容存檔於2020-02-18）. 
  6. ^ Google, NTT and the US GSA Deploy SAML 2.0 for Digital Identity Management. Oracle Journal. 2008-01-29 [2014-05-22]. （原始內容存檔於2014-05-22）. 
  7. ^ P. Mishra; et al, Differences between OASIS Security Assertion Markup Language (SAML) V1.1 and V1.0 (PDF), OASIS, May 2003 [7 April 2011], sstc-saml-diff-1.1-draft-01, （原始內容存檔 (PDF)於2020-09-28） 
  8. ^ How To Break XML Encryption (PDF). 計算機協會. 19 October 2011 [31 October 2014]. （原始內容存檔 (PDF)於2017-08-09）. 
  9. ^ RUB Researchers break W3C standard. 波鴻魯爾大學. 19 October 2011 [29 June 2012]. （原始內容存檔於2012-09-18）. 

外部連結

取自「https://zh.wikipedia.org/w/index.php?title=安全断言标记语言&oldid=76934436」