<div dir="ltr">Actually I am implementing SP, and the replay checking is mostly for assertion replays. Also with an LB on top of the hosts, per node cache doesn't really work.<div><br></div><div>I'm not requesting a feature, but more just curious of the decisions. </div><div><br></div><div>Also, what is your reason for not implementing SP? I understand there's a SP package implemented by shib, but is there any other reason for that?</div><div><br></div><div><br></div><div>George</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 18, 2016 at 6:40 AM, 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"><span class="">> I was thinking of using one of the MessageReplayHandlers that require<br>
> StorageService. There was only memcached based Storage Service, and was<br>
> thinking of using redis instead. I think in this case serverside storage is<br>
> required, unless you have any other suggestion?<br>
<br>
</span>Most people just do per-node caches in memory and leave it. The only real significant case where replay checking is valuable for the IdP is for people supporting SOAP over 443 using signed messages from clients. Replay and freshness are (currently) the only real MITM mitigation there. But very few people are doing that.<br>
<br>
If you're implementing an SP, replay checking matters more, but you shouldn't be implementing an SP.<br>
<br>
Unicon has a hazelcast plugin available also.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
</font></span></blockquote></div><br></div>