Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Audit ACL Permission change in AEM

Bhuwan_B
Community Advisor
Community Advisor

OOTB Audit Log shows only addition or modification of Users or Groups. How can we log Permission details once we update permission navigating to http://localhost:4502/security/permissions.html or using CRXDE Access Control Tab ?

1 Accepted Solution
markus_bulla_adobe
Correct answer by
Employee
Employee

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!

View solution in original post

1 Reply
Gaurav_Sachdeva1
Level 2
Level 2

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

markus_bulla_adobe
Employee
Employee

Hi @Gaurav_Sachdeva1!

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.

markus_bulla_adobe
Correct answer by
Employee
Employee

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!

View solution in original post