維基百科

安全斷言標記式語言

安全主張標記式語言（英語：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」