Troubleshooting: SP-Initiated by POST Fails with a Generic 'Error Has Been Logged' Message

Version Affected: All
 
 

Overview

When using SP-initiated by POST, the SAMLRequest (AuthN request) is successfully posted, but the user sees only a generic Error has been logged message. This is a generic custom error page shown for most unhandled exceptions or errors -- the actual underlying exception may only be visible in the realm's Error log or browser stack trace once Custom errors have been turned off.

Cause

Because Error has been logged is shown for most unhandled exceptions or errors, there's no single cause -- check the Error log, or turn off Custom errors to see the exception and stack trace directly in the browser, to identify what's actually failing. One confirmed cause: the AuthN request is missing an Issuer element, which logs as SAML20SPInitPost Error in SSO service, error: Object reference not set to an instance of an object., with a stack trace pointing to SAML20SPInitPost.CreateSAMLResponse. A different logged exception points to a different cause.

Resolution:

Identify the actual exception first, using either of the following:

• Check the realm's Error log around the time of the failure.
• On the realm's Logs tab in the Web Admin Console, temporarily turn off Custom errors and reproduce the failure -- this shows the raw exception and stack trace directly in the browser instead of the generic message. Turn it back on once you're done.

Then:

• If it matches the signature above (Object reference not set... in SAML20SPInitPost.CreateSAMLResponse), work with the Service Provider to add an Issuer element to the AuthN request.
• If it shows a different exception, that logged message -- not this one known example -- is what identifies the actual cause and fix.

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.