Defining Permission Rules and Rulesets

Permission rules are the means by which administrators define which operations on which application elements are allowed or forbidden to which users. For more details, please refer to Section Understanding Operations.

An application that has just been generated contains:

A Keycloak interface to manage users, groups and roles to which apply permission rules. For more details, please refer to Chapter Managing Users.
A default set of rules that can be edited from the web client. For more details, please refer to Section Understanding the Permission Management View.
A PermissionRulesApi (Javadoc) to add permission rules, upon application initialization or application element creation. For more details, please refer to Sections Setting Advanced Initialization and Setting Permissions Upon Element Creation.

When defining permission rules, the life cycle of an application comes into play. For example, in order to prevent users to create workspaces, some workspace(s) must be created upfront and specific permissions must be defined. If no permission rules are defined in an application, all users are allowed to perform any operation.

Permission rules are gathered into rulesets. Rulesets are associated with, either:

The application itself;
Application elements; or
Permission groups.

The ruleset of an application element (or of a permission group, etc.) is thus the collection of the permission rules attached to the element (or the group, etc.).

A permission rule has a matching part and a decision part.

The matching part is composed of:

A user pattern, which is one of the following (in decreasing order of specificity):
- USER(u) means that the rule will only apply to the user u;
- OWNER means that the rule will only apply to the user who owns the application element to which the operation is applied;
- ROLE(r) means that the rule will only apply to users who have the role r;
- EVERYBODY means that the rule will apply to all users.
An access right that is either ACCESS, MODIFY, DELETE, CREATE, or PERMISSIONS.
An application element type that is either WORKSPACE, SCENARIO, TASK, JOB, VIEW_DASHBOARD, APPLICATION_PREFERENCES, or APPLICATION_PERMISSIONS.
The decision part, which is a Boolean value.

The following permission rules are defined in the ruleset attached to a freshly generated application:

// Workspaces: Everybody can create a workspace, and then only the owner of a workspace can access it.
EVERYBODY, CREATE, WORKSPACE, true
EVERYBODY, ACCESS, WORKSPACE, false
OWNER,     ACCESS, WORKSPACE, true

// Scenarios: Only the owner of a scenario can delete it. (Duplicate these lines with MODIFY if you want
// to make scenarios read-only except for their owners.)
EVERYBODY, DELETE, SCENARIO, false
OWNER,     DELETE, SCENARIO, true

// We want users to have only access to scenarios that are contained in workspaces that they have access to.
// To this end, all rules on workspace access have to be duplicated on scenario access, here and on
// individual workspaces (see initWorkspaces).
EVERYBODY, ACCESS, SCENARIO, false
OWNER,     ACCESS, SCENARIO, true

// Views and dashboards: Everybody can create and access views and dashboards; only owners can modify or
// delete them. In addition, user 'gene_admin' has full permission on views and dashboards.
EVERYBODY,        MODIFY, VIEW_DASHBOARD, false
OWNER,            MODIFY, VIEW_DASHBOARD, true
USER(gene_admin), MODIFY, VIEW_DASHBOARD, true
EVERYBODY,        DELETE, VIEW_DASHBOARD, false
OWNER,            DELETE, VIEW_DASHBOARD, true
USER(gene_admin), DELETE, VIEW_DASHBOARD, true

// Tasks and jobs: Everybody can launch, see, stop, and erase a job.

// Application preferences: Everybody can access and modify them -- this is typically changed from the web client
// when the project is mature enough.

// Permissions: Only user 'gene-admin' is allowed to edit default rules and permission groups
EVERYBODY, MODIFY, APPLICATION_PERMISSIONS, false
USER(gene_admin), MODIFY, APPLICATION_PERMISSIONS, true
// Only user 'gene-admin' and the owner of an element are allowed to edit its permissions
EVERYBODY, PERMISSIONS, WORKSPACE, false
EVERYBODY, PERMISSIONS, SCENARIO, false
EVERYBODY, PERMISSIONS, VIEW_DASHBOARD, false
EVERYBODY, PERMISSIONS, TASK, false
EVERYBODY, PERMISSIONS, JOB, false
EVERYBODY, PERMISSIONS, APPLICATION_PREFERENCES, false
EVERYBODY, PERMISSIONS, APPLICATION_PERMISSIONS, false
USER(gene_admin), PERMISSIONS, WORKSPACE, true
USER(gene_admin), PERMISSIONS, SCENARIO, true
USER(gene_admin), PERMISSIONS, VIEW_DASHBOARD, true
USER(gene_admin), PERMISSIONS, TASK, true
USER(gene_admin), PERMISSIONS, JOB, true
USER(gene_admin), PERMISSIONS, APPLICATION_PREFERENCES, true
USER(gene_admin), PERMISSIONS, APPLICATION_PERMISSIONS, true
OWNER, PERMISSIONS, WORKSPACE, true
OWNER, PERMISSIONS, SCENARIO, true
OWNER, PERMISSIONS, VIEW_DASHBOARD, true
OWNER, PERMISSIONS, JOB, true

By default, a public workspace is created with the name Public Workspace. It is owned by user gene_admin. The following permission rules are included in the ruleset attached to it:

// Everybody has access on this public workspace, but nobody can delete it
EVERYBODY, ACCESS, WORKSPACE, true
EVERYBODY, DELETE, WORKSPACE, false
// Everybody has access to scenarios contained in the workspace, including for deletion
EVERYBODY, ACCESS, SCENARIO, true
EVERYBODY, DELETE, SCENARIO, true

As a result, the public workspace is shared in read-write mode, but cannot be deleted. Any other workspace is only accessible to its owner, with full privileges.