SLO responses IdP3.2.x

[O'Dowd, Josh]

Thanks Scott,

This helps my understanding better.

The SP is an ADFS implementation, I think, because they are asking me to look for a "ResponseURL" setting in the IdP that is similar to what they are seeing in ADFS setup.  As I said, I can see the IdP responding and I am not seeing any logout handling errors. The fact that the user ends up landing on the location URL of the SP metadata SLO binding(s) tells me the response is not being handled properly at the SP or maybe out at ADFS.  Curious to me that the user lands at the metadata URL which ends up being an error message from the web application, which doesn't know that URL.  Of course they insist everything is golden on their end and that the IdP isn't "redirecting" the user properly.

Well, thanks again for the edification on the subject.

Josh



-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, December 1, 2016 2:45 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: SLO responses IdP3.2.x

> 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


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net