[Standards-JIG] authorization: the next generation

David Waite dwaite at gmail.com
Wed Jul 14 17:42:50 UTC 2004

On Wed, 14 Jul 2004 09:49:35 -0600, Peter Saint-Andre
<stpeter at jabber.org> wrote:

<significant snippage>

> 6. Shibboleth Attribute Authority consults Attribute Release Policies to
> determine XMPP server's right to access attributes for user, then delivers
> list of attributes to XMPP server over encrypted channel (TLS/SSL).
> 7. User requests to join chatroom on remote XMPP-based conference
> service (note that this request is routed first through user's XMPP
> server, then to the XMPP server hosting the service, then to the
> conference service itself).
> 8. Conference service queries XMPP server for attributes.
> 9. XMPP server provides signed attribute bundle to conference service.

So in this scheme, I only expose one SAML assertion to the XMPP
server, for querying by any service which wants to use it for
authentication? It seems like the attribute authority should be making
the decision whether to trust a conference room or whatever with
receiving a copy of user attributes, and for determining which
attributes should be given.

Also, I'm concerned about transmitting the assertion in-band, as there
is no confidentiality guarantee hop-to-hop for XMPP. Plus a bit of FUD
- I am concerned that the multiple internal and external hops involved
will go through a component which does not pay attention to things
like XML Infoset fidelity, modifying the assertion in a way which
makes signature verification impossible.

<more snippsage to model #2>

> 4. User requests to join chatroom on remote XMPP-based conference
> service.
> 5. Conference service queries XMPP server for handle.
> 6. XMPP server provides handle to conference service (based on
> server-defined or user-defined access policy).
> 7. Conference service requests attributes directly from Attribute
> Authority.
> 8. Attribute Authority provides relevant attributes to conference service.

Contacting directly (using the SAML-specified SOAP/HTTP profile) seems
the best solution.

This does expose the weakness of XMPP for authentication - you can
have this mutual trusted party mechanism for finding out if a person
is authorized, but you have to trust servers completely to handle
their own domains, and there is no end-to-end encryption mechanism
standardized on to allow confidentiality or direct recipient

In an ideal world, the user would be retrieving and using this request
themselves via holder-of-key. That puts a very heavy implementation
requirement on clients, however.

> 9. Conference service makes access decision and returns error or
> success to user.
> Pros:
>   a. Only the relevant attributes are provided to service, not the
>      full bundle -- provides better respect for privacy.
>   b. Requires only communication of handle over XMPP (thus simplifying
>      the XMPP protocol development).
> Cons:
>   a. Forces Shibboleth communications onto XMPP services, which as
>      noted are not generally as smart as XMPP servers and which also
>      tend to be written in a greater diversity of languages (Python,
>      Perl, etc.).

The conference service does not need to be the policy decision point -
it can offload some of this work onto another service, via a trusted
connection. So it could be written in a language which does not
support shibboleth, calling a java or C piece which does via SSL.

-David Waite

More information about the Standards mailing list