SLO responses IdP3.2.x

[O'Dowd, Josh]

Sorry, still troubleshooting this...  I got the vendor to make some adjustments but we are not there yet.

Using some debugging tools on the browser, I can see that the SP is doing a SAML LogoutRequest to the IdP HTTP-Redirect binding endpoint via a 302 redirect to the browser.  The IdP is handling the request.  We do not propagate Logout requests but the IdP is successfully ending the service and SSO session, and the user ends up on the IdP logout view.  Problem now is that the SP session is still active, and I am not seeing the IdP send any response.  Nor am I seeing any errors.

FWIW, today I also noticed that we were still using the default session storage, which I see does not allow for SAML SLO.  I have since implemented MemcachedSessionStorage successfully and the results described above are using the new storage.  Lastly, we could not switch to client-side storage because we run a lot of CAS authentication.

Shouldn't the IdP be sending a response in this scenario?

Josh  

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, December 2, 2016 9:06 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: SLO responses IdP3.2.x

On 12/2/16, 11:00 AM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

> Is there any scenario in SP-initiated SAML2 SLO--whether front channel, or back--where the IdP is configured to
> redirect the user back to an SP URL that is not the SLO binding location, instead of sending a LogoutResponse to
> the SP binding location?

No, but the IdP doesn't redirect the *user* anywhere unless there's an error. The redirect is invisible otherwise, no matter where it goes. It will not be in the location bar.

-- Scott


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