Internet Engineering Task Force (IETF) K. Wierenga
Request for Comments: 6595 Cisco Systems, Inc.
Category: Standards Track E. Lear
ISSN: 2070-1721 Cisco Systems GmbH
S. Josefsson
SJD AB
April 2012
Internet Engineering Task Force (IETF) K. Wierenga
Request for Comments: 6595 Cisco Systems, Inc.
Category: Standards Track E. Lear
ISSN: 2070-1721 Cisco Systems GmbH
S. Josefsson
SJD AB
April 2012
A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)
安全断言标记语言（SAML）的简单身份验证和安全层（SASL）和GSS-API机制
Abstract
摘要
The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API.
安全断言标记语言（SAML）已在Internet上用于Web单点登录。简单身份验证和安全层（SASL）和通用安全服务应用程序接口（GSS-API）是通用身份验证的应用程序框架。此备忘录为SAML 2.0指定了SASL机制和GSS-API机制，允许将现有SAML标识提供程序与使用SASL和GSS-API的应用程序集成。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6595.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6595.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Applicability ..............................................4
2. Authentication Flow .............................................5
3. SAML SASL Mechanism Specification ...............................7
3.1. Initial Response ...........................................8
3.2. Authentication Request .....................................8
3.3. Outcome and Parameters .....................................9
4. SAML GSS-API Mechanism Specification ...........................10
4.1. GSS-API Principal Name Types for SAML .....................11
5. Examples .......................................................11
5.1. XMPP ......................................................11
5.2. IMAP ......................................................15
6. Security Considerations ........................................17
6.1. Man-in-the-Middle and Tunneling Attacks ...................17
6.2. Binding SAML Subject Identifiers to Authorization
Identities ................................................17
6.3. User Privacy ..............................................18
6.4. Collusion between RPs .....................................18
6.5. Security Considerations Specific to GSS-API ...............18
7. IANA Considerations ............................................18
7.1. IANA Mech-Profile .........................................18
7.2. IANA OID ..................................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................21
Appendix A. Acknowledgments .......................................22
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Applicability ..............................................4
2. Authentication Flow .............................................5
3. SAML SASL Mechanism Specification ...............................7
3.1. Initial Response ...........................................8
3.2. Authentication Request .....................................8
3.3. Outcome and Parameters .....................................9
4. SAML GSS-API Mechanism Specification ...........................10
4.1. GSS-API Principal Name Types for SAML .....................11
5. Examples .......................................................11
5.1. XMPP ......................................................11
5.2. IMAP ......................................................15
6. Security Considerations ........................................17
6.1. Man-in-the-Middle and Tunneling Attacks ...................17
6.2. Binding SAML Subject Identifiers to Authorization
Identities ................................................17
6.3. User Privacy ..............................................18
6.4. Collusion between RPs .....................................18
6.5. Security Considerations Specific to GSS-API ...............18
7. IANA Considerations ............................................18
7.1. IANA Mech-Profile .........................................18
7.2. IANA OID ..................................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................21
Appendix A. Acknowledgments .......................................22
Security Assertion Markup Language (SAML) 2.0 [OASIS-SAMLv2-CORE] is a set of specifications that provide various means for a user to be identified to a Relying Party (RP) through the exchange of (typically signed) assertions issued by an Identity Provider (IdP). It includes a number of protocols, protocol bindings [OASIS-SAMLv2-BIND], and interoperability profiles [OASIS-SAMLv2-PROF] designed for different use cases.
安全断言标记语言（SAML）2.0[OASIS-SAMLv2-CORE]是一组规范，通过交换由身份提供者（IdP）发布的（通常经过签名的）断言，为向依赖方（RP）识别用户提供了各种方法。它包括许多协议、协议绑定[OASIS-SAMLv2-BIND]以及针对不同用例设计的互操作性概要文件[OASIS-SAMLv2-PROF]。
The Simple Authentication and Security Layer (SASL) [RFC4422] is a generalized mechanism for identifying and authenticating a user and for optionally negotiating a security layer for subsequent protocol interactions. SASL is used by application protocols like IMAP [RFC3501], the Post Office Protocol (POP) [RFC1939], and the Extensible Message and Presence Protocol (XMPP) [RFC6120]. The effect is to make modular authentication, so that newer authentication mechanisms can be added as needed. This memo specifies just such a mechanism.
简单认证和安全层（SASL）[RFC4422]是一种通用机制，用于识别和认证用户，并可选地协商用于后续协议交互的安全层。SASL由应用程序协议使用，如IMAP[RFC3501]、邮局协议（POP）[RFC1939]和可扩展消息和状态协议（XMPP）[RFC6120]。其效果是进行模块化身份验证，以便根据需要添加新的身份验证机制。这份备忘录明确规定了这样一种机制。
The Generic Security Service Application Program Interface (GSS-API) [RFC2743] provides a framework for applications to support multiple authentication mechanisms through a unified programming interface. This document defines a pure SASL mechanism for SAML, but it conforms to the new bridge between SASL and the GSS-API called GS2 [RFC5801]. This means that this document defines both a SASL mechanism and a GSS-API mechanism. The GSS-API interface is OPTIONAL for SASL implementers, and the GSS-API considerations can be avoided in environments that use SASL directly without GSS-API.
通用安全服务应用程序接口（GSS-API）[RFC2743]为通过统一编程接口支持多种身份验证机制的应用程序提供了一个框架。本文档为SAML定义了一个纯SASL机制，但它符合SASL和GSS-API（称为GS2[RFC5801]）之间的新桥梁。这意味着本文档定义了SASL机制和GSS-API机制。GSS-API接口对于SASL实现者是可选的，在不使用GSS-API而直接使用SASL的环境中，可以避免GSS-API考虑事项。
As currently envisioned, this mechanism enables interworking between SASL and SAML in order to assert the identity of the user and other attributes to RPs. As such, while servers (as RPs) will advertise SASL mechanisms (including SAML), clients will select the SAML SASL mechanism as their SASL mechanism of choice.
正如目前设想的那样，该机制支持SASL和SAML之间的交互，以便向RPs断言用户身份和其他属性。因此，当服务器（如RPs）将公布SASL机制（包括SAML）时，客户机将选择SAML SASL机制作为其选择的SASL机制。
The SAML mechanism described in this memo aims to reuse the Web Browser Single Sign-On (SSO) profile defined in Section 4.1 of the SAML 2.0 profiles specification [OASIS-SAMLv2-PROF] to the maximum extent and therefore does not establish a separate authentication, integrity, and confidentiality mechanism. The mechanism assumes that a security layer, such as Transport Layer Security (TLS) [RFC5246], will continue to be used. This specification is appropriate for use when a browser instance is available. In the absence of a browser instance, SAML profiles that don't require a browser, such as the Enhanced Client or Proxy profile (as defined in Section 4.2 of [OASIS-SAMLv2-PROF], may be used, but that is outside the scope of this specification.
本备忘录中描述的SAML机制旨在最大限度地重用SAML 2.0配置文件规范[OASIS-SAMLv2-PROF]第4.1节中定义的Web浏览器单点登录（SSO）配置文件，因此不建立单独的身份验证、完整性和机密性机制。该机制假设将继续使用安全层，例如传输层安全性（TLS）[RFC5246]。此规范适用于浏览器实例可用时使用。在没有浏览器实例的情况下，可以使用不需要浏览器的SAML配置文件，例如增强型客户端或代理配置文件（如[OASIS-SAMLv2-PROF]第4.2节所定义），但这不在本规范的范围内。
Figure 1 describes the interworking between SAML and SASL: this document requires enhancements to the RP (the SASL server) and to the client, as the two SASL communication end points, but no changes to the SAML IdP are necessary. To accomplish this goal, some indirect messaging is tunneled within SASL, and some use of external methods is made.
图1描述了SAML和SASL之间的互通：本文档要求增强RP（SASL服务器）和客户机，作为两个SASL通信端点，但不需要对SAML IdP进行任何更改。为了实现这一目标，在SASL中通过隧道传输一些间接消息，并使用一些外部方法。
+-----------+
| |
>| Relying |
/ | Party |
// | |
// +-----------+
SAML/ // ^
HTTPS // +--|--+
// | S| |
/ S | A| |
// A | M| |
// S | L| |
// L | | |
// | | |
</ +--|--+
+------------+ v
| | +----------+
| SAML | HTTPS | |
| Identity |<--------------->| Client |
| Provider | | |
+------------+ +----------+
+-----------+
| |
>| Relying |
/ | Party |
// | |
// +-----------+
SAML/ // ^
HTTPS // +--|--+
// | S| |
/ S | A| |
// A | M| |
// S | L| |
// L | | |
// | | |
</ +--|--+
+------------+ v
| | +----------+
| SAML | HTTPS | |
| Identity |<--------------->| Client |
| Provider | | |
+------------+ +----------+
Figure 1: Interworking Architecture
图1：互通架构
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The reader is assumed to be familiar with the terms used in the SAML 2.0 core specification [OASIS-SAMLv2-CORE].
假定读者熟悉SAML2.0核心规范[OASIS-SAMLv2-core]中使用的术语。
Because this mechanism transports information that should not be controlled by an attacker, the SAML mechanism MUST only be used over channels protected by TLS, or over similar integrity-protected and authenticated channels. In addition, when TLS is used, the client MUST successfully validate the server's certificate ([RFC5280], [RFC6125]).
由于此机制传输不应由攻击者控制的信息，因此SAML机制只能在TLS保护的通道上使用，或在类似的完整性保护和身份验证通道上使用。此外，使用TLS时，客户端必须成功验证服务器的证书（[RFC5280]、[RFC6125]）。
Note: An Intranet does not constitute such an integrity-protected and authenticated channel!
注意：内部网不构成这样一个完整性保护和认证通道！
While SAML itself is merely a markup language, its common use case these days is with HTTP [RFC2616] or HTTPS [RFC2818] and HTML [W3C-REC-HTML401]. What follows is a typical flow:
虽然SAML本身只是一种标记语言，但它现在的常见用例是HTTP[RFC2616]或HTTPS[RFC2818]和HTML[W3C-REC-HTML401]。以下是一个典型的流程：
1. The browser requests a resource of an RP (via an HTTP request).
1. 浏览器请求RP的资源（通过HTTP请求）。
2. The RP redirects the browser via an HTTP redirect (as described in Section 10.3 of [RFC2616]) to the IdP or an IdP discovery service. When it does so, it includes the following parameters: (1) an authentication request that contains the name of the resource being requested, (2) a browser cookie, and (3) a return URL as specified in Section 3.1 of [OASIS-SAMLv2-PROF].
2. RP通过HTTP重定向（如[RFC2616]第10.3节所述）将浏览器重定向到IdP或IdP发现服务。执行此操作时，它包括以下参数：（1）包含所请求资源名称的身份验证请求，（2）浏览器cookie，以及（3）在[OASIS-SAMLv2-PROF]第3.1节中指定的返回URL。
3. The user authenticates to the IdP and perhaps authorizes the release of user attributes to the RP.
3. 用户向IdP认证，并且可能授权向RP发布用户属性。
4. In its authentication response, the IdP redirects (via an HTTP redirect) the browser back to the RP with an authentication assertion (stating that the IdP vouches that the subject has successfully authenticated), optionally along with some additional attributes.
4. 在其认证响应中，IdP（通过HTTP重定向）使用认证断言（声明IdP证明主体已成功认证）以及一些附加属性将浏览器重定向回RP。
5. The RP now has sufficient identity information to approve access to the resource or not, and acts accordingly. The authentication is concluded.
5. RP现在有足够的身份信息来批准或不批准对资源的访问，并相应地采取行动。认证结束。
When considering this flow in the context of SASL, we note that while the RP and the client both must change their code to implement this SASL mechanism, the IdP can remain untouched. The RP already has some sort of session (probably a TCP connection) established with the client. However, it may be necessary to redirect a SASL client to another application or handler. The steps are as follows:
在SASL上下文中考虑此流时，我们注意到，尽管RP和客户端都必须更改其代码以实现此SASL机制，但IdP可以保持不变。RP已经与客户端建立了某种会话（可能是TCP连接）。但是，可能需要将SASL客户端重定向到另一个应用程序或处理程序。步骤如下：
1. The SASL server (RP) advertises support for the SASL SAML20 mechanism to the client.
1. SASL服务器（RP）向客户端公布对SASL SAML20机制的支持。
2. The client initiates a SASL authentication with SAML20 and sends a domain name that allows the SASL server to determine the appropriate IdP.
2. 客户端使用SAML20启动SASL身份验证，并发送允许SASL服务器确定适当IdP的域名。
3. The SASL server transmits an authentication request encoded using a Uniform Resource Identifier (URI) as described in RFC 3986 [RFC3986] and an HTTP redirect to the IdP corresponding to the domain.
3. SASL服务器使用RFC 3986[RFC3986]中所述的统一资源标识符（URI）编码并将HTTP重定向发送到对应于域的IdP的身份验证请求。
4. The SASL client now sends a response consisting of "=". Authentication continues via the normal SAML flow, and the SASL server will receive the answer to the challenge out of band from the SASL conversation.
4. SASL客户端现在发送一个由“=”组成的响应。身份验证通过正常的SAML流继续，SASL服务器将从SASL对话接收带外质询的答案。
5. At this point, the SASL client MUST construct a URL containing the content received in the previous message from the SASL server. This URL is transmitted to the IdP either by the SASL client application or an appropriate handler, such as a browser.
5. 此时，SASL客户端必须构造一个URL，其中包含从SASL服务器收到的上一条消息中的内容。此URL通过SASL客户端应用程序或适当的处理程序（如浏览器）传输到IdP。
6. Next, the user authenticates to the IdP. The manner in which the end user is authenticated to the IdP, and any policies surrounding such authentication, are out of scope for SAML and hence for this document. This step happens out of band from SASL.
6. 接下来，用户向IdP认证。最终用户向IdP进行身份验证的方式以及围绕此类身份验证的任何策略不在SAML的范围内，因此也不在本文档的范围内。此步骤发生在SASL的带外。
7. The IdP will convey information about the success or failure of the authentication back to the SASL server (RP) in the form of an authentication statement or failure, using an indirect response via the client browser or the handler (and with an external browser, client control should be passed back to the SASL client). This step happens out of band from SASL.
7. IdP将使用通过客户端浏览器或处理程序的间接响应，以身份验证声明或失败的形式将身份验证成功或失败的信息传回SASL服务器（RP）（对于外部浏览器，客户端控制应传回SASL客户端）。此步骤发生在SASL的带外。
8. The SASL server sends an appropriate SASL response to the client.
8. SASL服务器向客户端发送适当的SASL响应。
Please note: What is described here is the case in which the client has not previously authenticated. It is possible that the client already holds a valid SAML authentication token so that the user does not need to be involved in the process anymore, but that would still be external to SASL. This is classic Web Single Sign-On, in which the Web Browser client presents the authentication token (cookie) to the RP without renewed user authentication at the IdP.
请注意：这里描述的是客户机之前未进行身份验证的情况。客户机可能已经持有一个有效的SAML身份验证令牌，因此用户不再需要参与该过程，但这仍然是SASL之外的。这是典型的Web单点登录，其中Web浏览器客户端向RP提供身份验证令牌（cookie），而无需在IdP处重新进行用户身份验证。
With all of this in mind, the flow appears as follows in Figure 2:
考虑到所有这些，流程如图2所示：
SASL Serv. Client IdP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|>-----(3)----->| | Authentication Request
| | |
|<-----(4)-----<| | Response of "="
| | |
| |<- -(5,6) - ->| Client<>IdP
| | | Authentication
| | |
|<- - - - - - - - - - -(7)- - -| Authentication Statement
| | |
|>-----(8)----->| | SASL Completion with
| | | Status
| | |
SASL Serv. Client IdP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|>-----(3)----->| | Authentication Request
| | |
|<-----(4)-----<| | Response of "="
| | |
| |<- -(5,6) - ->| Client<>IdP
| | | Authentication
| | |
|<- - - - - - - - - - -(7)- - -| Authentication Statement
| | |
|>-----(8)----->| | SASL Completion with
| | | Status
| | |
----- = SASL
- - - = HTTP or HTTPS (external to SASL)
----- = SASL
- - - = HTTP or HTTPS (external to SASL)
Figure 2: Authentication Flow
图2：身份验证流
This section specifies the details of the SAML SASL mechanism. See Section 5 of [RFC4422] for additional details.
本节指定SAML SASL机制的详细信息。更多详细信息，请参见[RFC4422]第5节。
The name of this mechanism is "SAML20". The mechanism is capable of transferring an authorization identity (via the "gs2-header"). The mechanism does not offer a security layer.
该机制的名称为“SAML20”。该机制能够传输授权标识（通过“gs2头”）。该机制不提供安全层。
The mechanism is client-first. The first mechanism message from the client to the server is the "initial-response". As described in [RFC4422], if the application protocol does not support sending a client response together with the authentication request, the server will send an empty server challenge to let the client begin. The second mechanism message is from the server to the client, containing the SAML "authentication-request". The third mechanism message is from the client to the server and is the fixed message consisting of "=". The fourth mechanism message is from the server to the client, indicating the SASL mechanism outcome.
机制是客户机优先。从客户端到服务器的第一条机制消息是“初始响应”。如[RFC4422]中所述，如果应用程序协议不支持将客户端响应与身份验证请求一起发送，则服务器将发送一个空的服务器质询以让客户端开始。第二条机制消息是从服务器到客户机，其中包含SAML“身份验证请求”。第三个机制消息是从客户端到服务器的，是由“=”组成的固定消息。第四条机制消息是从服务器到客户端的，指示SASL机制的结果。
A client initiates a SAML20 authentication with SASL by sending the GS2 header followed by the Identity Provider identifier (message 2 in Figure 2) and is defined using ABNF [RFC5234] as follows:
客户机通过发送GS2报头和标识提供者标识符（图2中的消息2）来启动SASL的SAML20身份验证，并使用ABNF[RFC5234]定义如下：
initial-response = gs2-header IdP-Identifier IdP-Identifier = domain ; domain name with corresponding IdP
初始响应=gs2报头IdP标识符IdP标识符=域；具有相应IdP的域名
The gs2-header is used as follows:
gs2收割台的使用方式如下：
- The "gs2-nonstd-flag" MUST NOT be present.
- “gs2 NONSD标志”不得出现。
- The "gs2-cb-flag" MUST be set to "n" because channel-binding [RFC5056] data cannot be integrity protected by the SAML negotiation. (Note: In theory, channel-binding data could be inserted in the SAML flow by the client and verified by the server, but that is currently not supported in SAML.)
- “gs2 cb标志”必须设置为“n”，因为SAML协商无法保护通道绑定[RFC5056]数据的完整性。（注意：理论上，通道绑定数据可以由客户端插入SAML流中，并由服务器进行验证，但SAML目前不支持这一点。）
- The "gs2-authzid" carries the optional authorization identity as specified in [RFC5801] (not to be confused with the IdP-Identifier).
- “gs2 authzid”带有[RFC5801]中指定的可选授权标识（不要与IdP标识符混淆）。
A domain name is either a "traditional domain name" as described in
[RFC1035] or an "internationalized domain name" as described in
[RFC5890]. Clients and servers MUST treat the IdP-Identifier as a
domain name slot [RFC5890]. They also SHOULD support
internationalized domain names (IDNs) in the IdP-Identifier field; if
they do so, all of the domain name's labels MUST be A-labels or
NR-LDH labels [RFC5890]. If necessary, internationalized labels MUST
be converted from U-labels to A-labels by using the Punycode encoding
[RFC3492] for A-labels prior to sending them to the SASL server, as
described in the protocol specification for Internationalized Domain
Names in Applications [RFC5891].
A domain name is either a "traditional domain name" as described in
[RFC1035] or an "internationalized domain name" as described in
[RFC5890]. Clients and servers MUST treat the IdP-Identifier as a
domain name slot [RFC5890]. They also SHOULD support
internationalized domain names (IDNs) in the IdP-Identifier field; if
they do so, all of the domain name's labels MUST be A-labels or
NR-LDH labels [RFC5890]. If necessary, internationalized labels MUST
be converted from U-labels to A-labels by using the Punycode encoding
[RFC3492] for A-labels prior to sending them to the SASL server, as
described in the protocol specification for Internationalized Domain
Names in Applications [RFC5891].
The SASL server transmits to the SASL client a URI that redirects the SAML client to the IdP (corresponding to the domain that the user provided), with a SAML authentication request as one of the parameters (message 3 in Figure 2) using the following ABNF:
SASL服务器向SASL客户端发送一个URI，该URI将SAML客户端重定向到IdP（对应于用户提供的域），并使用以下ABNF将SAML身份验证请求作为参数之一（图2中的消息3）：
authentication-request = URI
authentication-request = URI
The URI is specified in [RFC3986] and is encoded according to Section 3.4 ("HTTP Redirect Binding") of the SAML 2.0 bindings specification [OASIS-SAMLv2-BIND]. The SAML authentication request is encoded according to Section 3.4 ("Authentication Request
URI在[RFC3986]中指定，并根据SAML2.0绑定规范[OASIS-SAMLv2-BIND]第3.4节（“HTTP重定向绑定”）进行编码。SAML认证请求根据第3.4节（“认证请求”）进行编码
Protocol") of [OASIS-SAMLv2-CORE]. Should the client support Internationalized Resource Identifiers (IRIs) [RFC3987], it MUST first map the IRI to a URI before transmitting it to the server, as defined in Section 3.1 of [RFC3987].
[OASIS-SAMLv2-CORE]的协议）。如果客户端支持国际化资源标识符（IRI）[RFC3987]，则必须首先将IRI映射到URI，然后再将其传输到服务器，如[RFC3987]第3.1节所定义。
Note: The SASL server may have a static mapping of domain to corresponding IdP or, alternatively, a DNS-lookup mechanism could be envisioned, but that is out of scope for this document.
注意：SASL服务器可能具有域到相应IdP的静态映射，或者可以设想DNS查找机制，但这超出了本文档的范围。
Note: While the SASL client MAY sanity-check the URI it received, ultimately it is the SAML IdP that will be validated by the SAML client; this topic is out of scope for this document.
注意：虽然SASL客户端可能会对其接收到的URI进行健全性检查，但最终将由SAML客户端验证的是SAML IdP；此主题超出了本文档的范围。
The client then sends the authentication request via an HTTP GET (sent over a server-authenticated TLS channel) to the IdP, as if redirected to do so from an HTTP server and in accordance with the Web Browser SSO profile, as described in Section 4.1 of [OASIS-SAMLv2-PROF] (messages 5 and 6 in Figure 2).
然后，客户端通过HTTP GET（通过服务器认证的TLS通道发送）将认证请求发送到IdP，就像从HTTP服务器重定向到IdP一样，并根据Web浏览器SSO配置文件，如[OASIS-SAMLv2-PROF]第4.1节所述（图2中的消息5和6）。
The client handles both user authentication to the IdP and confirmation or rejection of the authentication of the RP (out of scope for this document).
客户机处理对IdP的用户身份验证以及RP身份验证的确认或拒绝（不在本文件范围内）。
After all authentication has been completed by the IdP, the IdP will send a redirect message to the client in the form of a URI corresponding to the RP as specified in the authentication request ("AssertionConsumerServiceURL") and with the SAML response as one of the parameters (message 7 in Figure 2).
在IdP完成所有身份验证后，IdP将以与身份验证请求中指定的RP相对应的URI（“AssertionConsumerServiceURL”）的形式向客户端发送重定向消息，并将SAML响应作为参数之一（图2中的消息7）。
Please note: This means that the SASL server needs to implement a SAML RP. Also, the SASL server needs to correlate the session it has with the SASL client with the appropriate SAML authentication result. It can do so by comparing the ID of the SAML authentication request it has issued with the one it receives in the SAML authentication statement.
请注意：这意味着SASL服务器需要实现SAML RP。此外，SASL服务器需要将其与SASL客户端的会话与适当的SAML身份验证结果相关联。它可以通过将已发出的SAML身份验证请求的ID与在SAML身份验证语句中收到的ID进行比较来实现这一点。
The SASL server (in its capacity as a SAML RP) now validates the SAML authentication response it received from the SAML client via HTTP or HTTPS.
SASL服务器（以SAML RP的身份）现在验证它通过HTTP或HTTPS从SAML客户端收到的SAML身份验证响应。
The outcome of that validation by the SASL server constitutes a SASL mechanism outcome and therefore (as stated in [RFC4422]) SHALL be used to set state in the server accordingly, and it SHALL be used by the server to report that state to the SASL client, as described in [RFC4422], Section 3.6 (message 8 in Figure 2).
SASL服务器验证的结果构成SASL机制结果，因此（如[RFC4422]中所述）应用于相应地设置服务器中的状态，服务器应使用该结果向SASL客户端报告该状态，如[RFC4422]第3.6节所述（图2中的消息8）。
This section and its sub-sections are not required for SASL implementors, but this section MUST be observed to implement the GSS-API mechanism discussed below.
SASL实现者不需要本节及其子节，但要实现下面讨论的GSS-API机制，必须遵守本节。
This section specifies a GSS-API mechanism that, when used via the GS2 bridge to SASL, behaves like the SASL mechanism defined in this document. Thus, it can loosely be said that the SAML SASL mechanism is also a GSS-API mechanism. The SAML user takes the role of the GSS-API Initiator, and the SAML RP takes the role of the GSS-API Acceptor. The SAML IdP does not have a role in GSS-API and is considered an internal matter for the SAML mechanism. The messages are the same, but
本节指定了一个GSS-API机制，当通过GS2桥接到SASL时，该机制的行为类似于本文档中定义的SASL机制。因此，可以粗略地说SAML SASL机制也是GSS-API机制。SAML用户扮演GSS-API发起人的角色，SAML RP扮演GSS-API接受者的角色。SAML IdP在GSS-API中不起作用，被视为SAML机制的内部事务。消息是相同的，但是
a) the GS2 header on the client's first message and channel-binding data are excluded when SAML is used as a GSS-API mechanism, and
a) 当SAML用作GSS-API机制时，客户端第一条消息和通道绑定数据上的GS2头被排除，并且
b) the initial context token header (Section 3.1 of [RFC2743]) is prefixed to the client's first authentication message (context token).
b) 初始上下文令牌头（RFC2743的第3.1节）以客户端的第一条身份验证消息（上下文令牌）为前缀。
The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17 (see Section 7.2 for more information). The DER encoding of the OID is 0x2b 0x06 0x01 0x05 0x05 0x11.
SAML的GSS-API机制OID为1.3.6.1.5.5.17（更多信息请参见第7.2节）。OID的DER编码为0x2b 0x06 0x01 0x05 0x05 0x11。
SAML20 security contexts MUST have the mutual_state flag (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential delegation; therefore, SAML security contexts MUST have the deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
SAML20安全上下文必须将相互_状态标志（GSS_C_相互_标志）设置为TRUE。SAML不支持凭证委派；因此，SAML安全上下文必须将deleg_状态标志（GSS_C_deleg_标志）设置为FALSE。
The mutual authentication property of this mechanism relies on successfully comparing the TLS server's identity with the negotiated target name. Since the TLS channel is managed by the application outside of the GSS-API mechanism, the mechanism itself is unable to confirm the name, while the application is able to perform this comparison for the mechanism. For this reason, applications MUST match the TLS server's identity with the target name, as discussed in [RFC6125]. More precisely, to pass identity validation, the client uses the securely negotiated targ_name as the reference identifier and matches it to the DNS-ID of the server's certificate, and it MUST reject the connection if there is a mismatch. For compatibility with deployed certificate hierarchies, the client MAY also perform a comparison with the Common Name ID (CN-ID) when there is no DNS-ID present. Wildcard matching is permitted. The targ_name reference identifier is a "traditional domain names"; thus, the comparison is made using case-insensitive ASCII comparison.
此机制的相互身份验证属性依赖于成功地将TLS服务器的标识与协商的目标名称进行比较。由于TLS通道由GSS-API机制之外的应用程序管理，因此该机制本身无法确认名称，而应用程序可以对该机制执行此比较。因此，应用程序必须将TLS服务器的标识与目标名称相匹配，如[RFC6125]中所述。更准确地说，为了通过身份验证，客户端使用安全协商的target_名称作为参考标识符，并将其与服务器证书的DNS-ID匹配，如果存在不匹配，则必须拒绝连接。为了与已部署的证书层次结构兼容，当不存在DNS-ID时，客户端还可以与公共名称ID（CN-ID）进行比较。允许通配符匹配。目标名称参考标识符是“传统域名”；因此，使用不区分大小写的ASCII比较进行比较。
The SAML mechanism does not support per-message tokens or the GSS_Pseudo_random() function [RFC4401].
SAML机制不支持每消息令牌或GSS_Pseudo_random（）函数[RFC4401]。
SAML supports standard generic name syntaxes for acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4.1). SAML supports only a single name type for initiators: GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for SAML. The query, display, and exported name syntaxes for SAML principal names are all the same. There are no SAML-specific name syntaxes -- applications should use generic GSS-API name types, such as GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743] Section 4). The exported name token, of course, conforms to [RFC2743], Section 3.2.
SAML支持接受程序的标准通用名称语法，如GSS_C_NT_HOSTBASED_服务（请参阅[RFC2743]，第4.1节）。SAML只支持启动器的单一名称类型：GSS\u C\u NT\u USER\u name。GSS_C_NT_USER_NAME是SAML的默认名称类型。SAML主体名称的查询、显示和导出名称语法都是相同的。没有特定于SAML的名称语法——应用程序应该使用通用的GSS-API名称类型，例如GSS_C_NT_USER_name和GSS_C_NT_HOSTBASED_SERVICE（请参见[RFC2743]第4节）。当然，导出的名称令牌符合[RFC2743]第3.2节。
Suppose the user has an identity at the SAML IdP saml.example.org and a Jabber Identifier (JID) "somenode@example.com" and wishes to authenticate his XMPP [RFC6120] connection to xmpp.example.com. The authentication on the wire would then look something like the following:
假设用户在SAML IdP SAML.example.org上有一个标识和一个Jabber标识符（JID）”somenode@example.com“并希望验证他与XMPP.example.com的XMPP[RFC6120]连接。然后，线路上的身份验证将如下所示：
Step 1: Client initiates stream to server:
步骤1：客户端向服务器发起流：
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com' version='1.0'>
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com' version='1.0'>
Step 2: Server responds with a stream tag sent to client:
步骤2：服务器用发送到客户端的流标记进行响应：
<stream:stream
xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'
id='some_id' from='example.com' version='1.0'>
<stream:stream
xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'
id='some_id' from='example.com' version='1.0'>
Step 3: Server informs client of available authentication mechanisms:
步骤3：服务器通知客户端可用的身份验证机制：
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>SAML20</mechanism>
</mechanisms>
</stream:features>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>SAML20</mechanism>
</mechanisms>
</stream:features>
Step 4: Client selects an authentication mechanism and provides the initial client response -- containing the gs2-header and domain -- that has been encoded in base64 according to Section 4 of [RFC4648]:
步骤4：客户端选择身份验证机制并提供初始客户端响应（包含gs2头和域），该响应已根据[RFC4648]第4节在base64中编码：
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20'>
biwsZXhhbXBsZS5vcmc=</auth>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20'>
biwsZXhhbXBsZS5vcmc=</auth>
The decoded string is
解码的字符串是
n,,example.org
n、 ，example.org
Step 5: Server sends a base64-encoded challenge to client in the form of an HTTP redirect to the SAML IdP corresponding to example.org (https://saml.example.org) with the SAML authentication request as specified in the redirection URL:
步骤5：服务器以HTTP重定向的形式向客户机发送base64编码的质询，并将其重定向到example.org对应的SAML IdP(https://saml.example.org)使用重定向URL中指定的SAML身份验证请求：
aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1MUmVx
dWVzdD1QSE5oYld4d09rRjFkR2h1VW1WeGRXVnpkQ0I0Yld4dWN6cHpZVzFz
Y0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnli
M1J2WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9U
QTVZVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQldaWEp6YVc5
dVBTSXlMakFpRFFvZ0lDQWdTWE56ZFdWSmJuTjBZVzUwUFNJeU1EQTNMVEV5
TFRFd1ZERXhPak01T2pNMFdpSWdSbTl5WTJWQmRYUm9iajBpWm1Gc2MyVWlE
UW9nSUNBZ1NYTlFZWE56YVhabFBTSm1ZV3h6WlNJTkNpQWdJQ0JRY205MGIy
TnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6cDBZenBUUVUx
TU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUUxWQlBVMVFpRFFvZ0lDQWdRWE56
WlhKMGFXOXVRMjl1YzNWdFpYSlRaWEoyYVdObFZWSk1QUTBLSUNBZ0lDQWdJ
Q0FpYUhSMGNITTZMeTk0YlhCd0xtVjRZVzF3YkdVdVkyOXRMMU5CVFV3dlFY
TnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0TkNpQThjMkZ0YkRw
SmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6
T25Sak9sTkJUVXc2TWk0d09tRnpjMlZ5ZEdsdmJpSStEUW9nSUNBZ0lHaDBk
SEJ6T2k4dmVHMXdjQzVsZUdGdGNHeGxMbU52YlEwS0lEd3ZjMkZ0YkRwSmMz
TjFaWEkrRFFvZ1BITmhiV3h3T2s1aGJXVkpSRkJ2YkdsamVTQjRiV3h1Y3pw
ellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3
T25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbGFXUXRabTl5YldGME9u
Qmxjbk5wYzNSbGJuUWlEUW9nSUNBZ0lGTlFUbUZ0WlZGMVlXeHBabWxsY2ow
aWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXeHNiM2REY21WaGRHVTlJblJ5
ZFdVaUlDOCtEUW9nUEhOaGJXeHdPbEpsY1hWbGMzUmxaRUYxZEdodVEyOXVk
R1Y0ZEEwS0lDQWdJQ0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9t
NWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WTI5c0lpQU5DaUFnSUNB
Z0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoaFkzUWlQZzBLSUNBOGMyRnRiRHBC
ZFhSb2JrTnZiblJsZUhSRGJHRnpjMUpsWmcwS0lDQWdJQ0FnZUcxc2JuTTZj
MkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09t
RnpjMlZ5ZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhN
NmRHTTZVMEZOVERveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOemQyOXlaRkJ5
YjNSbFkzUmxaRlJ5WVc1emNHOXlkQTBLSUNBOEwzTmhiV3c2UVhWMGFHNURi
MjUwWlhoMFEyeGhjM05TWldZK0RRb2dQQzl6WVcxc2NEcFNaWEYxWlhOMFpX UkJkWFJvYmtOdmJuUmxlSFErSUEwS1BDOXpZVzFzY0RwQmRYUm9ibEpsY1hW bGMzUSs=
MJUWWLHOMFEYGHJM05TWLDZK0RRB2DQQZL6WVCXC2NECFNAWEYXWLHOMFPX UKJKWFJVYMTOMJUUMXFERSUEWS1BDOxPzVZFZY0RWQMRYUM9IBEPSY1HW bGMzUSs=
The decoded challenge is as follows:
解码的质询如下所示：
https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk F1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OT A5YTMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogIC AgSXNzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdX Robj0iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2 NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW 5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVV JMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbn M6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbi I+DQogICAgIGh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3 N1ZXI+DQogPHNhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm 9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYX Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0On BlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3 RlZEF1dGhuQ29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm 5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaX Nvbj0iZXhhY3QiPg0KICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KIC AgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOm Fzc2VydGlvbiI+DQogICAgICAgICAgIHVybjpvYXNpczpuYW1lczp0YzpTQU 1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0DQ ogIDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4NCiA8L3NhbWxwOlJlcX Vlc3RlZEF1dGhuQ29udGV4dD4gDQo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=
https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOk F1dGhuumVxDWVzDCB4bWxUczPzyW1Cd0IdxJuOm9Hc2lZom5HbWvZonRjol NbTuw6Mi4WonB3RvY29SigIkCagicaleEpFyMjNd0ZmTmTmTmTy4Zi3Zc5NdC0otg0IbWzZxJd9UpsiyIdQogic AgSxNzDWVjBn0YWn0YW5Y50PSIYYY5PSIYYYYYYYY5VzMd5OjMd5OjM9IzM9Ig2VRobJzMfsc2uidedQogiCagSxNqyxZlpsJMywxZsinciagCbQCM90B2 NVBEJPBMRPBMC9InvyBvyxNpCzPuy1CzP0YZptqu1OjiumD5NcZpivfRqlvbPu1QogiCagQxNzZZJ0AW9Uq9Uc3VtZxZxXjZxZjZxJ20WnLVV JMpQg1IkIkIkIkIkIkIkIkIkIkIkIkIkIkIkIkIkIkIkIkIkUkUkZZZZZZZ9NbZZZZZZZZZZZ9Nb9Nb9NbZZZZZZZZZZZZZZZZM6C2FTBD0IdxJuom9Hc2Lzom5HbWvzonRjolnbtuW6Mi4Womfzc2VyGlvbi+Dqogicagiggh0DHbzoi8Veg1WCc5LegFTCgxlmNbq0IdWvc2TbPjc3 N1ZXI+DqogHnHbHbWwWwJrFbGljesBbB4BwxUczPzyPzyW1Cd0I0I0Ic0Ic2Hc2Hc6Hc0Hc2Hc2Hc2Hc2Hc2Lc2Lc2LbzzyWzyWb5Hb5Hb5HbzyWb5HzyWb5HzyWv9Sig9Sig9Sig9Sig9BLCNNPC3RLBNQIDQOGICIFNQTMFTZVF1YWXPZMLLc0IEG1WCC5LEGFTCG XLNVBSIGQWXSB3DDCMVHDGU9inryWUIIC8+DQOGPHHHHHHWWXWOLJLCxVLC3 RLZEF1DGHUQ29UDGV4DA0KICAGICBB4BWXUCZYW10IDXJUM9HC2ZO6M5HBWWZONRJOL6M6MI2BY2RY2R9TCGFYAX NVBJ0K8KKKKJ0KJ0KJ0KKJ0KJJ0KJ0KKKKKKKKKKKKKKZCRYCAgicageG1SBNM6C2FTBD0IdxJuom9Hc2LzZonRjolnbtuw6Mi4Wom Fzc2VydGlvbiI+Dqogicagicagicagicagicgicgicgicgicgicgicgicgicgic1czp1czp0YzpZc0YpZc2VzolBHc3n3jkuhjjjvdGvjdgVjDgVjHjHbnWb3Jb3J0dq OgidWc2TbDbDbDbDbDbDbxRobnVbnRbnRbnRbHrbnRbHrbnRbHrDfRbHrDbHrDbNbNbNbNbNbNbNbNbHrD=
Where the decoded SAMLRequest looks like the following:
其中解码的SAMLRequest如下所示：
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_bec424fa5103428909a30ff1e31168327f79474984" Version="2.0"
IssueInstant="2007-12-10T11:39:34Z" ForceAuthn="false"
IsPassive="false"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL=
"https://xmpp.example.com/SAML/AssertionConsumerService">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com
</saml:Issuer>
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
SPNameQualifier="xmpp.example.com" AllowCreate="true" />
<samlp:RequestedAuthnContext
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_bec424fa5103428909a30ff1e31168327f79474984" Version="2.0"
IssueInstant="2007-12-10T11:39:34Z" ForceAuthn="false"
IsPassive="false"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL=
"https://xmpp.example.com/SAML/AssertionConsumerService">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com
</saml:Issuer>
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
SPNameQualifier="xmpp.example.com" AllowCreate="true" />
<samlp:RequestedAuthnContext
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="exact">
<saml:AuthnContextClassRef
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="exact">
<saml:AuthnContextClassRef
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
Note: The server can use the request ID ("_bec424fa5103428909a30ff1e31168327f79474984") to correlate the SASL session with the SAML authentication.
注意：服务器可以使用请求ID（“bec424fa5103428909a30ff1e31168327f79474984”）将SASL会话与SAML身份验证关联起来。
Step 5 (alternative): Server returns error to client if no SAML authentication request can be constructed:
步骤5（可选）：如果无法构造SAML身份验证请求，服务器将向客户端返回错误：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
Step 6: Client sends the "=" response (base64-encoded) to the challenge:
步骤6：客户端向质询发送“=”响应（base64编码）：
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PQ==
</response>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PQ==
</response>
The following steps between brackets are out of scope for this document but are included to better illustrate the entire flow:
括号之间的以下步骤不在本文件范围内，但为了更好地说明整个流程，将其包括在内：
[The client now sends the URL to a browser instance for processing. The browser engages in a normal SAML authentication flow (external to SASL), like redirection to the IdP (https://saml.example.org); the user logs into https://saml.example.org and agrees to authenticate to xmpp.example.com. A redirect is passed back to the client browser. The client browser in turn sends the AuthN response, which contains the subject-identifier as an attribute, to the server. If the AuthN response doesn't contain the JID, the server maps the subject-identifier received from the IdP to a JID.]
[客户端现在将URL发送到浏览器实例进行处理。浏览器参与正常的SAML身份验证流（SASL外部），如重定向到IdP(https://saml.example.org)；用户登录到https://saml.example.org 并同意向xmpp.example.com进行身份验证。重定向被传递回客户端浏览器。客户端浏览器依次将包含主题标识符作为属性的AuthN响应发送到服务器。如果AuthN响应不包含JID，则服务器将映射主题标识符从国内流离失所者处接收到的难民救济金给JID。]
Step 7: Server informs client of successful authentication:
步骤7：服务器通知客户端身份验证成功：
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 7 (alternative): Server informs client of failed authentication:
步骤7（可选）：服务器通知客户端身份验证失败：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/>
</failure>
</stream:stream>
Please note: Line breaks were added to the base64 data for clarity.
请注意：为清晰起见，在base64数据中添加了换行符。
The following sequence describes an IMAP exchange. Lines beginning with 'S:' indicate data sent by the server, and lines starting with 'C:' indicate data sent by the client. Long lines are wrapped for readability.
以下序列描述IMAP交换。以“S:”开头的行表示服务器发送的数据，以“C:”开头的行表示客户端发送的数据。为便于阅读，长行被包装起来。
S: * OK IMAP4rev1
C: . CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS
S: . OK CAPABILITY Completed
C: . STARTTLS
S: . OK Begin TLS negotiation now
C: . CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=SAML20
S: . OK CAPABILITY Completed
C: . AUTHENTICATE SAML20
S: +
C: biwsZXhhbXBsZS5vcmc=
S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1M
UmVxdWVzdD1QSE5oYld4d09rRg0KMWRHaHVVbVZ4ZFdWemRDQjRiV3h1Y3pwe
llXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQg0KVFV3Nk1pNH
dPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lFbEVQU0pmWW1Wak5ESTBabUUxTVRBek5
ESTRPVEE1WQ0KVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQlda
WEp6YVc5dVBTSXlMakFpRFFvZ0lDQWdTWA0KTnpkV1ZKYm5OMFlXNTBQU0l5T
URBM0xURXlMVEV3VkRFeE9qTTVPak0wV2lJZ1JtOXlZMlZCZFhSb2JqMA0KaV
ptRnNjMlVpRFFvZ0lDQWdTWE5RWVhOemFYWmxQU0ptWVd4elpTSU5DaUFnSUN
CUWNtOTBiMk52YkVKcA0KYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6
cDBZenBUUVUxTU9qSXVNRHBpYVc1a2FXNW5jenBJVg0KRlJRTFZCUFUxUWlEU
W9nSUNBZ1FYTnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sVlZKTVBRME
tJQw0KQWdJQ0FnSUNBaWFIUjBjSE02THk5dFlXbHNMbVY0WVcxd2JHVXVZMjl
0TDFOQlRVd3ZRWE56WlhKMGFXOQ0KdVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0
TkNpQThjMkZ0YkRwSmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaQ0KZFhKdU9tO
WhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3T21GemMyVnlkR2x2YmlJK0
RRb2dJQ0FnSQ0KR2gwZEhCek9pOHZlRzF3Y0M1bGVHRnRjR3hsTG1OdmJRMEt
JRHd2YzJGdGJEcEpjM04xWlhJK0RRb2dQSA0KTmhiV3h3T2s1aGJXVkpSRkJ2
YkdsamVTQjRiV3h1Y3pwellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVg0Ke
k9uUmpPbE5CVFV3Nk1pNHdPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lDQkdiM0p0WV
S: * OK IMAP4rev1
C: . CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS
S: . OK CAPABILITY Completed
C: . STARTTLS
S: . OK Begin TLS negotiation now
C: . CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=SAML20
S: . OK CAPABILITY Completed
C: . AUTHENTICATE SAML20
S: +
C: biwsZXhhbXBsZS5vcmc=
S: + aHR0cHM6Ly9zYW1sLmV4YW1wbGUub3JnL1NBTUwvQnJvd3Nlcj9TQU1M
UmVxdWVzdD1QSE5oYld4d09rRg0KMWRHaHVVbVZ4ZFdWemRDQjRiV3h1Y3pwe
llXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVnpPblJqT2xOQg0KVFV3Nk1pNH
dPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lFbEVQU0pmWW1Wak5ESTBabUUxTVRBek5
ESTRPVEE1WQ0KVE13Wm1ZeFpUTXhNVFk0TXpJM1pqYzVORGMwT1RnMElpQlda
WEp6YVc5dVBTSXlMakFpRFFvZ0lDQWdTWA0KTnpkV1ZKYm5OMFlXNTBQU0l5T
URBM0xURXlMVEV3VkRFeE9qTTVPak0wV2lJZ1JtOXlZMlZCZFhSb2JqMA0KaV
ptRnNjMlVpRFFvZ0lDQWdTWE5RWVhOemFYWmxQU0ptWVd4elpTSU5DaUFnSUN
CUWNtOTBiMk52YkVKcA0KYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbGN6
cDBZenBUUVUxTU9qSXVNRHBpYVc1a2FXNW5jenBJVg0KRlJRTFZCUFUxUWlEU
W9nSUNBZ1FYTnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sVlZKTVBRME
tJQw0KQWdJQ0FnSUNBaWFIUjBjSE02THk5dFlXbHNMbVY0WVcxd2JHVXVZMjl
0TDFOQlRVd3ZRWE56WlhKMGFXOQ0KdVEyOXVjM1Z0WlhKVFpYSjJhV05sSWo0
TkNpQThjMkZ0YkRwSmMzTjFaWElnZUcxc2JuTTZjMkZ0YkQwaQ0KZFhKdU9tO
WhjMmx6T201aGJXVnpPblJqT2xOQlRVdzZNaTR3T21GemMyVnlkR2x2YmlJK0
RRb2dJQ0FnSQ0KR2gwZEhCek9pOHZlRzF3Y0M1bGVHRnRjR3hsTG1OdmJRMEt
JRHd2YzJGdGJEcEpjM04xWlhJK0RRb2dQSA0KTmhiV3h3T2s1aGJXVkpSRkJ2
YkdsamVTQjRiV3h1Y3pwellXMXNjRDBpZFhKdU9tOWhjMmx6T201aGJXVg0Ke
k9uUmpPbE5CVFV3Nk1pNHdPbkJ5YjNSdlkyOXNJZzBLSUNBZ0lDQkdiM0p0WV
hROUluVnlianB2WVhOcA0KY3pwdVlXMWxjenAwWXpwVFFVMU1Pakl1TURwdVl
XMWxhV1F0Wm05eWJXRjBPbkJsY25OcGMzUmxiblFpRA0KUW9nSUNBZ0lGTlFU
bUZ0WlZGMVlXeHBabWxsY2owaWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXe
HNiMw0KZERjbVZoZEdVOUluUnlkV1VpSUM4K0RRb2dQSE5oYld4d09sSmxjWF
ZsYzNSbFpFRjFkR2h1UTI5dWRHVg0KNGRBMEtJQ0FnSUNCNGJXeHVjenB6WVc
xc2NEMGlkWEp1T205aGMybHpPbTVoYldWek9uUmpPbE5CVFV3Ng0KTWk0d09u
QnliM1J2WTI5c0lpQU5DaUFnSUNBZ0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoa
FkzUWlQZzBLSQ0KQ0E4YzJGdGJEcEJkWFJvYmtOdmJuUmxlSFJEYkdGemMxSm
xaZzBLSUNBZ0lDQWdlRzFzYm5NNmMyRnRiRA0KMGlkWEp1T205aGMybHpPbTV
oYldWek9uUmpPbE5CVFV3Nk1pNHdPbUZ6YzJWeWRHbHZiaUkrRFFvZ0lDQQ0K
Z0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhNNmRHTTZVMEZOVERveUxqQTZZV002W
TJ4aGMzTmxjenBRWVhOeg0KZDI5eVpGQnliM1JsWTNSbFpGUnlZVzV6Y0c5eW
RBMEtJQ0E4TDNOaGJXdzZRWFYwYUc1RGIyNTBaWGgwUQ0KMnhoYzNOU1pXWSt
EUW9nUEM5ellXMXNjRHBTWlhGMVpYTjBaV1JCZFhSb2JrTnZiblJsZUhRK0lB
MEtQQw0KOXpZVzFzY0RwQmRYUm9ibEpsY1hWbGMzUSs=
C: PQ==
S: . OK Success (TLS protection)
hROUluVnlianB2WVhOcA0KY3pwdVlXMWxjenAwWXpwVFFVMU1Pakl1TURwdVl
XMWxhV1F0Wm05eWJXRjBPbkJsY25OcGMzUmxiblFpRA0KUW9nSUNBZ0lGTlFU
bUZ0WlZGMVlXeHBabWxsY2owaWVHMXdjQzVsZUdGdGNHeGxMbU52YlNJZ1FXe
HNiMw0KZERjbVZoZEdVOUluUnlkV1VpSUM4K0RRb2dQSE5oYld4d09sSmxjWF
ZsYzNSbFpFRjFkR2h1UTI5dWRHVg0KNGRBMEtJQ0FnSUNCNGJXeHVjenB6WVc
xc2NEMGlkWEp1T205aGMybHpPbTVoYldWek9uUmpPbE5CVFV3Ng0KTWk0d09u
QnliM1J2WTI5c0lpQU5DaUFnSUNBZ0lDQWdRMjl0Y0dGeWFYTnZiajBpWlhoa
FkzUWlQZzBLSQ0KQ0E4YzJGdGJEcEJkWFJvYmtOdmJuUmxlSFJEYkdGemMxSm
xaZzBLSUNBZ0lDQWdlRzFzYm5NNmMyRnRiRA0KMGlkWEp1T205aGMybHpPbTV
oYldWek9uUmpPbE5CVFV3Nk1pNHdPbUZ6YzJWeWRHbHZiaUkrRFFvZ0lDQQ0K
Z0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhNNmRHTTZVMEZOVERveUxqQTZZV002W
TJ4aGMzTmxjenBRWVhOeg0KZDI5eVpGQnliM1JsWTNSbFpGUnlZVzV6Y0c5eW
RBMEtJQ0E4TDNOaGJXdzZRWFYwYUc1RGIyNTBaWGgwUQ0KMnhoYzNOU1pXWSt
EUW9nUEM5ellXMXNjRHBTWlhGMVpYTjBaV1JCZFhSb2JrTnZiblJsZUhRK0lB
MEtQQw0KOXpZVzFzY0RwQmRYUm9ibEpsY1hWbGMzUSs=
C: PQ==
S: . OK Success (TLS protection)
The decoded challenge is as follows:
解码的质询如下所示：
https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOkF 1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNB TUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OTA5Y TMwZmYxZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogICAgSX NzdWVJbnN0YW50PSIyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdXRobj0 iZmFsc2UiDQogICAgSXNQYXNzaXZlPSJmYWxzZSINCiAgICBQcm90b2NvbEJp bmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW5nczpIV FRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPQ0KIC AgICAgICAiaHR0cHM6Ly9tYWlsLmV4YW1wbGUuY29tL1NBTUwvQXNzZXJ0aW9 uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0i dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICAgI Gh0dHBzOi8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3N1ZXI+DQogPH NhbWxwOk5hbWVJRFBvbGljeSB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWV zOnRjOlNBTUw6Mi4wOnByb3RvY29sIg0KICAgICBGb3JtYXQ9InVybjpvYXNp czpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnBlcnNpc3RlbnQiD QogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcGxlLmNvbSIgQWxsb3 dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV 4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6 Mi4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaXNvbj0iZXhhY3QiPg0KI CA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZg0KICAgICAgeG1sbnM6c2FtbD 0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICA gICB1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNz d29yZFByb3RlY3RlZFRyYW5zcG9ydA0KICA8L3NhbWw6QXV0aG5Db250ZXh0Q 2xhc3NSZWY+DQogPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQ+IA0KPC 9zYW1scDpBdXRoblJlcXVlc3Q+
https://saml.example.org/SAML/Browser?SAMLRequest=PHNhbWxwOkF GhuumVxDwVzDcb4BwxUczPzyW1Cd0IdxJuOm9Hc2Zm5HbWzZonRjolnb Tuw6Mi4OnBy2Rv9SigIgIgIgIgIg2SigIgIgEgEgEgFyzMd0ZmzTmTyZc5Nd5NdWvJbNn0Yw5YWg50PSIg5PsiYYYYm2LtEg2Vd0Ig2Vd0IgIg2Vg2OjMm0Wiigryy2Vd2Vd2Vd0IzMFSC2UIDQOGICAGASXNQYXNZZAXZLPSJMYWXZSINCAGICABQCM90B2NVBEJP BMRPBMC9INVYXNPCZCPUY1CZP0YZPTQU1OJIUMD5CAW5NCZPIV FRQLVBPPU1QOGICAGICAGIQOGIQXNZZJ0AW9UQ29UCZZZZZZZZZZZZZZZZZZZZJ0W9UQ9UQ9UQ9UCZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZDxjuom9HC2LZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM9HC2LZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBWZOM5HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBVZOM9HBZOM9HBVZOM9HBZOM9HBQogicagIFNQTMFTZVF1YWxPzMLLc0IEG1WCC5LegftCgXLLmnVbSigQWxB3 dDcmVhdGU9InRydWUiIC8+DQogPhHnHbWxWolCxVLC3rLzef1dGhuq9UdGfGv4da0 kicagicBwXuCzyW1c0idxJuOm9HC2lZmom5HvZonRzonRjolNbW6 Mi4WonBy2RbY2RbY2RbY2RvY2RvY2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2Rj2R0IDXJUOM9HC2LZOM5HBWZONRJOLNBTUW6MI4WOMFZC2VYDGLVBII+DQogICA GICB1CM46B2FZXM6M6U0FNTDOYLJA6YWM6Y2XHC3NLCZPQYXNZ D29YZFBYB3RLY3RZCG9YDA0KICA8L3NHBW6QXV0AG5D250ZXH0Q 2Hc3NZHZH3N0GPC9ZYSCW1ZYWPL1ZYL1Z0K9ZYBC1ZYBJ0BJ0BJ0LXL8L8L8LLZZZZZ0PC+I0NPC+
Where the decoded SAMLRequest looks like the following:
其中解码的SAMLRequest如下所示：
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_bec424fa5103428909a30ff1e31168327f79474984" Version="2.0"
IssueInstant="2007-12-10T11:39:34Z" ForceAuthn="false"
IsPassive="false"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL=
"https://mail.example.com/SAML/AssertionConsumerService">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com
</saml:Issuer>
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
SPNameQualifier="xmpp.example.com" AllowCreate="true" />
<samlp:RequestedAuthnContext
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="exact">
<saml:AuthnContextClassRef
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_bec424fa5103428909a30ff1e31168327f79474984" Version="2.0"
IssueInstant="2007-12-10T11:39:34Z" ForceAuthn="false"
IsPassive="false"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL=
"https://mail.example.com/SAML/AssertionConsumerService">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com
</saml:Issuer>
<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
SPNameQualifier="xmpp.example.com" AllowCreate="true" />
<samlp:RequestedAuthnContext
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Comparison="exact">
<saml:AuthnContextClassRef
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
This section addresses only security considerations associated with the use of SAML with SASL applications. For considerations relating to SAML in general, and for general SASL security considerations, the reader is referred to the SAML specifications and to other literature.
本节仅讨论与SASL应用程序使用SAML相关的安全注意事项。关于SAML的一般注意事项，以及SASL的一般安全注意事项，读者可以参考SAML规范和其他文献。
This mechanism is vulnerable to man-in-the-middle and tunneling attacks unless a client always verifies the server's identity before proceeding with authentication (see [RFC6125]). Typically, TLS is used to provide a secure channel with server authentication.
这种机制容易受到中间人攻击和隧道攻击，除非客户端总是在继续进行身份验证之前验证服务器的身份（请参见[RFC6125]）。通常，TLS用于提供具有服务器身份验证的安全通道。
As specified in [RFC4422], the server is responsible for binding credentials to a specific authorization identity. It is therefore necessary that only specific trusted IdPs be allowed. This is a typical part of SAML trust establishment between RPs and the IdP.
如[RFC4422]中所述，服务器负责将凭据绑定到特定的授权标识。因此，必须只允许特定的受信任的IDP。这是RPs和IdP之间SAML信任建立的典型部分。
The IdP is aware of each RP that a user logs into. There is nothing in the protocol to hide this information from the IdP. It is not a requirement to track the visits, but there is nothing that prohibits the collection of information. SASL server implementers should be aware that SAML IdPs will be able to track -- to some extent -- user access to their services.
IdP知道用户登录的每个RP。协议中没有对IdP隐藏此信息的内容。跟踪访问不是一项要求，但没有任何规定禁止收集信息。SASL服务器实现者应该知道，SAML IDP将能够在某种程度上跟踪用户对其服务的访问。
It is possible for RPs to link data that they have collected on the users. By using the same identifier to log into every RP, collusion between RPs is possible. In SAML, targeted identity was introduced. Targeted identity allows the IdP to transform the identifier the user typed in to an RP-specific opaque identifier. This way, the RP would never see the actual user identifier but instead would see a randomly generated identifier.
RPs可以链接他们在用户上收集的数据。通过使用相同的标识符登录到每个RP，RPs之间的共谋是可能的。在SAML中，引入了目标身份。目标标识允许IdP将用户键入的标识符转换为RP特定的不透明标识符。这样，RP将永远不会看到实际的用户标识符，而是会看到随机生成的标识符。
Security issues inherent in GSS-API [RFC2743] and GS2 [RFC5801] apply to the SAML GSS-API mechanism defined in this document. Further, and as discussed in Section 4, proper TLS server identity verification is critical to the security of the mechanism.
GSS-API[RFC2743]和GS2[RFC5801]中固有的安全问题适用于本文档中定义的SAML GSS-API机制。此外，如第4节所述，正确的TLS服务器身份验证对于机制的安全性至关重要。
The IANA has registered the following SASL profile:
IANA已注册了以下SASL配置文件：
SASL mechanism profile: SAML20
SASL机制配置文件：SAML20
Security Considerations: See this document
安全注意事项：请参阅本文档
Published Specification: See this document
发布的规范：参见本文档
For further information: Contact the authors of this document.
有关更多信息：请与本文档的作者联系。
Owner/Change controller: the IETF
所有者/变更控制者：IETF
Intended usage: COMMON
预期用途：普通
Note: None
注：无
The IANA has also assigned a new entry for this GSS mechanism in the SMI Security for Mechanism Codes sub-registry, whose prefix is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5), and referenced this specification in the registry.
IANA还在SMI安全机制代码子注册表中为该GSS机制分配了一个新条目，其前缀为iso.org.dod.internet.Security.mechanism（1.3.6.1.5.5），并在注册表中引用了该规范。
[OASIS-SAMLv2-BIND] Cantor, S., Ed., Hirsch, F., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-bindings-2.0-os, March 2005, <http:// docs.oasis-open.org/security/saml/v2.0/ saml-bindings-2.0-os.pdf>.
[OASIS-SAMLv2-BIND]Cantor，S.，Ed.，Hirsch，F.，Ed.，Kemp，J.，Ed.，Philpott，R.，Ed.，和E.Maler，Ed.，“OASIS安全断言标记语言（SAML）V2.0的绑定”，OASIS标准SAML-Bindings-2.0-os，2005年3月，<http://docs.OASIS-open.org/Security/SAML/V2.0/SAML-Bindings-2.0-os.pdf>。
[OASIS-SAMLv2-CORE] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E. Maler, Ed., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http:// docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>.
[OASIS-SAMLv2-CORE]Cantor，S.，Ed.，Kemp，J.，Ed.，Philpott，R.，Ed.，和E.Maler，Ed.，“OASIS安全断言标记语言（SAML）V2.0的断言和协议”，OASIS标准SAML-CORE-2.0-os，2005年3月，<http://docs.OASIS-open.org/Security/SAML/V2.0/SAML-CORE-2.0-os.pdf>。
[OASIS-SAMLv2-PROF] Hughes, J., Ed., Cantor, S., Ed., Hodges, J., Ed., Hirsch, F., Ed., Mishra, P., Ed., Philpott, R., Ed., and E. Maler, Ed., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005, <http://docs.oasis-open.org/security/ saml/v2.0/saml-profiles-2.0-os.pdf>.
[OASIS-SAMLv2-PROF]Hughes，J.，Ed.，Cantor，S.，Ed.，Hodges，J.，Ed.，Hirsch，F.，Ed.，Mishra，P.，Ed.，Philpott，R.，Ed.，和E.Maler，Ed.，“OASIS安全断言标记语言（SAML）V2.0的配置文件”，OASIS标准OASIS.SAML-Profiles-2.0-os，2005年3月<http://docs.oasis-open.org/security/ saml/v2.0/saml-profiles-2.0-os.pdf>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5801]Josefsson，S.和N.Williams，“在简单身份验证和安全层（SASL）中使用通用安全服务应用程序接口（GSS-API）机制：GS2机制系列”，RFC 58012010年7月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[W3C-REC-HTML401] Le Hors, A., Ed., Raggett, D., Ed., and I. Jacobs, Ed., "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C-REC-HTML401]Le Hors，A.，Ed.，Raggett，D.，Ed.，和I.Jacobs，Ed.，“HTML 4.01规范”，万维网联盟建议REC-HTML401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4401]Williams，N.，“通用安全服务应用程序接口（GSS-API）的伪随机函数（PRF）API扩展”，RFC4401，2006年2月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
The authors would like to thank Scott Cantor, Joe Hildebrand, Josh Howlett, Leif Johansson, Thomas Lenggenhager, Diego Lopez, Hank Mauldin, RL "Bob" Morgan, Stefan Plug, and Hannes Tschofenig for their review and contributions.
作者要感谢Scott Cantor、Joe Hildebrand、Josh Howlett、Leif Johansson、Thomas Lenggenhager、Diego Lopez、Hank Mauldin、RL“Bob”Morgan、Stefan Plug和Hannes Tschofenig的评论和贡献。
Authors' Addresses
作者地址
Klaas Wierenga Cisco Systems, Inc. Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands
克拉斯·维伦加思科系统有限公司荷兰阿姆斯特丹哈勒贝格韦13-19 1101 CH
Phone: +31 20 357 1752
EMail: klaas@cisco.com
Phone: +31 20 357 1752
EMail: klaas@cisco.com
Eliot Lear Cisco Systems GmbH Richtistrasse 7 CH-8304 Wallisellen Switzerland
艾略特·李尔思科系统有限公司瑞士瓦利塞伦Richtistrasse 7 CH-8304
Phone: +41 44 878 9200
EMail: lear@cisco.com
Phone: +41 44 878 9200
EMail: lear@cisco.com
Simon Josefsson SJD AB Johan Olof Wallins vag 13 Solna 171 64 Sweden
Simon Josefsson SJD AB Johan Olof Wallins vag 13 Solna 171 64瑞典
EMail: simon@josefsson.org
URI: http://josefsson.org/
EMail: simon@josefsson.org
URI: http://josefsson.org/