Skip to Content.
Sympa Menu

shibboleth-dev - Re: [Shib-Dev] PAOS/ECP Problems With Signed Messages

Subject: Shibboleth Developers

List archive

Re: [Shib-Dev] PAOS/ECP Problems With Signed Messages


Chronological Thread 
  • From: Jim Fox <>
  • To: "" <>
  • Subject: Re: [Shib-Dev] PAOS/ECP Problems With Signed Messages
  • Date: Sun, 12 Sep 2010 08:53:28 -0700


In your profile configuration for ecp:SAML2ECP set

signResponses="never"
signAssertions="always"

Usually 'signResponses="conditional"' works for me.

Jim

On Sep 12, 2010, at 6:37 AM, Andrew Seales wrote:

> Hi,
>
> We're currently trying to add Shibboleth support to an existing desktop
> client using the PAOS/ECP protocol binding. We've successfully been able
> to do this but we've had to modify the Java IdP ECP plugin to get the SP
> to accept the ECP response from the IdP.
>
> Currently the ECP implementation in the Shibb IdP plugin seems to sign
> the entire SOAP message rather than just the body. 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. 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, or modify the
> IdP plugin to not strip the RelayState header. 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.
>
> What would be the correct way to handle this interaction?
>
> 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. This is relevent because we're trying to convice
> some other software vendors to add support to their existing desktop
> clients for connecting to SAML2 protected resources so simpler client
> modifications is good.
>
> In case it's relevent, we're running our own test federation using
> v2.1.5 of the Shibb IdP and v2.3.1 of the Shibb SP. We are using the ECP
> plugin for the IdP from subversion at r237.
>
> Regards,
> --
> 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
>




Archive powered by MHonArc 2.6.16.

Top of Page