Shibboleth Developers

[Ian Young <>]

I am moving towards putting AA signing support in our federation 
metadata, so I'm checking my understanding of it and doing some 
experiments.  I'd welcome any clarifications and corrections on the 
following, which represents my current understanding, and any ideas as 
to why the experiment I ran didn't work in practice.

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

On the SP side, obviously 1.2 supported a signature on the auth 
response, but did it support signatures at any of the other three 
points?  I have a feeling that something changed in 1.3 in this regard, 
but I don't remember exactly what it was.

In the 1.2 IdP, we had four RelyingParty attributes to select signing or 
not in each of those four circumstances, with the default being that 
only the auth response was signed.

In 1.3, this page documents the way the IdP configuration now works:

https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/IdPRelyingConfig

"signAssertions: If this boolean attribute has a value of true, all 
assertions generated for transport to this relying party will be signed. 
This is mostly useful for using the attribute assertion in contexts 
outside of the Shibboleth flows and defaults to false."

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

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.

So much for the theory... does all this ring true or have I missed 
something?

On to the practical section.  I tried tweaking metadata for an SP to add 
@WantAssertionsSigned="true", and am able to see that the auth response 
and auth assertion are both signed.  At the SP (1.3-8) I can see the 
whole authn message (I have lots of logging turned on) and I can see 
both signatures being verified and path validated.  The diagnostics for 
the assertion go like this:

        passing signed authentication assertion to trust layer
        validating signature with KeyDescriptors
        failed to validate signature with KeyDescriptors

...this is sensible, there are no keys in this metadata, just cert names...

        validating signature using certificate from within the signature
        signature verified with key inside signature,
                attempting certificate validation...
        comparing certificate to KeyDescriptors
        [...]
        matched subject CN to a key name (idp.iay.org.uk)
        performing certificate path validation...
        building CA list from KeyAuthority extension
        successfully validated certificate chain

... and so on.  This seems to be what I'd expect.

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).  Immediately after the soap line in the log, I 
can see:

        validating signature with KeyDescriptors
        failed to validate signature with KeyDescriptors
        validating signature using certificate from within the signature
        signature failed to verify, error messages follow
                Reference URI="...." failed to verify
        failed to verify signature with embedded certificates
        signed assertion failed to validate, removing it

And indeed I end up with no attributes presented to the application. 
Now, comparing with the auth assertion case this looks like it hasn't 
got as far as looking in the metadata for AA KeyDescriptors, the 
signature itself is showing up as invalid.

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

    -- Ian