Forums, Documentation & Knowledge Base - ComponentSpace

Troubleshooting XML Signatures


https://componentspace.com/Forums/Topic28.aspx

By ComponentSpace - 2/20/2014

SAML assertions and protocol messages may include an XML signature. If a signature fails to verify then either the signed XML has been altered in some way or the wrong certificate has been used to perform the verification.
One common problem when manipulating signed XML is to be careful to preserve white-space characters as these characters are significant when generating signatures. Internally, the SAML components ensures white-space is preserved. If you load or manipulate the signed XML, ensure the XML is not modified prior to verifying its signature and specifically ensure white-spaces are preserved.
If signature verification is failing ensure the correct certificate is being used. The certificate is either contained in the XML signature or is loaded from a certificate file or store. If you are using a separately loaded certificate rather than a certificate contained within the XML signature, ensure the certificate is the correct one.

VerifySAML
If you believe the correct certificate is being used you can run a supplied utility, VerifySAML, to see whether the signature can be verified.
For example, to verify the signature on a SAML protocol response you would capture the response to file, ensuring the XML is not altered in any way, and run:
VerifySaml.exe [–c <certificateFileName>] <filename>
The certificateFileName is a CER file containing the certificate to use to verify the signature. Only specify this parameter if the certificate is being loaded from a certificate file or store. If the certificate is included in the XML signature, then do not specify this parameter.
The filename is the file containing the SAML protocol response as XML.
This utility may be used to verify signatures on SAML requests, responses and assertions.

VerifySAML Log File
The VerifySAML utility generates a VerifySAML.log file in the working directory. This includes log entries generated by the .NET framework during signature verification.

If signature verification is successful, the log will include entries like:

System.Security.Cryptography.Xml.SignedXml Verbose: 13 : [SignedMessage#00245fb7, VerifyReference] Reference Reference#003917f2 hashed with "http://www.w3.org/2000/09/xmldsig#sha1" (SHA1CryptoServiceProvider) has hash value a3503180ce819de2efc3a66f9b29b7d2687033ec, expected hash value a3503180ce819de2efc3a66f9b29b7d2687033ec.
System.Security.Cryptography.Xml.SignedXml Information: 9 : [SignedMessage#00245fb7, SignatureVerificationResult] Verification with key RSACryptoServiceProvider#039490e2 was successful

This shows that the calculated hash of the canonicalized XML matches the hash or digest value contained in the XML signature. This confirms that the XML has not been modified.

It also shows that the calculated signature value matches the signature value in the XML signature. This confirms that the XML was signed by the owner or subject of the certificate.

If the XML has been modified after signing, the log will include entries like:

System.Security.Cryptography.Xml.SignedXml Verbose: 13 : [SignedMessage#00245fb7, VerifyReference] Reference Reference#003917f2 hashed with "http://www.w3.org/2000/09/xmldsig#sha1" (SHA1CryptoServiceProvider) has hash value 604bfa74922eb89c25d061a0e9eda3d3f1967d9c, expected hash value a3503180ce819de2efc3a66f9b29b7d2687033ec.
System.Security.Cryptography.Xml.SignedXml Information: 12 : [SignedMessage#00245fb7, VerificationFailure] Verification failed checking references.

This shows that the calculated hash of the canonicalized XML does not match the hash or digest value contained in the XML signature. This means that the XML has been modified.

If the wrong certificate is used to verify the signature, the log will include entries like:

System.Security.Cryptography.Xml.SignedXml Information: 12 : [SignedMessage#00245fb7, VerificationFailure] Verification failed checking SignedInfo.

Java VerifyXMLSignature
A Java application is supplied for independently checking XML signatures. This application may be run using the provided VerifyXMLSignature.bat script file.

The VerifyXMLSignature.bat uses Java 1.6 or better to verify XML signatures.

XML Signatures and Prefixes
Consider the following section of XML:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol/>

The element name is Response; it’s prefixed with samlp; and it’s declared in the urn:oasis:names:tc:SAML:2.0:protocol namespace.

What uniquely identifies this element is its name and namespace. The prefix is a mechanism for linking an element with its namespace declaration.

By conventions samlp is used for the urn:oasis:names:tc:SAML:2.0:protocol namespace although any other prefix would be equally valid.

Java and some other implementations often use the ds prefix for the XML signature namespace. For example:

<ds:Signature xmlns="http://www.w3.org/2000/09/xmldsig#/">

The .NET framework treats the XML signature namespace as the default namespace and consequently doesn’t use a prefix. For example:

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

Both forms, with and without a prefix, are equally valid.

The SAML components support verifying XML signatures that use no prefix, the ds prefix or some other prefix.

XML signatures generated by the SAML components will not include a prefix.

When confronted with XML signature verification issues, some third parties who are familiar with the use of the ds prefix will assume that the missing prefix is the issue. This is not the case and, if it ever were the case, this would indicate poorly implemented XML signature verification at the third party.

By ComponentSpace - 5/22/2020

Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com.

https://www.componentspace.com/Forums/17/Enabing-SAML-Trace