Access Policies

Access Control Policy documents are JSON documents that live at the Platform level. They provide a recipe that describes the access control that should be granted to any policy holder that is assigned the policy. Users may be assigned the policy directly, via a group or via a Team.

Policy Document

The Access Control Policy document provides a series of Statements that declare truths about what authority rights the policy holder should have over resources in the system.

Each Statement must define the following:

  • action - either grant or revoke
  • roles - an array of roles that are either granted or revoked
  • conditions - an array of conditions that must be met in order for the statement to apply

You can create as many Access Control Policies as you would like.

Access Policy Structure

An Access Policy consists of a series of statements. Each statement is effectively a rule that describes a right that should be granted or revoked. A policy may contain multiple statements.

Here is a simple Access Policy:

{
    "title": "{title}",
    "statements": [{
        "action": "{action}",
        "roles": [],
        "conditions": [{
            "type": "{conditionType},
            "config": {
                ...
            }
        ]}
    }]
}

Where title can be any title you like.

For each statement, you will need to provide:

  • action is the action to perform (either grant the designated roles or revoke the designated roles)
  • roles is a list of role keys that should be granted or revoked (depending on the action above)
  • An optional list of conditions

If you don't provide any conditions, then the statements will always be applied. For any conditions that you do provide, you'll need to specify:

  • type is the type of condition (such as path)
  • config is any condition-specific configuration that you can use to set up how your condition executes

Conditions

Cloud CMS provides a large number of conditions that you can use to make your Access Control Policies both powerful and interesting.

The following conditions are supported:

Assignment

Access Control Policies can be assigned to Users, Groups or Teams.

Examples

Let's take a look at some examples.

Example #1

Let's assume we have a project named "Public Web Site".

  • The project has an Editors team
  • The Editors team is assigned the editor role.
  • Joe is on the Editors team.

As a result, Joe has editor rights against all content in the project.

Example #2

Let's assume we have a project named "Public Web Site".

  • The project has an Editors team
  • The Editors team has no directly assigned roles
  • The Editors team the following Access Policy assigned - Has Editor Role over all Content in Spanish (locale 'es')
  • Joe is on the Editors team.

As a result, Joe has editor rights against all content that is in Spanish. He will not have Editor rights over content in other languages or content that does not have a locale defined.

Example #3

Let's assume we have a project named "Public Web Site".

  • The project has an Editors team
  • The Editors team is assigned the consumer role.
  • The Editors team the following Access Policy assigned - Has Editor Role over all Content in Spanish (locale 'es')
  • The Editors team the following Access Policy assigned - Has Manager Role over all Content in the '/products' folder)
  • Joe is on the Editors team.

As a result, Joe can read all of the content in the project (due to the direct consumer role assignment).
He can also edit any of the content that is in Spanish.
And he is a manager of any content located in the /products folder.

Example #4

Here is a sample Access Control Policy document that has a single statement. This statement grants the manager role to any content nodes that are within the /products folder. It uses a regular expression to have this statement apply to the /products folder as well as all sub-folders.

{
    "title": "Product Manager",
    "statements": [{
        "action": "grant",
        "roles": ["manager"],
        "conditions": [{
            "type": "path",
            "config": {
                "path": "^/products.*"
            }
        }]
    }]
}

Note that the Access Control Policy above has the name Product Manager. This makes sense because we're granting the Manager role to everything that falls under the /products folder in our taxonomy. There may be additional rights that we want to confer upon a Product Manager and we could add those to this policy. This policy could then be assigned to all users who we want to act as Product Managers within the system.

More Information

Conditions:

Samples: