Troubleshooting: SAML Assertion Encryption Errors

Version Affected: All
 
 

Overview

SAML Assertion encryption can fail in a few different ways when it is enabled on a realm’s Post Authentication tab — an exception is thrown while encrypting the assertion, or the assertion is sent without ever being encrypted at all. There are several independent causes, each with its own error signature:

• See Cause 1 - The Audit log or Debug log shows an exception ending in System.Convert.FromBase64String
• See Cause 2 - The Audit log or Debug log shows an exception ending in ComponentSpace.SAML2.Assertions.EncryptedAssertion..ctor
• See Cause 3 - No exception is thrown, but the SAML assertion is still sent in plain text

These causes are not related, so a fix for one will not resolve another.

 

In this article

• Cause 1: Encryption certificate is not in Base64 format
• Cause 2: SAML Data/Key Encryption Method is set to a hashing algorithm
• Cause 3: SAML Assertion is not also signed

Cause 1: Encryption certificate is not in Base64 format

Encrypting the SAML assertion fails, and the Audit log or Debug log shows an exception similar to:

Error: at System.Convert.FromBase64_Decode(...)
at System.Convert.FromBase64CharPtr(...)
at System.Convert.FromBase64String(String s)
at MFC.SAML20.SAMLUtil.EncryptAssertion(XmlElement xmlSAMLAssertion, String SAMLEncryptionCert, String SAMLKeyEncryptionMethod, String SAMLEncryptionMethod)

The certificate blob pasted into the realm’s Encryption Cert field (Post Authentication tab) is not valid Base64 — typically because the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- header and footer lines were left in when the certificate was pasted.

Resolution 1:

To resolve this:

1. Export the certificate from the IdP in Base64 encoded format and open it in a text editor.
2. Copy only the blob between the header and footer lines (the highlighted text below), not the header and footer lines themselves.

3. Paste that blob into the realm’s Encryption Cert field on the Post Authentication tab, as shown below, and save.

Cause 2: SAML Data/Key Encryption Method is set to a hashing algorithm

Encrypting the SAML assertion fails, and the Audit log or Debug log shows an exception similar to:

SAML20IdPInit exception error: Failed to encrypt SAML assertion., stack: at ComponentSpace.SAML2.Assertions.EncryptedAssertion..ctor(XmlElement samlAssertion, X509Certificate2 x509Certificate, EncryptionMethod keyEncryptionMethod, EncryptionMethod dataEncryptionMethod)
at MFC.SAML20.SAMLUtil.EncryptAssertion(XmlElement xmlSAMLAssertion, String SAMLEncryptionCert, String SAMLKeyEncryptionMethod, String SAMLEncryptionMethod)

The realm’s SAML Data Encryption Method and/or SAML Key Encryption Method (Post Authentication tab) is set to a hashing algorithm, such as SHA, instead of an actual encryption algorithm.

Resolution 2:

To resolve this:

1. On the realm’s Post Authentication tab, set SAML Data Encryption Method to XmlEncAES256Url and SAML Key Encryption Method to XmlEncAES256KeyWrapUrl, as shown below — both are AES-based, not hashing algorithms.

2. Save the realm and test again.

Cause 3: SAML Assertion is not also signed

No exception is thrown, but despite Encrypt SAML Assertion being set to True on the Post Authentication tab, the SAML assertion is still sent in plain text.

An encrypted SAML assertion must also be signed — encryption alone does not take effect unless Sign SAML Assertion is also enabled.

Resolution 3:

To resolve this:

1. On the realm’s Post Authentication tab, set Sign SAML Assertion to True, as shown below, in addition to Encrypt SAML Assertion.

2. Save the realm and confirm the assertion is now encrypted.

See also How To: Encrypt a SAML Assertion for the steps to enable SAML assertion encryption in the first place.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.