How Access Rights are Evaluated

NOTE
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

chlimage_1-307

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:

chlimage_1-308

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.

TestUse a test installation to practice and ensure that you understand the relationships between the various users and groups.
Default Users / GroupsAlways 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

chlimage_1-309

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

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

chlimage_1-47

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.

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

  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:

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

crx_accesscontrol_selectprincipal

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 NameWhich controls the privilege to...
jcr:readRetrieve a node and read its properties and their values.
rep:writeThis is a jackrabbit specific aggregate privilege of jcr:write and jcr:nodeTypeManagement.
jcr:allThis is an aggregate privilege that contains all other predefined privileges.
Advanced
crx:replicatePerform replication of a node.
jcr:addChildNodesCreate child nodes of a node.
jcr:lifecycleManagementPerform lifecycle operations on a node.
jcr:lockManagementLock and unlock a node; refresh a lock.
jcr:modifyAccessControlModify the access control policies of a node.
jcr:modifyPropertiesCreate, modify and remove the properties of a node.
jcr:namespaceManagementRegister, unregister and modify namespace definitions.
jcr:nodeTypeDefinitionManagementImport node type definitions to the repository.
jcr:nodeTypeManagementAdd 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:readAccessControlRead the access control policy of a node.
jcr:removeChildNodesRemove child nodes of a node.
jcr:removeNodeRemove a node.
jcr:retentionManagementPerform retention management operations on a node.
jcr:versionManagementPerform versioning operations on a node.
jcr:workspaceManagementThe creation and deletion of workspaces through the JCR API.
jcr:writeThis is an aggregate privilege that contains:
- jcr:modifyProperties
- jcr:addChildNodes
- jcr:removeNode
- jcr:removeChildNodes
rep:privilegeManagementRegister 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.

    ac_privileges

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

    ac_privilegeregister

  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:

    crx_accesscontrol_applicable

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

    crx_accesscontrol_newlocal

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

    crx_accesscontrol_addentry

    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.

    crx_accesscontrol_reorder

  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:

    crx_accesscontrol_test

Experience Manager