When an application is configured in the RSA SecurID Access Cloud Administration Console to be SAML SP-initiated with an HTTP Redirect binding, any signed AuthnRequest sent for that application to the RSA Identity Router (IDR) will be rejected by the IDR. This issue can be confirmed as root cause of an authentication problem by checking the items described below.
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 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 - Handler is configured to expect a digital signature on the inbound SAML AuthNRequest.
ERROR com.symplified.adapter.authn.SamlUtils2_0 - SAML AuthNRequest was not signed, and no signature could be inherited from an enclosing SAML Element.
ERROR com.symplified.adapter.authn.Saml2PingDirectPostAssertionHandler - Inbound SAML AuthNRequest should have been signed, but no valid signature was found.
ERROR com.symplified.service.appliance.idp.IdPServlet - Unexpected exception thrown by IdP service:
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:
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.
To allow end users to authenticate for the affected application, any one of the following actions can be taken:
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)
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.
For SAML applications for single sign on, RSA SecurID Access does not support signed SAML SP-initiated AuthnRequests with the HTTP Redirect binding. Only unsigned SP-initiated AuthnRequests are accepted.
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,