How can I automate applying permissions for a JCR node? - jackrabbit

Question

For the CQ5 environment I work on we have a farm of publisher servers. Some of the content on these servers is restricted so only users who belong to certain groups can see the content. I'd like to script the setting of permissions for the folders (nodes) that are to be secured so I don't have to manually repeat the steps of applying security using the Access Control Editor of Content Explorer (This Adobe documentation has instructions for doing it manually via Access Control Editor). The scenario is that sometimes new folders are to be created to hold secure pages, and we want to apply permissions to the folders prior to activating any content into those folders.
Since the environment has several publishers, it is repetitive, manual, and error-prone work to open Content Explorer and set the permissions on each one. I'd like to do be able to automate this so I could roll out permissions to all the servers via a script--perhaps via a curl command or some other mechanism (perhaps a package?) that can be automated.
I found the Sling jackrabbit-accessmanager bundle that seems like it will facilitate automation of this, but it seems like it opens a security hole. If I put this bundle on my publishers, it seems like I would be providing an REST interface to let anyone modify the permissions and grant access to folders/nodes that should be secured or to add security restrictions on nodes that should have none.
How can I automate the creation/modification of node permissions via a script--and do so in a way that only allows an administrator to apply the permissions changes?

Answer 1

This tool lets you manage permissions in a centralised way, they can also be installed automatically at deploy time:
https://github.com/Netcentric/accesscontroltool
Regarding permissions applied to new folders, the solution is setting permission properly on their parent folder. CQ/AEM will automatically apply the same permissions to all children unless another rule break the inheritance.

Answer 2

I found one alternative I hadn't considered before: using the Day CQ ACL Setup Service. It is mentioned at http://dev.day.com/docs/en/cq/5-5/developing/security_model_changes.html.
AclSetupService allows one to add permission to a single path or a given user/group. This will be applied on each restart of CQ to guaranteed a certain permission state within CQ. For example, "allow;inherit;everyone;/" prevent everyone from accessing CQ (i.e. it forces all users to login first). As noted in the description of AclSetupService, you will need the following pattern per entry:
( "allow" | "deny" ) ";" ( privileges | "inherit" ) ";" principal ";" path
Choose either "allow" or "deny" for the first part.
Next enter one of the privilege below or set it to inherit permission from ancestor.
Then enter a single user/group.
Finally enter a single path to apply the permission to.
Using this will replace permission set within the repository when you restart CQ. These could be scripted by using the process outlined here and here.
Privileges can be:
jcr:read
rep:write
jcr:all
crx:replicate
imp:setComplete
jcr:addChildNodes
jcr:lifecycleManagement
jcr:lockManagement
jcr:modifyAccessControl
jcr:modifyProperties
jcr:namespaceManagement
jcr:nodeTypeDefinitionManagement
jcr:nodeTypeManagement
jcr:readAccessControl
jcr:removeChildNodes
jcr:removeNode
jcr:retentionManagement
jcr:versionManagement
jcr:workspaceManagement
jcr:write
rep:privilegeManagement

Answer 3

If you would like to use the Sling jackrabbit-accessmanager bundle on a publish instance it is possible. You would want to make sure your dispatcher which sits in front of the publish instance does not allow the permission requests (/.modifyAce., .deleteAce., etc) and the publish instances can only be accessed directly from inside your network. It's standard practice to deny all requests in the dispatcher and specify what is allowed.
Is there are reason you are not just replicating the permissions when the folder is activated? There should be a rep:policy node underneath the secure folder which gets replicated.