<div dir="ltr">This issue has persisted since the upgrade and I have more details. We set the relayState parameter to 'cookie' so the client could see the relay state.<div><br></div><div>It appears that the relay state isn't being set correctly when the SP redirects to do the authn request. An example:</div><div><br></div><div>I navigate to:</div><div><br></div><div><a href="https://blogs.uw.edu/ianwalsh/wp-admin/">https://blogs.uw.edu/ianwalsh/wp-admin/</a></div><div><br></div><div>I am immediately redirected to the IdP with the AuthN request but my shib state cookie has the value of:</div><div><br></div><div>_shibstate_xxxxxxxxxx_xxxx=https%3A%2F%<a href="http://2Fblogs.uw.edu">2Fblogs.uw.edu</a>%2Fwp-admin%2F;<br></div><div><br></div><div>which is not the full path which I originated.</div><div><br></div><div>Any thoughts, with this additional data point?</div><div><br></div><div>Thanks in advance.</div><div><br></div><div>-Ian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 8, 2018 at 2:50 PM, Ian Walsh <span dir="ltr"><<a href="mailto:ianwalsh@uw.edu" target="_blank">ianwalsh@uw.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the replies folks.<div><br></div><div>The engineer currently troubleshooting this notes that when he experiences the problem he also tests using his hosts file to bypass the load balancer, yet he continue to have this issue on individual hosts protected by Shibboleth SP.</div><div><br></div><div>That would suggest that something else in the ecosystem is leading to this behavior, not (necessarily) the load-balancer doing the wrong thing. </div><div><br></div><div>They've upgraded to 3.0.2 now so we'll see if they continue to report trouble.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Ian</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 8, 2018 at 1:00 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"><span>> According to that team the shibd logs don't show any kind of smoking gun.<br>
> Once this begins to occur it appears to continue until action is taken. They have<br>
> been restarting shibd to mitigate, which appears to work until it occurs again,<br>
> but that's not a sustainable solution.<br>
<br>
</span>There are no supported relay state options that could possibly be "fixed" by a restart unless you're pointing it at a database or memcache storage back-end for the relayState setting and it's losing its connection. Otherwise it's cookie, in-memory, or literal and all of those are entirely subject to client, IdP, or load balancer whims, never the SP itself.<br>
<br>
It's likely that the restart is a red herring but since you mentioned it, I'm compelled to call that impossible without having done something unusual. My guess is restart correlates to "load balanced node change" and this is a deployment with an insufficiently sticky load balancer relying on in-memory relay state, which is impossible.<br>
<span class="m_6992106771900328276HOEnZb"><font color="#888888"><br>
-- Scott<br>
</font></span><div class="m_6992106771900328276HOEnZb"><div class="m_6992106771900328276h5"><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/co<wbr>nfluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.n<wbr>et</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>