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

Auditing details of user/group updates impacts performance - add option to turn it on

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.5.0, 6.5.1, 6.5.2
    • Fix Version/s: 7.0.0, 6.5.3
    • Component/s: audit logging
    • Labels:
    • Sprint:
      AM Sustaining Sprint 74
    • Story Points:
      3
    • Needs backport:
      No
    • Support Ticket IDs:
    • Verified Version/s:
    • Needs QA verification:
      Yes
    • Functional tests:
      No
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      Auditing details of user/group updates impacts performance

      How to reproduce the issue

      Create sample auth that takes username/password as inputs, search matching user and then update that user (please see attached sample).

      1. Login to admin console
      2. Create a subrealm "testrealm001"
      3. Follow the manual to setup SampleAuth
        https://backstage.forgerock.com/docs/am/5.1/authentication-guide/index.html#service-conf-sample-auth-module
      4. Configure "SampleAuth" module under "testrealm001"
      5. Run gatling script and observe performance difference between 5.1.1 and 6.5.2.2
      Expected behaviour
      Audit logging call in AMIdentity.setAttributes() should be optional.
      
      Current behaviour
      AMIdentity.setAttributes() will always trigger audit logging. 
      

      Work around

      None

      Code analysis

      Audit logging for user/group updates were added via OPENAM-13675.
      It mentions about possible performance impact, but option for disabling user/group updates events are not implemented yet.

      On the subject of performance, logging extra audit events will likely impact performance and may be unnecessary for some customers. We may wish to add an option for disabling logging of these types of events. I'd prefer to add a general filtering capability for audit events rather than adding yet another system property for this specific case. As there is unlikely to be time for general filtering (and this would need to be added to commons in any case) perhaps we can suggest that customers who do not want this extra logging should disable auditing of the activity topic (which is already a feature we support).
      

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                sachiko Sachiko Wallace
                Reporter:
                sachiko Sachiko Wallace
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: