Shibboleth Developers

[Jim Fox <>]

There is a test shell script in the svn repository (doc/testecp.sh) that 
shows how the soap messages are handled.

Jim

On Sep 12, 2010, at 11:32 AM, Scott Cantor wrote:

>> 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
> 
>