Manually force Shibboleth SP to expire/invalidate all sessions

[Tom Noonan]

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.  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.  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>.  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.

For today I can get this functionality by restarting the shibd processes.
If V3 uses persistent client side sessions than this would be a blocker for
us, as if we see a user performing suspicious activity we won't be able to
lock them out as disabling the user in the IdP won't take effect until the
SP session expires.  I'd appreciate if this could be taken into
consideration in V3, as, in my opinion, it's very important in a corporate
use environment.  Thanks.

--Tom Noonan II

On Tue, Feb 20, 2018 at 4:05 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > So there's no way to expire out the known sessions in shibd?  That's
> really
> > what I need, I don't need to logout users at the IdP level.
>
> I assumed you wanted to expire specific sessions, and I wasn't talking
> about the IdP (but that said, of course, it's true that the SP has to
> trigger an IdP administrative logout, which we also don't yet support).
>
> If you want to expire all of them, restarting shibd isn't even purely
> sufficient in the abstract if you're using another storage service, but in
> practice it usually would work now. There's no explicit means and adding
> client side session storage, which will be the default in V3, would defeat
> that.
>
> -- Scott
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180221/e033101e/attachment.html>