Manually force Shibboleth SP to expire/invalidate all sessions

[Cantor, Scott]

> Okay, thanks.  I like the idea of the sessions being stored client side, as it
> makes the persistence/clustering problems go away.  However from an
> administrative standpoint there needs to be a way to invalidate those
> sessions.

Well, 15 years of not having it suggests "need" is a bit strong. Defending against insider attacks is virtually impossible, so this is in general a poor and ineffective tool for that.
 
> If the default session lifetime is 8h (the default), then there is an
> 8h window in which someone could be disabled in the IdP but still access
> services as their service session is valid.

Or in some mobile app cases, months. This is just how the web works today, and fighting that is a losing battle. People need to rethink their approaches. As an example, if applications enforced authorization checks more than once at login time, you'd have less of an issue.

>  All that is needed is to invalidate
> existing SP sessions and force reauth against the IdP.  This could be
> implemented with a simple timestamp check, i.e. invalidate all sessions older
> than <stamp>.

The SP doesn't track that, it tracks expiration. There's some math that could be done I would imagine but that means enforcing that check, and the code where that would have to happen is brutally complex. Also, this idea that invalidating *everybody* to catch one would be something people would use seems questionable to me. Nobody has suggested before that that's really a solution, they usually want targeted logout of one session. I admit that changes the complexity quite a bit to just throw everything out.

>  Invalidating all sessions will require valid users to reauth, but I
> view the potential disruption to valid users as an acceptable tradeoff with
> complexity as, at least with the SAML provider I'm using, reauth with a valid
> provider session for a HTTP GET is transparent.

*You* might, but I would have to have more evidence that anybody else would really see that as acceptable before I would buy that as a solution. Otherwise this is just logout, and given that the client side feature makes logout impossible in practice (*), I would guess that you wouldn't be able to use it anyway, so it's probably moot what it does to this particular problem.

-- Scott

(*) It moves a "recoverable" session token out into the client and with logout necessarily only seen by one SP node, it's not possible with any ordinary effort I intend to spend to prevent the session from just being re-established by a user with even a modicum of technical skill.