SLO in IdP 2.4

[Cantor, Scott]

> Despite the caveats, I'm keenly interested in this proposed new feature:

I think it will be a fairly royal mess, but that's partly why I did it.

> InCommon wants to support this in metadata but I'm not exactly sure
> what's required. If we supported <md:SingleLogoutService> endpoints at
> both the IdP and SP for front channel bindings only, would that be
> sufficient?

It supports back channel to the IdP if a deployment is capable of that. It never sends logout requests to an SP, but it will respond to the initial request if it's not told to skip that step, and that would be front only. So you this code would never look at a back channel SP endpoint.

If you're asking if I expect it would be used back channel, I really couldn't say. I can't use it, I don't have server side sessions, but plenty of people do. If they wanted the SP to handle the UI and just send a notification to the IdP, back channel is certainly more reliable for that.

SAML logout is so poorly adapted to the IdP's design in the session cache that I honestly wouldn't use those endpoints at all unless I was very clear on the implications. The feature was designed for proprietary use moreso than standard use, making metadata moot. It's really an internal enterprise feature intended to replace custom cookie clearing scripts.
 
Note that adding endpoints to an IdP's metadata will have very serious implications on any SP that is routing the user through /Shibboleth.sso/Logout. That instantly causes, in a default configuration, a SAML logout flow that could be very different from what's expected to happen now. Easy to fix, but I wouldn't be surprised if I get a ton of bitching over it.
 
-- Scott