administratively invalidate user's SSO session(s)

Simon Lundström simlu at su.se
Fri Jan 14 13:47:51 UTC 2022


On Thu, 2022-01-13 at 22:24:48 +0100, Cantor, Scott 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.
> 
> 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.

IANAD(eveloper) but shouldn't it be possible for the client storage to
set the session ID that you want to logout on a blocklist and when the
user hits the IDP again and present the blocked session ID the IDP
invalidates/removes it from client storage and sends the user to the
login page?

This, of course, now requires that your blocklist is clustered and
available to all your IDPs...

Have a great weekend all!

BR,
- Simon


More information about the users mailing list