administratively invalidate user's SSO session(s)

[Cantor, Scott]

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.

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.

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