Shibboleth Developers

["Scott Cantor" <>]

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

It is? Hmm, I guess it sort of implies that, but that would be a bad idea.
Exposing the artifact to anything except the SP is just asking to get
hacked. Horrible idea, IMHO.

I'll raise next chance I get, but I don't think that's what they meant...

OTOH, again, in SAML, the IdP is typically just redirecting to itself. Key
distinction that probably makes all the difference.

> 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?

It certainly can, but we would never enforce this in a profile. This is up
to the WAYF to do or not as it (and the user) chooses. If it does, the
intent is that it does it in way cognizant of and consistent with the other
aspects of the profile.

> 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. :)

Again, maybe. This is of course borderline impossible to combine with your
earlier question. Either you remember it or you don't. Nobody has yet
proposed a workable implementation that can somehow "remember when you want
it to" and "forget when you want it to". ;-)

This is the place where all WAYFs go to die, so to speak.

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

No, I disagree. This doesn't affect interoperability IMHO, but keep
reading...

> 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.

Ok, so you're just suggesting that a memory per-SP is more useful. I could
probably buy that in some cases. Nothing I said precludes it, but trying to
mandate it would not be appropriate in this spec.

> 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).

Sure, it's more tightly formulated since it's sharing the cookie data
structure between the IdP and SP, while my extension proposal is for a case
in which it's not shared, allowing the WAYF to implement whatever it
chooses.

> 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).

Sorry, I really didn't appreciate that this was your complaint at all. You
said the profile was vague, but without claiming what you thought it needed
to do instead. This I can buy as a concern, but again, it's not something
that needs to be baked into this proposal, because once the WAYF can control
the information itself (and perhaps optionally export a limited view of it
compatible with the SAML profile), the WAYF can and should do whatever it
wants. Your proposal is an implementation guideline.

> 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").

The cookies are private to the WAYF. Anything private doesn't need to be in
the profile.

Now, if you wanted to suggest that we export the more complex structure to
the SP/IdP, then something more might be needed, but I don't think that's
strictly necessary. It's certainly not needed for the SP, since all he would
care about is his own pair. The IdP meanwhile would need to provide more
detail on the URL to set a cookie for a given SP, but again, the cookie
structure wouldn't be shared.

> 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.

I agree, but you seem to think that more needs to be specified to achieve
this than I do. If it's handled by the WAYF, then it doesn't need to be in
the profile, because it's private. Build it, and if people like it, they'll
deploy it.

I totally understand your point here about the SAML profile (now), but that
doesn't imply requiring WAYFs to do things that are really a matter for
implementations to decide.

-- Scott