Presence and IntComm WG

[Tom Scavo <>]

FYI

----------------------------------------------------------------------

A SASL Mechanism for SAML Enhanced Clients
Scott Cantor (ed), IETF Internet Draft

An initial level -00 IETF Standards Track Internet Draft has been
published for "A SASL Mechanism for SAML Enhanced Clients."  This
document was adapted largely from an earlier specification titled
"A SASL Mechanism for SAML," edited by Klaas Wierenga and Eliot Lear.

From the 'Introduction': "Security Assertion Markup Language (SAML)
is a multi-party protocol (or rather set of protocols) that provides
a means for a user to offer identity assertions and other attributes
to a relying party (RP) via the help of an identity provider (IdP).
Simple Authentication and Security Layer (SASL), defined in IETF RFC
4422, 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.

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

Based upon the worked example, the following operations are performed
with the SAML SASL Mechanism Specification: "(1) Advertisement: 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. (2) Initiation: A client initiates a 'SAML20'
authentication (3) Server Redirect: The SASL Server transmits a redirect
to the URI of a discovery service or an IdP that is configured at the
server, with a SAML authentication request in the form of a SAML
assertion as one of the parameters. (4) Client Empty Response and other:
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
SAML bindings 2.0 specification (SAML Core, OASIS Standard). (5) Outcome
and parameters: The SAML authentication having completed externally,
the SASL server will transmit the outcome..."

http://xml.coverpages.org/draft-cantor-ietf-sasl-saml-ec-00.txt
See also SAML references: http://xml.coverpages.org/saml.html

----------------------------------------------------------------------