Manually force Shibboleth SP to expire/invalidate all sessions

Peter Schober peter.schober at
Wed Feb 21 09:27:51 EST 2018

* Tom Noonan <tom at> [2018-02-21 15:02]:
> I'm currently using the SP as a auth proxy in front of another app. As I
> understand the model there will always be a delay between disabling the
> user in the IdP and having their sessions expire in the SP as the SP has
> it's own sessions.  This can me minimized, but not eliminated, with low
> lifetimes but that kills the user experience with frequent redirects to the
> IdP.  So, in my opinion after several days of pondering this problem, a
> longer session is better for user experience but some sort of
> administrative kill switch is needed.  I think that's going to be the best
> tradeoff between usability and security.

Sure, that's all easy to agree with, but since administrative logout
doesn't exist (as explained by Scott) and is unlikely to exist going
forward (ditto) not sure what you expect.
I guess you can become a member of the Shibboleth consortium and try
to make your voice and arguments heard. (Noone is against having
better security, it's a trade-off in light of restricted dev
resources, complexity of the required changes, other features asked
for, etc.)

Have you considered using a storage backend that does support
clustering and fail-over properly? Memcache in itself has no
replication, andrepcache seems to be a dead end. Have you tried
replacing your memcached instances with Couchbase Server?
The community edition is FLOSS (if I can find the license anywhere)
but if you have no issues paying for Oracle RAC licenses you might of
course consider the Enterprise Edition.

(I note that SimpleSAMLphp uses replicated memcache for a clustered
session store, and that seems to serve all of the Norwegian Higher Ed
just fine -- they're all using a shared, single IDP instance -- but
SSP has added its own replication layer on top of memcache.)


More information about the users mailing list