Presence and IntComm WG

[Peter Saint-Andre <>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tom,

Because of preparations for the IETF meeting next week, I probably won't
have time to reply further in this thread until the week of November 16.
However, I'll be interested to pick it up then. :)

Peter

On 11/1/09 9:22 AM, Tom Scavo wrote:
> On Wed, Oct 28, 2009 at 3:19 PM, Peter Saint-Andre 
> <>
>  wrote:
>> On 10/28/09 2:01 PM, Tom Scavo wrote:
>>> You're looking for a way to do back-channel
>>> (server-to-server) access control, that is, an XMPP server calls out
>>> to another XMPP server for an access control decision (or attributes
>>> that can be used to make an access control decision).
>> I think the communication could happen over HTTP instead of XMPP. For
>> example, using my XMPP client I try to access a protected resource (say,
>> a chatroom) at a remote XMPP service. The remote service discovers the
>> canonical attribute authority for the domain of my local XMPP service
> 
> So-called Identity Provider (IdP) Discovery is a major hurdle to
> overcome. I'll come back to this.
> 
>> and sends a normal Shib request to that AA using HTTP.
> 
> Not Shibboleth, but a standard <samlp:AttributeQuery>, yes.
> 
>> Yes, the remote
>> XMPP service would need to have the smarts to discover my AA and send it
>> a request over HTTP, but I'm assuming we have code for that
> 
> We do? My previous project (GridShib) implemented such code for SAML
> V1.1 about four years ago but the code was tightly bound to the Globus
> Toolkit and was never completely set free. Numerous projects have
> considered this use case since then, but I don't know of any code that
> could be leveraged in this context. Maybe the Shintau project has
> something by now, I don't know.
> 
>> and the
>> software running at the remote XMPP service would need to install some
>> kind of shim to use the Shib code.
> 
> Are you referring to the SAML relying party (i.e., the Service
> Provider, or SP)? No, Shibboleth is not relevant to the use case you
> describe. Shibboleth is an implementation of the SAML Web Browser SSO
> Profile. If your use case does not involve a web browser, then
> Shibboleth is almost certainly not applicable.
> 
> Best case scenario, let's suppose we can find client software that
> implements the <samlp:AttributeQuery> protocol. To solve your use
> case, we would need to do the following:
> 
> 1) Define a profile that addresses the IdP Discovery problem,
> specifies the end-user identifier used in the query, and gives an
> attribute profile that satisfies the attribute requirements.
> 
> 2) On the IdP side, provide a plugin for one or more target
> implementations (such as Shibboleth) that realize the profile.
> 
> 3) Deploy the plugin far and wide.
> 
> Deja vu :-) We've done this (or tried to do this) in the X.509 space.
> In that case, the identifier was the subject name of an end user's
> X.509 certificate, which assumes the existence of an X.509 PKI that
> extends to the IdP. Unfortunately, this turned out be a non-starter.
> 
> A crucial question is: what identifier will be used in the query?
> Clearly, the IdP needs to be able to map that identifier to a unique
> user in its security domain. It may not be obvious, however, that a
> typical campus IdP will not release attributes in this case, since
> there is no indication in the query that the user is actually involved
> in the transaction. The risk is too great that the SP is phishing for
> attributes.
> 
> Is there a better solution than SAML attribute query? I don't know. I
> don't understand XMPP well enough to offer an alternative. From past
> experience, I would focus on the client, looking for ways to push the
> attributes to the XMPP server, thereby avoiding attribute query
> altogether. I know, you don't want to modify the client, but what can
> I say.
> 
> Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrvIC4ACgkQNL8k5A2w/vwf6wCg2WfMvxI5GoCROUUHqgUk1VNJ
xD0AoLsOXof/omW7ngauSC9Tb8Eq3wfa
=lBgN
-----END PGP SIGNATURE-----