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

Audit Logging change of behaviour when capturing "principals" and "userid" data for each authentication entry.

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.0.0, 6.5.0, 6.0.0.7, 6.5.1, 6.5.2, 6.5.2.1, 6.5.2.2, 6.5.2.3, 5.5.2
    • Fix Version/s: 5.5.3, 6.0.1, 7.0.0, 6.5.3
    • Component/s: audit logging
    • Labels:
    • Sprint:
      AM Sustaining Sprint 76, AM Sustaining Sprint 77
    • Story Points:
      3
    • Needs backport:
      No
    • Support Ticket IDs:
    • Needs QA verification:
      No
    • Functional tests:
      Yes
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      AM Audit Logging no longer captures a UserId when logging a failed authentication (even if the failure is an invalid password). Prinicipals no longer captured when logging a successful authentication. This behaviour is different from AM 5, where both fields would be captured regardless of success or failure (except in the case of a non-existent user account).

      How to reproduce the issue

      1. Install AM 6.5.2.3 into your chosen container and launch it.
      2. Perform default configuration of AM from the browser.
      3. Enable secondary audit logging using the capture method of your choice (JDBC, CSV or some other method).
      4. Have a user log in successfully, then log out.
      5. Have a user attempt to log in, but enter the wrong password.
      6. Attempt to log in using a non-existent user account.

      The resulting output will confirm the above findings.

      Expected behaviour
      "principals" field will always be populated with the provided user input either via a REST call or via the GUI. "UserId" will be populated if a user account matching the attempted log in exists.

      ie:

      • OK Login will hacve principal and userId (for AM-LOGIN-COMPLETED). This bug only affect AM-LOGIN-COMPLETED and not AM-MODULE-LOGIN-COMPLETED.
        {"realm":"/","transactionId":"862ef6ef-e25a-4898-9774-4668700f3137-99385","userId":"id=demo,ou=user,dc=openam,dc=forgerock,dc=org","component":"Authentication","eventName":"AM-LOGIN-COMPLETED","result":"SUCCESSFUL","entries":[{"moduleId":"DataStore","info":{"ipAddress":"x.x.x.x","authLevel":"0"}}],"principal":["demo"],"timestamp":"2020-07-02T08:38:45.073Z","trackingIds":["862ef6ef-e25a-4898-9774-4668700f3137-99392"],"_id":"862ef6ef-e25a-4898-9774-4668700f3137-99427"}
        
      • Failed login will not have userId but principal
        {"realm":"/","transactionId":"862ef6ef-e25a-4898-9774-4668700f3137-62839","component":"Authentication","eventName":"AM-LOGIN-COMPLETED","result":"FAILED","entries":[{"moduleId":"DataStore","info":{"failureReason":"INVALID_PASSWORD","ipAddress":"x.x.x.x","authLevel":"0"}}],"principal":["testadmin"],"timestamp":"2020-07-02T07:23:59.757Z","trackingIds":["862ef6ef-e25a-4898-9774-4668700f3137-62821"],"_id":"862ef6ef-e25a-4898-9774-4668700f3137-62858"}
        
      Current behaviour
      "principals" is only populated if authentication fails. It will be let blank if authentication succeeds.
      "UserId" is only populated if authentication was successful. It will be blank in all other authentication failure scenarios.

      Work around

      There is no known workaround.

        Attachments

          Activity

            People

            • Assignee:
              chee-weng.chea C-Weng C
              Reporter:
              pete.andrews Pete Andrews
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: