I have an issue with validation of a response signature that I’ve been unable to work out despite my diagnostics.
ComponentSpace.SAML2 v6.1
I’m using the low-level API to validate a SAML response from a Ping Federate Identity Provider. At the most basic level I get a failure to verify the response signature.
If I ignore the response signature failure, and go on to both decrypt and verify the assertion signature, then I get a successful verification for the assertion.
What’s strange is that I can see that the certificate included in the assertion (once decrypted) and the certificate included in the response are the same (and match the certificate that I’m using to perform the verification).
Having enabled ComponentSpace’s tracing, I can see that nothing in those logs are showing any problems, and in fact the call into the .NET framework’s System.Security.Cryptography.Xml.SignedXml.CheckSignature() is where the failure is ultimately coming from.
Enabling the tracing in the System.Security.Cryptography.Xml.SignedXml only really logs the fact that the signature is not valid without any other obvious errors.
Some Java implementations, such as PingFederate, make use of Apache XML Security for XML signature generation.
An update to the Apache XML Security library results in the inclusion of carriage return characters as either “
” or “ ” entity references.
This is perfectly valid but unfortunately the System.Security.Cryptography.Xml.* classes used for XML signature verification have a bug that’s related to the canonicalization of the XML prior to signature verification.
We’ve reported the issue with the carriage returns to Microsoft.
We’re encouraging customers impacted by this issue to add a comment to the bug report to express the importance of a fix to them.
Firstly, I suggest taking the look at the XML using Notepad etc to confirm carriage return character entity references are included.
Assuming they are, one workaround is to have the identity provider update “org.apache.xml.security.ignoreLineBreaks” in run.properties file from “false” to “true”. This stops the inclusion of these carriage return character entity references.
If this isn’t possible, simply ignore the SAML response signature and verify the SAML assertion signature instead. This doesn’t introduce any security issues as it’s the SAML assertion that carries the actual user identity information.
Hey - thanks for the detailed reply. It’s really interesting that there’s a potential for this kind of incompatibility. I had no idea and knowing is half the battle!
I’ve verified that indeed I do see line endings in the XML, so I’m confident that this is the problem.
Out of interest, if it’s the “fault” of the updated Apache library, why does the assertion signature seem unaffected?
I’ll certainly add my comments to the issue thread. Although if the bug is in the .NET framework and not the WinAPI cryptography layer, I am not hopeful I’ll ever see a fix.
@ComponentSpace Just wondering if you have any real-world threats to effectively ignoring the Response signature and just going off the Assertion signature?
There’s a lot of concern in our sec team that the only workaround I have is to ignore a security feature. For instance, I could see how it could potentially allow a bad actor to construct a valid Response message that includes a Status of “urn:oasis:names:tc:SAML:2.0:status:Success” from a message that has, say, “urn:oasis:names:tc:SAML:2.0:status:RequestDenied”.
You could modify the Response and the assertion would verify based on the inner signature but the identity should not be granted access to the Service Provider.
A “urn:oasis:names:tc:SAML:2.0:status:RequestDenied” SAML response wouldn’t include a SAML assertion. SAML responses should only ever include a SAML assertion if the status is “urn:oasis:names:tc:SAML:2.0:status:Success”.
It’s true that an attacker could modify some part of the SAML response but I can’t think of anything that would prove to be a useful attack. The important information is contained in the SAML assertion which is signed. Many identity providers sign the SAML assertion only.