DocumentationAEM 6.5User Guide

User, Group, and Access Rights Administration user-group-and-access-rights-administration

Last update: Wed Sep 20 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

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.

  • Applicable for that workspace.

  • It cannot have subusers. For hierarchical access rights, you should use groups.

  • You can specify access rights for the user account.

    However, to simplify management, Adobe recommends that (in most cases) you assign access rights to group accounts. Assigning access rights for each individual user quickly becomes 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.
  • 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 lets you configure the access rights for both user and group accounts. The same basic principles of evaluation are then applied to both.

How Access Rights are Evaluated 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 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 are 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 compiling-the-list-of-access-rights-for-a-subject

In CRX, the subject depends 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

chlimage_1-56

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 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:

chlimage_1-57

Order of Precedence 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) one 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 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 is well repaid.

Applying a clear structure simplifies 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 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

chlimage_1-58

Properties

  • UserID

    Short name for the account is 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 a GroupID (when available) opens 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 act 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 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 can look as if they were performed by user-A personally.

Creating a User Account 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 Save (green tick symbol).

  5. The dialog box is expanded so that you can do the following:

    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

Updating a User Account updating-a-user-account

  1. With the User Administration dialog box, open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Click the required account so you can open it for editing.
  4. Make a change, then click 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 removing-a-user-account

  1. With the User Administration dialog box, open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Select the required account and click Remove User; the account is 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 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.

Except for the Password, properties cannot be edited, they must be deleted and recreated.

Changing the Password changing-the-password

The Password is a special property that can be changed by clicking 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 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 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

chlimage_1-8

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 a GroupID opens the dialog box 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.

NOTE
When the Owner, Editor, or Viewer role is assigned to a user on any Asset folder, a new group gets created. The group name is of the format mac-default-<foldername> for each folder on which the roles are defined.

Creating a Group Account creating-a-group-account

  1. Open the Group Administration dialog box.

  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 Save (green tick symbol).

  5. The dialog box is expanded so that you can:

    1. Configure Properties.
    2. See Group Membership.
    3. Manage Members.

Updating a Group Account updating-a-group-account

  1. With the Group Administration dialog box, open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Click the required account so you can open it for editing.
  4. Make a change, then click 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 removing-a-group-account

  1. With the Group Administration dialog box, open the list view of all accounts.
  2. Navigate through the tree structure.
  3. Select the required account and click Remove Group; the account is 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 defining-properties-1

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 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 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 lower-right pane:

crx_accesscontrol_tab

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. When 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 overrides 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 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” is 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 box.

    This lets you 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 box.

crx_accesscontrol_selectprincipal

NOTE
To simplify management Adobe recommends 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 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 a new privilege.

Registering New Privileges registering-new-privileges

You can also register new privileges:

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

    ac_privileges

  2. Use the Register Privilege icon (+) so you can define a privilege:

    ac_privilegeregister

  3. Click OK to save. The privilege is now available for selection.

Adding an Access Control Entry 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:

    crx_accesscontrol_applicable

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

    crx_accesscontrol_newlocal

  4. Click the + icon so you can add an entry:

    crx_accesscontrol_addentry

    note note
    NOTE
    Currently a workaround is needed to specify an empty string.
    For this, you must use "".

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

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

CRX validates your selection; for a given principal there exists (at most) one deny and one 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 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.

    crx_accesscontrol_reorder

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

Removing an Access Control Policy 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 is removed from both the tables for the Local and the Effective Access Control Policies.

Testing an Access Control Policy testing-an-access-control-policy

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

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

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

    crx_accesscontrol_test

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2