Resource access control guide

Table of Contents

1. Access Rules

Access Rules are policies that define the rules to manage access to your resources. They provide a means for making sure certain users, roles, groups and/or permission holders can or can not access a specific set of resources.

A typical access rule may look like this: allow - idr://my-store/path/** - read,write,delete - role.designer

Table 1. Access Rule parts
Part Description Examples

Access

Controls whether to allow or deny access to one or more resources

allow

deny

Resource

Specifies to which resource(s) the access rule applies

idr://my-store/my-folder/**

project://<account-name>/my-project

Operations

Controls to which operations the access rule applies

read,write

delete

accept

*

Permission

Controls to whom the access rule applies

user.john

role.administrator

perm.ext:<account-name>:my-project:read

role.designers or role.administrator

role.approvers and role.reviewers
A deny access rule takes precedence. As soon as at least 1 such access rule applies, access will be denied.

1.1. Access Rule wildcards

1.1.1. Resource

The resource part of an access rule supports the following wildcards:

  • ? matches one character

  • * matches zero or more characters (/ not included)

  • ** matches zero or more 'directories' in a path

Examples

  • project://<account-name>/summer-campaign-???? matches all projects where the name begins with summer-campaign followed by 4 characters, for example a year

  • idr://my-store/my-folder/*.sdt matches all .sdt files within the 'my-folder' directory, but not in sub-directories

  • idr://my-store/my-folder/** matches all files and folders within the 'my-folder' directory (the directory my-folder not included)

1.1.2. Operations

The operations part of an access rule supports the following wildcards:

  • * matches every possible operation

1.2. Permission

The permission part of an access rule supports the following prefixes:

  • user. Makes an access rule apply to a specific user based on their username.

  • role. Makes an access rule apply to users who are assigned the specified role.

  • perm. Makes an access rule apply to users who are granted the specified permission.

1.2.1. Complex permission

You can express complex permissions which combine multiple permissions using and and or statements.

When evaluating complex permissions containing both boolean operators the and operator will take precedence over the or operator.

When we take the conditional expression user.john or role.approvers and role.reviewers or role.administrators the order of evaluation will be as follows:

  1. user.john or

  2. role.approvers and role.reviewers or

  3. role.administrators

1.2.2. The perm. prefix (User permissions)

These type of permission strings allow an access rule to apply to users based on their underlying permissions.

Your account receives access to the base permission ext:<account-name> which can be built upon. Apart from the static base permission it is possible to create a completely custom permission hierarchy tailored to your project’s needs.

Example: I have a project-x which should only be accessible for employees assigned to team-x.

  1. I create an access rule allowing read access to project-x and I let it apply to the permission string perm.ext:<account-name>:project-x:read. (allow - project://<acount-name>/project-x - read - perm.ext:<account-name>:project-x:read)

  2. I create a role project-x-role and assign it the permission ext:<account-name>:project-x:read.

  3. (Optional) I create a group team-x and assign it the role project-x-role.

  4. I make sure the users of team-x either get the group or the role assigned to them.

The strength here lies in the fact that your roles are in this way more loosely coupled to your access rule configuration and the resources they apply to. Revoking access now simply means removing a permission from a role instead of altering an access rule. The same goes for granting access.

Separators & Wildcards

User permissions contain separators : and , and support * as a wildcard. Some examples:

  • ext:<account-name>:project-x implies both ext:<account-name>:project-x:read and ext:<account-name>:project-x:write

  • ext:<account-name>:project-x:read,write implies both ext:<account-name>:project-x:read and ext:<account-name>:project-x:write

  • ext:<account-name>:project-x is the equivalent of ext:<account-name>:project-x:*

1.3. Configuration

Access Rules can be managed by an account administrator through the Access Rule management console.

Permission auth:access-rules is required in order to manage Access Rules.

Any change you make to your Access Rule configuration can take up to 10 minutes before it kicks in.

2. Resource Promotion

Access to projects, environments, tasks and their resources can be managed on both Project level and Resource level by making use of Access Rules.

Access Rules need to be configured separately outside of the Resource Promotion application. Learn more.

2.1. Resource Level

Resource level access control allows you to specifically control who can perform which task actions (accept, promote, reject and abort) on one or more resources.

A resource access rule path (idr://resource-store/path) consists of the following parts:

  • idr:// The resource scheme used to denote resource level access rules.

  • resource-store The name of the store to which the access rule applies.

  • path The resource path to which the access rule applies. This generally consists of a combination of your account name, your project name and your environment name. (e.g. <account-name>/<project-name>/<environment-name>/**)

The path part of the access rule supports wildcards. Learn more.

Here’s a list of all the possible operations on Resource level access rules:

  • read Allows a resource or directory to be read or listed.

  • write Allows a resource or directory to be created or edited.

  • delete Allows a resource or directory to be deleted.

  • accept Allows a resource to be accepted for promotion.

The different task actions require different allowed resource operations for different environments.

E.g.: Aborting a task using the revert changes option will possibly write or delete resources on all previous environments except the first.

Table 2. Task actions and their required resource operations
Task Action Access Resource Operations

Accept

allow

idr://my-store/my-account/my-project/target-environment/**

read,accept

Promote

allow

idr://my-store/my-account/my-project/source-environment/**

read

allow

idr://my-store/my-account/my-project/target-environment/**

write

Reject revert changes

allow

idr://my-store/my-account/my-project/relevant-environment/**

write,delete

Abort keep changes

allow

idr://my-store/my-account/my-project/relevant-environment/**

write,delete

Abort revert changes

allow

idr://my-store/my-account/my-project/relevant-environment/**

write,delete
The difference between the option keep changes and revert changes for the abort task action is that the relevant-environment shifts from being all environments above the starting environment of your task to all environments. Learn more.
Table 3. Resource level access rule examples
Use case Access Resource Operations Permission

Allow the role designers access to all resources within the templates folder in the draft environment

allow

idr://my-store/my-account/my-project/draft/templates/**

*

role.designers

Allow the role approvers access to accept all resources within the test environment

allow

idr://my-store/my-account/my-project/test/**

read,accept

role.approvers

Organize a setup where the role approvers can accept all resources in lower environments and where someone of the role managers is needed for accepting resources towards the last environment

allow

idr://my-store/my-account/my-project/**

read,accept

role.approvers

deny

idr://my-store/my-account/my-project/acceptance/**

read,accept

role.approvers

allow

idr://my-store/my-account/my-project/**

read,accept

role.managers

Organize a setup where the role designers can access all resources in the draft environment and are only able to promote resources towards the test environment

allow

idr://my-store/my-account/my-project/draft/**

*

role.designers

allow

idr://my-store/my-account/my-project/test/**

write

role.designers
These examples assume a project setup of a typical DTAP street consisting of 4 environments: draft, test, acceptance and production.

2.2. Project Level

Project level access control allows you to control who can manage (create, edit and delete) projects as well as who can use (read) these projects.

A project access rule path (project://<account-name>/<project-name>) consists of the following parts:

  • project:// The project scheme used to denote project level access rules.

  • account-name The account to which the access rule applies.

  • project-name The name of the project to which the access rule applies.

The project-name part of the access rule supports wildcards. Learn more.
Project level access rules will only work for the account in which they are specified.

Here’s a list of all the possible operations on Project level access rules:

  • read Allows a project to be viewed. Users will be able to list projects and see their tasks and assigned resources.

Every possible task action requires read access.

  • write Allows a project to be created and edited. Users will be able to create projects and edit their descriptions.

  • delete Allows a project to deleted. Users will be able to delete a project and all of its underlying resources.

  • assign Allows resources to be assigned within a project. Users will be able to assign resources to a project’s open tasks.

Table 4. Project level access rule examples
Use case Access Resource Operations Permission

Allow the role "users" read access to all your projects

allow

project://account/**

read

role.users

Allow the role "users" read access to a specific project

allow

project://account/specific-project

read

role.users

Allow the role "administrators" manage access to all your projects

allow

project://account/**

*

role.administrators

Deny anyone with the role "student" all access to a specific project

deny

project://account/public-website

*

role.student

Allow members of the role marketing read and assign access to projects beginning with marketing-

allow

project://account/marketing-*

read, assign

role.marketing

Comments or suggestions?
Tell us here.

If you have any suggestions or comments about this guide, please send us an email using this form.