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

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

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:

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:

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 Administation link on the Main Console of CRX

the Security menu of the CRX Explorer

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.

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

Open the User Administration dialog.

Click Create User.

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.

Click on the Save (green tick symbol).

The dialog will be expanded so that you can:

Configure Properties.

See Group Membership.

Define Impersonators.

Updating a User Account

With the User Administration dialog open the list view of all accounts.

Navigate through the tree structure.

Click on the required account to open for edit.

Make a change then click on Save (green tick symbol) for that entry.

Click Close to finish, or List... to return to the list of all user accounts.

Removing a User Account

With the User Administration dialog open the list view of all accounts.

Navigate through the tree structure.

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:

Open the User Administration dialog for the appropriate account.

Define a Property name.

Select the Type from the drop-down list.

Define the Value.

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:

Open the User Administration dialog for the appropriate account.

Specify the account to be allowed to impersonate that account.
You can use Browse... to select an existing account.

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 Administation link on the Main Console of CRX

the Security menu of the CRX Explorer

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

Open the Group Administration dialog.

Click Create Group.

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.

Click on the Save (green tick symbol).

The dialog will be expanded so that you can:

Configure Properties.

See Group Membership.

Manage Members.

Updating a Group Account

With the Group Administration dialog open the list view of all accounts.

Navigate through the tree structure.

Click on the required account to open for edit.

Make a change then click on Save (green tick symbol) for that entry.

Click Close to finish, or List... to return to the list of all group accounts.

Removing a Group Account

With the Group Administration dialog open the list view of all accounts.

Navigate through the tree structure.

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:

Open the Group Administration dialog for the appropriate account.

Define a Property name.

Select the Type from the drop-down list.

Define the Value.

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:

Open the Group Administration dialog for the appropriate account.

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.

Click Save (green tick symbol) for the new property.

Or delete an existing member with the trash symbol.

Access Right Management

A standard dialog is used for the Access Control Editor.

Once you are logged into the appropriate workspace, it can be accessed from the Security menu of the CRX Explorer

If you have already selected a resource in the CRX Explorer, the editor will use this, or you can use Select... from within the dialog. In either case the location of the resource under consideration is shown as the Path:

Applicable Access Control Policies

These policies can be selected and applied.

Local Access Control Policies

These are access control policies that you can add, update, order, or remove.

You must click Apply for them to become Effective.

Effective Access Control Policies

These access control policies have been applied and are now in effect for any access requests.

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.

Adding an Access Control Entry

Open the Access Control Editor for the required resource in the repository.

If not already done, set the Access Control Policy:

Under Local Access Control Policies, select the policy by clicking the checkbox.

Click Set selected policies.

Click on the link New ACE - this is under Local Access Control Policies.

The dialog will be extended to allow you to enter:

Principal: either enter the name, or use Browse... to select the user or group account.

Select allow or deny.

Privileges: you can select one, or more, privileges to be allowed, or denied.

Restrictions: are jackrabbit specific extensions. Currently these can only be configured for principal-based ACLs.

Click save (green tick symbol).

If the changes are complete click Apply, they will now be shown under Effective Access Control Policies and take effect.

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.

The following privileges are available for selection (see the Security API for full details):

Privilege Name

Which controls the privilege to...

jcr:lifecycleManagement

Perform lifecycle operations on a node.

jcr:lockManagement

Lock and unlock a node; refresh a lock.

jcr:versionManagement

Perform versioning operations on a node.

jcr:addChildNodes

Create child nodes of a node.

jcr:read

Retrieve a node and read its properties and their values.

jcr:modifyAccessControl

Modify the access control policies of a node.

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.

jcr:removeChildNodes

Remove child nodes of a node.

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.