AEM User / Group permissions for subfolders

[jwendling]

Currently, we have the folder structure listed below. When I set up a permission group Group A with access to Company A, for this to work I have to include read access to the Team and Clients level folders. The issue I'm having is when a new folder for Company D is added to the Clients folder, Group A ends up having visibility into the newly added folder. Is there a way to avoid this?

• Team folder (top-level folder in files)
  • Clients
    • Company A 
    • Company B
    • Company C
    • Company D (Newly added folder)

[diksha_mishra]

Can you try re-applying Read Only permissions to Clients folder? That should reflect Read only on all the subfolders. If you still face issues, please share a snapshot of assigned user permissions.

[BrijeshYadav]

Add rep:Restrictions policy at /content/team/Clients. Here is an example of rep_policy.xml

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:rep="internal"
          jcr:primaryType="rep:ACL">
    <GroupA
            jcr:primaryType="rep:GrantACE"
            rep:principalName="Group A"
            rep:privileges="{Name}[jcr:read]">
        <rep:restrictions
                jcr:primaryType="rep:Restrictions"
                rep:glob="/*/Company D*"/>
    </GroupA>
</jcr:root>  

[FreedomMarketin · Accepted solution]

Good question and unfortunately, the answer is "not exactly."

Your issue is an ongoing governance issue as new Company folders are added.  The other solution provided will work as a one-time fix, but if you wanted to manage permissions every time a new Company folder was created you could do so through the normal /useradmin interface--there's no special benefit to directly editing the rep:policy node.

When we've had situations like this, we've found the best solution is normally to make the Company folders a top-level folder.  Then you can add read-access as new folders are added to appropriate groups (i.e. Group D gets access to Company D folder) without having to do deny permissions to all the existing groups to cancel the inherited read access.  This can get cluttered if you've got a lot of Company folders and some users get access to a lot of them, but it's the only way without customization that you can avoid a bunch of manual governance (and risk of inappropriate access if you forget to add all the deny nodes when you add a new Company folder).

The only other option without customization is to build really good governance processes.

The third option is to customize an event listener in the parent folder to automatically add deny nodes to existing security groups when a new child folder is added. This probably isn't too terribly hard, but I'll confess that we've never had a situation where the number of child folders was so unmanageable that this was worth doing.  It's the sort of customization that may require maintenance (and certainly regression testing) through patching and upgrades.

Hope this helps,

Beau