Shibboleth Developers

[Tom Scavo <>]

On Mon, 15 Nov 2004 14:35:51 -0500, Scott Cantor 
<>
 wrote:
> > 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.

Just another reason why SAML2 IdP Discovery is not for Shibboleth.

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

That's exactly what they meant.  As far as I can tell, they (who is
"they" anyway :) meant for each provider to manage its own instance of
the common domain server.  That's not gonna cut it here.

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

Precisely!

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

I totally agree.  All I'm saying is that an (optional) cookie (NOT the
common domain cookie) can provide this capability if the deployment
wishes to exercise it.

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

But if the user chooses to remember it, can all the (SP, IdP) pairs be
aggregated on a single web page so that they can change their mind
later on?  (I think so...)

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

Like elephants? :-)

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

No mandate, just additional possibilities.

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

Way back when I called it "vague", that's exactly how I felt too.  Now
it's becoming more clear what could be erected in its place,
especially since the WAYF concept is so firmly entrenched (which is an
advantage, not a liability).

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

My basic proposal is for two cookies, one that maintains IdP history
and another that stores (SP, IdP) pairs.  Beyond that, everything else
is implementation, yes.

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

That's exactly right!  Each SP has access to its preferred IdP only,
no more, no less.

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

Nope.  I propose we remove the IdP from the cookie writing business
altogether.  The history cookie is of limited usefulness (IMHO) so why
not let the WAYF write it at the same time it redirects to the IdP? 
Yes, authentication at the IdP may fail, but so what?  The user
clearly intended it to succeed, so why not append the IdP providerId
to the history cookie at the WAYF and be done with it?  Sure does
simply the process.

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

There is nothing in the SAML2 IdP Discovery profile or the profile
suggested in the Shib Architecture doc (which I like, btw :) that is a
step towards (SP, IdP) pairs and a general GUI for modifying these
pairs (which precludes the need for specialized clients).

> If it's handled by the WAYF, then it doesn't need to be in
> the profile, because it's private.

I claim the history cookie can be handled by the WAYF but it MUST be
in the spec for interoperability.  Likewise, the (SP, IdP) pairs are
handled by the WAYF and they too MUST be in the spec (assuming we can
figure out how to store this data in a reasonable way).

> Build it, and if people like it, they'll
> deploy it.

Design first, build later...you know that better than anybody. ;-)

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

Now we're getting somewhere! <phew>

Thanks,
Tom