administratively invalidate user's SSO session(s)
IAM David Bantz
dabantz at alaska.edu
Thu Jan 13 22:18:41 UTC 2022
On 13Jan2022 at 12:24:48, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
> On 1/13/22, 4:17 PM, "users on behalf of IAM David Bantz" <
> users-bounces at shibboleth.net on behalf of dabantz at alaska.edu> wrote:
> We’re using built-in server-side storage (not a separate database).
> Not clustered? That's unusual.
Clustered in the sense of multiple servers behind a load balancer, but
non-synced server side storage and weighting an active node in the load
balancer to keep traffic on a single server unless it fails a health check
or we manually switch for major update (both quite rare, so still ~ “5 9s”
service availability without the additional infrastructure.
> It is possible to manipulate the storage service regardless of the
> implementation, but it's not really a documented thing and the session
> store is equally undocumented and can change at any time (not that it does
> much but we reserve the right).
> I can't really take the time it would require to "document" an
> undocumented feature on list, but it is physically possible.
Got it. That’s actually somewhat helpful in resisting a demand to literally
remove existing SSO sessions for a user via API.
That seems to leave me with options of (a) advocating keeping our
SSOInterupt attribute in place for the SSO lifetime, which interrupts /
prevents re-use (“you can have your account back with new credentials
tomorrow”) or (b) detecting recent password change (required to remove the
SSOInterrupt attribute) and require re-authentication despite having
otherwise valid SSO session.
> Client storage, i.e. the default, is the one case it's just not physically
> possible to hack a solution for administrative logout and is why the
> feature hasn't been implemented yet because we don't see any future for any
> other session model. So we have to bake in a revocation solution of some
> kind. This missing bit is about the only obvious reason not to use client
> -- Scott
> For Consortium Member technical support, see
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users