Shibboleth Developers

["Scott Cantor" <>]

> Will the "new technical proposal for using the WAYF as a discovery
> service that routes back to the SP for proper generation of requests"
> be based on using SessionInitiators?

It sounds a bit odd to say, but it's kind of orthogonal. A SessionInitiator
is really internal to the SP. The way I think of it is as a local resource
you can access to cause an AuthnRequest message to be sent instead of having
to link in some kind of library API.

Today, it's overloaded with the WAYF issue, but by design you're *supposed*
to tell it the IdP. Then it has the semantic, exactly, "send a message to
this party...".

The reason I say that is that for 2.0, there are other messages
(LogoutRequest, NameIDManageRequest) that also have to be "triggerable", so
while you wouldn't call that a "SessionInitiator", it's the same idea.

So, the idea behind the WAYF change is for the SP to send a redirect to the
WAYF saying "tell me the IdP to use, and send the user back to X". It so
happens that functionally X is the SessionInitiator in my code, but that's a
private matter. The WAYF doesn't know that, and it doesn't need to.

A WAYF should really just be a shared domain to keep a cookie. What we're
adding is a simple redirect protocol to maintain it.

It still doesn't change the fact that a single WAYF can't work. I don't see
it being viable to bounce a user through 5 redirects just to locate a cookie
on one of the WAYFs, but that's where this will end up if people keep insist
on trying to use them. At least with the new design, the SP still gets
control, and we can prevent multiple prompts by including passive flags and
things like that. It makes a bad solution merely bad instead of horrible, I
guess.

The right answer is still the same as always. The SP should maintain its own
cookie, or we need to fix the client or switch to Cardspace. Discovery will
never work with current browsers, it will always be broken. Nobody can fix
that.

I'll repeat what I've noted before. *Everybody* else doing wide-scale SSO is
assuming that the user is supposed to enter their IdP or equivalent into the
application. We seem to be the only community ignoring that option. I still
don't know why, but either we're wrong or everybody else is.

> If so, will it be possible to
> include the SessionInitiators in the metadata?

Leaving aside that there is no place to put them, it probably wouldn't be
appropriate. Metadata advertises things other people use to send you
messages, but this isn't an external endpoint, it's an internal one.

Also, I would note that if you want to push a user to an SP, there are
better ways to do it than that. Particular in SAML 2.0, since there's a
defined way to ask the IdP to send an unsolicited response. There's even an
extension we proposed to allow portals to do that while still signing the
request.

-- Scott