Acl Setup service

As of CQ 5.3, run-mode dependent default permissions can be defined with the AclSetupService that always runs during startup.

The AclSetupService allows you to specify access control entries to be created at a given path for a given principal name. In addition, it allows you to clear existing entries at a given path for a given principal name.

Because of the nature of the service, this may potentially cause issues with existing access control content.

Sample read permission given on apps to everyone group on startup.

allow;jcr:read;everyone;/apps

The first config above is OOTB. 

Config added 

allow;jcr:read;intranet-site-managers;/apps

Error.log

Acl setup service permissions being applied can be seen in the logs during startup.

When config is saved

18.09.2017 13:02:40.116 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.day.cq.security.ACLSetup)] com.day.cq.security.impl.ACLSetupService adjust ACL rules based on configuration.

18.09.2017 13:02:40.150 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.day.cq.security.ACLSetup)] com.day.cq.security.impl.ACLSetupService applying Rule{allow=true, inherit='false', privileges='[jcr:read]', principal='intranet-site-managers', path='/apps'}

18.09.2017 13:02:40.244 *INFO* [CM Event Dispatcher (Fire ConfigurationEvent: pid=com.day.cq.security.ACLSetup)] com.day.cq.security.impl.ACLSetupService done.

18.09.2017 13:02:40.793 *INFO* [JcrInstaller.1] org.apache.sling.installer.provider.jcr.impl.WatchedFolder Watching folder /apps/cq/security/config.author (priority 201)

18.09.2017 13:02:41.332 *INFO* [JcrInstaller.1] org.apache.sling.installer.provider.jcr.impl.JcrInstaller Registering resource with OSGi installer: [InstallableResource, priority=201, id=/apps/cq/security/config.author/com.day.cq.security.ACLSetup.config]

On Starting you see the following logs

18.09.2017 13:09:20.440 *INFO* [FelixStartLevel] com.day.cq.security.impl.ACLSetupService adjust ACL rules based on configuration.

18.09.2017 13:09:20.456 *INFO* [FelixStartLevel] com.day.cq.security.impl.ACLSetupService applying Rule{allow=true, inherit='false', privileges='[jcr:read]', principal='intranet-site-managers', path='/apps'}

18.09.2017 13:09:20.487 *INFO* [FelixStartLevel] com.day.cq.security.impl.ACLSetupService done.

Continue reading : Acl handling via pom

Acl handling via pom

By default acls are installed in overwrite mode.

Acls package install behavior can be changed by modifiying the pom.xml.

Update you pom build plugin "content-package-maven-plugin": with the aclHandling options.

acHandling options: - ignore - overwrite - merge - merge_preserve - clear

Example: for merging acls on installation.

<plugin>

    <groupId>com.day.jcr.vault</groupId>

    <artifactId>content-package-maven-plugin</artifactId>

    <version>0.0.24</version>

    <extensions>true</extensions>

    <configuration>

        <failOnError>true</failOnError>

        <username>${crx.username}</username>

        <password>${crx.password}</password>

        <properties>

            <acHandling>merge </acHandling>

        </properties>

    </configuration>
</plugin>

ACLs and How they are evaluated

Access Control Lists(ACL) are made up of the individual permissions (ACE’s (Access control enteries)) and are used to determine the order in which these permissions are actually applied.

An AccessControlEntry (ACE) represents the association of one or more Privilege objects with a specific Principal.

A standard installation of a CRX repository is configured to use resource-based access control lists.

Resource-based ACLs

That means that a resource = node is associated with a list of allow/deny entries for certain principals (users or groups), which naturally maps to store them along the JCR node.

ACLs and How They Are Evaluated

• Allow rights have higher precedence than deny rights.
• Group principals are evaluated in order, both within the hierarchy and order within a single access control list ie on the same node (CONCURRENT).
• This list is then scanned bottom-up until the first appropriate permission to apply to a page is found.

Concurrent (on the same node) Permission on ACL

• The permission created first in user admin is added to the node first (1st ACE) and then the next permission is added below it (2nd ACE). 
• This list is then scanned bottom-up until the first appropriate permission to apply to a page is found. 

EXAMPLE 1. 

Suppose, you have the following ACL for the same resource under /content/geometrixx/

en/products.

If a user is part of the two groups ‘allowed-it’ and ‘restricted-it’, you can see that the

access to the page products is denied because the ACL deny in read access is the rule

at the bottom.

EXAMPLE 2.

            

Now, if the order of the ACL is the opposite, a user, part of two groups, allowed-it and
restricted-it, will have access /to the products page (because the ACL allow in read access
is the rule at the bottom).

Continue reading : Acl setup service