One document matched: draft-ietf-kitten-sasl-saml-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC1035 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4422 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY RFC4648 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC2616 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2234 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC2743 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY RFC3501 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY RFC3920 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3920.xml">
<!ENTITY RFC3986 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC5801 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5801.xml">
<!ENTITY SAML20 SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml">
<!ENTITY SAML20BIND SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-bindings-2.0-os.xml">
<!ENTITY SAML20PROF SYSTEM
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-profiles-2.0-os.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc compact="no" ?> <?rfc
sortrefs="yes" ?> <?rfc strict="yes" ?> <?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" docName="draft-ietf-kitten-sasl-saml-02.txt" category="std">
<front>
<title abbrev="A SASL & GSS-API Mechanism for SAML">
A SASL and GSS-API Mechanism for SAML
</title>
<author fullname="Klaas Wierenga" initials="K." surname="Wierenga">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Haarlerbergweg 13-19</street>
<city>Amsterdam</city>
<code>1101 CH</code>
<region>Noord-Holland</region>
<country>Netherlands</country>
</postal>
<phone>+31 20 357 1752</phone>
<email>klaas@cisco.com</email>
</address>
</author>
<author fullname="Eliot Lear" initials="E." surname="Lear">
<organization>Cisco Systems GmbH</organization>
<address>
<postal>
<street>Richtistrasse 7</street>
<city>Wallisellen</city>
<code>CH-8304</code>
<region>ZH</region>
<country>Switzerland</country>
</postal>
<phone>+41 44 878 9200</phone>
<email>lear@cisco.com</email>
</address>
</author>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization>SJD AB</organization>
<address>
<postal>
<street>Hagagatan 24</street>
<city>Stockholm</city>
<code>113 47</code>
<country>SE</country>
</postal>
<email>simon@josefsson.org</email>
<uri>http://josefsson.org/</uri>
</address>
</author>
<date year="2011"/>
<abstract>
<t>
Security Assertion Markup Language (SAML) has found its
usage on the Internet for Web Single Sign-On. 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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Security Assertion Markup Language (SAML) 2.0 <xref target="OASIS.saml-core-2.0-os"/> is a modular
specification that provides 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 <xref target="OASIS.saml-bindings-2.0-os"/>,
and interoperability profiles <xref target="OASIS.saml-profiles-2.0-os"/> designed for different
use cases.
</t>
<t>
Simple Authentication and Security Layer (SASL) <xref target="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
<xref target="RFC3501">IMAP</xref> and <xref target="RFC3920">XMPP</xref>. The effect is to make
modular authentication, so that newer authentication mechanisms can be added as needed. This memo
specifies just such a mechanism.
</t>
<t>
The <xref target="RFC2743">Generic Security Service Application
Program Interface (GSS-API)</xref> 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 <xref target="RFC5801">GS2</xref>. This means that
this document defines both a SASL mechanism and a GSS-API mechanism.
We want to point out that the GSS-API interface is optional for SASL
implementers, and the GSS-API considerations can be avoided in
environments that uses SASL directly without GSS-API.
</t>
<t> As currently envisioned, this mechanism
is to allow the interworking between SASL and SAML in order to assert
identity and other attributes to relying parties. As such, while servers
(as relying parties) will advertise SASL mechanisms (including SAML),
clients will select
the SAML SASL mechanism as their SASL mechanism of choice. </t>
<t>The SAML mechanism described in this memo aims to re-use the
available SAML deployment to a maximum extent and therefore does not
establish a separate authentication, integrity and confidentiality
mechanism. The mechanisms assumes a security layer, such as Transport
Layer Security (TLS), to protect against some attacks.</t>
<t><xref target="overview"/> describes the interworking between SAML and
SASL: this document requires enhancements to the Relying Party and to
the Client (as the two SASL communication end points) but no changes to
the SAML Identity Provider are necessary. To accomplish this goal some
indirect messaging is tunneled within SASL, and some use of external
methods is made.</t>
<t> <figure anchor="overview" title="Interworking
Architecture"> <artwork><![CDATA[
+-----------+
| |
>| Relying |
/ | Party |
// | |
// +-----------+
SAML/ // ^
HTTPs // +--|--+
// | S| |
/ S | A| |
// A | M| |
// S | L| |
// L | | |
// | | |
</ +--|--+
+------------+ v
| | +----------+
| SAML | HTTPs | |
| Identity |<--------------->| Client |
| Provider | | |
+------------+ +----------+
]]></artwork> </figure> </t>
</section>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>The reader is assumed to be familiar with the terms used in the SAML
2.0 specification.</t>
</section>
<section title="Applicability for non-HTTP Use Cases">
<t>While SAML
itself is merely a markup language, its common use case these days is
with HTTP. What follows is a typical flow: </t>
<t>
<list style="numbers">
<t>The browser requests a resource of a Relying Party (RP) (via an HTTP request).</t>
<t>The RP sends an HTTP
redirect as described in Section 10.3 of <xref target="RFC2616" /> to
the browser to the Identity Provider (IdP) or an IdP discovery service with
an authentication request that contains the name of resource being
requested, some sort of a cookie and a return URL, </t>
<t> The user
authenticates to the IdP and perhaps authorizes the authentication to
the service provider. </t>
<t> In its authentication response, the IdP
redirects 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. </t>
<t> RP now has sufficient identity
information to approve access to the resource or not, and acts
accordingly. The authentication is concluded. </t>
</list> </t>
<t>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 must 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. This will be discussed below.
The steps are shown from below:</t>
<t>
<list style="numbers">
<t> The Relying Party or SASL server advertises support for the SASL
SAML20 mechanism to the client </t>
<t> The client initiates a SASL authentication with SAML20 and sends a domain</t>
<t>The Relying Party transmits an authentication request encoded using a Universal Resource
Identifier (URI) as described in RFC 3986 <xref target="RFC3986"/> and a redirect to the IdP
corresponding to the domain</t>
<t> The SASL client now sends an empty response, as authentication continues via the normal SAML
flow. </t>
<t> At this point the SASL client MUST construct a URL containing the content received in the
previous message from the RP. This URL is transmitted to the IdP either by the SASL client
application or an appropriate handler, such as a browser.</t>
<t>Next the client authenticates to the IdP. The manner in which the end user is authenticated to
the IdP and any policies surrounding such authentication is out of scope for SAML and hence for
this draft. This step happens out of band from SASL.</t>
<t>The IdP will convey information about the success or failure of the authentication back to the
the RP in the form of an Authentication Statement or failure, using a indirect response via the
client browser or the handler. This step happens out of band from SASL.</t>
<t> The SASL Server sends an appropriate SASL response to the client, along with an
optional list of attributes</t>
</list> </t>
<t>Please note: What is described here is the case in which the client has not previously
authenticated. If the client can handle SAML internally 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.
</t>
<t> With all of this in mind, the flow appears as follows: </t>
<t>
<figure anchor="flow" title="Authentication flow">
<artwork><![CDATA[
SASL Serv. Client IdP
|>-----(1)----->| | Advertisement
| | |
|<-----(2)-----<| | Initiation
| | |
|>-----(3)----->| | Authentication Request
| | |
|<-----(4)-----<| | Empty Response
| | |
| |< - - - - - ->| Client<>IDP
| | | Authentication
| | |
|<- - - - - - - - - - - - - - -| Authentication Statement
| | |
|>-----(6)----->| | SASL completion with
| | | status
| | |
----- = SASL
- - - = HTTP or HTTPs (external to SASL)
]]>
</artwork>
</figure> </t>
</section>
<section title="SAML SASL Mechanism Specification">
<t>
Based on the previous figure, the following operations are performed
with the SAML SASL mechanism.
</t>
<t>
The mechanism is "client first" as discussed in section 3 of <xref
target="RFC4422"/> which means that the initial server challenge
will be empty if the protocol does not support an initial client
response.
</t>
<section title="Advertisement" anchor="advertisement">
<t>
To advertise
that a server supports SAML 2.0, during application session initiation,
it displays the name "SAML20" in the list of supported SASL
mechanisms.
</t>
</section>
<section title="Initiation" anchor="initiation">
<t>
A client initiates a "SAML20" authentication with SASL by sending the
GS2 header followed by the authentication identifier. The GS2 header carries the optional
authorization identity.
</t>
<figure>
<artwork>
<![CDATA[
initial-response = gs2-header Idp-Identifier
IdP-Identifier = domain ; domain name with corresponding IdP
]]>
</artwork>
</figure>
<t>
The "gs2-header" is specified in <xref target="RFC5801"/>, and it is used
as follows. The "gs2-nonstd-flag" MUST NOT be present. Regarding
the channel binding "gs2-cb-flag" field, see Section 5. The "gs2-
authzid" carries the optional authorization identity.
Domain name is specified in <xref target="RFC1035"/>.
</t>
</section>
<section title="Server Redirect" anchor="1stresponse">
<t>
The SASL Server transmits a URI to the IdP that corresponds to the domain the user provided,
with a SAML authentication request in the form of a SAML assertion as one of the parameters.
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</t>
<figure>
<artwork>
<![CDATA[
redirect-url = URI
]]>
</artwork>
</figure>
<t>
As before, URI is specified in <xref target="RFC3986"/>.
</t>
</section>
<section title="Client Empty Response and other" anchor="empty">
<t>
The SASL client hands
the URI it received from the server in the previous step to either a
browser or other appropriate handler to continue authentication
externally while sending an empty response to the SASL server.
The URI is encoded according to
Section 3.4 of the <xref target="OASIS.saml-bindings-2.0-os">SAML
bindings 2.0 specification</xref>.
</t>
<figure>
<artwork>
<![CDATA[
empty-response = ""
]]>
</artwork>
</figure>
</section>
<section title="Outcome and parameters" anchor="outcome">
<t>
The SAML authentication having completed externally, the SASL
server will transmit the outcome of the authentication exchange as
success or failure.
</t>
</section>
</section>
<section title="SAML GSS-API Mechanism Specification" anchor="gss-api">
<t>
This section and its sub-sections and all normative references of it
not referenced elsewhere in this document are INFORMATIONAL for SASL
implementors, but they are NORMATIVE for GSS-API implementors.
</t>
<t>
The SAML SASL mechanism is actually also a GSS-API mechanism. The
messages are the same, but
</t>
<t>
a) the GS2 header on the client's first
message and channel binding data is excluded when SAML is used as a
GSS-API mechanism, and
</t>
<t>
b) the RFC2743 section 3.1 initial context token header is prefixed to
the client's first authentication message (context token).
</t>
<t>
The GSS-API mechanism OID for SAML is 1.3.6.1.4.1.11591.4.8.
</t>
<t>
SAML20 security contexts always have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential
delegation, therefore SAML security contexts alway have the
deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
</t>
<t>
The SAML mechanism does not support per-message tokens or
GSS_Pseudo_random.
</t>
<t>
Note that the GSS-API mechanism MUST only be used by the client
when a secure channel with server authentication (e.g., TLS) is
available.
</t>
<section title="GSS-API Principal Name Types for SAML" anchor="gss-api-name-types">
<t>
SAML supports standard generic name syntaxes for acceptors such as
GSS_C_NT_HOSTBASED_SERVICE (see <xref target="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 <xref target="RFC2743"/>,
Section 4). The exported name token does, of course, conform to
<xref target="RFC2743"/>, Section 3.2.
</t>
</section>
</section>
<section title="Channel Binding" anchor="channel-binding">
<t>
The "gs2-cb-flag" MUST use "n" because channel binding data cannot
be integrity protected by the SAML negotiation. FIXME: Transfer
channel binding in SAML assertion?
</t>
</section>
<section title="Examples" anchor="examples">
<section title="XMPP" anchor="examples-xmpp">
<t> 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 connection to xmpp.example.com. The
authentication on the wire would then look something like the following: </t>
<t>Step 1: Client initiates stream to server: </t>
<figure><artwork>
<![CDATA[
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com' version='1.0'>
]]>
</artwork></figure>
<t>Step 2: Server responds with a stream tag sent to client: </t>
<figure><artwork>
<![CDATA[
<stream:stream
xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'
id='some_id' from='example.com' version='1.0'>
]]>
</artwork></figure>
<t>Step 3: Server informs client of available authentication
mechanisms:</t>
<figure><artwork>
<![CDATA[
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>SAML20</mechanism>
</mechanisms>
</stream:features>
]]>
</artwork></figure>
<t>Step 4: Client selects an authentication mechanism and provides the
initial client response containing the <xref target="RFC4648">BASE64</xref> encoded gs2-header and
domain: </t>
<figure><artwork>
<![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20'>
biwsZXhhbXBsZS5vcmc</auth>
]]>
</artwork></figure>
<t>The decoded string is: n,,example.org</t>
<t>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: </t>
<figure><artwork>
<![CDATA[
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=
]]>
</artwork></figure>
<t>The decoded challenge is:</t>
<figure><artwork>
<![CDATA[
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=
]]>
</artwork></figure>
<t>Where the decoded SAMLRequest looks like:</t>
<figure><artwork>
<![CDATA[
<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>
]]>
</artwork></figure>
<t>Step 5 (alt): Server returns error to client:</t>
<figure> <artwork>
<![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
]]>
</artwork></figure>
<t>Step 6: Client sends a BASE64 encoded empty response to the
challenge:</t>
<figure><artwork>
<![CDATA[
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
=
</response>
]]>
</artwork></figure>
<t>
[ The client now sends the URL to a browser for processing. The browser
engages in a normal SAML authentication flow (external to SASL),
like redirection to the Identity Provider (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 who
sends the AuthN response to the server, containing the subject-identifier as
an attribute. If the AuthN response doesn't contain the JID, the server maps
the subject-identifier received from the IdP to a JID]
</t>
<t>Step 7: Server informs client of successful authentication: </t>
<figure><artwork>
<![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
]]>
</artwork></figure>
<t>Step 7 (alt): Server informs client of failed authentication: </t>
<figure><artwork>
<![CDATA[
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
]]>
</artwork></figure>
<t>Step 8: Client initiates a new stream to server: </t>
<figure><artwork>
<![CDATA[
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com' version='1.0'>
]]>
</artwork></figure>
<t>Step 9: Server responds by sending a stream header to client along
with any additional features (or an empty features element): </t>
<figure><artwork>
<![CDATA[
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345' from='example.com' version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>
]]>
</artwork></figure>
<t>Step 10: Client binds a resource:</t>
<figure><artwork>
<![CDATA[
<iq type='set' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
</iq>
]]>
</artwork></figure>
<t>Step 11: Server informs client of successful resource binding:</t>
<figure><artwork>
<![CDATA[
<iq type='result' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>
]]>
</artwork></figure>
<t>Please note: line breaks were added to the
base64 for clarity.</t>
</section>
<section title="IMAP" anchor="examples-imap">
<t>The following 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.</t>
<figure><artwork>
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: + 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=
C:
S: . OK Success (tls protection)
</artwork></figure>
</section>
</section>
<section title="Security Considerations">
<t>
This section will address only security considerations associated
with the use of SAML with SASL applications. For considerations
relating to SAML in general, the reader is referred to the SAML
specification and to other literature. Similarly, for general SASL
Security Considerations, the reader is referred to that
specification.
</t>
<section title="Man in the middle and Tunneling Attacks">
<t>
This mechanism is vulnerable to man in the middle and tunneling
attacks unless a client always verify the server identity before
proceeding with authentication. Typically TLS is used to provide a
secure channel with server authentication.
</t>
</section>
<section title="Binding SAML subject identifiers to Authorization Identities">
<t>
As specified in <xref target="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 typical part of SAML trust establishment between RP's and IdP.
</t>
</section>
<section title="User Privacy">
<t>
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 servers should be aware that
SAML IdPs will track - to some extent - user access to
their services.
</t>
</section>
<section title="Collusion between RPs">
<t>
It is possible for RPs to link data that they have collected on you.
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 opaque identifier. This way the RP would never see the
actual user identifier, but a randomly generated identifier. This is
an option the user has to understand and decide to use if the IdP is
supporting it.
</t>
</section>
</section>
<section title="IANA Considerations"> <t> The IANA is requested to
register the following
SASL profile: </t> <t/> <t>SASL mechanism profile: SAML20</t>
<t>Security
Considerations: See this document</t> <t>Published Specification: See
this document</t> <t>For further information: Contact the authors of
this document.</t> <t>Owner/Change controller: the IETF</t> <t>Note:
None</t>
</section>
</middle>
<back>
<references title="Normative References"> &RFC1035; &RFC2119;
&RFC2616; &RFC2743; &RFC3986;
&RFC4422; &RFC4648; &RFC5801; &SAML20; &SAML20BIND; &SAML20PROF;
</references>
<references title="Informative References">
&RFC3501;
&RFC3920;
</references>
<section title="Acknowledgments">
<t>
The authors would like to thank Scott Cantor, Joe Hildebrand, Josh Howlett, Leif Johansson,
Diego Lopez, Hank Mauldin, RL 'Bob' Morgan, Stefan Plug and Hannes Tschofenig for their review
and contributions.
</t>
</section>
<section title="Changes"> <t>This section to be removed
prior to publication.</t> <t>
<list style="symbols">
<t>02 Changed IdP URI to domain per Joe Hildebrand, fixed some typos</t>
<t>00 WG -00 draft. Updates GSS-API section, some fixes per Scott Cantor</t>
<t>01 Added authorization identity, added GSS-API specifics, added client supplied IdP</t>
<t>00 Initial Revision. </t> </list> </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:26:39 |