Subject: Review of draft-wierenga-ietf-sasl-saml-01.txt:

From: Alexey Melnikov <[email-masked]>
Date: Sun, 25 Jul 2010 16:16:16 +0200

The document mostly looks good to me. I have some major architectural 
issue and a couple of smaller ones.

1.  Introduction

   The Generic Security Service Application Program Interface (GSS-API)
   [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

s/OpenID/SAML

   bridge between SASL and the GSS-API called GS2 [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.

3.  Applicability for non-HTTP Use Cases

   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:

   1.  The Relying Party or SASL server advertises support for the SASL
       SAML20 mechanism to the client

   2.  The client initiates a SASL authentication with SAML20 and sends
       an IdP identity

   3.  The Relying Party transmits an authentication request encoded
       using a Universal Resource Identifier (URI) as described in RFC
       3986 [RFC3986] and a redirect to the IdP

   4.  The SASL client now sends an empty response, as authentication
       continues via the normal SAML flow.

This might be eliminated (see below).

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

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

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

Why does IdP need to talk to RP (SASL server)? How would IdP identify 
the SASL session to the SASL server?
Can this be done through the client? The latter would be a natural data 
flow for SASL.

(This will also affect diagrams and examples, if changed.)

   8.  The SASL Server sends an appropriate SASL response to the client,
       along with an optional list of attributes

4.3.  Server Redirect

   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.

I assume that the redirect is an HTTP URI?
For interoperability this needs to be spelled out explicitly.

7.  Example

   The decoded challenge is:

  HTTP/1.1 302 Object Moved Date: 22 Oct 2009 07:00:49 GMT Location:
  https://saml.example.org/SAML/Browser?SAMLRequest=

Is line wrapping correct here?

  PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOl
  NBTUw6Mi4wOnByb3RvY29sIg0KICAgIElEPSJfYmVjNDI0ZmE1MTAzNDI4OTA5YTMwZmYx
  ZTMxMTY4MzI3Zjc5NDc0OTg0IiBWZXJzaW9uPSIyLjAiDQogICAgSXNzdWVJbnN0YW50PS

---

From: "Scott Cantor" <[email-masked]>
Date: Sun, 25 Jul 2010 15:53:43 -0400

> the SASL session to the SASL server?

The IdP/RP communication is a result of using a particular SAML binding. I
don't think this mechanism actually cares which binding is used between the
web client anf the RP. It could be artifact, which results in a callback, or
POST, which doesn't.

> Can this be done through the client? The latter would be a natural data

That's why I submitted an alternative mechanism, because I prefer that to
using a web browser. The client can't do it here, because the SASL client
has passed control to the browser, and the SAML response is handled by the
browser, not the SASL client. That takes place via web, and the SASL server
has to coordinate that with the web server.

> For interoperability this needs to be spelled out explicitly.

The language is off. It's not a SAML assertion, it's a SAML AuthnRequest.
The formal specification is the HTTP-Redirect binding.

-- Scott