End user error message

When this problem occurs, the following error may be displayed in the RSA SecurID Access Portal:

Application appears to be improperly configured. Contact your Administrator for assistance.

As this is a generic error message, it can occur for other reasons also. The symplified.log (available from View Log for the Identity Router in the Cloud Administration Console, or in the bundle logs) and/or a trace of the HTTP GET request should also be checked to confirm root cause of the issue. 

The symplified.log

The symplified.log of the IDR that received the AuthnRequest will have the following events logged at the time of the authentication attempt:​

DEBUG com.symplified.adapter.authn.Saml2PingDirectPostAssertionHandler[400] - Handler is configured to expect a digital signature on the inbound SAML AuthNRequest.
ERROR com.symplified.adapter.authn.SamlUtils2_0[1258] - SAML AuthNRequest was not signed, and no signature could be inherited from an enclosing SAML Element.
ERROR com.symplified.adapter.authn.Saml2PingDirectPostAssertionHandler[408] - Inbound SAML AuthNRequest should have been signed, but no valid signature was found.
ERROR com.symplified.service.appliance.idp.IdPServlet[92] - Unexpected exception thrown by IdP service: 
com.symplified.service.appliance.idp.AssertionCreationException: APPLICATION_AUTHENTICATION_ERROR

Note: ​The first line shown above as a DEBUG line will only appear if debug logging is enabled for the IDR.
 

HTTP GET trace

An HTTP Redirect binding means that the SAML request must be encoded and sent in the query string of the URL of an HTTP GET request.  The HTTP GET request can be examined if you are able to trace and decrypt the HTTP messages for the authentication attempt, which is most easily done from the end user's device.  The end user's browser is where the request from the application is redirected to the IDR.  

When a SAML AuthnRequest is signed, it means it is sent with an XML digital signature.  For a signed SAML request with an HTTP Redirect binding, the query string will contain SigAlg and Signature field-value pairs, in addition to the mandatory SAMLRequest and idp_id field-value pairs.  So, using the HTTP Redirect binding, a SAML AuthnRequest will have this format:

https://sso.mycompany.com/IdPServlet?idp_id=<IDP identifier>&SAMLRequest=<encoded AuthnRequest>&SigAlg=<signature algorithm URI>&Signature=<encoded signature>

The presence of the Signature field-value pair indicates that the request is signed.  The SigAlg field-value pair should also be present when the request is signed.

• Change the application's SAML configuration so that it does not sign SP-initiated AuthnRequests sent with the HTTP Redirect binding (that is, no Signature or SigAlg attribute should be sent with the AuthnRequest)
• Change the application's SAML configuration so that it uses the HTTP POST binding.  You will also need to edit the application's configuration in the RSA Cloud Administration Console, to change it to an HTTP POST binding.
• In the RSA Cloud Authentication Service, use a Service Provider (Relying Party) configuration, instead of a SAML Application configuration.  A  Relying Party Service Provider solution supports signed requests with the HTTP Redirect binding, but it does not provide single-sign on.  It allows the application to be protected with an access policy and multifactor authentication.

Note: Do not sign the AuthNRequests sent to the identity router by way of the Redirect binding.

• When configuring SAML applications with an SP-initiated HTTP Redirect binding, note RSA® SecurID Access Known Issue number NGX-18007 .
• When a SAML request with HTTP Redirect binding is sent to the IDR with a signature, the wording of the ERROR messages in the symplified.log indicate that no signature can be found. This is expected behavior due to the way the message is processed internally by the IDR,