Back-channel logout request written to the browser

Description

I've configured a LogoutInitiator that supports SOAP binding only:

<code>
<LogoutInitiator type="Chaining" Location="/BackChannelLogout" relayState="cookie">
<LogoutInitiator type="SAML2"
outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" />
<LogoutInitiator type="Local"/>
</LogoutInitiator>
</code>

When I access /Shibboleth.sso/BackChannelLogout, I get the SOAP LogoutRequest message in the browser instead of being sent to the IdP.

Logs:

DEBUG Shibboleth.Listener [8]: dispatching message (find::StorageService::SessionCache)
DEBUG Shibboleth.Listener [8]: dispatching message (sp8.slotest/BackChannelLogout::run::SAML2LI)
DEBUG Shibboleth.SessionCache [8]: searching for session (_1df34695c4f1668091332f2016d48e00)
DEBUG Shibboleth.SessionCache [8]: reconstituting session and checking validity
DEBUG OpenSAML.MessageEncoder.SAML2SOAP [8]: validating input
DEBUG OpenSAML.MessageEncoder.SAML2SOAP [8]: marshalling the envelope
DEBUG OpenSAML.MessageEncoder.SAML2SOAP [8]: marshalled envelope:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><samlp:LogoutRequestxmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://sandbox.slotest.aai.niif.hu:8443/idp/profile/SAML2/SOAP/SLO" ID="_36b8987adf03fcc37b76e53780b7ac5f" IssueInstant="2009-08-11T11:56:25Z" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp8.slotest.aai.niif.hu/shibboleth</saml:Issuer><saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_c67b9f397cb2d1362c893265cd025a90</saml2:NameID><samlp:SessionIndex>a2c149821dbdea3c0a64849efea84f2652d7d4d56686c5890d13753e8aa62422</samlp:SessionIndex></samlp:LogoutRequest></S:Body></S:Envelope>
DEBUG OpenSAML.MessageEncoder.SAML2SOAP [8]: sending serialized envelope
INFO Shibboleth.SessionCache [8]: removed session (_1df34695c4f1668091332f2016d48e00)

Please let me know if I can help with debugging or testing. It all turned out while deploying a test environment for SLO, so we have all the tools at hand.

Previous back-channel tests were done with an IdP metadata showing only SOAP-aware endpoints. SLO was working well then.

Environment

None

Activity

Show:

Scott Cantor August 12, 2009 at 9:54 AM

http://svn.middleware.georgetown.edu/view/cpp-sp?view=rev&revision=3091

Added code to handlers using that property to ensure only front-channel bindings are processed that way.

bajnokk@niif.hu August 12, 2009 at 6:02 AM

The whitespace-trick did the magic.
I'm just wondering how the outgoingBindings is processed, anyway, now I can do what I want, thank you, Scott.

Scott Cantor August 11, 2009 at 10:14 AM

Quick test indicates you should use a value of " " (one or more spaces) for the attribute to disable front-channel. Try that and if it works I'll close and clarify the docs.

Scott Cantor August 11, 2009 at 9:51 AM

Looking at the code, my suggestion is to try using an empty outgoingBindings attribute to achieve this. If that doesn't work, or crashes (yikes), please report back. Otherwise I think it's a documentation clarification rather than a bug.

(One thing the handler does do is favor front channel over back channel, which comes out of a recommendation in the profile.)

Scott Cantor August 11, 2009 at 9:07 AM

My recollection is that there isn't currently a way to restrict outbound bindings to back channel only in that manner. It's misinterpreting the setting and somewhat surprisingly managing to send back a request because the SOAP message handling uses the same API internally as the front channel.

I'll clean it up and if need be add a setting to make it possible to do back channel only.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Created August 11, 2009 at 7:07 AM
Updated August 17, 2009 at 8:57 AM
Resolved August 12, 2009 at 9:54 AM

Flag notifications