Access Rights

You are reading the CRX 2.3 version of Access Rights.
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:

Access Rights - the concepts of how they are defined and evaluated
User Administration - managing the individual accounts used for access
Group Administration - simplify user management by forming groups
Access Right Management - defining policies that control how these users and groups can access resources

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

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:

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

Access Right Development

CRX implements access control as defined by JSR-283.

Note

See User, Group and Access Rights Administration for information about how these are administered using the CQ GUI.

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.
jcr:write	This is an aggregate privilege that contains: - jcr:modifyProperties - jcr:addChildNodes - jcr:removeNode - jcr:removeChildNodes
jcr:removeNode	Remove a node.
jcr:readAccessControl	Read the access control policy of a node.
jcr:modifyProperties	Create, modify and remove the properties of a node.
jcr:retentionManagement	Perform retention management operations on a node.

Related Information

For information about developing with access control APIs in CRX 2, please refer to the section about standardization of the security module in CRX 2.

Your comments are welcome!

Did you notice a way we could improve the documentation on this page? Is something unclear or insufficiently explained? Please leave your comments below and we will make the appropriate changes. Comments that have been addressed, by improving the documentation accordingly, will then be removed.

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.