<div dir="ltr">If I decode the SAMLResponse it is "unfortunately" a Success-response sent back from the IDP. Shibboleth-logs show nothing out of the ordinary. At first I was specifying my entityId to be <a href="https://mysite.com/shibboleth">https://mysite.com/shibboleth</a>, but later changed it to <a href="https://mysite.com/Shibboleth.sso">https://mysite.com/Shibboleth.sso</a> as the logout response came into an URL based on my entityID. (I see also that DestinationUrl and RelayState differ in the response querystring.)<div>Is it possible to set DEBUG-log-level to somehow pinpoint what the Logout-flow does? As I have "SAML2" and "Local" in the chaining, it seems like an error that Local does not take RelayState into account?</div><div><br></div><div>Thanks Scott.</div><div><br></div><div>Best, Erik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020 at 2:53 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Offhand I would guess the IdP is responding with failure in the LogoutResponse and not Success, but that's just guessing. The code does check for RelayState and treats it as a return location to recover based on the type of relayState setting the SP is using.<br>
<br>
It's moot since SPs cannot rely on control of the UI if they use SAML logout. Most IdPs will (and if they actually support SAML logout, have to) maintain control of the UI.<br>
<br>
-- Scott<br>
<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/confluence/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.net</a><br>
</blockquote></div>