Shibboleth Developers

["Scott Cantor" <>]

> 1) Many applications maintain their own sessions, using
>     shib only to get them started.  Any SLO mechanism
>     at the SP must provide a way to notify these applications
>     of a log out.

Of course. And if the applications leave the user stranded instead of
sending the user back to pick up the rest of the SLO protocol, that's pretty
much the end of SLO too, unless an IFRAME or AJAX trick is used to notify
the app. I think people will find that it's a two way street and the
application is just as responsible for playing nice.

>  As many of them use only cookies to maintain
>     state, a backdoor notification method would not work for them.

Yeah, the main problem being that the browser won't come back to a protected
location that the module could detect a deleted session against. A "mark as
deleted" approach only works for resources with an AuthType of shibboleth.

This also means that administrative logout won't work (always back-channel)
for them. It's crucial for the metadata to tell the IdP not to use SOAP in
those cases, so it's all part of deploying it right.

> 3) SAML 2 indicates that every <LogoutRequest> must be
>     responded to with a <LogoutResponse>.  This results in
>     the browser user ending up back at the SP -- entirely
>     the wrong place.

Just because the browser is used to get the final LogoutResponse to the SP
doesn't mean the user visually ends up back at the SP. I don't think most
implementations attempt to actually do full page redirects to every site.

If the IdP doesn't want to allow for SP-initiated logout, you can block that
too, I guess.

I tend to think that an SP driving only works when you have a consistent
scarab involved for initiating the logout from any site. At that point, I
disagree with you about where the right ending place is. I suspect it's
somewhere central to the federation of sites that is associated with that
scarab.

-- Scott