Activity access control configuration overview

Policies

To grant access permissions to users, you first create policies. Each policy defines a particular set of access permissions. You can then link users to policies to grant them the associated access permissions.

Whenever a user makes an access request in Campaign Management, the access control system dynamically decides whether to grant or deny the request, using this process:

1. A user requests access to an activity.

2. The system retrieves all the access control policies that the user is linked to.

3. The system evaluates the policies to decide whether the user has permission to receive the requested access.

4. The system grants or denies access based on the outcome of the evaluation.

For example, assume a user opens the details panel of a particular activity: if the user's policies give permission to see the activity's details, the system will display those details to the user; otherwise, the system hides the details from the user.

Statements

To define the exact permissions that a policy grants, you create statements. A policy can contain one or multiple statements. Each statement defines a particular scope of access. For example, a statement might grant full access to create, edit, or delete all activities, or it might only grant access to view activities of a specified type.

Statements are additive, which means a policy grants the sum of all its statements added together. In cases where two applicable statements have an overlapping scope (such as the same activity type), the statement which grants more access is the one that will take effect. Additionally, users can be linked to multiple policies, so users are granted the combination of the statements across all the policies they are linked to.

What is Attribute-Based Access Control (ABAC)?

To understand how Uptempo's activity access controls work, it's helpful to understand some basics about Attribute-Based Access Control (ABAC).

Like all access control models, ABAC is centered around the concept of protecting resources by deciding which users are allowed to perform specific actions on those resources:

Resources

The objects that the ABAC system is protecting. In Campaign Management, these are your activities and their data.

Users

The entities who are requesting access to the resources. In Campaign Management, these are user accounts with access to Campaign Management (the Activities section).

Actions

The operations that users are requesting to perform on a resource, such as viewing, creating, editing, deleting, etc. In Campaign Management, these actions include the basic user operations such as viewing or creating an activity, but can also be defined more specifically: for example, placing an activity in the hierarchy as a child of another activity is an action that can be defined and controlled.

When a user makes a request to the system to perform an action on a resource, the ABAC system looks at the attributes of the user and resource involved:

Attributes

Definable properties or characteristics of the entities involved in an access request (the user who is making the request, and the resource involved in the request). In Campaign Management, these are typically properties of activities, such as the activity type (user properties are not currently supported as ABAC attributes).

The ABAC system then looks at the user's policies, and the statements they contain. Each statement is a rule that defines certain attribute-based requirements, and specifies an access control effect (allow or deny) that is applied when these requirements are met.

To make an access control decision, the ABAC system compares the attributes of the user and the requested resource, and evaluates them against the user's access control policies. If the user is linked to a policy that defines a statement for the attributes involved, the ABAC system grants (or denies) access accordingly.

Example

Assume a user has an access control statement that says:

ALLOW users in the location EUROPE to VIEW resources with the type DOCUMENT.

If that user makes an access request where:

• The user's requested Action is: VIEW

• The user's Location attribute is: EUROPE

• The requested resource's Type attribute is: DOCUMENT

Then this statement would take effect, because all the statement's requirements are met by the access request. As a result, the access control system applies the effect specified by the statement (ALLOW), and grants access.

If any of the statement's requirements were not met (for example, if the requested action is EDIT), the statement would not apply. In this case, assuming the user has no other statements that are applicable to the request, the access control system denies access.

Structure of activity access control statements

In Uptempo, the basic structure of an access control statement consists of four properties:

Effect (required)

The effect the statement has when it applies to an access request, that is, whether the statement allows or denies access.

Action (required)

The operation that the user is requesting to perform on the resource, for example view, create, etc.

Resource (required)

The type of object that the user is requesting to perform the action on, for example an activity type.

Conditions (optional)

Additional conditions to define the resource with greater granularity, based on activity attribute values (for example, activities where a specified activity attribute has a particular value).

You construct statements by using the Statement Editor to define each property. Completed statements are represented as sentences that summarize the access scope of the statement. For example:

If a statement contains conditions, this is indicated in the statement summary, along with the number of applicable conditions. For example:

You can click on Conditions to view the conditions on the statement. The conditions are listed individually, like this:

Conditions can be set based on matching either a single value with operator "is", or on matching one of multiple values with the operator "is one of".