Manually force Shibboleth SP to expire/invalidate all sessions

Tom Noonan tom at joinroot.com
Wed Feb 21 09:44:26 EST 2018


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

My expectation is to discuss it and see if it can be added, as the planned
V3 change Scott mentioned will break my current workaround.  I found
https://issues.shibboleth.net/jira/browse/SSPCPP-775 which appears to be in
the discovery and requirements phase.  So my intention is to bounce this
idea off Scott, who appears to be the owner of this code, and see what he
says.  If the planned implementation uses timestamped sessions, which I
imagine it would, then implementing this feature might be very easy and
something I could submit a pull request for in the future.

I'm also unfamiliar with the Shibboleth consortium and how to join it to
officially raise my concerns, so by voicing my concerns here I'm also
learning what I need to do to follow this project's flows.  So I guess my
expectation is to discuss this need with the community, see what those who
know more about this than I do say, and learn how to get it things
considered that don't currently exist.

--Tom Noonan II

On Wed, Feb 21, 2018 at 9:27 AM, Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Tom Noonan <tom at joinroot.com> [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?
> https://www.couchbase.com/memcached
> 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.)
>
> -peter
> --
> 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/d3a3ec46/attachment.html>


More information about the users mailing list