<html><body><div dir="ltr">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: </div><div dir="ltr"><br></div><div dir="ltr">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?</div><div dir="ltr"><br></div><div dir="ltr">David St. Pierre Bantz</div><div dir="ltr"><br>
<div class="gmail_quote" dir="ltr">
<div dir="ltr" class="gmail_attr">On 13Jan2022 at 12:24:48, "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
<div>
<div>
On 1/13/22, 4:17 PM, "users on behalf of IAM David Bantz" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:dabantz@alaska.edu">dabantz@alaska.edu</a>> wrote:<br></div></div></blockquote><span class="Apple-tab-span" style="white-space:pre"> </span>...<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite"><div><div><br>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).<br><br>I can't really take the time it would require to "document" an undocumented feature on list, but it is physically possible….<br>
</div>
</div>
</blockquote>
</div>
</div></body></html>