Shibboleth Developers

["Scott Cantor" <>]

> SAML 1.1 allows signing either at the level of the Response, and 
> independently at the level of the Assertion.  In the Shibboleth 
> Browser/POST profile, we have two messages from the IdP to the SP, and 
> at least in principle there are therefore four things that might be 
> signed (auth response, auth assertion, attr response, attr assertion).

This depends on whether attributes are present in the original response, but
you know that.

> Now, it seems that the auth response is always signed, you can flip 
> signing on for both assertions (not independently) and you don't have 
> the ability to sign the attr response any more (of course, you don't 
> need it because the TLS channel gives you this functionality).

It was mainly a confidentiality thing. I find it hard to understand how TLS
can provide meaningful confidentiality without also authenticating the
endpoint, which is what makes the signing pointless.

Others seem to think this is false, that lack of peer authentication doesn't
negate the confidentiality. I think this is only true in the strictest
sense, but not in an application sense of the word. Feedback on this would
be welcome.

> As well as the RelyingParty configuration at the IdP, the 1.3 IdP will 
> sign assertions if the SPSSODescriptor in the metadata has a 
> @WantAssertionsSigned attribute set to "true", but again this applies to 
> both assertions.

Wow. Didn't know Walter had implemented that.

> Now, the signed attribute assertion does not go so well. My log results 
> for the attribute response are incomplete: I can see the start of the 
> response, at <soap:Envelope> but the log info ends after 5725 chars 
> round about the time the signature is about to start (there are lots of 
> attributes in there, the Content-Length is 7990).  I guess the log line 
> must be limited in some way (not a big surprise if so, although 5725 
> seems a bit arbitrary).

I think you're seeing libcurl output, not mine. I don't dump the SOAP
myself, I don't think. libcurl probably truncates the trace, or perhaps it's
caused by the code I added to deal with libcurl sending me binary trace
data. Could be the linefeed, I'll check that.

> Any ideas as to why this signature is failing to verify, or whether that 
> is actually what I'm seeing?

Sounds like it. I just turned on WantAssertionsSigned for wayf, and tested
it. It worked fine once I added a KeyDescriptor to the AttributeAuthority
role. Did you do that?

-- Scott