User Administration and Security

This chapter describes how to configure and maintain user authorization and also describes the theory behind how authentication and authorization work in AEM.

This section deals with the various entities and related concepts in more detail to help you configure an easy to maintain user management concept.

Users will log in to AEM with their account. Each user account is unique and holds the basic account details, together with the privileges assigned.

Users are often members of Groups, which simplify the allocation of these permissions and/or privileges.

Groups are collections of users and/or other groups; these are all called Members of a group.

Their primary purpose is to simplify the maintenance process by reducing the number of entities to be updated, as a change made to a group is applied to all members of the group. Groups often reflect:

• a role within the application; such as someone who is allowed to surf the content, or someone who is allowed to contribute content.

• your own organization; you may want to extend the roles to differentiate between contributors from different departments when they are restricted to different branches in the content tree.

Therefore groups tend to remain stable, whereas users come and go more frequently.

With planning and a clean structure, the use of groups can reflect your structure, giving you a clear overview and an efficient mechanism for updates.

AEM WCM installs a number of users and groups. These can be seen when you first access the Security Console after installation.

The following tables list each item together with:

• a short description
  
• any recommendations about necessary changes
  

Please change all default passwords (if you do not delete the account itself in certain circumstances).

AEM uses ACLs to determine what actions a user or group and can take and where it can perform those actions.

Permissions define who is allowed to perform which actions on a resource. The permissions are the result of access control evaluations.

You can change the permissions granted/denied to a given user by selecting or clearing the checkboxes for the individual AEM actions. A check mark indicates that an action is allowed. No checkmark indicates that an action is denied.

Where the checkmark is located in the grid also indicates what permissions users have in what locations within AEM (that is, which paths).

Actions can be performed on a page (resource). For each page in the hierarchy, you can specify which action the user is allowed to take on that page. Permissions enable you to allow or deny an action.

AEM WCM uses Access Control Lists (ACLs) to organize the permissions being applied to the various pages.

Access Control Lists are made up of the individual permissions and are used to determine the order in which these permissions are actually applied. The list is formed according to the hierarchy of the pages under consideration. This list is then scanned bottom-up until the first appropriate permission to apply to a page is found.

The permissions are also applied to any child pages.

If a permission is not inherited from the parent node but has at least one local entry for it, then the following symbols are appended to the check box. A local entry is one that is created in the CRX 2.2 interface (Wildcard ACLs currently can only be created in CRX.)

For an action at a given path:

When you hover over the asterisk or exclamation mark, a tooltip provides more details about the declared entries. The tooltip is split into two parts:

The following are recommendations about managing access control lists:

• Do not assign permissions directly to users. Assign them only to groups.

This will simplify the maintenance, as the number of groups is much smaller than the number of users, and also less volatile.

• If you want a group/user to be able only to modify pages, do not grant them create or deny rights. Only grant them modify and read rights.

• Use Deny sparingly. As far as possible use only Allow.

  Using deny can cause unexpected effects if the permissions are applied in a different order than the order expected. If a user is a member of more than one group, the Deny statements from one group may cancel the Allow statement from another group or vice versa. It is hard to keep an overview when this happens and can easily lead to unforeseen results, whereas Allow assignments do not cause such conflicts.

  Adobe recommends that you work with Allow rather than Deny see Best Practices.

Before modifying either permission, be sure you understand how they work and inter-relate. See the CRX documentation to illustrate how AEM WCM evaluates access rights and examples on setting up access control lists.

Permissions give users and groups access to AEM functionality on AEM pages.

You browse permissions by path by expanding/collapsing the nodes and you can track the permission inheritance up to the root node.

You allow or deny permissions by selecting or clearing the appropriate check boxes.

Along with the grid view, AEM provides a detailed view of permissions for a selected user/group at a given path. The detail view provides additional information.

In addition to viewing information, you can also include or exclude the current user or group from a group. See Adding Users or Groups while Adding Permissions. Changes made here are immediately reflected in the upper portion of the detailed view.

To access the Detail view, in the Permissions tab, click Details for any selected group/user and path.

Details are split into two parts:

With the Impersonate functionality a user can work on behalf of another user.

This means that a user account can specify other accounts that can operate with their account. In other words, if user-B is allowed to impersonate user-A, then user-B can take actions using the full account details of user-A.

This allows the impersonator accounts to complete tasks as if they were using the account they are impersonating; for example, during an absence or to share an excessive load short-term.

The following describes best practices when working with permissions and privileges:

Users include people using the system and foreign systems making requests to the system.

A group is a set of users.

Both can be configured using the User Administration functionality within the Security Console.

You access all users, groups, and associated permissions using the Security console. All the procedures described in this section are performed in this window.

To access AEM WCM security, do one of the following:

• From the Welcome screen or various locations in AEM, click the security icon:
  

• Navigate directly to http://<server>:<port>/useradmin. Be sure you log into AEM as an administrator.
  

The following window displays:

The left tree lists all the users and groups currently in the system. You can select the columns you want displayed, sort the contents of the columns, and even change the order in which the columns are displayed by dragging the column-header to a new position.

The tabs provide access to various configurations:

You can filter the list by entering a filter expression, which hides all the users and groups that do not match the expression. You can also hide users and groups by using the Hide User and Hide Group buttons. 

To filter users or groups:

Hiding users or groups is another way to filter the list of all users and groups in a system. There are two toggle mechanisms. Clicking Hide User hides all users from view and clicking Hide Groups hides all groups from view (you cannot hide both users and groups at the same time). To filter the list by using a filter expression, see Filtering users and groups.

To hide users and groups:

To create a new user or group:

To delete a user or group:

1. In the Security console, select the user or group you want to delete. If you want to delete multiple items, Shift+click or Control+click to select them.

2. Click Edit, then select Delete. AEM WCM asks whether you want to delete the user or group.

3. Click OK to confirm or Cancel to cancel your action.

To modify user and group properties:

Use the following procedure to modify a user's password.

AEM offers three different ways to add users or groups to an existing group:

• When you are in the group, you can add members (either users or groups).
• When you are in the member, you can add members to groups.
• When you are working on Permissions, you can add members to groups.

The Groups tab shows you which groups the current account belongs to. You can use it to add the selected account to a group:

The Members tab only works for groups and shows you which users and groups belong to the current group. You can used it to add accounts to a group:

To add members to a group at in a certain path:

AEM offers three different ways to remove users or groups from a group:

• When you are in the group profile, you can remove members (either users or groups).
• When you are in the member profile, you can remove members from groups.
• When you are working on Permissions, you can remove members from groups.

To remove a user or group account from a group:

To remove accounts from a group:

To remove members from a group at a certain path:

When the deployment is a publish farm, users and groups need to be synchronized among all publish nodes.  

To learn about user sync and how to enable it, see User Sychronization.

This section describes how to set permissions, including replication privileges.

Permissions allow users to perform certain actions on resources at certain paths. It also includes the ability to create or delete pages.

To add, modify, or delete permissions:

Replication privilege is the right to publish content, and it can be set for groups and users.

To set replication privileges:

When adding or removing permissions, you can either browse or search for the node.

There are two different types of path search:

• Path search - If the search string starts with a "/" then the search will search for the direct sub-nodes of the given path:

In the search box, you can do the following:

• FullText search - If the search string does not start with a "/" then a fulltext search is executed on all the nodes under the path "/content."

To perform a search on paths or fulltext:

You can specify one or more users that are allowed to impersonate the current user. This means they can switch their account settings to those of the current user and act on behalf of this user.

Use this function with caution as it may allow users to perform actions that their own user cannot. When impersonating a user, users are notified that they are not logged in as themselves.

There are various scenarios when you may want to use this functionality, including:

• If you are out of the office, you can let another person impersonate you while you are away. By using this feature, you can make sure that somebody has your access rights and you do not need to modify a user profile or give out your password.

• You can use it for debugging purposes. For example, to see how the Web site looks for a user with restricted access rights. Also, if a user complains about technical problems, you can impersonate that user to diagnose and fix the problem.

To impersonate an existing user:

To set user and group preferences, including language, window management, and toolbar preferences:

To set users or administrators to have the privileges to delete/activate/deactivate other users:

If you plan to implement application-specific privileges, the following information describes what you need to know to implement a custom privilege and how to enforce it throughout CQ:

The hierarchy-modification privilege is covered by a combination of jcr-privileges. The replication privilege is named crx:replicate that is stored/evaluated along with other privileges on the jcr repository. It is, however, not enforced on the jcr level.

The definition and registration of custom privileges is officially part of the Jackrabbit API as of version 2.4 (see also JCR-2887). Further usage is covered by JCR Access Control Management such as definedby JSR 283 (section 16). In addition, the Jackrabbit API defines a couple of extensions.

The privilege registration mechanism is reflected in the UI under Repository Configuration. 

The registration of new (custom) privileges is itself protected by a built-in privilege that must be granted on the repository level (in JCR: passing 'null' as the 'absPath' parameter in the ac mgt api, see jsr 333 for details). By default, admin and all members of administrators have that privilege granted.