<div dir="ltr">Okay, thanks.  I like the idea of the sessions being stored client side, as it makes the persistence/clustering problems go away.  However from an administrative standpoint there needs to be a way to invalidate those sessions.  If the default session lifetime is 8h (the default), then there is an 8h window in which someone could be disabled in the IdP but still access services as their service session is valid.  All that is needed is to invalidate existing SP sessions and force reauth against the IdP.  This could be implemented with a simple timestamp check, i.e. invalidate all sessions older than <stamp>.  Invalidating all sessions will require valid users to reauth, but <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I view the potential disruption to valid users as an acceptable tradeoff with complexity as, at least with the SAML provider I'm using, reauth with a valid provider session for a HTTP GET is transparent.</span><div><br></div><div>For today I can get this functionality by restarting the shibd processes.  If V3 uses persistent client side sessions than this would be a blocker for us, as if we see a user performing suspicious activity we won't be able to lock them out as disabling the user in the IdP won't take effect until the SP session expires.  I'd appreciate if this could be taken into consideration in V3, as, in my opinion, it's very important in a corporate use environment.  Thanks.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">--Tom Noonan II</span><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 20, 2018 at 4:05 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> So there's no way to expire out the known sessions in shibd?  That's really<br>
> what I need, I don't need to logout users at the IdP level.<br>
<br>
I assumed you wanted to expire specific sessions, and I wasn't talking about the IdP (but that said, of course, it's true that the SP has to trigger an IdP administrative logout, which we also don't yet support).<br>
<br>
If you want to expire all of them, restarting shibd isn't even purely sufficient in the abstract if you're using another storage service, but in practice it usually would work now. There's no explicit means and adding client side session storage, which will be the default in V3, would defeat that.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div></div>