Uploaded image for project: 'OpenAM Agents'
  1. OpenAM Agents
  2. AMAGENTS-2893

Race condition in agent-authn-tx cookie causes lost state identifier's.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.5.1.0, 5.5.0.0, 5.6.1.0
    • Fix Version/s: 5.7.0
    • Component/s: Web Agents
    • Target Version/s:
    • Sprint:
      2020.01 - Agents, 2020.02 - Agents
    • Support Ticket IDs:

      Description

      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:

      state identifier not present in authentication state
      unable to verify pre-authentication cookie
      

      and the 403 returned to the browser creates: 

      Unable to verify pre-authentication cookie
      

      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. 

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              nick.james Nicholas James
              Reporter:
              jeremy.cocks Jeremy Cocks
              QA Assignee:
              Alex Levin Alex Levin
              Votes:
              3 Vote for this issue
              Watchers:
              13 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: