Authorization for CQ WCM

Documentation for CQ 5.2 WCM
Prev		Next

Users

Users will log in to CQ with their account. Each user account is unique and holds the basic account details, together with the privileges assigned.

Users are often members of Groups, which simplify the allocation of these permissions and/or privileges.

Groups

Groups are collections of users and/or other groups; these are all called Members of a group.

Their primary purpose is to simplify the maintenance process by reducing the number of entities to be updated, as a change made to a group is applied to all members of the group. Groups often reflect:

a role within the application; such as someone who is allowed to “surf” the content, or someone who is allowed to “contribute” content.
your own organization; you may want to extend the roles to differentiate between contributors from different departments when they are restricted to different branches in the content tree.

Therefore groups tend to remain stable, whereas users come and go more frequently.

With planning and a clean structure, the use of groups can reflect your structure, giving you a clear overview and an efficient mechanism for updates.

Default Users and Groups

CQ WCM installs a number of users and groups. These can be seen when you first access the Security Console after installation.

The following tables list each item with a short description and Day's recommendation about any changes necessary. If you do not delete the accounts listed here, please change the default password.

Table 6. Default Users and Groups

User ID	Type	Description	Recommendation
`admin` Default password: `admin`	User	System administration account and member of the administrator group, with full access rights. This account is used for the connection between CQ WCM and CRX. As such its configuration cannot be edited - with the exception of the password.	Day strongly recommends that the password for this user account be changed from the default. Preferably upon installation, though it can be done afterwards. Other attributes cannot be configured as this account is integral to CQ5. Note: This account is not to be confused with the admin account of the Communiqué Servlet Engine.
`anonymous` Default password: `none`	User	Holds the default rights for unauthenticated access to an instance. Per default this holds the minimum access rights. For a publish instance, anonymous is a member of the surfers group, whereas for an author instance it is a member of the uploaders group.	Do not delete this account. Modifying this account has additional security implications. If you have to edit this account, make a backup copy first.
`author` Default password: `author`	User	A author account allowed to write to `/content`. Encompasses contributor and surfer privileges. Can be used as a webmaster as it has access to the entire `/content` tree.
`administrators`	Group	Group that gives administrator rights to all its members. Only admin is allowed to edit this group. Has full access rights.
`contributor`	Group	Basic privileges which allow the user to write content (as in functionality only). Does not allocate any privileges to the /content tree - these must be specifically allocated for the individual groups or users.
`everyone`	Group	Every user in CQ WCM is a member of the group `everyone`, even though you may not see the group or the membership relation in all tools. This group can be thought of as the “default rights” as it can be used to apply permissions for everyone, even users that will be created in the future.	Do not modify or delete this group. Modifying this account has additional security implications.
`privilege-administrators`	Group	Allows a user to edit the privileges on the account of a different user.
`surfer`	Group	Group that allows the members to read content.
`tag-administrators`	Group	Group that is allowed to edit tags.
`uploader`	Group	Privileges needed to allow the smart uploading widget to write to `/tmp`.
`user-administrators`	Group	Authorizes user administration; for example the right to read home-directories.
`workflow-editors`	Group	Group that is allowed to create and modify workflow models.
`workflow-users`	Group	A user participating in a workflow must be member of group workflow-users. This gives him or her full access to: `/etc/workflow/`instances so that he or she can update the workflow instance. The group is included in the standard installation, but you must manually add your users to the group.

Permissions

Permissions define who is allowed to perform which actions on a resource. The permissions are held as access control lists.

Permissions allow you to either Allow or Deny the actions.

Actions

Actions can be performed on a page (resource). For each page in the hierarchy, you can specify which action the user is allowed to take on that page. See the section called “Permissions”.

The following actions are available:

Table 7. Actions

Action	Description
Read	The user is allowed to read the page and any child pages.
Modify	The user can modify existing content on the page and on any child pages.
Create	The user can: create new paragraphs on the page or on any child page. create a new page, or child page, if the Privilege `Modify Hierarchy` has also been granted.
Delete	The user can: delete existing paragraphs from the page or any child page. delete a page, or child page, if the Privilege `Modify Hierarchy` has also been granted.
Read ACL	The user can read the access control list of the page or child pages.
Write ACL	The user can modify the access control list of the page or any child pages.

Access Control Lists and how they are evaluated

CQ WCM uses Access Control Lists (ACLs) to organize the permissions being applied to the various pages.

Access Control Lists are made up of the individual permissions and are used to determine the order in which these permissions are actually applied. The list is formed according to the hierarchy of the pages under consideration. This list is then scanned bottom-up until the first appropriate permission to apply to a page is found.

Table 8. Permission States

Action	Description
Allow	CQ WCM allows the user to perform the action on this page or on any child pages.
Deny	CQ WCM does not allow the user to perform the action on this page nor on any child pages. See the section called “Access Control Lists and how they are evaluated” for further details of how these interact.
Inherit	The permissions are inherited from a parent page at some point higher up the tree.

Action

Description

Allow

CQ WCM allows the user to perform the action on this page or on any child pages.

Deny

CQ WCM does not allow the user to perform the action on this page nor on any child pages.

See the section called “Access Control Lists and how they are evaluated” for further details of how these interact.

Inherit

The permissions are inherited from a parent page at some point higher up the tree.

	Important
	If no permissions are defined for a page (neither direct nor inherited) then all actions are denied.

The following are recommendations about managing access control lists:

Do not assign permissions directly to users. Assign them only to groups.
This will simplify the maintenance, as the number of groups is much smaller than the number of users, and also less volatile.
Use Deny sparingly. As far as possible use only Allow.
Using deny can cause unexpected effects if the permissions are applied in a different order to that expected. If a user is a member of more than one group, the Deny statements from one group may cancel the Allow statement from another group, or vice versa. It is hard to keep an overview when this happens and can easily lead to unforeseen results, whereas Allow assignments do not cause such conflicts.
Day recommends that you work with Allow rather than Deny see the section called “Best Practices”.

Before modifying either permission, be sure you understand how they work and inter-relate. See the CRX documentation to illustrate how CQ WCM evaluates access rights and Examples on setting up access control lists.

	Note
	For Communiqué 4 users: Whereas Communiqué 4 ACLs were user-based, CQ5 ACLs are resource-based. Pre- and post-ACLs do not apply in CQ5.

Privileges

Privileges are similar to permissions, but are allocated to allow access to functionality within the application.

You can Allow/Grant or Deny them.

Within the standard installation of CQ WCM the privilege to modify the hierarchy can be allocated. This allows the user to create and/or delete pages - if the relevant action has been allocated the correct permission.

Depending on your installation, additional privileges may be available.

Replication Privilege

A special form of privilege, Replication Privilege is highlighted (with its own tab) in CQ WCM as replication is integral to the whole concept of CQ WCM.

For each page you can either Allow or Deny a user's right to replicate content to another environment. As with permissions the privilege is also applied to any child pages.

	Note
	Replication privileges can also be combined as access control lists, so as with permissions it is recommended to work with `Allow` rather than `Deny` see the section called “Best Practices”..

Impersonating another User

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

This means that a user account can specify other accounts 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.

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.

	Important
	If an accounts impersonates another it is very difficult to see. An entry is made in the audit log when the impersonation starts and ends, but the other log files (such as the access log) 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.

Best Practices

The following describes best practices when working with permissions and privileges:

Table 9. Best Practices

Rule	Reason
Use Groups.	Don't assign 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 group’s rights (wherever possible). Avoid using a Deny statement. Groups are evaluated in order, and the order may be defined differently per user. In other words: You may have little control over the order in which the statements are implemented and evaluated. If you use only `Allow` statements, the order does not matter.
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.

Prev	Up	Next
User Administration and Security	Home	Configuring the Users and Groups