How to Benefit from AEM User Permissions

AEM, like most large software systems that are widely used throughout an organization, contains a system of regulating access to its data and functionality. In AEM’s case, the restrictions primarily focus around resources or content saved to the repository and what actions can be performed. These restrictions are called user permissions and can be modified by systems administrators depending on what a user needs to do in AEM. One way that the permission process is streamlined is the use of user groups which change access of all users within it at the same time. These are the four authorization categories that define how a user can interact with AEM:

1. Permissions – This defines what paths in AEM the user can navigate through and how they can interact with a resource. For example, restricting access to the apps folder if a user is not part of the development process. AEM uses an ACL or access control list to determine what actions a user can perform.
2. AEM Actions – What actions can be performed on a resource, also known as a page, in AEM which include reading, editing, and deleting.
3. Privileges – These restrictions are what allows or denies a user to parts of a site’s functionality, e.g. replication of resources from within the site. Privileges are set on principles which are associated with either a specific user or group. When a user’s privileges contradict their groups the user privileges apply.
4. Resources – The content that a user is trying to perform an action on also has specific authorizations that define what types of actions can be performed on it.

There are a few out of the box user groups in AEM and they are great examples of how permissions can be set up for a variety of different users. One of these is called the contributor group which was created for a user who needs to add content but does not need access to everything (See Figure 1). This group is interesting because they have write privileges to the content section, but it’s limited. Due to the variety of content that can be added from different sources, the users in this group do not all need the same access. Their write access is user based while the rest of the configuration is attached to the group. There is also an OOTB content-author group which is similar to the previously discussed contributor, except users in this group do the actual site authoring. Thus the permissions for the authors are a little bit more basic, they have read, write, create, and delete permissions which are attached to that group as a whole (See Figure 2).

ACL/More about permissions
AEM uses an access control list that consists of a list of actions that a user can perform on resources within the system. These actions can include creating a new page in a given path, modify components on an existing page, and replicating data between instances. Typically these are applied to an entire group but can be set on a specific user. Another way to use the ACL is by applying the necessary permissions on specific pages, which also affect the child pages as well. The different permissions are set the same way except with either allowing or denying each permission in the list. Depending on the proper permissions associated with a user one of the following seven actions can be performed on the specified resources that they have that access to:

1. Read – Allows the user access to read a page and all of the child pages underneath.
2. Modify – Allows the user to create a new paragraph or modify the existing content on a page and it’s child pages.
3. Create – Allows the user to create a page and child pages. If the modify permission has not been granted to the user any content underneath the jcr:content node can not be accessed.
4. Delete – Allows the user the ability to delete pages, child pages, and any existing paragraphs that are on a page.
5. Read ACL – Allows the user to read the access control list of a page and any child pages.
6. Edit ACL – Allows the user to modify the access control list of a page and any child pages.
7. Replicate – Allows the user to replicate pages, child pages, and content from one environment to another.

LDAP Support
There are other ways of handling user account management besides storing all the account data in AEM. For a more centralized account service an LDAP, or Lightweight Directory Access Protocol, the system can be set up to reduce the amount of manual user data that administrators have to enter in by pulling the basic user information from another system. For connecting to AEM there needs to be synchronization between the LDAP server and CRX where the LDAP credentials are saved into the CRX repository. After the connection and synchronization of the user account, an AEM user administrator would then only have to add in the different permissions for the users and groups as needed. 

This practice is also useful for other systems that can use the common information as well so each system’s user administrators can focus on the specifics for that software instead of general information needed in an account.
While there are different methods of managing users in AEM the concept for role defining using permissions is the same. It not only helps with securing different parts of the system but also can help reduce mistakes. This can prevent user error for example restrictions can prevent a newer user from modifying or deleting important content from within the system. There are also different schools of thought about how users should be managed and thankfully AEM’s administration is flexible enough to allow for varying implementations based on the situation.