<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 1:54 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">On 1/17/14, 2:46 PM, "Scott Koranda" <<a href="mailto:skoranda@gmail.com">skoranda@gmail.com</a>> wrote:<br>
><br>
>One can help mitigate the issue by configuring the SP serving the<br>
>protected images to prefer the artifact resolution profile.<br>
<br>
But how does the initial (or a timed-out) login happen? Or are you<br>
assuming the original wiki page with the links is also authenticated? I<br>
may have missed that assumption in the OP' note.<br>
<br></blockquote><div><br></div><div>Yes, the original wiki page with the links is also authenticated/protected using</div><div>a SAML (Shibboleth) SP. </div><div><br></div><div>I assumed because I happen to know the OP's use case, sorry. </div>
<div><br></div><div>It all "works" because one can, using the "old style" configuration for the SP, </div><div>configure the SP to try to initiate a session using artifact resolution first if the IdP metadata</div>
<div>indicates the IdP supports it. If the metadata indicates the IdP does not support artifact</div><div>then the SP defaults to the other profiles.</div><div><br></div><div>The problem comes when an IdP advertises it supports artifact resolution but it does not.</div>
<div>That happens more often than I would have thought.</div><div><br></div><div>Thanks,</div><div><br></div><div>Scott K for LIGO</div></div></div></div>