administratively invalidate user's SSO session(s)

[IAM David Bantz]

Passing on reverse engineering the ‘not really documented’ session store to
find and remove SSO sessions, but still seeking to render illicit SSO
sessions useless, is the following feasible:

When misuse is discovered that could have created illicit SSO sessions for
an account, we both flag the account in the credential store and force
password reset. Upon attempted login via the IdP with otherwise valid SSO
session in the browser we currently rely on the attribute to interrupt the
login and display an error message. Can we instead merely “force
(re-)authentication” requiring use of (newly reset) password?

David St. Pierre 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:
>
...

>
> 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….
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220118/c5891f86/attachment.htm>