Push Publishing Permissions

Push Publishing permissions differ from permissions needed to publish on a local server because push publishing requires appropriate permissions on both the sending server and the receiving (Endpoint) server.

Necessary Permissions

For a user to be able to publish a piece of content to an Endpoint, the user must have all of the following permissions:

• Sending Server:
  • Content: View Rights to the content being pushed.
  • Workflow: If the content type uses a Mandatory Workflow, then the user must have Permissions for the Workflow Action(s) that perform a push.
  • Environment: In addition, if the content is being pushed to an Environment (instead of just added to a Bundle), the user must have authorization to use the Push Publishing Environment being pushed to.
• Receiving Server (Endpoint or the server a Bundle is Uploaded to):
  • Dynamic Endpoint:
    • Add children or Edit permissions (as appropriate) AND Publish rights on the receiving server (for all content pushed) OR
    • No user account on the receiving server.
  • Static Endpoint:
    • Appropriate AWS S3 ACL and Bucket rights.

Sending Server

Content Permissions

For a user to be able to push a content item, the user must have View rights to the content item. These rights must either be assigned a Role (recommended) or to the individual user account, but can either be direcly assigned to the content item or inherited from the Content Type or the Site or Folder field on the Content Type.

Note: Users assigned the CMS Administrator Role automatically have rights to view to every object in the system, even if View rights to an object have not been explicitly assigned to the CMS Administrator Role.

Workflow Permissions

If a Content Type has been assigned a Mandatory Workflow, then the only actions available on items of the Content Type are the actions defined in the Workflow. If this is the case, then the user account performing the push must have permissions to use whichever Workflow Actions perform push publishing. The permissions for which users or Roles can perform a Workflow Action are configured in each individual Workflow action individually.

Publishing Environment Permissions

Each Publishing Environment specifies the Roles and/or users that have permission to push to the environment. For a user to be able to push to the servers in an environment, the user must have Permissions to that environment, either through an assigned Role (recommended) or directly assigned to the individual user account.

Note: Users assigned the CMS Administrator Role automatically have permissions to push to every environment, even if teh CMS Administrator Role has not been explicitly assigned to the environment.

Dynamic Endpoint

Permissions on the Endpoint Server

User Permissions

It is important to understand that neither users nor content publisher Roles need to exist on the Endpoint to successfully push objects. Push Publishing is designed to work so that if users on the authoring server do not have user accounts on the Endpoint, the push will work without errors. In fact, Push Publishing is designed so that the chance of conflicts is greatly minimized when users which create and push content on the authoring server(s) do not have user accounts on the Endpoint(s).

This is because a user who has the rights to push content to an Endpoint does not automatically have rights to publish that content on the Endpoint. The content can only be published on the Endpoint if any of the following is true:

• The user account performing the push does not exist on the receiving server.
  • When the user account does not exist on the receiving server, dotCMS publishes the content on the receiving server using the Administrator account (which has permissions to publish all content).
• The user account performing the push has Publish rights to the content being pushed on the receiving server.
  • If the user account performing the push does exist on the receiving server, dotCMS checks the Permissions of all content pushed to ensure that the user account has the appropriate Permissions to publish the content.
  • If the user account does not have permissions to any of the content being pushed, the entire push fails.
    • For this reason, it is recommended that you do not push users between servers or reproduce Roles on both the pushing and receiving servers.
• The HEADLESS_CONTENT_DELIVERY property in the dotmarketing-config.properties file is set to true.
  • The HEADLESS_CONTENT_DELIVERY property specifies whether content is pushed using individual user permissions or by the system user.
    • By default this property is set to false.
    • Note: It is strongly recommmended that all changes to the dotmarketing-config.properties file be made through a properties extension file.
  • When this property is set to true, content is always pushed by (and with the permissions) of the system user, ensuring that the push will succeed regardless of the pushing user's permissions on the receiving server.
  • When this property is set to false, content is pushed with the permissions that the user performing the push user has on the receiving server.
    • The entire push will fail if the user performing the push does exist on the receiving server and does not** have publish permissions for any** of the content being pushed (even a single item).
  • Note that if the user performing the push does not exist on the receiving server, the push will still be performed by the system user (and will thus always succeed, since permissions are not checked).

Note: A user account assigned the CMS Administrator Role on the receiving server automatically has rights to publish every object on the receiving server, even if Publish rights to an object have not been explicitly assigned to the CMS Administrator Role on the receiving server.

Content Locks

Push Publishing does not respect locks of content on the Dynamic Endpoint.

This is intentional. Since content is not intended to be edited on both the sending server and the Endpoint, if a user has permissions to push content to the Endpoint, then the push of that content will succeed even if that content is locked on the Endpoint. In this case, the lock on the Endpoint will be removed and the content will be pushed successfully.

This behavior ensures that pushes of content work based only on the permissions of your users and Roles, and not based on the state of the individual pieces of content being pushed. This enables push publishing to “just work” - once you have set up your push publishing connections and permissions, there is no need to inspect or worry about the state of the content on the Endpoint.

Recommendations

The following recommendations can help to avoid having to duplicate users and permissions on each server when pushing to a Dynamic Endpoint:

• Do NOT duplicate user accounts on the production server/environment.
  • If the same users must access both the authoring and production servers, it is ideal to create separate user accounts (with separate permissions) on each server, to prevent accidental conflicts.
• Grant content creation and editing permissions only to Roles on authoring/staging server.
  • If the same Roles exist on both the authoring and production servers, do not grant those Roles content editing permissions on the production server(s).
• Limit object permissions on the receiving server(s).
  • Permission objects on the receiving server to inherit the minimum needed Role permissions from their parent object.
• But ensure that parent and child objects on the receiving server have the necessary permissions.
  • Since permissions do NOT push, child objects pushed will automatically inherit permissions from their immediate parent on the receiving server.
  • Make sure that the receiving server parent objects have the desired minimal roles (such as the needed intranet roles or CMS Anonymous if the objects being pushed require front-end login access).
• Create and train users on a Push-to-Production publishing policy.
  • Ensure that no users edit or publish directly on the production server(s).
• If you wish to limit which users can push different types of content:
  • Assign all appropriate users to a Role that can push to the appropriate push environment.
  • Create different Mandatory Workflows for each Content Type, and set up the Push Publishing Action in each Workflow to allow only the appropriate Roles or users to push that Content Type.

Static AWS S3 Endpoint

Note: Static Endpoints are only supported in dotCMS Enterprise editions for customers with a Site License (Platform level license). Please see the list of dotCMS versions for more information on features supported in different version of dotCMS.

User Permissions

You must first configure your AWS S3 Permissions to allow the user account used by dotCMS to access the bucket. At a minimum, the user account must have List and Upload/Delete permissions to the bucket.

Bucket Policy Access Control List (ACL)

The user account dotCMS uses to access your AWS S3 server must have appropriate rights (the correct “bucket policy”) to modify the buckets in your AWS S3 environment. However the account does not need administrator rights on your AWS S3 server or account in order to push content to your static server.

To set up the rights for the AWS account used by dotCMS, you must set the “bucket policy” on your AWS S3 site using an Access Control List (ACL) for the AWS account with a minimum set of rights for each bucket dotCMS is going to push to.

Note:

• If you are using AWS S3 Configuration Variables to generate the bucket used by dotCMS, then dotCMS must have rights to all possible buckets which can be generated using the variables.
  • For example, if your bucket name contains {languageId}, dotCMS must have rights to write a different bucket for each Language ID configured on your dotCMS system.
• If you are using an AWS account which does not have permissions to create these buckets you must manually create all the possibly buckets before pushing content, or the push will fail.

Minimum Rights

The following example ACL demonstrates the minimum rights required for dotCMS to push content to a single bucket on your AWS S3 server (replace [[BucketName]] with the name of the bucket):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "MinimumAccess",
            "Effect": "Allow",
            "Action": [
                "s3:DeleteObject",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:GetObjectTagging",
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:PutObjectTagging"
            ],
            "Resource": [
                "arn:aws:s3:::[[BucketName]]/*"
            ]
        },
        {
            "Sid": "MinimumRead",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::[[BucketName]]"
            ]
        }
    ]
}

Expanded Permissions

The following ACL provides an example of expanded permissions, which grant the user account used by dotCMS the ability to create and edit all buckets on your AWS S3 server. Note the use of wildcards to designate the bucket name; you may change the use of wildcards to grant appropriate permissions only to a subset of buckets on your server by combining appropriate prefixes with wildcards in the bucket name.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "OpenAccess",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::[[BucketName]]/*"
        }
    ]
}

For more information on configuring rights in AWS S3, please see the Amazon Documentation.

AWS S3 Access Validation

When you configure a Static AWS S3 Endpoint, dotCMS validates the Endpoint Properties before it will allow you to save the configuration for the Endpoint. If dotCMS is unable to connect to AWS S3 using the properties you've entered, dotCMS will not allow you to save the Endpoint using the properties you've entered.

When dotCMS performs this validation, an attempt is made to access a specific bucket on the AWS S3 server. By default, dotCMS will generate a random bucket name, and verify that it has the rights to create a bucket with that name (without actually creating the bucket). If you have configured the AWS user account used by dotCMS with limited rights on your AWS S3 server - specifically without the ability to create new buckets - this validation will fail, and you will not be able to save the AWS S3 Endpoint configuration.

To prevent this problem, you may add the aws_validation_bucket property to the AWS S3 Endpoint configuration. This property specifies the name of a bucket that dotCMS should use to validate the AWS S3 connection and permissions. The bucket specified in this property needs to be a bucket that the AWS user account used by dotCMS has permission to Edit (the user account must be able to add and update files in the bucket, but does not need permission to create new buckets).

For more information on Static AWS S3 Endpoint properties, please see the Connecting Remote Servers documentation.

AWS S3 Static Website Hosting Configuration

Finally, you must configure your AWS S3 server to act as a static web server, and point it to the correct location for the home page of your static site. The standard dotCMS server configuration uses the “index” page as the home page for the site.

Differences Between Push Rights and Publish Rights

Publish rights enable a user or Role to publish content on the front-end of a server. The rights to push enable a user or Role to move content between servers without changing the state of the content being pushed.

• A user who has Publish rights for content has the ability to publish the content to the front-end of the local site (the site where the user has those rights).
  • Publish rights do not give a user the ability to publish (push) the content to another server.
• A user who has permissions to use a push Environment has the ability to push content from the local server to the Environment to which they have rights, whether that content is published on the local server or not.
  • Content which is published on the sending server and pushed to the receiving server will be published on the receiving server after it is pushed.
  • Content which is not published on the sending server will remain unpublished on the receiving server after it is pushed.
• A user who has permissions to use a Publishing Environment also has rights to delete content on the servers in the Environment they have rights to.
  • To restrict the ability to delete content from a Dynamic Endpoint, you must set up appropriate user accounts and permissions to limit the user's ability to delete content on the Endpoint.

This distinction in rights allows you to:

• Fully publish content on a sending server and verify that everything works correctly before you push it to the receiving server.
• Separate the rights of content creators (who may create and modify content on the sending/authoring server) and content publishers responsible for the production server (who can push content without necessarily having rights to create or modify it).