ACL ordering with RepoInit in Adobe Experience Manager LTS

This article describes how changes in ACL insertion order with RepoInit in Adobe Experience Manager (AEM) LTS versions can result in custom group Allow permissions being overridden by default Deny rules, and provides steps to ensure the correct ACL order.

Description description

Environment

  • Adobe Experience Manager (AEM) 6.6.x (LTS SP2)
  • Adobe Experience Manager (AEM) 6.5.x

Issue/Symptoms

When custom author groups and ACLs are created using Sling RepoInit, the order of Access Control Entries (ACEs) differs between AEM 6.5 and AEM LTS (6.6.x). In AEM 6.5, custom ACEs are appended after default/product ACEs on the same paths. In AEM LTS, custom ACLs are inserted before default ACEs. For example, on a path such as /content/projects, a custom group Allow entry may appear before a default Deny everyone entry. Because all users are members of the everyone group, the Deny entry can override the custom group permissions, impacting delete and write permissions for those groups. No error messages are logged, but effective permissions are affected.

Cause

A change in RepoInit ACL insertion order in AEM LTS causes custom Allow entries to be inserted before default Deny entries, resulting in Deny rules overriding custom permissions. Explicitly removing and re-adding ACLs via RepoInit ensures the correct order.

Resolution resolution

To fix the issue, follow these steps:

  1. Update your RepoInit configuration to explicitly remove existing custom ACLs from the affected paths before re-adding them. For example:

    code language-none
    set ACL for
    remove * on /content/projects
    allow jcr:lockManagement, jcr:read, jcr:versionManagement, jcr:write on /content/projects
    end
    

Replace <custom-group> with your actual group name.
2. Deploy the updated RepoInit configuration through your standard deployment pipeline.
3. After deployment, verify that the ACL order is as expected and that custom group permissions are effective. You can use CRXDE or the AEM Security console to confirm that custom Allow entries appear after default Deny entries for the relevant paths.
4. Test delete and write operations for affected groups to ensure permissions are correct.
5. Avoid manual ACL reordering in CRXDE for production environments, as this is not a scalable or supported long-term solution.

recommendation-more-help
experience-cloud-kcs-help-kbarticles