AEM permissioning is used to determine what actions a user or group can perform and who is allowed to view a particular resource in AEM. It is one of the most important task that should be planned carefully for long term scalability and maintenance of assets in AEM.
In this tutorial, we are going to cover below topics that an AEM Administrator/developer face in day to day life:-
- Understanding how permissions are evaluated in AEM.
- Best Practices for applying AEM Permissions.
- Understanding default restrictions and its patterns
- Set up sub-folder permissioning.
How Permissions are evaluated in AEM:-
AEM Permissions / Restrictions means what actions a user or group of users can perform on a resource. AEM permissions uses Access Control List (ACLs) to evaluated and determine what should be the final permissions applicable for a user or group of users.
Access Control List (ACLs) is a combination of direct and indirect permissions that are applied to a user or group of users. Some permissions might be directly applied to a group and some are inherited for the parent group. When a user request for a resource in AEM a list is formed according to requested resource hierarchy in AEM. This list is then scanned bottom-up until the first appropriate permission to apply to a page/resource is found.
Order and Evaluation of Permission in ACLs List:-
- Permissions are inherited throughout the resource hierarchy.
- User Principals/Permission always take precedence over group Principals/Permission irrespective of
- their order in the access control list
- their position in the node hierarchy
- Within a given type of principal (user vs. group) the order of executing is
- order of entries as specified originally (the index of the permission entry)
- entries associated with the target tree take precedence over inherited entries
Note:- Refer ACL Evaluation for more details.
Best Practices for applying AEM Permissions:-
- Avoid assigning permissions to a user, always assign them to a group and then add users to respective groups. This structure will help in long term maintenance of system by simply managing all permissions for specific type of users under one group.
- Always prefer Allow permission and use Deny as minimum as possible. Because Groups are evaluated in order, and the order may be defined differently per user. In other words: You may have little control over the order in which the statements are implemented and evaluated. If you use only Allow statements, the order does not matter.
- Keep your permissioning Model as simple and clear as possible. this will help in long term maintenance and administrators of users in AEM.
- Always update passwords for default admin user immediately after installation to prevent any security issues.
Understanding Jackrabbit Actions and Patterns:-
Jackrabbit 2.x provides following seven actions:-
|User will get Read permission to that node and all child nodes
|User can modify existing content on the page and on any child pages.
At the JCR level, users can modify a resource by modifying its properties, locking, versioning, nt-modifications, and they have complete write permission on nodes defining a jcr:content child node, for example cq:Page, nt:file, cq:Asset.
|User can create a new page or child page.
If modify is denied the subtrees below jcr:content are specifically excluded because the creation of jcr:content and its child nodes are considered a page modification. This only applies to nodes defining a jcr:content child node.
|User can delete a page , existing paragraphs from the page or any child page.
If modify is denied any subtrees below jcr:content are specifically excluded as removing jcr:content and its child nodes is considered a page modification. This only applies to nodes defining a jcr:content child node.
|The user can read the access control list of the page or child pages.
|The user can modify the access control list of the page or any child pages.
|The user can replicate content to another environment.
Jackrabbit 2.x Rep Patterns:-
There are again seven rep restrictions that by default are provided by Jackrabbit.
In this section we will cover all possible patterns for rep:glob restrictions.
Let’s consider we want to apply rep:glob restriction for node path /foo.
|no restriction: matches /foo and all descendants
|matches node /foo only (no descendants, not even properties)
|foo, siblings of foo and their descendants
|all descendants of /foo whose paths end with ‘cat’
|all siblings and descendants of foo that have a name ending with ‘cat’
|all non-direct descendants of /foo named ‘cat’
|all descendant of /foo that have the direct foo-descendant segment starting with ‘cat’
|all descendants of /foo and foo’s siblings that have a name segment ‘cat’
|all descendants of ‘/foocat’
|all descendants of ‘/foo/cat’
|all descendants of /foo that have an intermediate segment ending with ‘cat’
|‘/foo/cat’ and all it’s descendants
|all descendants of ‘/foo/cat’
|‘/foocat’ and all it’s descendants
|all descendants of ‘/foocat’
Note :- Refer Jackrabbit Restrictions for more examples.
Set up Sub-Folder Permission:-
Let’s consider a use case that we have below DAM folder Hierarchy
and we need create different user groups like:-
- Business Users – Users who can only view/edit assets under a specific sub folder (Business Users Folder).
- Administrators – Full Access group users
- Viewers – Read only Access to specific sub folder.
In this use case, i will explain only about Business users use case, that other two are straight forward.
As per requirement once business user logs in. He/she should be able to view/edit only assets under Business Users Folder. He should not be able to view Projects, Test, Creatives or any asset parallel to Business Users Folder.
- Create a Business Users group by navigating to Tools –> Security –> Groups.
- As these group users need basic Dam Permissions, Let’s add them to Dam Users Group.
- Once Business Users group is created lets add respective permission to it by navigating to Tools –> Security –> Permissions.
- Search for Business-users group created in previous step. Note this is a case sensitive search.
Explanation about above ACE (Access Control Entries).
- As these group users are part of DAM Users group, by default they have read/write access on Dam. As part of first rule we are restricting read access to /content/dam and any folder below it.
- Business Users folder is present under library folder, so we need read only access only to current library folder. We can use rule rep=””, to provide permission only to current node.
- We also need read only access to library folder jcr:content to fetch folder title. Because we cannot have allow and deny rule written for same path, we have added rep:glob=”/library/jcr:content” to /content/dam.
- In last we need read access to every thing inside business-users folder. So, we have added jcr:read to /content/dam/library/business-users.
Now it’s time to validate our permissions. I have create a test-user and add it to Business-Users group. Let’s login with test-user and see how users of Business-users group are seeing content in DAM.
As you can see, users of business-users group are only able to view/edit content inside business-users folder hierarchy.
Want to read More about AEM Permissioning Visit :- AEM Securities.
Hope i am able to explain how AEM permissioning works and how permissions are evaluated in AEM. Will keep on adding more use cases to this post.