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

CTS Operation Fails Entry Already Exists logged for SAML2 Authentication is done

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 13.5.0, 13.5.1, 14.1.1, 5.5.1, 6.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.0.0.4, 6.0.0.5, 6.0.0.6, 6.5.0, 6.5.0.1
    • Fix Version/s: 13.5.3, 6.5.1, 6.5.0.2, 14.1.2, 6.0.0.7, 6.0.1, 7.0.0, 5.5.2
    • Component/s: CTS, SAML
    • Labels:
    • Environment:
      Same behaviour in 13.5.1 and 6.5.0.1
    • Sprint:
      AM Sustaining Sprint 59, AM Sustaining Sprint 60
    • Story Points:
      5
    • Needs backport:
      Yes
    • Support Ticket IDs:
    • Needs QA verification:
      No
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      When performing SAML2 authentication (AM as the IDP with SAML2 Failover enable) and if the same SAML2 SP authentication is done (where AM IDP SAML2 is still logged in and is still intact), the following exception will be logged in CoteSystem log

      ERROR: CTS Async: Task Processor Error: processing task
      org.forgerock.openam.sm.datalayer.api.LdapOperationFailedException:
      CTS: Operation failed:
      Result Code: Entry Already Exists
      Diagnostic Message: The entry coreTokenId=733239306139356536653833633765373965663439633233303533383436613434366564636234343031,ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org cannot be added because an entry with that name already exists
      Matched DN:
              at org.forgerock.openam.cts.impl.LdapAdapter.create(LdapAdapter.java:121)
              at org.forgerock.openam.sm.datalayer.impl.tasks.CreateTask.performTask(CreateTask.java:54)
              at org.forgerock.openam.sm.datalayer.api.AbstractTask.execute(AbstractTask.java:55)
              at org.forgerock.openam.sm.datalayer.impl.SeriesTaskExecutor$TaskDecorator.execute(SeriesTaskExecutor.java:228)
              at org.forgerock.openam.sm.datalayer.impl.SimpleTaskExecutor.execute(SimpleTaskExecutor.java:59)
              at org.forgerock.openam.sm.datalayer.impl.SeriesTaskExecutorThread.run(SeriesTaskExecutorThread.java:86)
      

      How to reproduce the issue

      We are interested only on the AM IDP but since this involves a testing client, we need to install an SAML2 SP too. However focus on the IDP logs

      1. Install AM IDP (AM-1)
      2. Install AM SP (AM-2)
      3. You can configure a SAML2 Integrated module on AM-2 (SP) to authenticate to IDP
      4. Ensure in Global > SAML2 Configuration on AM IDP > SAML2 Failover is enabled
      5. Test the flow that doing an authentication on AM-2 using the SAML2 auth module works
      6. Now clear the session cookie on the SP2 side.
      7. Now repeat the access the AM-2 to trigger the SAML2 auth (but there is a IDP session)
      8. Observe that the repeated SAML2 authentication will cause the above exception
      Expected behaviour
      Should not have exception (as it is logged in ERROR)
      
      Current behaviour
      Exception is logged when SAML2 failover is enabled and when there is a IDP sessioon still existing (and found in CTS) and it is repeated created on the same key.
      

      Work around

      This is not really much of an issue when this exception happens.
      There is no problem other than logs registering that there is an entry existed.
      For now you can ignore this exception.

      Code analysis

      IDPSSOUtil.java
                       if (SAML2FailoverUtils.isSAML2FailoverEnabled()) {
      ...
                      SAML2FailoverUtils.saveSAML2TokenWithoutSecondaryKey(sessionIndex, new IDPSessionCopy(idpSession),
                             sessionExpireTime);
                  }
      

      The saving code always uses CTS create to create the entry and fails if it
      already exists. Note that another for this may be in Saml2SessionUpgradeHandler that one may want to check too.

      PS: The only hard part of this issue is that say in AM65 with error level logging, the above exception is seen but it is hard to tell the cause leading to it if loglevel is not increased. (For this issue, since we are replicating it we know the cause for this SAML2 entry as we can also check the CTS entries)

      Fix:

      • Maybe the saveSAML2Token should be a upsert (available on 6.5.x)
      • It is also possible that at least for this error it can be ignored too.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                chee-weng.chea C-Weng C
                Reporter:
                chee-weng.chea C-Weng C
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 0h
                  0h
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 4h
                  4h