User, Group and Access Rights Administration

You are reading the CRX 2.3 version of User, Group and Access Rights Administration.
This documentation is also available for the following versions: CRX 2.2  CRX 2.1  CRX 2.0 (for CQ 5.3) 

Enabling access to a CRX repository involves several topics:

The basic elements are:

User Accounts

CRX authenticates access by identifying, and verifying, a user (by that a person, or another application) according to details held in the user account.

In CRX every user account is a node in the workspace. A CRX user account has the following properties:

  • It represents one user of CRX.
  • It holds a user name and password.
  • Is applicable for that workspace.
  • It cannot have sub-users. For hierarchical access rights you should use groups.
  • You can specify access rights for the user account.
    However, to simplify management we recommend that (in the majority of cases) you assign access rights to group accounts. Assigning access rights for each individual user quickly becomes very difficult to manage (the exceptions are certain system users when only one or two instances exist).

Group Accounts

Group accounts are collections of users and/or other groups. These are used to simplify management as a change in the access rights assigned to a group is automatically applied to all users in that group. A user does not have to belong to any group, but often belongs to several.

In CRX a group has the following properties:

  • It represents a group of users with common access rights. For example, authors or developers.
  • Is applicable for that workspace.
  • It can have members; these can be individual users or other groups.
  • Hierarchical grouping can be achieved with member relationships. You cannot place a group directly below another group in the repository.
  • You can define the access rights for all group members.

Access Rights

CRX uses Access Rights to control access to specific areas of the repository.

This is done by assigning privileges to either allow or deny access to a resource (node or path) in the repository. As various privileges can be assigned, they must be evaluated to determine which combination is applicable for the current request.

CRX allows you to configure the access rights for both user and groups accounts. The same basic principles of evaluation are then applied to both.

How Access Rights are Evaluated

Note

CRX implements access control as defined by JSR-283.

A standard installation of a CRX repository is configured to use resource-based access control lists. This is one possible implementation of JSR-283 access control and one of the implementations present with Jackrabbit.

Subjects and Principals

CRX uses two key concepts when evaluating access rights:

  • A principal is an entity that carries access rights. Principals include:
    • A user account.
    • A group account.
      If a user account belongs to one, or more, groups it is also associated with each of those group principals.
  • A subject is used to represent the source of a request.
    It is used to consolidate the access rights applicable for that request. These are taken from:
    • The user principal
      The rights that you assign directly to the user account.
    • All groups principals associated with that user
      All rights assigned to any of the groups that the user belongs to.
    The result is then used to allow or deny access to the resource requested.

Compiling the list of Access Rights for a Subject

In CRX the subject is dependent on:

  • the user principal
  • all the group principals that are associated with that user

The list of access rights applicable for the subject is constructed from:

  • the rights that you assign directly to the user account
  • plus all rights assigned to any of the groups that the user belongs to
file

Note

  • CRX does not take any user hierarchy into account when it compiles the list.
  • CRX uses a group hierarchy only when you include a group as a member of another group. There is no automatic inheritance of group permissions.
  • The order in which you specify the groups does not affect the access rights.

Resolving Request and Access Rights

When CRX handles the request it compares the access request from the subject with the access control list on the repository node:

So if Linda requests to update the /features node in the following repository structure:

file

Order of Precedence

Access rights in CRX are evaluated as follows:

  • User principals always take precedence over group principals irrespective of:
    • their order in the access control list
    • their position in the node hierarchy
  • For a given principal there exists (at most) 1 deny and 1 allow entry on a given node. The implementation always clears redundant entries and makes sure that the same privilege is not listed in both the allow and deny entries.

Note

This evaluation process is appropriate for the resource based access control of a standard CRX installation.

Taking two examples where the user aUser is member of the group aGroup:

   + parentNode
     + acl
       + ace: aUser - deny - write
     + childNode
       + acl
         + ace: aGroup - allow - write
       + grandChildNode

        

In the above case:

  • aUser is not granted write permission on grandChildNode.
   + parentNode
     + acl
       + ace: aUser - deny - write
     + childNode
       + acl
         + ace: aGroup - allow - write
         + ace: aUser - deny - write
       + grandChildNode
        

In this case:

  • aUser is not granted write permission on grandChildNode.
  • The second ACE for aUser is redundant.

Access rights from multiple group principals are evaluated based on their order, both within the hierarchy and within a single access control list.

Best Practices

The following table list some recommendations and best practices:

Recommendation... Reason...
Use Groups

Avoid assigning access rights on a user-by-user basis. There are several reasons for this:

  • You have many more users than groups, so groups simplify the structure.
  • Groups help provide an overview over all accounts.
  • Inheritance is simpler with groups.
  • Users come and go. Groups are long-term.
Be Positive

Always use Allow statements to specify the access rights of the group principal (wherever possible). Avoid using a Deny statement.

Group principals are evaluated in order, both within the hierarchy and order within a single access control list.

Keep it Simple

Investing some time and thought when configuring a new installation will be well repaid.

Applying a clear structure will simplify the ongoing maintenance and administration, ensuring that both your current colleagues and/or future successors can easily understand what is being implemented.

Test Use a test installation to practice and ensure that you understand the relationships between the various users and groups.
Default Users / Groups Always update the Default Users and Groups immediately after installation to help prevent any security issues.

User Administration

A standard dialog is used for User Administration.

You must be logged into the appropriate workspace, then you can access the dialog from both:

  • the User Administration link on the Main Console of CRX
  • the Security menu of the CRX Explorer
file
Properties

  • UserID
    Short name for the account, used when accessing CRX.
  • Principal Name
    A full text name for the account.
  • Password
    Needed when accessing CRX with this account.
  • ntlmhash
    Automatically assigned for each new account and updated when the password is changed.
  • You can add new properties by defining a name, type and value. Click Save (green tick symbol) for each new property.

Group Membership

This displays all groups that the account belongs to. The Inherited column indicates membership that has been inherited as a result of membership of another group.

Clicking on a GroupID (when available) will open the Group Administration for that group.

Impersonators

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

This means that a user account can specify other accounts (user or group) which 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 (including ID, name and access rights).

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.

If an account impersonates another it is very difficult to see. The log files hold no information about the fact that impersonation has occurred on the events. So if user-B is impersonating user-A all events will look as if they were performed by user-A personally.

Creating a User Account

  1. Open the User Administration dialog.
  2. Click Create User.
  3. You can then enter the Properties:
    • UserID used as the account name.
    • Password needed when logging in.
    • Principal Name to provide a full textual name.
    • Intermediate Path which can be used to form a tree structure.
  4. Click on the Save (green tick symbol).
  5. The dialog will be expanded so that you can:
    1. Configure Properties.
    2. See Group Membership.
    3. Define Impersonators.

Note

A loss of performance can sometimes be seen when registering new users in installations that have a high number of both:

  • users
  • groups with many members

See Repository Setup - User Manager for information about how to configure the repository to counteract this.

Updating a User Account

  1. With the User Administration dialog open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Click on the required account to open for edit.
  4. Make a change then click on Save (green tick symbol) for that entry.
  5. Click Close to finish, or List... to return to the list of all user accounts.

Removing a User Account

  1. With the User Administration dialog open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Select the required account and click Remove User; the account will be deleted immediately.

Note

This removes the node for this principal from the repository.

Access right entries are not removed. This ensures the historical integrity.

Defining Properties

You can define Properties for either new or existing accounts:

  1. Open the User Administration dialog for the appropriate account.
  2. Define a Property name.
  3. Select the Type from the drop-down list.
  4. Define the Value.
  5. Click Save (green click symbol) for the new property.

Existing properties can be deleted with the trash symbol.

With the exception of the Password, properties cannot be edited, they must be deleted and recreated.

Changing the Password

The Password is a special property that can be changed by clicking on the Change Password link.

You can also change the password to your own user account from the Security menu in the CRX Explorer.

Defining an Impersonator

You can define Impersonators for either new or existing accounts:

  1. Open the User Administration dialog for the appropriate account.
  2. Specify the account to be allowed to impersonate that account.
    You can use Browse... to select an existing account. 
  3. Click Save (green tick symbol) for the new property.

Group Administration

A standard dialog is used for Group Administration.

You must be logged into the appropriate workspace, then you can access the dialog from both:

  • the Group Administration link on the Main Console of CRX
  • the Security menu of the CRX Explorer
file
Properties

  • GroupID
    Short name for the group account.
  • Principal Name
    A full text name for the group account.
  • You can add new properties by defining a name, type and value. Click Save (green tick symbol) for each new property.
  • Members
    You can add users, or other groups, as members of this group.

Group Membership

This displays all groups that the current group account belongs to. The Inherited column indicates membership that has been inherited as a result of membership of another group.

Clicking on a GroupID will open the dialog for that group.

Members

Lists all accounts (users and/or groups) that are members of the current group.

The Inherited column indicates membership that has been inherited as a result of membership of another group.

Creating a Group Account

  1. Open the Group Administration dialog.
  2. Click Create Group.
  3. You can then enter the Properties:
    • Principal Name to provide a full textual name.
    • Intermediate Path which can be used to form a tree structure.
  4. Click on the Save (green tick symbol).
  5. The dialog will be expanded so that you can:
    1. Configure Properties.
    2. See Group Membership.
    3. Manage Members.

Updating a Group Account

  1. With the Group Administration dialog open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Click on the required account to open for edit.
  4. Make a change then click on Save (green tick symbol) for that entry.
  5. Click Close to finish, or List... to return to the list of all group accounts.

Removing a Group Account

  1. With the Group Administration dialog open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Select the required account and click Remove Group; the account will be deleted immediately.

Note

This removes the node for this principal from the repository.

Access right entries are not removed. This ensures the historical integrity.

Defining Properties

You can define Properties for either new or existing accounts:

  1. Open the Group Administration dialog for the appropriate account.
  2. Define a Property name.
  3. Select the Type from the drop-down list.
  4. Define the Value.
  5. Click Save (green tick symbol) for the new property.

Existing properties can be deleted with the trash symbol.

Members

You can add members to the current group:

  1. Open the Group Administration dialog for the appropriate account.
  2. Either:
    • Enter the name of the required member (user or group account).
    • Or use Browse... to search for, and select, the principal (user or group account) that you want to add.
  3. Click Save (green tick symbol) for the new property.

Or delete an existing member with the trash symbol.

Access Right Management

With the Access Control tab of CRXDE Lite you can define the access control policies and assign the related privileges.

For example, for Current Path select the required resource in the left pane, the Access Control tab in the bottom right pane:

file

The policies are categorized according to:

  • Applicable Access Control Policies
    These policies can be applied.
    These are policies that are available for creating a local policy. Once you select and add an applicable policy it becomes a local policy.
  • Local Access Control Policies
    These are access control policies that you have applied. You can then update, order, or remove them.
    A local policy will override any policies inherited from the parent.
  • Effective Access Control Policies
    These are the access control policies that are now in effect for any access requests. They show the aggregated policies derived from both the local policies and any inherited from the parent.

Policy Selection

The policies can be selected for:

  • Current Path
    As in the example above, select a resource within the repository. The policies for this "current path" will be shown.
  • Repository
    Selects repository level access control. For example, when setting the jcr:namespaceManagement privilege, which is only relevant for the repository, not a node.
  • Principal
    A principal that is registered in the repository.
    You can either type in the Principal name or click the icon to the right of the field to open the Select Principal dialog.
    This allows you to Search for a User or Group. Select the required principal from the resulting list, then click OK to carry the value back to the previous dialog.
file

Note

To simplify management we recommend that you assign access rights to group accounts, not individual user accounts.

It is easier to manage a few groups, rather than many user accounts.

Privileges

The following privileges are available for selection when adding an access control entry (see the Security API for full details):

Privilege Name Which controls the privilege to...
jcr:read Retrieve a node and read its properties and their values.
rep:write This is a jackrabbit specific aggregate privilege of jcr:write and jcr:nodeTypeManagement.
jcr:all This is an aggregate privilege that contains all other predefined privileges.
Advanced  
crx:replicate Perform replication of a node.
jcr:addChildNodes Create child nodes of a node.
jcr:lifecycleManagement Perform lifecycle operations on a node.
jcr:lockManagement Lock and unlock a node; refresh a lock.
jcr:modifyAccessControl Modify the access control policies of a node.
jcr:modifyProperties Create, modify and remove the properties of a node.
jcr:namespaceManagement Register, unregister and modify namespace definitions.
jcr:nodeTypeDefinitionManagement Import node type definitions to the repository.
jcr:nodeTypeManagement Add and remove mixin node types and change the primary node type of a node. This also includes any calls to Node.addNode and XML importing methods where the mixin or primary type of new node is explicitly specified.
jcr:readAccessControl Read the access control policy of a node.
jcr:removeChildNodes Remove child nodes of a node.
jcr:removeNode Remove a node.
jcr:retentionManagement Perform retention management operations on a node.
jcr:versionManagement Perform versioning operations on a node.
jcr:workspaceManagement The creation and deletion of workspaces through the JCR API.
jcr:write This is an aggregate privilege that contains:
- jcr:modifyProperties
- jcr:addChildNodes
- jcr:removeNode
- jcr:removeChildNodes
rep:privilegeManagement Register new privilege.

Registering New Privileges

You can also register new privileges:

  1. From the toolbar select Tools, then Privileges to display the privileges currently registered.

    file
  2. Use the Register Privilege icon (+) to open the dialog and define a new privilege:

    file
  3. Click OK to save. The privilege will now be available for selection.

Adding an Access Control Entry

  1. Select your resource and open the Access Control tab.

  2. To add a new Local Access Control Policies, click the + icon at the right of the Applicable Access Control Policy list:

    file
  3. A new entry appears under Local Access Control Policies:

    file
  4. Click the + icon to add a new entry:

    file

    Note

    Currently a workaround is needed to specify an empty string.

    For this you need to use "".

  5. Define your access control policy and click OK to save. Your new policy will:

    • be listed under Local Access Control Policy
    • the changes will be reflected in the Effective Access Control Policies.

CRX will validate your selection; for a given principal there exists (at most) 1 deny and 1 allow entry on a given node. The implementation always clears redundant entries and makes sure that the same privilege is not listed in both the allow and deny entries.

Ordering Local Access Control Policies

The order in the list indicates the order in which the policies are applied.

  1. In the table of Local Access Control Policies select the required entry and drag it to the new position in the table.

    file
  2. The changes will be shown in both the tables for the Local and the Effective Access Control Policies.

Removing an Access Control Policy

  1. In the table of Local Access Control Policies click the red icon (-) at the right of the entry.

  2. The entry will be removed from both the tables for the Local and the Effective Access Control Policies.

Testing an Access Control Policy

  1. From the CRXDE Lite toolbar select Tools, then Test Access Control....

  2. A new dialog opens in the top right pane. Select the Path and/or Principal that you want to test.

  3. Click Test to see the results for your selection:

    file

Your comments are welcome!
Did you notice a way we could improve the documentation on this page?
Please leave your comments below and we will make the appropriate changes.

COMMENTS

  • By John Francis - 8:23 PM on Oct 19, 2011   Reply
    Do you have any further details on "Restrictions" beyond "Restrictions: are jackrabbit specific extensions. Currently these can only be configured for principal-based ACLs."
    • By aheimoz - 5:18 AM on Oct 20, 2011   Reply
      There is more information on the jackrabbit site; for example under http://wiki.apache.org/jackrabbit/AccessControl#How_Principal-based_ACLs_are_stored.
      If you still have questions, then you can post all details of your query to the following mailing-list:
      day-communique (at) googlegroups (dot) com

      Hope that helps.
      • By Ken Stailey - 6:14 PM on Dec 14, 2012   Reply
        The rep:glob restrictions are used to limit what nodes can be affected by the ACL entry. The ACL does not apply to nodes that do not match the pattern. For rep:nodePath the specification is a pathname not a glob.
      • By Rebs - 4:56 AM on Nov 04, 2011   Reply
        What is rep:Userid for ?? where can i get more info on these types ?
        • By alvawb - 7:35 PM on Nov 28, 2011   Reply
          See http://jackrabbit.apache.org/api/2.0/org/apache/jackrabbit/core/security/user/UserManagerImpl.html#P_USERID and http://dev.day.com/docs/en/cq/current/javadoc/com/day/cq/security/Authorizable.html for more information. Hope that helps.
        • By Andy Shreve - 5:16 PM on Apr 11, 2012   Reply
          Typo: Administation (twice).

          The layout in the screenshot of the Access Control tab in CRXDE Lite is completely different from what I see in my local CQ5.4 quickstart when logged in as admin. I don't see the principal icons, the Restrictions column, the radio buttons for Current Path & Repository, or any way to change the privileges. The Privileges option and the Test Access Control option are not available in the Tools menu in CRXDE Lite. I wonder if the documentation is out of date or if these features are enabled elsewhere.
          • By Andy Shreve - 11:33 PM on Apr 11, 2012   Reply
            As it turns out, I didn't know there had been a new CQ release 3 weeks ago. The release notes for CQ5.5 show there were many UI enhancements in the Platform Security area. That explains why I don't see those features.
            • By Alexandre COLLIGNON - 8:18 AM on Apr 12, 2012   Reply
              Andy,

              I just corrected the typos. Thanks !

              Alex
            • By Petr Beranek - 3:48 PM on Nov 12, 2013   Reply
              Multiple questions:
              1. How can get a list of users, groups and associated permissions from AEM? This is needed for an audit promptly.
              2. What is the minimal user rights one needs to view content - what all places in repository must the user have read access to?
              • By alvawb - 5:21 PM on Nov 12, 2013   Reply
                For the minimum rights one needs, see the rights under the anonymous user: http://dev.day.com/docs/en/cq/current/administering/security.html#Users and Groups in AEM. And this http://helpx.adobe.com/experience-manager/using/using-ajax-requests-display-cq.html may only help for part of the first question. Since you're under a time constraint, I suggest you post to our forum at
                http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manager.html where you'll reach more people or open a support ticket.
              • By Harish Kumar - 3:25 AM on Nov 21, 2013   Reply
                How can I migrate only the users and groups i have created with permissions from one instance to other?
                • By zumbrunn - 11:35 PM on Nov 24, 2013   Reply
                  Hi Harish Kumar, the permissions are properties of the content nodes. So, if you want to migrate permissions together with the users and groups, you would create a package that contains the users and groups as well as the root nodes of the content/permission model you want to migrate.

                ADD A COMMENT

                 

                In order to post a comment, you need to sign-in.

                Note: Customers with DayCare user accounts need to create a new account for use on day.com.

                ***