User Permissions

Last Updated: May 18, 2020
documentation for the dotCMS Content Management System

dotCMS objects can be permissioned directly to a user as well as receiving role based object permissions. Large groups of similarly permissioned users can all be easily assigned to the same role, however if a few users in that group need additional access to a few objects, permissions can be quickly extended to those unique users without affecting role distribution.

Only Administrators Can Edit Users

Important: Only User accounts with the CMS Administrator Role can add and modify user accounts. If a User does not have the CMS Administrator Role assigned, they will not be able to make changes to User accounts, even if they have access to the Users Tool in the back-end.

Managing User Roles

You may assign permissions for specific objects to User accounts either directly (in the Users Tool), or via Roles. It is recommended that you assign permissions using Roles whenever possible, since Roles are an efficient way of standardizing permissions to ensure that all users which need certain types of access to a particular resource have the same permissions, without having to update and compare different users.

Screen Shot: The Users Tool in the dotCMS Back-end

Assigning Roles

To assign Roles to a User,

  1. Select the User.
  2. Select the Roles tab.
  3. If necessary, expand the top-level Roles to display the Role to be assigned.
  4. Check the checkbox next to the Role to assign.
  5. Click the right-arrow button (») to assign the selected Role(s).
    • The selected Roles(s) will display in the right-side list of assigned Roles.
  6. Click the Save button.

Users can also be assigned Roles while editing the Role. For more information, please see the Role Permissions documentation.

Screen Shot: Assigning Roles to Users

Removing Roles

You can also remove Roles from users via either the Users Tool or the Roles Tool. To remove a Role(s) from a User:

  1. Select the User.
  2. Select the Roles tab.
  3. Select the Role(s) to be removed in the right-side list of assigned Roles.
  4. Click the left-arrow button («) to remove the selected Role(s).
  5. Click the Save button.

Auto-Assigning Roles with LDAP

If you have enabled LDAP integration, you can configure dotCMS to automatically assign Roles to users who login via LDAP, based on the Groups assigned to the User within LDAP. For more information, please see the LDAP Configuration documentation.

Individual User Permissions

Although it is recommended that you assign permissions to objects through Roles whenever possible, there may be cases where you wish to give an individual user access to specific objects outside of Roles. This can be done either by creating a special Role which is assigned only to the specific User, or by explicitly giving the User permissions to the object in the Permissions tab of the User screen.

To view the permissions assigned to a specific User, select the Permissions tab in the User screen detail area.

Example User Permissions

In the following example, User “John Cook” has already been assigned the “Content Publisher” Role which gives this user permission to add, edit, and publish content. In addition, this user has been given “View” and “Edit” rights to all Templates and Containers on the the System Host - which will allow him to view and edit all Templates and Containers that inherit permissions from the System Host.

Screen Shot: Individual User Permissions

Assigned User Permissions from Object Configuration

You may also change individual User permissions when editing specific objects. The Permissions tab in each object allows you to select Roles or Users.

Screen Shot: Setting Individual User Permissions on an Object

Note: If the object being edited is inheriting permissions from another object, you will not be able to change the permissions for the object. To disable permission inheritance on an object, select the Permissions tab and then click the “Permission Individually” button.

Front-end and Back-end Users

Every User in dotCMS can be configured as a Front-end user and/or Back-end user. Front-end users may submit content via forms on the front-end of your site. Back-end users may login to the dotCMS back-end.

You may configure these properties for each user in the Access section of the User configuration screen:

Screen Shot: User Access

Access to Content and APIs

The following table shows what content a user has access to, based on whether the user account has been configured for Front-end User and/or Back-end User access, and whether an API Access Token assigned to the account is used when performing a REST API call:

Front-end User Back-end User Auth Token Submit Content via
Front-end Forms?
Login to
Back-end UI?
REST API
Endpoints?
True True Not Req. Yes Yes All1
True False True Yes No2 All1
True False False Yes No2 Limited3
False True Not Req. No Yes All1
False False True No No All1
False False False No No Anonymous Only4
1: The user may still only access objects which the user has appropriate permissions for (read, write, publish, etc.)
2: The user may not login to the back-end even if Tools and Tool Groups have been assigned to any Roles the user has been assigned.

3: Please see below for the list of REST APIs which may not be accessed by users with only  Front-end User access.

REST API Access by Unauthenticated Users

Access to the REST API for unauthenticated users is controlled by the REST_API_REJECT_WITH_NO_USER and CONTENT_APIS_ALLOW_ANONYMOUS properties; to allow unauthenticated users to write content using the REST API, set these properties as follows:

REST_API_REJECT_WITH_NO_USER=true
CONTENT_APIS_ALLOW_ANONYMOUS=write

Endpoints Limited to Back-end Users

The following REST endpoints are not accessible by users with only Front-end User access. These APIs may only be accessed by users with Back-end User access, or by user accounts that have an API Access Token assigned, when the API Access Token is used in the REST API call:

/bundle /cluster /config /environment
/license /osgi /role /ruleengine
/ws/v1/system /v1/configuration /v1/esindex /v1/notification
/v1/portlet /v1/roles /v1/sites/{siteId}/ruleengine /v1/system-status
/v1/users /v2/users

On this page