Shibboleth Developers

[Tom Scavo <>]

On Mon, 15 Nov 2004 13:24:15 -0500, Scott Cantor 
<>
 wrote:
> > Section 3.4.2:
> >
> > - May the IdP put a response to the browser/artifact profile in the
> > return parameter?
> 
> Technically, yes, but that would be a very bad idea and strongly worth
> discouraging.

Why?  That is, in fact, encouraged by the SAML2 IdP Discovery profile.

> > Yes, but that's not the only use of the cookie retrieval endpoint.  An
> > SP may want to hand an authn request to the WAYF and say "here, deal
> > with it, and I don't want to hear back from you."  Seems two types of
> > retrieval endpoints are needed: one interactive (if necessary) and one
> > not.
> 
> We already have that, that's what the WAYF does now. That's *not* this.

Yes, but what the WAYF does *now* determines what it is capable of
doing *later*.  Does the WAYF record the user's choice of IdP so that
the next time the client requests the SP, the redirect goes through to
the same IdP automatically?  Also, may that initial choice of IdP be
modified by the user in the future?  (I may regret asking these
questions, since I really don't know the answers. :)

> > - For a given user, for every SP there is a preferred IdP, that is,
> > there is a list of (SP, IdP) ordered pairs associated with each user.
> 
> Implementation detail, not part of any profile.

This could be considered an implementation detail, I suppose, unless
you wanted providers to interoperate. ;-)

> > - Every SP has access to its corresponding preferred IdP.
> 
> Don't know what you mean by "has access to". 

It means that an SP can redirect to the WAYF and expect the authn
request to be (silently) redirected to the same IdP the user used the
last time the SP was visited.

> And I also don't really see the
> point...what's the use case for these pairs? 

The assumption is that IdPs on a per-SP basis is more usable than IdPs
on a last-used basis (which is what SAML2 IdP Discovery is all about).

> In Shib, most SPs are usable
> with any number of IdPs.

Of course, but that's not the point.  A particular user has a
preferred IdP and that IdP may be different for different SPs.  If you
buy that (which doesn't appear to be the case :) then something more
than SAML2 IdP Discovery is needed (which is what I've been saying all
along).

> > - A GUI can be constructed to allow the user to modify the IdP history
> > list.  Likewise, the user may also modify the (SP, IdP) ordered pairs.
> >  The GUI is hosted by the WAYF.
> 
> Again, implementation detail, not a profile.

Again, an implementation detail that depends on the existence of
certain cookies, in this case, one for the IdP history list (which is
of less importance) and one for (SP, IdP) ordered pairs.  The latter
appears to be a big step forward towards generalized IdP discovery
(with a little "d").

> > - No DNS trickery is required.  All profile functionality is localized
> > on a central WAYF.  The SP and IdP need not implement anything beyond
> > simple redirects.
> 
> True of my proposal I think, though I still insist we implement the SAML
> profile as well.

If you had a choice, where would the profile functionality be located,
on the WAYF or on the providers?  SAML2 IdP Discovery is predicated on
the assumption that each provider manages an instance of the common
domain server with the specified functionality.  Boy, it sure would be
easier if that functionality were centrally implemented on a single
host (in our case, a WAYF).  Morever, by doing so, a standard GUI can
be written that gives the user complete control over the cookies. 
This is more in line with the "Shibboleth Way", I think.

> -- Scott

Cheers,
Tom