Hi Team,
We are migrating application from .NET to .NET Core. We are using respective component space library licensed version for .NET Core. We are consuming SAML response from Identity provider with .NET core below statement. I am facing below issue while receiving SSO response.
await _samlServiceProvider.ReceiveSsoAsync();
ERROR Message from Seri log:
11:34:02 ERR] Receiving an SSO response from a partner identity provider has failed.
ComponentSpace.Saml2.Exceptions.SamlSignatureException: The SAML response signature failed to verify.
at ComponentSpace.Saml2.SamlServiceProvider.VerifySamlResponseSignatureAsync(XmlElement samlResponseElement)
at ComponentSpace.Saml2.SamlServiceProvider.ProcessSamlResponseAsync(XmlElement samlResponseElement, String relayState)
at ComponentSpace.Saml2.SamlServiceProvider.ReceiveSsoAsync()
Id = 416, Status = Faulted, Method = “{null}”, Result = “{Not yet computed}”
AsyncState: null
CancellationPending: false
CreationOptions: None
Exception: InnerException = {“The SAML response signature failed to verify.”}
Id: 416
Result: null
Status: Faulted
SAML response received properly but while decryption it is raising above error. I can see received SAML response while debugging. I verified both certificates, client public certificate and our private certificate. Those are proper. Made sure those are installed on server. Please refer attached file “SAML Configuration Code.txt” for SAML configuration that I am using for receiving this response.
Adding Encryption algorithm tags from response as error is related to signature verification failure.
<saml:EncryptedAssertion xmlns:saml=“urn:oasis:names:tc:SAML:2.0:assertion”>
<EncryptedData Type=“<a href=“http://www.w3.org/2001/04/xmlenc#Element” “=””><a href=“http://www.w3.org/2001/04/xmlenc#Element”“>http://www.w3.org/2001/04/xmlenc#Element” xmlns=“”=“”>“>http://www.w3.org/2001/04/xmlenc#”>
<EncryptionMethod Algorithm=“<a href=“http://www.w3.org/2001/04/xmlenc#tripledes-cbc” “=””><a href=“http://www.w3.org/2001/04/xmlenc#tripledes-cbc”“>http://www.w3.org/2001/04/xmlenc#tripledes-cbc” />
<KeyInfo xmlns=“”=“”>“>http://www.w3.org/2000/09/xmldsig#”>
<EncryptedKey xmlns=“”=“”>“>http://www.w3.org/2001/04/xmlenc#”>
<EncryptionMethod Algorithm=“<a href=“http://www.w3.org/2001/04/xmlenc#rsa-1_5” “=””><a href=“http://www.w3.org/2001/04/xmlenc#rsa-1_5"”>http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns=“”=“”>“>http://www.w3.org/2000/09/xmldsig#”>
To verify algorithms, tried below settings for partner identity provider configurations as well-
SignAuthnRequest = true,
SignatureAlgorithm=“<a href=“http://www.w3.org/2000/09/xmldsig#rsa-sha1",">http://www.w3.org/2000/09/xmldsig#rsa-sha1”,
DigestAlgorithm=”<a href=“http://www.w3.org/2000/09/xmldsig#sha1",">http://www.w3.org/2000/09/xmldsig#sha1”,
DataEncryptionAlgorithm=“<a href=“http://www.w3.org/2001/04/xmlenc#tripledes-cbc",">http://www.w3.org/2001/04/xmlenc#tripledes-cbc”,
KeyEncryptionAlgorithm=”<a href=“http://www.w3.org/2001/04/xmlenc#rsa-1_5",">http://www.w3.org/2001/04/xmlenc#rsa-1_5”,
Just want to add one point. Client certificate is expired. I think this should not create any problem because it is working fine with .NET implementation.
Please let me know what can be probable cause of this error and way to resolve this error. Thank you!
Regards,
Vijayendra
An expired certificate won’t be the issue.
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/7936/Enabling-SAML-Trace
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/7936/Enabling-SAML-Trace
Attached SAML trace for your reference. Please let me know if you need additional details.
Regards,
Vijayendra
Thanks for the log. I tried verifying the signature here and confirmed it wouldn’t verify.
If you take a look at the SAML response XML from the log, you’ll see that it’s formatted with newlines and other whitespace characters. This is perfectly valid as long as this is done before signing. Typically when we see a signature failure like this, it’s because of the formatting of the XML.
I also see that the SAML response was sent using Postman. I presume a SAML response was saved and resent using Postman. That’s ok as long as the original XML hasn’t been modified. However, you will run into other issues as we check various timestamps and for replay attacks.
I suggest testing against the real identity provider. The signature should then verify.