Manually force Shibboleth SP to expire/invalidate all sessions

[Tom Noonan]

My intention is to prevent a session with the SP from allowing a user to
continue accessing a service when they've been disabled in the IdP.  I can
do this with V2, and I've opened another thread to understand V3 better.

Just to close the loop, let me explain what I'm doing with V2.  I'm using
mod_shib/shibd to provide an authenticated proxy in front of an application
and Google as my SAML provider.  This will focus on the SP and proxy, my
app does not come into play here.

- So, when a user hits my app mod_shib/shibd redirects them to Google, as
Google is configured as my IdP.
- They auth with Google and are redirected back to my app.
- Shibd now has a session, stored in memory per
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPClustering,
details of which are viewable at Shibboleth.sso/Session
- The user will now be transparently proxied to my app until the Shibd
session expires, at which point they'll be redirected to the IdP.

So, consider the following:

- A user hits my app mod_shib/shibd redirects them to Google, as Google is
configured as my IdP.
- Their account is active, they auth with Google and are redirected back to
my app.
- Shibd now has a session, stored in memory per
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPClustering,
details of which are viewable at Shibboleth.sso/Session
- The user will now be transparently proxied to my app
- For whatever reason (abuse, termination, etc...) an admin disables the
user in Google.  Any further logins to Google will now fail.
- The user continues to have access as they have a valid session with
shibd, despite being disabled in the IdP.

This is the problem I'm trying to resolve.  In this case the issue is the
cached session in the SP.  As this is an administrative action I plan to
simply write a script that restarts all the shibd processes, which will
cause all the cached sessions to be lost.  When this happens for our
disabled user they will perform a request which will be redirected to the
IdP (Google) as their SP session is no longer valid and Google will reject
them.  Valid users will also be redirected to Google to reauth, but  ss
their sessions with Google are still valid they will be immediately
redirected back.  As this is an edge case flush operation I think this is
an acceptable tradeoff.

So as I mentioned restarting V2 shibd meets my needs for this edge case, as
it causes all the SP sessions to be invalidated.  I'm not sure if this will
work with V3, but I've opened another thread to understand that.

I'm going to close this thread as I think it's reached it's logical end.
Thanks for the help!



--Tom Noonan II

On Wed, Feb 21, 2018 at 11:40 AM, Michael A Grady <mgrady at unicon.net> wrote:

> If the "bottom line" is to prevent a given user from continuing to use the
> service, and you are using Apache HTTPD as a reverse proxy, couldn't you
> add in "negated" group authorization in addition to the Shib-based authz
> rules? I.e. don't allow access to anyone that is a member of this group?
> Using whatever approach the given version of the Shib SP, and of Apache
> HTTPD, you are using:
>
>   https://wiki.shibboleth.net/confluence/display/SHIB2/
> NativeSPApacheConfig#NativeSPApacheConfig-AuthConfigOptions
>
>
> On Feb 21, 2018, at 10:33 AM, Tom Noonan <tom at joinroot.com> wrote:
>
> No worries, I appreciate the help in any case!
>
> --Tom Noonan II
>
> On Wed, Feb 21, 2018 at 11:30 AM, Peter Schober <peter.schober at univie.
> ac.at> wrote:
>
>> * Tom Noonan <tom at joinroot.com> [2018-02-21 17:23]:
>> > I'm not using memcached.  I think there is some confusion with another
>> > thread.
>>
>> Indeed, apologies. I was referring to a hijacked thread that at one
>> point changed its subject to "Shibboleth SP clustering using shared
>> database", where someone wanted to cluster Apache httpd with Shib as a
>> reverse proxy to another resource.
>> That latter part is what caused me to chase you down a road you had no
>> intention of going.
>> -peter
>>
>
> --
> Michael A. Grady
> IAM Architect, Unicon, Inc.
>
>
>
>
> --
> 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/4cc0a4f6/attachment.html>