Helllo,
We have been trying to test SAML 2.0 for one of our client and SAMLMessageSignature.Verify method returns always FALSE.
I tried using both versions of this method. We are using SAML 2.0 NET 4 version dlls.
as few posts suggest, I tried with xdoc.PreserveWhitespace = true and also with xdoc.PreserveWhitespace = false to make sure I am checking for white spaces too…
public static bool Verify(XmlElement xmlElement);
public static bool Verify(XmlElement xmlElement, X509Certificate2 x509Certificate);
I uploaded the SAML on google drive
https://drive.google.com/file/d/1GtT6OZBHW_zzRJTLFL56ZATZiRhCfwCP/view?usp=sharing - NOT WORKING
Here is one more file that is working fine that was generate using separate certificate
https://drive.google.com/file/d/1XvJ5mjNT9cxpg3SGGu9WKh6YyJ917dah/view?usp=sharing - WORKING
We tried to enable the trace by following link but it is not generating any trace file.
<ahref=“https: www.componentspace.com=”" forums=“” 17=“” enabing-saml-trace"=“”>https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Can anyone please look into attached files and let me know what’s missing here?
Appreciate the help!
</ahref="https:>
I downloaded the not working test.xml and wasn’t able to verify the signature either.
I tried our .NET utility as well as equivalent Java utility.
Neither could verify the signature using the embedded certificate.
The most likely cause is that the XML has been modified after signing.
You always need to set XmlDocument.PreserveWhitespace to true.
If you don’t, Microsoft will invalidate the signature by adding whitespace characters as formatting.
I also tried the working SAML Response 256.xml but this failed to verify.
If you open this file in Notepad you’ll see it’s formatted so that most likely explains why that file’s signature doesn’t verify.
How did you create test.xml?
Was it supplied to you or did you capture it? If so, how?
[quote][/quote]
I downloaded the not working test.xml and wasn't able to verify the signature either.
I tried our .NET utility as well as equivalent Java utility.
Neither could verify the signature using the embedded certificate.
The most likely cause is that the XML has been modified after signing.
You always need to set Xmldocument.PreserveWhitespace to true.
If you don't, Microsoft will invalidate the signature by adding whitespace characters as formatting.
I also tried the working SAML Response 256.xml but this failed to verify.
If you open this file in Notepad you'll see it's formatted so that most likely explains why that file's signature doesn't verify.
How did you create test.xml?
Was it supplied to you or did you capture it? If so, how?
I tried our .NET utility as well as equivalent Java utility.
Neither could verify the signature using the embedded certificate.
The most likely cause is that the XML has been modified after signing.
You always need to set Xmldocument.PreserveWhitespace to true.
If you don't, Microsoft will invalidate the signature by adding whitespace characters as formatting.
I also tried the working SAML Response 256.xml but this failed to verify.
If you open this file in Notepad you'll see it's formatted so that most likely explains why that file's signature doesn't verify.
How did you create test.xml?
Was it supplied to you or did you capture it? If so, how?
Thanks for checking.. Here is more info.
in our App, Client send us the base64 string in the request and then we convert that string into XML using this method. Unfortunately, we store only XML data in log table and I provided you the xml ( test.xml) from log table without any formatting.
xmlElement= ComponentSpace.SAML2.Utility.SAML.ToXmlElement(Encoding.UTF8.GetString(Convert.FromBase64String(base64String)));
and so, we are not setting PreserveWhitespace flag on our Prod
BUT in our test utility, when we verify the SAML, We take the SAML from log table and then use PreserveWhitespace = TRUE and test it.
"SAML Response 256.txt" - SAML has the formatting and our test utility validated it when PreserveWhitespace was set to FALSE.
I copied the unformatted version of same SAML here
"SAML Response 256_No Formatting.xml" -> https://drive.google.com/file/d/1GsFTxbT3azIbylqrnDUrYUjC1LE4RDys/view?usp=sharing
Test.xml is not validating in any scenario - https://drive.google.com/file/d/1GtT6OZBHW_zzRJTLFL56ZATZiRhCfwCP/view?usp=sharing
Do you think it would help if I get the base64 string from client and share with you?
[quote][/quote]
I downloaded the not working test.xml and wasn't able to verify the signature either.
I tried our .NET utility as well as equivalent Java utility.
Neither could verify the signature using the embedded certificate.
The most likely cause is that the XML has been modified after signing.
You always need to set Xmldocument.PreserveWhitespace to true.
If you don't, Microsoft will invalidate the signature by adding whitespace characters as formatting.
I also tried the working SAML Response 256.xml but this failed to verify.
If you open this file in Notepad you'll see it's formatted so that most likely explains why that file's signature doesn't verify.
How did you create test.xml?
Was it supplied to you or did you capture it? If so, how?
I tried our .NET utility as well as equivalent Java utility.
Neither could verify the signature using the embedded certificate.
The most likely cause is that the XML has been modified after signing.
You always need to set Xmldocument.PreserveWhitespace to true.
If you don't, Microsoft will invalidate the signature by adding whitespace characters as formatting.
I also tried the working SAML Response 256.xml but this failed to verify.
If you open this file in Notepad you'll see it's formatted so that most likely explains why that file's signature doesn't verify.
How did you create test.xml?
Was it supplied to you or did you capture it? If so, how?
Thanks for checking.. Here is more info.
in our App, Client send us the base64 string in the request and then we convert that string into XML using this method. Unfortunately, we store only XML data in log table and I provided you the xml ( test.xml) from log table without any formatting.
xmlElement= ComponentSpace.SAML2.Utility.SAML.ToXmlElement(Encoding.UTF8.GetString(Convert.FromBase64String(base64String)));
and so, we are not setting PreserveWhitespace flag on our Prod
BUT in our test utility, when we verify the SAML, We take the SAML from log table and then use PreserveWhitespace = TRUE and test it.
"SAML Response 256.txt" - SAML has the formatting and our test utility validated it when PreserveWhitespace was set to FALSE.
I copied the unformatted version of same SAML here
"SAML Response 256_No Formatting.xml" -> https://drive.google.com/file/d/1GsFTxbT3azIbylqrnDUrYUjC1LE4RDys/view?usp=sharing
Test.xml is not validating in any scenario - https://drive.google.com/file/d/1GtT6OZBHW_zzRJTLFL56ZATZiRhCfwCP/view?usp=sharing
Do you think it would help if I get the base64 string from client and share with you?
[/quote]
I shared both XML and Base64 string here
SAML_Base64_0830_NotWorking.txt ----------------https://drive.google.com/file/d/1hneTZtlTKuZXQQGIiffum5PDYGu5HTUv/view?usp=sharing
SAML_XML_0830_NotWorking.txt---------------------https://drive.google.com/file/d/1_oMdy7xsXfosTaQfKl7rjU-XaC0-mob1/view?usp=sharing
Any suggestions to enable to trace? I do not see any other way to debug this...
I downloaded the base-64 encoded string, decoded it and attempted to verify the SAML response signature.
This failed to verify using both our .NET and Java signature verification utilities.
The SAML response has at least two issues I could see.
There’s no Issuer child element to the SAML response. This should appear immediately prior to the signature but is missing.
The Reference URI is missing. This should be set to the SAML response ID.
Are they using a commercial SAML product?
I suspect they might not be and that their implementation is wrong.
I suggest going back to your client and mentioning the Issuer and Reference URI problems.
Also supply them with the base-64 string and ask if they can verify the signature.
I’m certain the problem lies at their end.
[quote][/quote]
I downloaded the base-64 encoded string, decoded it and attempted to verify the SAML response signature.
This failed to verify using both our .NET and Java signature verification utilities.
The SAML response has at least two issues I could see.
There's no Issuer child element to the SAML response. This should appear immediately prior to the signature but is missing.
The Reference URI is missing. This should be set to the SAML response ID.
Are they using a commercial SAML product?
I suspect they might not be and that their implementation is wrong.
I suggest going back to your client and mentioning the Issuer and Reference URI problems.
Also supply them with the base-64 string and ask if they can verify the signature.
I'm certain the problem lies at their end.
This failed to verify using both our .NET and Java signature verification utilities.
The SAML response has at least two issues I could see.
There's no Issuer child element to the SAML response. This should appear immediately prior to the signature but is missing.
The Reference URI is missing. This should be set to the SAML response ID.
Are they using a commercial SAML product?
I suspect they might not be and that their implementation is wrong.
I suggest going back to your client and mentioning the Issuer and Reference URI problems.
Also supply them with the base-64 string and ask if they can verify the signature.
I'm certain the problem lies at their end.
Hello ComponentSpace Development - I asked our client to try your suggestions above and it worked!!
They sent us the request with correct Issuer and URI values and it passed through the validation.
Thanks for your help, Cheers..
Thanks for the update.