Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-14409

CTS Entry Already Exists errors without CTS affinity or active passive DS servers

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Not a defect
    • Affects Version/s: 13.5.0, 5.5.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Needs backport:
      No
    • Support Ticket IDs:
    • Needs QA verification:
      No
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      No (add reasons in the comment)

      Description

      Bug description

      When not using CTS affinity or DS active passive configuration, there is a race condition that occurs  during retrieval of an OAuth token, such that an error 500 results.

      How to reproduce the issue

      1. Install a single AM server, with 2 external dir servers proving the config and CTS stores.
      2. Perform a large number of curl requests for an OAuth token e.g. curl --request POST --data "client_id=testoauth&grant_type=password&username=testuser&password=password&client_secret=clientpassword" https://openam.amtest2.com/access/oauth2/access_token
      Expected behaviour
      All of the requests will complete successfully
      
      Current behaviour
      A number of the requests fail with an error 500.  For these, there are logged entries in CoreSystem and Session debug logs that indicate (taken from AM 5.5.1 environment):
      
      Diagnostic Message: The entry coreTokenId=<coreTokenId>,ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=test,dc=com cannot be added because an entry with that name already exists
      Matched DN: 
       at org.forgerock.openam.cts.impl.LdapAdapter.create(LdapAdapter.java:111)
       at org.forgerock.openam.sm.datalayer.impl.tasks.UpdateTask.performTask(UpdateTask.java:57)
      

      Work around

      The documented solution here is https://backstage.forgerock.com/docs/am/6.5/install-guide/#cts-deployment-architectures. , use CTS Affinity, or active/passive CTS dir servers

      Code analysis

      Believe what is happening is that the authentication results in an ldap add request for the coreTokenId to e.g. DS1.  This is then replicated to DS2.  However the subsequent processing then results in an update to the CTS, and the ldap search performed as part of this is performed against DS2, after the add in DS1 but before the replication to DS2.  As a result the update determines that it needs to add the coreTokenId, and the add is then performed against DS1, which fails.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                lawrence.yarham Lawrence Yarham
                Reporter:
                lawrence.yarham Lawrence Yarham
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: