<html><body><div dir="ltr"><br><br>
<div class="gmail_quote">
<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><br><blockquote type="cite"> We’re using built-in server-side storage (not a separate database).<br></blockquote><br>Not clustered? That's unusual.<br></div></div></blockquote><div class="gmail_quote"><br></div>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.<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 class="gmail_quote"><br></div><div class="gmail_quote" dir="ltr">Got it. That’s actually somewhat helpful in resisting a demand to literally remove existing SSO sessions for a user via API.</div><div class="gmail_quote" dir="ltr"><br></div><div class="gmail_quote" dir="ltr">That seems to leave me with options of (a) advocating keeping our <font face="menlo, monospace">SSOInterupt</font> 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 <font face="menlo, monospace">SSOInterrupt</font><font face="ui-sans-serif, sans-serif"> attribute) and re</font>quire re-authentication despite having otherwise valid SSO session. </div><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>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.<br><br>-- Scott<br> <br><br>-- <br>For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div>
</div>
</blockquote>
</div>
</div></body></html>