<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>I'm afraid I'm struggling a little with this one. The SP I want to use the SLO is actually running on the same host as the IdP but to simplify the troubleshooting/logging I have added another SP running on a separate server/domain and am having the same issue.<div><br></div><div>The stage I'm at is:</div><div><br></div><div>Authentication is OK and hitting <a href="https://api.iproov.com/Shibboleth.sso/Session">https://api.iproov.com/Shibboleth.sso/Session</a> shows the session.</div><div><br></div><div>If I hit <a href="https://api.iproov.com/Shibboleth.sso/Logout">Shibboleth.sso/Logout</a> with the browser I get the "Local Logout - <strong style="font-family: Times; ">Status of Local Logout:</strong><span style="font-family: Times; "> Logout completed successfully.</span>" and the SP logs:</div><div><br></div><div><div>2013-06-12 17:38:14 DEBUG Shibboleth.Listener [2]: dispatching message (find::StorageService::SessionCache)</div><div>2013-06-12 17:38:14 DEBUG Shibboleth.Listener [2]: dispatching message (default/Logout::run::SAML2LI)</div><div>2013-06-12 17:38:14 DEBUG Shibboleth.SessionCache [2]: searching for session (_8cdeae0e18e786de4d8554b61a67885d)</div><div>2013-06-12 17:38:14 DEBUG Shibboleth.SessionCache [2]: reconstituting session and checking validity</div><div><font color="#e32400">2013-06-12 17:38:14 WARN Shibboleth.LogoutInitiator.SAML2 [2]: bypassing SAML 2.0 logout, no NameID or issuing entityID found in session</font></div><div>2013-06-12 17:38:14 INFO Shibboleth.SessionCache [2]: removed session (_8cdeae0e18e786de4d8554b61a67885d)</div><div><br></div></div><div><br></div><div>The /Status page shows that I have NameID set to the users login name - does the message mean that I have to have NameID & entityID set as I read it that either will do?</div><div><br></div><div><br></div><div>Dom</div><div><br></div><div><div><div>On 12 Jun 2013, at 07:49, JF <<a href="mailto:jamesforrest56@gmail.com">jamesforrest56@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>Thanks Scott,<br><br>we do have complete control over the app but I'll follow your suggestion as I suspect this isn't the only time this will come up. I'll report back here how we get on.<br><br><br>jf<br><br>On 11 Jun 2013, at 22:39, "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite">I believe an option for achieving this is:<br><br>1)<span class="Apple-tab-span" style="white-space:pre"> </span>On logout having the user access the<br><a href="https://aaa.bbb.com/Shibboleth.sso/Logout">https://aaa.bbb.com/Shibboleth.sso/Logout</a> to terminate the users session<br>on the SP<br>2)<span class="Apple-tab-span" style="white-space:pre"> </span>Modifying localLogout.html on the SP to redirect the user to the<br>localLogout on the IdP<br></blockquote><br>You could, but it would probably be "better" in general to use the SAML protocol for that, if for no other reason than if it doesn't work for this constrained a case, it's not even worth continuing to talk about it.<br><br>The local hook is not meant for use by systems that are not tightly coupled, though it sounds like that might be true in this case. To be more explicit, if you don't have direct control over or at least a tight relationship with the systems generating links to the proprietary hook, you're asking for trouble using it, just like any non-standard mechanism.<br><br>-- Scott<br><br><br>--<br>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote><br></blockquote></div><br></div></body></html>