跳转到内容

安全断言标记语言

本页使用了标题或全文手工转换
维基百科，自由的百科全书

安全主張标记语言（英語：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://wiki.zwnes.eu.org/w/index.php?title=安全断言标记语言&oldid=85430733”