Manually force Shibboleth SP to expire/invalidate all sessions

[Cantor, Scott]

> Thanks for the detailed response.   I feel like two topics are getting conflated
> here:
> 
> - Logout form the IdP.  For my use case this is not needed as disabling the
> user in our SAML provider causes this, at least in the SAML provider I'm using.

What you're asking for, explicitly, is called administrative SP logout and requires both the IdP and SP implement it (but I'm not including the IdP part in my answers here). What you're suggesting is that there's some kind of workaround to avoid doing it that way, and I contend that nobody until now has ever suggested that would be a viable workaround. I think that they will not accept dumping everybody's session to catch one. But I could be wrong.
 
> - Expiring SP sessions.  This is the topic I'm driving at.  I simply want to expire
> the cached SP sessions to force the IdP to be rechecked, not log users out of
> the IdP.

That is simply logout while stipulating the IdP has already done its part. Expiring a session in response to some action or state change == administrative logout.

> Fair, however when using the Shibboleth SP as an auth proxy, isn't the SP the
> application performing authorization?  I'm using the SP as an authenticated
> proxy, so my app doesn't have to worry about auth.  Shib does it all for me.

The SP is primarily for *authentication* and delivering attributes to an application for authz. That is the primary use case. The SP cannot do authz effectively in the majority of non-trivial cases because it lacks sufficient context. The SP is not meant to be a proxy in that sense either, it's meant to live within the web server hosting the application, logically if not physically.

> Bah, okay.  I was hoping it was tracked the other way around.  This is why I
> wanted to informally kick the idea around here.

It tracks a hardwired expiration time inside the session, and then it does some very ugly things to tie the expiration within the storage layer with the timeout factor. It slides the storage expiration forward to track the "last access" time, so that you get the effect of a timeout, and then adds a check for the overall expiration alongside the address checking.

Because the client-side session cannot efficiently be updated to track last access time, that feature will absolutely eliminate timeouts as a supported option when that feature is in use. It will still enforce lifetime.

The session objects could be modified to include creation time, but it's probably just as possible to work backward from the lifetime setting to recover it, or just rethink your suggestion. If the setting wasn't "sessions created before time X" but "sessions that will expire before time X", it's the same outcome. I simply would have to assess the impact.

> No, it isn't.  I can have my SP session expire while still being logged in to my
> SAML provider

Logout does not mean the IdP is involved. Logout happens at both the SP and the IdP. They are separate things. Any termination of a session is a logout. They're simply synonyms. You're simplying positing that SP-only logout is sufficient for your needs.

>  If that happens I just get redirected to the IdP which
> immediately auths and redirects back.  I'm not asking to log users out of the
> IdP, I'm looking to expire the cached SP sessions to require the SP to reauth
> against the IdP to ensure the user is still valid.

I've been ignoring that part of your answer, but for the sake of argument...what is it this IdP would do to make that happen? A Shibboleth IdP doesn't, at least not unless caching of resolved attributes is off. There is no "liveness" check done for a user and they would be absolutely autenticated and passed back to the SP silently in many, many cases. It could be tricked into doing such a check via the attribute resolver, I suppose. Basically, it could be done, but often wouldn't be done.

> This is a good point.  Will the client side feature allow one shibd process to
> accept a session initiated from another shibd session, thereby removing the
> need for sticky sessions?  I'm not clear from SSPCPP-775 if sticky sessions will
> still be required.

Efficiency requires stickiness, but the point of the feature is to move sessions from one SP to another (I don't make reference to "shibd", that's an implementation detail of the SP software that should be ignored, you just run it and that's it). So it eliminates stickiness as an absolute, but call it "affinity" I guess, if you want reasonable performance.

What it *is* is a SSO protocol. Moving a session from server A to B is SSO. It happens to be a very limited one that is built around cookies and common encryption keys, a very low rent version of what SiteMinder does/did and what pubcookie does, but limited in scope and design.

It isn't going to have the sort of nonce and timestamp semantics that a true SSO protocol design would have to use to target the session migration, because that wouldn't solve my use case. It has to be transparent to a user's application requests to be viable, so having any sort of actual triggered move of the session would take more work and require POST preservation that would transit nodes, though it would be much more controlled and have tighter semantics.

This is just a blob in a cookie that's encrypted and authenticated but makes a session fully usable on any node with the key if it gets a hold of the blob, for the lifetime of the blob. That's why it breaks logout. The logout will clear both the session cookie and the blob cookie, but a smart user can save both and simply replay them and voila, session rises from the dead.

A targeted SSO node to node would solve that and other problems, but it simply isn't a fit for what I need to reduce my support burden, it would just add to it.

-- Scott