Subject: difference between sasl-saml and sasl-saml-ec drafts (was: Re: Review of draft-wierenga-ietf-sasl-saml-01.txt:)

From: Klaas Wierenga <[email-masked]>
Date: Tue, 03 Aug 2010 12:15:38 +0200

Hi,

At the KITTEN WG meeting I noticed that below answer from Scott was not 
completely clear to everyone, so hear an attempt to give a bit more clarity:

SASL-SAML:

Here the assumption is that the SASL-client receives a SAML 
authentication requests and hands that to a browser that deals with the 
SAML authentication, the SASL client is NOT part of the authentication 
exchange anymore, apart from receiving the final ok from the SASL server 
(hence the empty reply to the challenge). The  result of the 
authentication at the SAML IdP is communicated to the SASL-server 
out-of-band.

+ minimal change to SASL client (just fire up a browser with the right URL)
+ no extra application that is used to enter authentication credentials
+ Doesn't need to touch the IdP

- rely on external program
- 'strange' user experience

SASL-SAML-EC

Here the assumption is that the SASL-client is ALSO a SAML client. So 
the SASL client receives the SAML authentication request and performs 
all the SAML magic itself, the Authentication Statement from the SASL 
server is send as the SASL response to the SASL servers challenge. In 
order to do so the SASL client must implement the SAML Enhanced Client 
or Proxy profile and the SAML IdP must support that.

+ 'cleaner' solution
+ doesn't require external program

- yet another piece of software to trust with user credentials
- IdP needs to support the ECP profile
- SASL client needs to implement the ECP profile

One way of merging these two proposals would be if in the SASL-SAML case 
the control can be handed back to the SASL client. Options like having 
the client listen on a port on localhost (essentially becoming a 
webserver) to which the browser is redirected back after authentication 
or serving out a MIME-type like x-sasl-jabber for which the SASL client 
is the handler come to mind, but they don't give me the warm fuzzy 
feeling yet...
It would however allow the SASL exchange be the same for both 
mechanisms, rather than out-of-band for one and in-band for the other, 
so ideas in that space are welcomed.

Hope this helps!

Klaas

On 7/25/10 9:53 PM, Scott Cantor wrote:
>> Why does IdP need to talk to RP (SASL server)? How would IdP identify
>> 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
>> flow for SASL.
>
> 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.
>
>> 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.
>
> The language is off. It's not a SAML assertion, it's a SAML AuthnRequest.
> The formal specification is the HTTP-Redirect binding.
>
> -- Scott
>
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 3 Aug 2010 11:14:53 -0400

Couple of small corrections:

> SASL-SAML-EC
> 
> Here the assumption is that the SASL-client is ALSO a SAML client.

Technically "SAML-aware client", meaning it doesn't have to handle SAML
assertions or know how to parse any SAML messages, but plays a role in the
exchange. It's a SOAP intermediary, actually, not a SAML one.

> So the SASL client receives the SAML authentication request and performs
> server is send as the SASL response to the SASL servers challenge.

s/from the SASL server/from the IdP

-- Scott