Shibboleth Developers

[Andrew Seales <>]

Hi,

Thanks for your feedback. We generated some new test cases and found a 
mistake in out client so it looks like the IdP ECP plugin is behaving 
correctly after all.

Andrew

On 12/09/10 19:32, 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
>
>
>
>    


--
Andrew Seales

EDINA                   tel: +44 (0) 131 650 3022
Edinburgh University    fax: +44 (0) 131 650 3308
Causewayside House      url: http://edina.ac.uk
160 Causewayside        email: 

Edinburgh EH9 1PR


The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.