Federation fails with Unable to get AuthnRequest from cache, sending error response in AM (All versions)

Symptoms

Federation fails when using SP initiated SSO, whereas IdP initiated SSO succeeds. Although the root cause is located on the IdP side, the IdP will send an assertion back to the SP, containing an error message. For that reason, the symptoms will appear on the SP side. If the SP is AM, it will fail with a HTTP 500 error and the following message:

Other SPs may display a different type of error.

On the IdP side, you will see the following entry in the IdP Federation logs at error level:

At message level (or with a SAML Trace if HTTP-POST is used) you will see that the Response sent from the IdP to the SP has a StatusCode set to "Responder". This is a way for the IdP to let the SP know that there has been an issue and that it cannot send the assertion back:

Recent Changes

Bookmarked the IdP Login page.

Changed the cache setting for SAML2.

Passed from IdP initiated SSO to SP initiated SSO.

Added an IdP instance.

Causes

This issue is due to the way AM (acting as the IdP) deals with a SP initiated SSO flow. Upon receiving the Authentication Request, AM keeps a reference to the request in the cache, called the ReqID. It then redirects the user for authentication; upon successful authentication, it creates the assertion and verifies that the reference to the original request exists in the cache. If it does not, it logs the error "Unable to get AuthnRequest from cache, sending error response" and sends a Responder to the SP.

In an IdP initiated SSO, there is no Authentication Request to refer to, which is why using IdP initiated SSO works correctly in this scenario.

There can be various causes for the issue:

• Bookmarks: The user bookmarks the IdP landing page. The URL then holds a stale ReqID. When trying the same flow at a later date, the ReqID is no longer in the cache. Such a bookmark looks like this: https://idp.example.com:8443/am/XUI/#login/&realm=/&forward=true&spEntityID=http%3A%2F%2Fsp.example.com%3A8080%2Fopenam&goto=%2FSSORedirect%2FmetaAlias%2Fidp%3FReqID%3Ds20ea737f864932df1dd3bca2e3c7bd6b598baa420%26index%3Dnull%26acsURL%3Dhttp%253A%252F%252Fsp.example.com%253A8080%252Fopenam%252FConsumer%252FmetaAlias%252Fsp%26spEntityID%3Dhttp%253A%252F%252Fsp.example.com%253A8080%252Fopenam%26binding%3Durn%253Aoasis%253Anames%253Atc%253ASAML%253A2.0%253Abindings%253AHTTP-POST&AMAuthCookie=
• Cache: The cache is too short. By default, the ReqID is kept in the cache for 10 minutes. If the cache has been shortened too much (such as 3 seconds), users will not be able to type in their credentials in time and federation will fail.
• Timeout: Even with the default 10 minute cache in place, there are circumstances where a user leaves their browser open without logging in. When trying later on, federation will fail. This is essentially the same as having a short cache; however, it will only happen occasionally and a retry would solve the issue.
• Pre-AM 6.5.3 : Multiple IdPs exist, but stickiness is not enforced: This will cause issues, possibly intermittent, when the initial authentication request lands on one server and authentication happens on another. The IdP will not be able to find the ReqID in the cache and federation will fail. Sticky load balancing is no longer a requirement in AM 6.5.3; see Session state considerations for further information.

Solution

The solution will depend on the cause:

• Bookmarks: Do not bookmark the IdP login page (the page containing the ReqId value). Users should bookmark the spSSOInit.jsp URL instead, for example: https://sp.example.com:8443/am/saml2/jsp/spSSOInit.jsp?idpEntityID=https%3A%2F%2Fidp.example.com%3A8443%2Fam&metaAlias=/sp
• Cache: Make sure the cache allows enough time to complete the authentication chain. See How do I configure how long the SAML AuthnRequest remains in cache in AM (All versions)? for further information on changing the cache.
• Timeout: Use the IdP initiated SSO to avoid the problem altogether as you cannot increase the cache indefinitely to capture all these instances. Alternatively you can write a custom IdP Adapter that would catch this scenario and, instead of returning an assertion, would interrupt the federation flow and redirect the user to a custom page. The custom page would explain there was an error, ask the user to try to log in again, and provide the link to the spSSOInit.jsp URL as shown in the first bullet.
• Pre-AM 6.5.3: Multiple IdPs exist, but stickiness is not enforced: You should enforce stickiness; if this is not possible, you will need to use the IdP initiated SSO.

See Also

How do I configure how long the SAML AuthnRequest remains in cache in AM (All versions)?

How do I configure IdP or SP initiated Single Sign On in Identity Cloud or AM (All versions)?

How do I redirect to a specific page after a successful IdP or SP initiated login in Identity Cloud or AM (All versions)?

Related Training

N/A

Related Issue Tracker IDs

OPENAM-1194 (Unable to get AuthnRequest error in multiserver setup