IDP logout in V3

[Cantor, Scott]

On 6/29/15, 6:04 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
>
>And I suppose it would be a very bad idea to publish /idp/profile/Logout as my SAML2 SLO redirect endpoint in metadata, especially of folks are expecting it to do something SAML-ish such as asynchronous logout?

You can't, it won't accept that type of message. Well, you could, I guess, but it would ignore the request, and it would never issue a response.

>Only reason I'd do this is so that /Shibboleth.sso/Logout still works properly from the SPs.

Just invoke it with the return parameter set to the /idp/profile/Logout location.

>Putting a database in place to make things work correctly is major overkill and adds a single point of failure that we aren't prepared to deal with. At least with Paul's db-backed storage service added onto V2, life would go on in an unclustered sense if my database was down. From what I'mr eading here, I can't have both database and in-memory storage, thus cookies are the way to go if I'm willing to hack logout.

I believe at least for sessions the JPA plugin will just silently fail if it's done, which isn't exactly the same as "unclustered", but it might not be fatal.

You could certainly request a more advanced implementation that back-stops with memory. I would imagine we'd just wrap that around any store so that if it fails, it uses the cache.

-- Scott