I’m using xmlseclibs to try and sign a SOAP document, but it does not seem to canonicalize things in the same way depending on whether I’m signing or validating.
I’ll give you an example. This is the XML I am trying to sign:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" IssueInstant="2010-02-04T15:27:43Z" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester"/>
</samlp:Status>
</samlp:Response>
</soapenv:Body>
</soapenv:Envelope>
I got some code working in PHP to sign it using a combination of public key and private key certificates, and it seemed to work. It added the <ds:Signature> element with all the proper stuff, and it looked great. But then I tested it by immediately trying to validate it after signing it, again with xmlseclibs (and the public key certificate), but the validation failed. So the exact same code library is doing both the signing and validating, but the two processes don’t agree for some reason.
I added some debugging code to xmlseclibs to find out what it’s doing, and I realized that the reason the signing key it comes up with and the validation key it comes up with are different are because it canonicalizes things differently in the two situations. When I tell it to sign the <samlp:Response> element, this is the canonical form it signs (I’ve added newlines here for readability):
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester">
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>
However when it goes to validate the signature, this is the canonical form it computes to validate against (again, I’ve added newlines here):
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester">
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>
So as you can see, this version omits the xmlns:saml attribute from the <samlp:Response> element, while the first does not. (Note that this is different from the xmlns:samlp attribute, which is included in both.) This seems pretty clearly like a bug in xmlseclibs, but nonetheless it’s one I’d be happy to fix myself if I just knew which canonical form was the correct one. Should that attribute be omitted by exclusive canonicalization? Or should it be included? Which one is the correct exclusive canonical form?
You are creating the DOM document improperly and trying to use the invalid in-memory tree. Either serialize and use the serialized result or properly create the namespace declarations in the tree before trying to sign. See the bug report for more information: http://code.google.com/p/xmlseclibs/issues/detail?id=6