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
- eithergrant
orrevoke
roles
- an array of roles that are either granted or revokedconditions
- 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 (eithergrant
the designated roles orrevoke
the designated roles)roles
is a list of role keys that should be granted or revoked (depending on theaction
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 aspath
)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: