One document matched: draft-wierenga-ietf-sasl-saml-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[ <!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 RFC3986 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.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">
<!ENTITY GS2 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sasl-gs2.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-wierenga-ietf-sasl-saml-01.txt"
category="std">
<front>
<title abbrev="A SASL Mechanism for SAML">
A SASL 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>
<date year="2010"/>
<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 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 IMAP, POP and
XMPP. 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 Generic Security Service Application Program Interface (GSS-API) <xref target="RFC2743"/>
provides a framework for applications to support multiple
authentication mechanisms through a unified interface. This document
defines a pure SASL mechanism for OpenID, but it conforms to the new
bridge between SASL and the GSS-API called GS2 <xref target="I-D.ietf-sasl-gs2"/>.
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. It is anticipated that existing security
layers, such as Transport Layer Security (TLS), will continued to be
used.</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 an IdP identity</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</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>
<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 = Identifier ; IdP identifier
Identifier = URI ; IdP URI
]]>
</artwork>
</figure>
<t>
The "gs2-header" is specified in <xref target="I-D.ietf-sasl-gs2"/>, 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.
URI is specified in <xref target="RFC3986"/>.
</t>
</section>
<section title="Server Redirect" anchor="1stresponse">
<t>
The SASL Server transmits a redirect to the IdP that the user provided,
with a SAML authentication request
in the form of a SAML assertion as one of the parameters.</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>
</section>
<section title="Outcome and parameters" anchor="outcome">
<t>
The SAML authentication having completed externally, the SASL server will
transmit the outcome
</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 XXXXX
</t>
<t>
SAML security contexts always have the mutual_state flag
(GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential
delegation, therefore SCRAM 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>
<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.
GSS-API name attributes may be defined in the future to hold the
SAML Subject Identifier.
</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.
</t>
</section>
<section title="Example" anchor="example">
<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: </t>
<figure><artwork>
<![CDATA[
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20'>
https://saml.example.org</auth>
]]>
</artwork></figure>
<t>Step 5: Server sends a <xref target="RFC4648">BASE64</xref> encoded challenge to client
in the form
of an HTTP Redirect to the SAML IdP with the SAML
Authentication Request as specified in the redirection url: </t>
<figure><artwork>
<![CDATA[
SFRUUC8xLjEgMzAyIE9iamVjdCBNb3ZlZCBEYXRlOiAyMiBPY3QgMjAwOSAwNzowMDo0OS
BHTVQgTG9jYXRpb246DQpodHRwczovL3NhbWwuZXhhbXBsZS5vcmcvU0FNTC9Ccm93c2Vy
P1NBTUxSZXF1ZXN0PQ0KUEhOaGJXeHdPa0YxZEdodVVtVnhkV1Z6ZENCNGJXeHVjenB6WV
cxc2NEMGlkWEp1T205aGMybHpPbTVoYldWek9uUmpPbE5CVFV3Ng0KTWk0d09uQnliM1J2
WTI5c0lnMEtJQ0FnSUVsRVBTSmZZbVZqTkRJMFptRTFNVEF6TkRJNE9UQTVZVE13Wm1ZeF
pUTXhNVFk0TXpJMw0KWmpjNU5EYzBPVGcwSWlCV1pYSnphVzl1UFNJeUxqQWlEUW9nSUNB
Z1NYTnpkV1ZKYm5OMFlXNTBQU0l5TURBM0xURXlMVEV3VkRFeA0KT2pNNU9qTTBXaUlnUm
05eVkyVkJkWFJvYmowaVptRnNjMlVpRFFvZ0lDQWdTWE5RWVhOemFYWmxQU0ptWVd4elpT
SU5DaUFnSUNCUQ0KY205MGIyTnZiRUpwYm1ScGJtYzlJblZ5YmpwdllYTnBjenB1WVcxbG
N6cDBZenBUUVUxTU9qSXVNRHBpYVc1a2FXNW5jenBJVkZSUQ0KTFZCUFUxUWlEUW9nSUNB
Z1FYTnpaWEowYVc5dVEyOXVjM1Z0WlhKVFpYSjJhV05sVlZKTVBRMEtJQ0FnSUNBZ0lDQW
lhSFIwY0hNNg0KTHk5NGJYQndMbVY0WVcxd2JHVXVZMjl0TDFOQlRVd3ZRWE56WlhKMGFX
OXVRMjl1YzNWdFpYSlRaWEoyYVdObElqNE5DaUE4YzJGdA0KYkRwSmMzTjFaWElnZUcxc2
JuTTZjMkZ0YkQwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09tRnpj
MlZ5ZEdsdg0KYmlJK0RRb2dJQ0FnSUdoMGRIQnpPaTh2ZUcxd2NDNWxlR0Z0Y0d4bExtTn
ZiUTBLSUR3dmMyRnRiRHBKYzNOMVpYSStEUW9nUEhOaA0KYld4d09rNWhiV1ZKUkZCdmJH
bGplU0I0Yld4dWN6cHpZVzFzY0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVX
c2TWk0dw0KT25CeWIzUnZZMjlzSWcwS0lDQWdJQ0JHYjNKdFlYUTlJblZ5YmpwdllYTnBj
enB1WVcxbGN6cDBZenBUUVUxTU9qSXVNRHB1WVcxbA0KYVdRdFptOXliV0YwT25CbGNuTn
BjM1JsYm5RaURRb2dJQ0FnSUZOUVRtRnRaVkYxWVd4cFptbGxjajBpZUcxd2NDNWxlR0Z0
Y0d4bA0KTG1OdmJTSWdRV3hzYjNkRGNtVmhkR1U5SW5SeWRXVWlJQzgrRFFvZ1BITmhiV3
h3T2xKbGNYVmxjM1JsWkVGMWRHaHVRMjl1ZEdWNA0KZEEwS0lDQWdJQ0I0Yld4dWN6cHpZ
VzFzY0QwaWRYSnVPbTloYzJsek9tNWhiV1Z6T25Sak9sTkJUVXc2TWk0d09uQnliM1J2WT
I5cw0KSWlBTkNpQWdJQ0FnSUNBZ1EyOXRjR0Z5YVhOdmJqMGlaWGhoWTNRaVBnMEtJQ0E4
YzJGdGJEcEJkWFJvYmtOdmJuUmxlSFJEYkdGeg0KYzFKbFpnMEtJQ0FnSUNBZ2VHMXNibk
02YzJGdGJEMGlkWEp1T205aGMybHpPbTVoYldWek9uUmpPbE5CVFV3Nk1pNHdPbUZ6YzJW
eQ0KZEdsdmJpSStEUW9nb0NBZ0lDQjFjbTQ2YjJGemFYTTZibUZ0WlhNNmRHTTZVMEZOVE
RveUxqQTZZV002WTJ4aGMzTmxjenBRWVhOeg0KZDI5eVpGQnliM1JsWTNSbFpGUnlZVzV6
Y0c5eWRBMEtJQ0E4TDNOaGJXdzZRWFYwYUc1RGIyNTBaWGgwUTJ4aGMzTlNaV1krRFFvZw
0KUEM5ellXMXNjRHBTWlhGMVpYTjBaV1JCZFhSb2JrTnZiblJsZUhRK0lBMEtQQzl6WVcx
c2NEcEJkWFJvYmxKbGNYVmxjM1Er
]]>
</artwork></figure>
<t>The decoded challenge is:</t>
<figure><artwork>
<![CDATA[
HTTP/1.1 302 Object Moved Date: 22 Oct 2009 07:00:49 GMT Location:
https://saml.example.org/SAML/Browser?SAMLRequest=
PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OTA5YTMwZmYx
ZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogICAgSXNzdWVJbnN0YW50PS
IyMDA3LTEyLTEwVDExOjM5OjM0WiIgRm9yY2VBdXRobj0iZmFsc2UiDQogICAgSXNQYXNz
aXZlPSJmYWxzZSINCiAgICBQcm90b2NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0Yz
pTQU1MOjIuMDpiaW5kaW5nczpIVFRQLVBPU1QiDQogICAgQXNzZXJ0aW9uQ29uc3VtZXJT
ZXJ2aWNlVVJMPQ0KICAgICAgICAiaHR0cHM6Ly94bXBwLmV4YW1wbGUuY29tL1NBTUwvQX
NzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIj4NCiA8c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0i
dXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogICAgIGh0dHBzOi
8veG1wcC5leGFtcGxlLmNvbQ0KIDwvc2FtbDpJc3N1ZXI+DQogPHNhbWxwOk5hbWVJRFBv
bGljeSB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY2
9sIg0KICAgICBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQt
Zm9ybWF0OnBlcnNpc3RlbnQiDQogICAgIFNQTmFtZVF1YWxpZmllcj0ieG1wcC5leGFtcG
xlLmNvbSIgQWxsb3dDcmVhdGU9InRydWUiIC8+DQogPHNhbWxwOlJlcXVlc3RlZEF1dGhu
Q29udGV4dA0KICAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi
4wOnByb3RvY29sIiANCiAgICAgICAgQ29tcGFyaXNvbj0iZXhhY3QiPg0KICA8c2FtbDpB
dXRobkNvbnRleHRDbGFzc1JlZg0KICAgICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbW
VzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+DQogoCAgICB1cm46b2FzaXM6bmFtZXM6dGM6
U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydA0KICA8L3
NhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+DQogPC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNv
bnRleHQ+IA0KPC9zYW1scDpBdXRoblJlcXVlc3Q+
]]>
</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="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="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"> &RFC2119;
&RFC2616; &RFC2743; &RFC3986;
&RFC4422; &RFC4648; &SAML20; &SAML20BIND; &SAML20PROF; &GS2;
</references>
<section title="Acknowledgments">
<t>
The authors would like to thank Scott Cantor, Joe Hildebrand, Josh Howlett, Leif Johansson,
Simon Josefsson, Diego Lopez, Hank Mauldin, RL 'Bob' Morgan 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>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 04:27:43 |