Shibboleth Developers

["Scott Cantor" <>]

> Currently the ECP implementation in the Shibb IdP plugin seems to sign
> the entire SOAP message rather than just the body.

I'd be very surprised if that were the case, I don't recall discussing any
profile for doing that. Can you post a sample? I'm only aware of us allowing
for signatures over SAML objects, either the Response or the Assertion.
Neither involves SOAP, body or otherwise. Is there perhaps a buggy signature
using a URI of "" instead of a fragment reference?

> This is a problem as
> that leaves us unable to re-insert the RelayState headers in the SOAP
> message before sending the IdP's response back to the SP.

Well, no. That would be incorrect anyway. the client does NOT send the SOAP
message from the IdP to the SP, it creates its own SOAP message and adds the
Response from the Body of the IdP's message to that message along with some
other headers, such as RelayState. You can't just copy the XML verbatim.

> In our opinion
> this leaves us with two approaches; either modify both the Shibb SP and
> the Shibb IdP plugin to only sign the body of the message,

Something is fishy there. The SP certainly does no signing at the SOAP
layer.

> or modify the
> IdP plugin to not strip the RelayState header.

I don't know what that means. The IdP would never see that header. If it
does, the client has a bug.

> At the moment we have
> taken the simpler approach of only modifying the IdP plugin. This leaves
> the RelayState header in the SOAP message that goes to the IdP. While
> this leaves in extra information that the IdP would not normally know,
> this is only the name of the cookie at the SP end that links the request
> to the protected resource that was initially requested. Since this isn't
> the contents of the cookie and only its name, we didn't think this would
> be a problem.

That is deployment specific, it is not always a cookie name.

> What would be the correct way to handle this interaction?

See above. Something is seriously off.

> Ideally we'd like to be able to keep the RelayState header in the
> message sent to the IdP as this allows modifications to existing clients
> to be much simpler.

Sorry, that's not permitted. If for no other reason than because of the
mustUnderstands in the header blocks. Whether or not we implement proper
SOAP handling in the IdP, you can't implement things in a manner that would
require incorrect SOAP handling.

-- Scott