administratively invalidate user's SSO session(s)

[IAM David Bantz]

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
> storage.
>
> -- Scott
>
>
> --
> 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/20220113/831489a0/attachment.htm>