Presence and IntComm WG

["Callahan, Tim" <>]

Here's a note that Jorj forwarded for today's discussion(Shib/SASL). We 
briefly discussed this message on our last call. It would be very nice if we 
could help with the counter-proposal (volunteers?)
-Tim

Begin forwarded message:

> From: 
> 
> Date: December 15, 2009 8:46:59 PM EST
> To: Jorj Bauer 
> <>
> Subject: XMPP + Shibboleth
> 
> The Shib team exchanged some email on this topic, and spent some time on 
> our regular conference call discussing this topic. Down below, I've pasted 
> in a proposal from Scott Cantor, describing one way to integrate Shib and 
> SASL.
> 
> Scott wrote this note, tho, in response to someone who had written up a 
> proposal for combining Shib + SASL which involved using a web browser... 
> both Scott and I disagree rather strongly with that approach. But, there 
> seems to be a set of people who feel that's the way to proceed.
> 
> I think the next step is to find someone who's willing to write up a 
> counter-proposal to the browser-based approach.
> 
> During the Shib call, someone mentioned that WAVE uses XMPP just as a 
> transport over SSL/TLS; it doesn't use XMPP security. So, even if we were 
> able to integrate Shib + SASL, the value wouldn't flow up to the WAVE 
> layer. Is that your understanding ?
> 
> Thoughts on next steps ?
> 
> 
> At 10:21 PM -0500 12/13/09, Scott Cantor wrote:
>> Another general question is why it's a good idea to try to tie this 
>> to a web browser when it's not a browser use case. This is a point of 
>> contention, as I know some people think this is a practical approach, 
>> but the feedback I get is that I'm not in a small minority when I 
>> suggest this is kludgy to many users. It also seems to complicate your 
>> mechanism quite a bit.
>> 
>> The usual argument for this seems to be to allow people to reuse 
>> their existing web UI for login, but SOAP provides a pretty good 
>> framework for
>> client->server authentication with extensible types of credentials 
>> client->(in fact
>> that's probably about all it's useful for).
>> 
>> So, my counterproposal (taking this with a grain of salt in that I'm 
>> not that familiar with SASL, so let me know where I'm off base):
>> 
>> As I understand it, with SASL you can produce a "challenge" of some 
>> sort to the client, and then the client can produce a response to the 
>> challenge to complete the handshake. So my suggestion is to use the 
>> challenge to pass an AuthnRequest from the SASL server to the client 
>> so the client can relay it to its chosen IdP. It may make sense to 
>> base64-encode the message, or leave it as XML. I'm not sure what's 
>> appropriate.
>> 
>> Your profile seems to include the notion of web-based discovery, but 
>> with a client like this, your biggest win is that the client should 
>> know the IdP(s) it can use. So you don't do discovery, that's already 
>> handled. The SASL server can include a Scoping element with an 
>> IdPList inside the AuthnRequest if it wants to filter the IdPs the client 
>> can use.
>> 
>> The client then delivers the request to the IdP it chooses using 
>> SOAP, and using either a simple authentication via HTTP or TLS, or a 
>> more complex mechanism using WS-Security. The response is then issued back 
>> to the client.
>> It seems me that the "mechanism" code in the client could be 
>> responsible for carrying out all of the interactions with the IdP, 
>> and you have the usual problem of "exposing" the user's credentials 
>> in some fashion to the mechanism, which doesn't seem very different 
>> than what other SASL mechanisms would need now.
>> 
>> Then you complete the SASL handshake by handing the Response back to 
>> the SASL server from the client and you're done.
>> 
>> Note that a benefit of this model is that you can implement 
>> server-side SASL clients that use SAML assertions they acquire via 
>> web SSO to authenticate to the IdP (delegation).


No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.716 / Virus Database: 270.14.110/2568 - Release Date: 12/17/09 
03:30:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 9.0.725 / Virus Database: 270.14.129/2605 - Release Date: 01/07/10 
02:35:00