<div dir="ltr"><div>The database stores a sequence number per user. This sequence is incremented each time the user connect. If the cookie is stolen, an old sequence number is detected (from the thief or from the user) and the row of the database is removed. So the thief can only use its current session, if he connects before the user. If he connects after the wrong sequence number will be detected. In case of stolen cookie, unfortunately the process does not remove the current thief's j2ee session <span id="gmail-result_box" class="gmail-" lang="en"><span class="gmail-">even if it is detected</span></span>. But the "good" user may be informed of that.<br></div><div><br></div><div>
But it is true that clustering the database is a problem i did not think of.

I did not think of clustering the idp either. <br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-25 20:32 GMT+02:00 Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Yes the point of the approach is avoiding stolen cookie.<br>
> What do you mean by a lack of reliability ? You mean a bad reliability if the<br>
> database shutdown or has too much load ?<br>
<br>
</span>Yes. You have a single point of failure. Most people don't cluster databases. This use case happens to tolerate a looser replicated store, but it's still pointless, there is no need for a database to prevent forgery. The advantage of the database is solely per-session revocation.<br>
<br>
Stealing a cookie isn't the threat you're addressing, forgery is. Unless you address-bind the cookie, there is no mitigation to theft, no database solves that.<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>