Presence and IntComm WG

[Tom Scavo <>]

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