Audit ACL Permission change in AEM | Community
Skip to main content
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by MarkusBullaAdobe

Hi @bhuwan_b!

Citing from my reply on this thread:

 

Please check the following documentation:

[...]

I double checked and can confirm the behavior differs from the documentation [...].

After checking it seems that you need to raise the log level to "DEBUG" and add another entry to the "Logger" section of the OSGI configuration:

 

com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet

 

This will at least give you some basic logging on permission management, such as:

 

*DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin adds policy on /content/dam for test *DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin removing policy for /content/dam, [759448319_, 759448319

 

 

Hope that helps!

2 replies

Gaurav_Sachdeva_
Gaurav_Sachdeva_
Level 3
July 29, 2021

Try creating event listener on /home/users node and create a custom log file for any changes in ACL under this node structure.

    MarkusBullaAdobe
    Adobe Employee
    MarkusBullaAdobeAdobe Employee
    Adobe Employee
    July 30, 2021

    Hi @gaurav_sachdeva_!

    Unfortunately, the listener approach will probably not lead to the desired result. If you give a user additional permissions, e. g. to read or edit a certain repository path, this will be stored on the according path and it's rep:policy node-structure. There will be no change to the user node below /home/users (unless you perform additional changes on the user), especially nothing with regards to the users permissions will change here or is tracked in the user nodes. So a listener on /home/users will only track permission changes on user nodes (which are usually not changed very often apart from user creation or deletion), not if you change permissions for any other part of the repository.

    As a side note: Even if this would be the case and permissions would be stored on the according principal nodes (which they are not), it would still not be a good idea to set permissions on user level. Permissions should always be managed on group level and users get them through assigned group memberships.

    MarkusBullaAdobe
    Adobe Employee
    MarkusBullaAdobeAdobe EmployeeAccepted solution
    Adobe Employee
    July 30, 2021

    Hi @bhuwan_b!

    Citing from my reply on this thread:

     

    Please check the following documentation:

    [...]

    I double checked and can confirm the behavior differs from the documentation [...].

    After checking it seems that you need to raise the log level to "DEBUG" and add another entry to the "Logger" section of the OSGI configuration:

     

    com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet

     

    This will at least give you some basic logging on permission management, such as:

     

    *DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin adds policy on /content/dam for test *DEBUG* [127.0.0.1 POST /bin/policies HTTP/1.1] com.adobe.granite.security.permissions.internal.servlets.PoliciesServlet admin removing policy for /content/dam, [759448319_, 759448319

     

     

    Hope that helps!

      Terms & ConditionsAccessibility statement

      Loading footer...