What's Shibboleth's view on the Logout functionality?

[Cantor, Scott]

On 7/30/15, 5:45 PM, "users on behalf of Wayne Si" <users-bounces at shibboleth.net on behalf of w.si at celcat.com> wrote:



>We managed to get the login part working properly and get the IdP responding to the LogoutRequest thanks to Scott’s help yesterday. However the IdP response on the LogoutRequest always returns An error occurred which is exactly same as
> David described in his email
> 
>http://shibboleth.1660669.n2.nabble.com/Logout-SAML-Error-message-v3-td7610948.html 

With the "right" metadata, the out of the box IdP config won't ever get such a request because there should be no SingleLogoutService in the metadata, since it does not support that profile without server-side storage, which would break the default clustering support.

There are a few things that can be done server side short of moving the whole session cache there, but the IdP doesn't support them. Notably "stapling" logout requests so that subsequent access by the matching session results in the logout "committing". That can work if you're willing to treat all logouts as "partial", but that has its own problems because of ADFS bugs among other reasons. And in any case, it's not implemented at the moment.

Once we get local storage working, that should allow for default enabling the tracking of SPs even with the client-side store, and that would allow basic logout support to be there without losing the simple clustering.

>David wanted to get more error details returned in the IdP response as expressed in his issue ticket https://issues.shibboleth.net/jira/browse/IDP-576,

Which is not happening. What that bug is about, and remains open for, is getting the IdP to log things better when this case happens, not about returning data that it absolutely 100% will never do by default. What will come back remains "an error occurred". That is not a bug.

> however I’m more interested in what exactly causes the error and how to fix it.

The client-side session store is in a cookie and there is no way to fit the necessary information into a cookie under 8k to enable SAML logout without a lot of questionable assumptions or without improperly implementing the standard.

The flags that enable the session cache features required to get logout to function are off by default and cannot be enabled without switching to the server-side cache. That's what causes the error, but it's not evident from the log.

> All I want is that the Shibboleth IdP can destroy the cookie shib_idp_session
> and shib_idp_session_ss on the client side, or at least invalidate the session id held in the cookie in IdP’s memory.

The latter would be essentially the stapling idea, and we don't have that implemented. It is NOT a session ID. Look at what a SAML LogoutRequest contains and you'll see why.

The former suggestion is not how SAML logout works. The IdP cannot just clear the session directly, it's processing a message that contains specific data in it that have to be looked up to locate the session. When it can't do that lookup, it can't find a session. It doesn't matter what the "active" session is, it can't know that that's the one involved. That's just not how SAML was defined. It isn't even formally correct because in SAML terms, it's allowable for one user to request another be logged out (which we don't support, but which your simplification would break if we wanted to, and we kind of do want to at some point).

You can argue that SAML logout is broken, and I can argue that the idea of logout being done by anything but the browser (which can do it trivially but refuses to) is even more broken, and we'd both be right.

If you want to implement a proprietary logout, then you can use the IdP's proprietary logout endpoint at /idp/profile/Logout, which does in fact access the active session and clear it. That is not SAML or any standard thing, and so is not required to behave in the same way.

> Are there any built-in way or some property switches to achieve it?

If you want SAML logout to work right now, you turn on server-side sessions and enable the properties that track and index the SPSessions. Then it will do the local logout at the IdP, and leave you logged into everything else, and return a SAML status of PartialLogout most of the time.

Since you suggested at the beginning you were looking at what the "default" config did, the answer is that a SAML Logout will always fail until at least the next version.

> Do we have to customize IdP’s workflow or ask the users to close down
> the browser?

Closing the browser stopped working a long time ago. Disabling SSO on shared devices is a good policy if they can be identified.

-- Scott