Hi, A client of ours with an in-house SSO system that they’re using to send a SAML response to our application for logging in is having an issue with “The SAML response signature failed to verify” errors. They say it’s due to extra carriage returns in their signatureValue field where previously their value was all on one line. This seems to me like they messed something up and need to change it back but they’re arguing that I need to strip out the carriage returns from the response on my side of the SAML transaction.
They provide links to a crypto.stackexchange.com question (#61061) here: https://crypto.stackexchange.com/questions/61061/signed-xml-signaturevalue-element-value-hash-in-base64-contains-xd
and this article from w3 here: https://www.w3.org/TR/xml-c14n11/
stating that the receiving application should be able to strip the carriage returns from the XML before parsing.
While I’m trying to get them to tell me what they changed on their end and maybe convince them that something isn’t right, have you seen this before and have a method for clearing out these carriage returns from the response xml? We’re consuming their response using the ComponentSpace.SAML2.dll version 2.6.0.19 via the SAMLServiceProvider.ReceiveSSO() method so aren’t directly touching the content of the response.
While I can’t give a copy of the response for confidentiality reasons I can give you a blurry screenshot so you have an idea what I mean about the carriage returns:
Modifying the XML by adding whitespace characters, such as the carriage returns you describe, after the XML has been signed will invalidate the XML signature.
The canonicalization they’re referring to will not remove these whitespace characters.
There’s nothing you can or should do on your side to correct this.
They need to ensure they don’t modify the XML after signing.
The canonicalization they're referring to will not remove these whitespace characters.
There's nothing you can or should do on your side to correct this.
They need to ensure they don't modify the XML after signing.
They say they aren't modifying the xml after signing and that the change was upgrading their SSO framework to the next version. I don't see how they could get the above result without modifying the xml after signing (I don't remember ever seeing a signature with blank lines in it) and since it's an in-house IDP they built I suspect someone made a mistake in what order they do things. We'll see if I'm told to find a way to make it work anyway. Maybe I can get them to tell me what framework they're using.
The canonicalization they're referring to will not remove these whitespace characters.
There's nothing you can or should do on your side to correct this.
They need to ensure they don't modify the XML after signing.
They say they aren't modifying the xml after signing and that the change was upgrading their SSO framework to the next version. I don't see how they could get the above result without modifying the xml after signing (I don't remember ever seeing a signature with blank lines in it) and since it's an in-house IDP they built I suspect someone made a mistake in what order they do things. We'll see if I'm told to find a way to make it work anyway. Maybe I can get them to tell me what framework they're using.[/quote]
They replied with
[quote]To clarify – the XML is not being modified after being signed, the carriage returns are in the signature itself.
The SSO team will not divulge the name of the framework they’re using, citing security reasons.
They are considering this to be a bug on the .NET side. Incidentally, it is working fine with Java.[/quote]
I'll be doing my own research but please let me know if this rings any bells or if you have any info that may help me. That it's "working fine with Java" at least gives me something to use in my search terms.
In case there’s some additional information you need that’s in there, here’s a sanitized copy of the response xml they provided with the key, signature, and identifiable values replaced with meaningless utterance (a.k.a. blah or equivalent).
Please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
We can then check the signature using utilities we’ve written in .NET and Java.
That way we can independently check the signature.
If it fails in .NET and Java it’s very unlikely to be a bug at our end.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
We can then check the signature using utilities we've written in .NET and Java.
That way we can independently check the signature.
If it fails in .NET and Java it's very unlikely to be a bug at our end.
The client is pushing back on this as well. If I give you an un-obfuscated copy of the request XML they gave me, would your validation tool be able to test with that? If so is there a secure method I could use to send it to you so it isn't hanging out here on the support forum? I'll check this after hours today to avoid wasting another day between responses.
Either way thanks for working with me on this, I can only apologize for the lack of information and share in the frustration.
Yes. Please email the XML as a file attachment to support@componentspace.com mentioning the forum post.
You should receive the file shortly.
I replied to your email.
I ran our two XML signature verification utilities and neither could verify the XML signatures.
This means neither the C#/.NET framework implementation nor the Java implementation could verify the signatures.
If the carriage returns have been added after signing, this will invalidate the signatures.
Canonicalization will not strip these carriage returns and the application should not have to do this explicitly.
If the carriage returns are present prior to signing, this is perfectly valid although not common.
However, the signatures would have then verified.
I suggest going back to the IdP with this information.
The client continues to insist that there is a .net bug that needs to be fixed, following is their argument.
[quote]
I referred this back to our SSO team and they remain convinced that this is an issue on [your] side, as per their message below.
“Just Google for “line breaks in digital signatures” and you will find this issue only happens with dot Net
https://www.aleksey.com/pipermail/xmlsec/2010/008921.html
1) File a bug against Microsoft. XMLDsig spec
(http://www.w3.org/TR/xmldsig-core) refers to RFC 2045
(http://www.ietf.org/rfc/rfc2045.txt) which describes base64 encoding/decoding in section 6.8:
“The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 must be ignored by decoding software. In base64 data, characters other than those in Table 1, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances.””
[/quote]If there’s a bug in the .NET framework there’s also a bug in Java.
We are confident there’s not a bug in either platform.
Line breaks in the signature are fine if these are in place at the time the signature is generated.
If line breaks are added after the signature these will invalidate the signature.
This presumably is what the IdP is doing.
We don’t have issues with verifying XML signatures from any of the major SAML offerings.
We occasionally see issues with in-house implementations.
Given this was working before they added the line breaks, I suspect this is the case here.
I’m happy to provide the source code to our Java utility so you and the IdP can confirm what I’m saying.
We are confident there's not a bug in either platform.
Line breaks in the signature are fine if these are in place at the time the signature is generated.
If line breaks are added after the signature these will invalidate the signature.
This presumably is what the IdP is doing.
We don't have issues with verifying XML signatures from any of the major SAML offerings.
We occasionally see issues with in-house implementations.
Given this was working before they added the line breaks, I suspect this is the case here.
I'm happy to provide the source code to our Java utility so you and the IdP can confirm what I'm saying.
I think that source code would be quite helpful, actually. Please do share.
Would you be able to attend a phone/web meeting with us and our client to discuss this matter with their SSO team and hopefully come to some agreement on how to best handle this?
Please contact support@componentspace.com.
However, I’m not sure there’s a lot that we can do on our side.
As shown, neither .NET nor Java can verify their signatures.
Their implementation is wrong as adding line breaks after signing invalidates the signature.
They need to correct their implementation.