SLO responses IdP3.2.x

[Cantor, Scott]

> I am still a little green on how the SLO transaction works.  If the SP is making a
> LogutRequest via SLO HTTP-POST binding, according to the location URL
> provided in the IdP metadata, does the IdP then send the LogoutResponse
> to the location URL provided in the SLO HTTP-POST binding of the SP
> metadata?

If the request doesn't carry the Asynchronous extension element, the IdP is obligated (within reason) to respond to the SP. Bindings are not matched that way. A front channel request will have a front channel response but the request could be Redirect and the response POST. Just like with SSO. The binding chosen is more or less baked into the IdP as a precedence to use subject to whatever the SP supports.

But you need to understand that "response" here doesn't mean "SP controls the UI". We do not support that and I don't have any real intention of going back to it. The response is in a hidden iframe to complete the exchange and get the response back to the SP. In a correctly implemented application, that response should not matter because there shouldn't be anything else to clean up. But we do it because the standard does require it.

> I am troubleshooting a problem where the SP is sending a LogoutRequest to
> the IdP HTTP-POST binding.  I see the IdP (in the logs) handling the request.
> The user browser is landing on the URL provided by the SP HTTP-POST
> binding (the HTTP-Redirect binding location is the same as POST).

That's only likely if the IdP rejected the request. If it can't *do* the logout at the IdP, then it will (often) respond full frame with a SAML LogoutResponse with an error in it. That becomes an SP error handling issue at that point.

> This is causing an error to occur in the service application and the developer is telling
> me the IdP isn't redirecting the user properly, and that the user should be
> redirected to a URL that is nowhere to be found.  They are asking if there is
> an option on the IdP to register a redirect URL for logout requests from that SP.

It is the case that there can be RelayState, and if it's supplied we will return it (including in the error case). In the error case, of course, that then becomes up to the SP what it wants to do. In the non-error case, we will not render anything. If the hidden iframe results in *another* redirect at the end by the SP, the browser will follow it, but it's a hidden iframe.

> It is my understanding that with a SAML logout request to the IdP, that the
> IdP will respond to the corresponding binding location provided by the SP.
> Am I not understanding this correctly?

It responds to an endpoint in the metadata that has a supported front-channel binding, and includes any RelayState it was sent, again like in the SSO case. The general message pattern is the same for SSO and SLO when you just look at a particular IdP/SP pair.

All that said....

A *Shibboleth SP* defaults now to including the Asynchronous extension in its requests. And it also correctly implements the requirement to clean up the session there *before* issuing a LogoutRequest. That is, if it doesn't get a response, the logout was still done.
 
-- Scott