It's become evident that a race condition can occur within the agent-authn-tx pre-authentication cookie, which is used to store information about authenticated resources.
While a user may be able to reduce the amount of information stored in the cookie by measures such as configuring more unauthenticated resources (NEU's - like favicon, images etc). There are certain situations where it is not feasible to simply allow access to what customers would consider legitimate enforced data, where this condition is present.
This is more apparent in use cases with authentication scenarios where authentication processes are rapid (i.e Kerberos / Cert).
A scenario that shows this in action:
- (1) Agent receives a request for Resource 1 (i.e resource.css) and redirects to authentication. This creates a state, ending with an identifier "1234ab", set in the agent-authn-tx cookie sent back to the browser.
(These two requests will happen when the user is not yet authenticated, for example after some inactivity period and/or session timeout. The two requests come from the same user-agent, during the same second.
Both requests are processed by the agent with a redirect to the login URL, where an Auth module is used. This is amplified in situations as mentioned above, where there is no user interaction).
- (2) Agent receives a request for resource2 (resource2.css) and redirects to authentication. It creates another state, ending with "ab1234", set in the agent-authn-tx cookie sent back to the browser.
This is where the problem is created: response to request 2 overwrites the agent-authn-tx cookie value. State(1) is lost & State(2) is set in the cookie.
- (3) The agent receives the response from authentication started at 2. It goes on correctly, ending with the redirect to the originally requested CSS resource.
- (4) The agent receives the response from authentication started at 1. It tries to find the state 1 (ending with "ab1234"), which is not anymore in the agent-authn-tx cookie.
This will create errors in debug:
and the 403 returned to the browser creates:
Thus fails to load the appropriate resource it had requested prior.
While it is safe in some instances, to logically add as many plausible not enforced URL's as possible to avoid cookie growth as we recommend, some not.enforced URL's should not necessarily be dictated due this behaviour, especially if this a result of legitimate enforced resources.
This leads to applications resources being missed which results in user experience diminishing as a result of errors from the web application to no fault of its own.
This can be mitigated to a degree with a refresh of the page, which will allow the user to get rid of the error as the authentication cookie is available in the subsequent requests. I would not find this as an appropriate workaround though, especially again from a user experience perspective.