Permissions

Required permissions set to perform specific actions

General Concepts

Most SaaS are in essence a user interface built on top of a collection of APIs, performing actions commonly known as CRUD. The SaaS server processes the Create, Update and Delete commands, whereas the user interface or CLI Reads information from the server. Both the user interface and the server then perform a set of actions with data from CRUD.

SaaS permissioning allows or prevents you from calling certain CRUD APIs. Optable has simplified its permissioning to its purest expression.

<object>.view permissions allow you to read from the server (e.g. list audiences, get details of a specific audience)

<object>.edit permissions allow you to write to the server (e.g. create a role, update a role, delete a role)

Permissions Detail

These are the current permissions available within Optable.

Object	Permission	Detail
Analyses	view	List your DCN's analyses, and view analyses details (description, partner, audience, etc.) & reports
	edit	Create, edit, end, archive your DCN's analyses
Matches	view	List your DCN's matches, and view matches details (description, schedule, etc.)
	edit	Create, run or archive your DCN's matches
Audiences	view	List your DCN's audiences, and view audience details (description, business rule, etc.)
	edit	Create, update or archive your DCN's audiences
Exports	view	List previous exports of an audience
	edit	Export your DCN's audiences to a set destination
Data Subject Requests	view	List your DCN's data subject requests to date (access, erase, unsuppress)
	edit	Make data subject requests (access, erase, unsuppress) within your DCN
Accounts	view	List your DCN's accounts, and view account details (name, email, role, etc.)
	edit	Edit (name, role), deactivate, delete accounts within your DCN
Roles	view	List existing roles and get their associated permissions
	edit	Create, update or delete roles within your DCN

Creating a Role Without View Accesses

A service account or an engineer performing a task through the CLI don't necessarily require view permissions. For instance, exporting an audience to a set destination (optable-cli audience export <id> <destination id>) only requires exports.edit permission. It therefore makes sense to allow users to create roles without view permissions.

A user without view permissions will not be able to complete certain tasks through Optable's user interface. Optable currently enforces view permissions when creating a role through the UI, and strongly suggests you to be very careful when creating roles with missing view accesses, and to properly name and describe them to avoid errors and frustrations.

Permissions Relationships

When missing a permission on an object, you may end up unable to perform an action through the user interface that you reasonably thought was possible. Below is a list of relationships between permissions that you should keep in mind.

• Clean rooms:

  • You need audiences.view and partnerships.view permissions to perform clean room operations such as a match or an analysis.

  • You need partnership.view to see active analyses.

• Audiences:

  • You need exports.edit permission to export an audience.

  • You need matches.view permission to create, edit and view query audiences referencing a match.

• Sources:

  • You need audiences.edit permission to create an audience automatically from a file upload.

• Privacy:

  • You need partnerships.view permission to manage differential privacy, and see monthly privacy budget usage.

  • While you can list previous data subject requests (DSR) with dsr.view permission, and create DSR with dsr.edit permission, you need both permissions to perform DSR - Access request. Lacking dsr.edit will prevent you from making the access request, while lacking dsr.view will prevent you from getting the result.

• Accounts:

  • You need roles.view permission to invite, create or update an account, as you need to assign a role.

Sensitive Permissions

Please bear in mind that certain permissions are very powerful and the best practice is to grant these to only a few authorized users in your organization. Below is a list of sensitive permissions:

• roles.edit allows a user to modify their own role, and grant themselves full admin permissions.

• accounts.edit allows a user to re-invite themselves to the DCN, using another email address, and assign an admin role to their new user. This can be done through the CLI even without roles.view permission.

• dsr.view only lists historical DSR to date, without their detail. dsr.edit allows you to perform erasure and unsuppress requests. Giving both permissions to a user allows them to perform a series of access requests. This can be dangerous if the user is trying to learn information about a specific user for personal motives.

• exports.edit permission is to be given with caution, as the user can export all the DCN raw data to their personal cloud storage for personal motives.