administratively invalidate user's SSO session(s)

[Matt Brennan]

What are you using for a session store?

In my case, we store our session data in SQL. Invalidating a session is as
simple as deleting the row from the SQL table. When the user with that
session comes back, Shibboleth can't find the record and forces the user to
re-authenticate.

-Matt

On Wed, Jan 12, 2022 at 8:38 PM IAM David Bantz <dabantz at alaska.edu> wrote:

> When we discover an SSO session created by a bad actor, we can block
> further use of that user’s SSO session(s), setting an attribute in the
> attribute store that triggers an interrupt for any attempted use of the SSO
> session (analogous to putting a hold on use of a library or credit card).
> In principle we could wait a few hours for any existing SSO sessions to
> expire, but users of course want to get back to normal operation by
> resetting their password and removing that attribute trigger. Seems it
> should be passible to remove any existing unexpired SSO sessions from the
> server-side store, eliminating the ability of said bad actor to continue to
> use their ill-gotten SSO session(s) while allowing the legitimate account
> holder to establish new SSO sessions with their new credentials. How might
> I go about providing that ability to security admins?
>
> David St. Pierre Bantz
> U Alaska IAM
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> 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/20220112/252340d5/attachment.htm>