I am signing WS-Security Soap request with SignedXML, but having trouble matching SOAPUI signature value

Question

I am upgrading a previous WCF client that implements WS-Security. The service previously only needed a valid certificate along with a UsernameToken. The provider has changed their requirement and now, in addition to the previous WS-Security elements, now require a Timestamp element and for that element alone to be digitally signed.

I actually believe that I have the enhancements implemented reasonably well. The request "looks good", including the signature. But the service does not accept the request. It doesn't indicate why. But I have determined it is the signature.

I can send the request successfully with SOAP-UI. My belief, since I am only signing the timestamp element, is that I should be able to provide (for testing purposes) the same values of the wsu:Id, wsu:Created, and wsu:Expires as were used in the SOAP-UI request (knowing that these values are stale) and be able to produce the same Signature Value and Reference Digest Value as SOAP-UI generated.

Is this a valid assumption?

One challenge to this assumption is that if I import the entire SOAP envelope into the SignedXML object, I get a different value of the two hashes than I get when I import only the wsse:Security element. This surprises me since the signing process in each case is properly identifying the wsu:Timestamp element.

By properly identifying wsu:Timestamp, I mean that the overload of the GetElementId() method is finding wsu:Timestamp when called.

I will include actual code I have implemented if these basic questions indicate I am on the right track:

I have overridden GetIdElement to make sure that the wsu:Id is recognized.

I am using Framework 4.7.1 and GetRSAPrivateKey() (from an import of the certificate that allows the private key export) to obtain the signing key.

I have created a reference to the wsu:Timestamp element:

<Reference URI="#TS-62B6909D4542C911A415716590862947">
    <Transforms>
      <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
         <InclusiveNamespaces PrefixList="wsse wsu cmaw s soapenv xsd"
                xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
      </Transform>
    </Transforms>
    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
            <DigestValue>TtV9lso1WsMvwhiiKPADpYshmJcb95NZOj6BkuV5UmI=</DigestValue>
</Reference>

I have used:

CryptoConfig.AddAlgorithm(typeof   (RSAPKCS1SHA256SignatureDescription), "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256");

signedXML.SignedInfo.CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl;

I have the "#" at the start of the reference URL (and no "#" at the actual reference.

Anyway, my first question is if I should expect to be able to match the working SOAP-UP signature in a controlled test (stale values) and if it is reasonable that importing the entire soap envelope should produce a different signature than importing just the wsse:Security element (I'm using a Message Inspector for generating the wsse:Security element and, without finding a different way, I don't have access to the entire envelope to give to SignedXML.

Note: I have looked at many good articles here an elsewhere that explain how to sign the messages. But my current challenge is getting a signature that works - which I hope just means matching SOAP-UI.

Thoughts on this?

Answer 1

I eventually determined that the signature value calculated when SignedXml is working with the entire SOAP envelope is different than the signature value calculated when SignedXml is only working with the subset. I do not understand why this is the case since I was only signing the Timestamp element, which was present in both cases and was being properly located by SignedXml. But it isn't necessary that I know this particular "why".

The client works now after this refactoring to sign based on the entire soap envelope..