This section deals with the various entities and related concepts in more detail to help you configure an easy to maintain user management concept.
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 are collections of users and/or other groups; these are
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.
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
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.
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.
A author account allowed to write to
Can be used as a webmaster as
it has access to the entire
Group that gives administrator rights to all its members. Only admin is allowed to edit this group.
Has full access rights.
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.
Every user in CQ WCM is a member of the group
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.
|Group||Allows a user to edit the privileges on the account of a different user.|
|Group||Group that allows the members to read content.|
|Group||Group that is allowed to edit tags.|
|Group||Privileges needed to allow the smart uploading widget
to write to |
|Group||Authorizes user administration; for example the right to read home-directories.|
|Group||Group that is allowed to create and modify workflow models.|
A user participating in a workflow must be member
of group workflow-users. This gives him or her full access to:
The group is included in the standard installation, but you must manually add your users to the group.
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
Deny the 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
|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.|
The user can:
The user can:
|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.|
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
|Allow||CQ WCM allows the user to perform the action on this page or on any child pages.|
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.|
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.
Denysparingly. As far as possible use only
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.
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 are similar to permissions, but are allocated to allow access to functionality within the application.
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.
A special form of privilege,
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
Deny a user's right to replicate content to
another environment. As with permissions the privilege is also applied
to any child pages.
Replication privileges can also be combined as access control
lists, so as with permissions it is recommended to work with
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.
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.
The following describes best practices when working with permissions and privileges:
Table 9. Best Practices
Don't assign access rights on a user-by-user basis. There are several reasons for this:
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
|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.|