SAML

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

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

## 原則

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

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

SAML 沒有規定身分提供者的身分驗證方法；他們大多使用使用者名稱和密碼，但也有其他驗證方式，包括採用多重要素驗證。諸如輕型目錄存取協定、RADIUS 和 Active Directory 等目錄服務允許使用者使用一組使用者名稱和密碼登入，這是身分提供者使用身分驗證權杖的一個典型來源。許多流行的網際網路社群網路服務也提供身分驗證服務，理論上他們也可以支援 SAML 交換。

## 歷史

OASIS 安全服務技術委員會（SSTC）於 2001 年 1 月首次舉行會議，提出「定義一個用於交換身分驗證和授權的 XML 框架。」為完成此目標，下列智慧財產權在該年的頭兩個月內向 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 標準。

與此同時，大型企業、非營利及政府組織的聯盟 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 的開發已在政府、高等教育和全球商業企業中普遍存在。

## 版本

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

* SAML 1.0 於 2002 年 11 月獲准成為 OASIS 標準
* 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 版本很類似，僅存在微小差異。

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 2.0 都為身分驗證和訊息完整性使用基於 XML Signature 標準的數位簽章。

**XML Encryption**
: SAML 2.0 使用 XML Encryption 為加密名稱識別碼、加密屬性和加密主張提供元素（SAML 1.1 沒有加密功能）。但 XML 加密據報有著嚴重的安全問題。

**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。

### 協定

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.

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.

### 繫結

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

* OASIS Web Services Security (WSS) Technical Committee （頁面存檔備份，存於網際網路檔案館）
  * OASIS WS-Security SAML Token Profile （頁面存檔備份，存於網際網路檔案館）
* Liberty Alliance
  * Liberty Identity Federation Framework (ID-FF) （頁面存檔備份，存於網際網路檔案館）
  * Liberty Identity Web Services Framework (ID-WSF) （頁面存檔備份，存於網際網路檔案館）
* OASIS eXtensible Access Control Markup Language (XACML) Technical Committee （頁面存檔備份，存於網際網路檔案館）
  * SAML 2.0 Profile of XACML v2.0 （頁面存檔備份，存於網際網路檔案館）

### 安全

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

* TLS 1.0 + 用於傳輸層安全
* XML Signature 和 XML Encryption 用於訊息層安全

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

## 參見

* 基於 SAML 的產品和服務
* 身分管理
* 身分管理系統
* OpenID Connect
* 資訊卡
* WS-Federation
* OAuth

## 參考資料

## 外部連結

* OASIS Security Services Technical Committee （頁面存檔備份，存於網際網路檔案館）
* Cover Pages: Security Assertion Markup Language (SAML)
* Tutorial Video: Ten Things You Need To Know About SAML （頁面存檔備份，存於網際網路檔案館）
* How to Study and Learn SAML （頁面存檔備份，存於網際網路檔案館）
* Demystifying SAML （頁面存檔備份，存於網際網路檔案館）
* First public SAML 2.0 identity provider （頁面存檔備份，存於網際網路檔案館）
* Federated ID gains momentum （頁面存檔備份，存於網際網路檔案館）
* SAML 101 （頁面存檔備份，存於網際網路檔案館）
* The Basics of SAML