Manually force Shibboleth SP to expire/invalidate all sessions

[Tom Noonan]

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

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

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

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

> Also, this idea that invalidating *everybody* to catch one would be
something people would use seems questionable to me.

I get that, but remember I'm not asking to log users out of the IdP just to
expire the SP sessions.  I was asking for this as I believed it to be the
solution of least difficulty.

> Otherwise this is just logout

No, it isn't.  I can have my SP session expire while still being logged in
to my SAML provider.  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.

> client side feature makes logout impossible in practice ...  prevent the
session from just being re-established by a user with even a modicum of
technical skill.

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.

--Tom Noonan II

On Wed, Feb 21, 2018 at 10:18 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > 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.
>
> --
> 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/6def8809/attachment.html>