Permission System: General Introduction

The users of the application are not defined in the application itself, but are provided to the application by Keycloak. You can either define the users by configuring Keycloak, or set Keycloak to retrieve users from another identity provider, such as your LDAP directory. In all cases, users are known to the application using a login name, such as "user1" or "alice", independently of additional data attached to users such as their first and last names.

Users are usually assigned roles, which are basically equivalent to tags and which can be leveraged in the definition of permission rules. For example, a user with the role "Planner" could be allowed to create a new plan, while a user without this role would not.

The application elements are the objects on which the operations controlled by the permission system apply. Examples are scenarios, tasks, views and dashboards.

Data-Related Application Elements

The application elements that relate to data are scenarios and workspaces. A scenario contains an instance of the data model defined before generating the application. A workspace contains a number of scenarios; a scenario is always contained in a workspace. Scenarios and workspaces have an owner, who initially is the user that created them.

In addition, a scenario can be locked. As explained on the dedicated page, there are two kinds of locks on a scenario: system locks and user locks. A system lock is put by the platform when launching a job on a scenario; the lock is owned by the job. A user lock is put by a user, typically using the menu entries of the user interface; the lock is owned by the user.

Operations on workspaces and scenarios are the usual ones: creation, access to and modification of their properties and contents, deletion.

Processing-Related Application Elements

The application elements that relate to processings are tasks and jobs. A job is the execution of a task. Jobs that execute a given task are considered to be contained by the task, in the same ways as a workspace contains scenarios. From the viewpoint of the permission system, launching a task execution is thus like creating a job contained in the task. Jobs have an owner, who is the user that launched their execution. Tasks have no owner.

There is no operation on a task except including it in the list of tasks, as they are created statically by code. On the other hand, jobs can be created, their properties (step list, outputs, log) can be displayed, a job can be stopped, and it can be erased from the list of jobs.

User-Interface-Related Application Elements

The application elements that relate to the user interface are views and dashboards. Although views and dashboard are different from a user experience viewpoint, they are gathered as a single application element type. A view or dashboard is not contained in another application element. It has an owner, who initially is the user that created it.

The operations on a view or dashboard can be gathered as follows: creation of a view or dashboard, access to the view or dashboard, modification of a property of the view or dashboard (e.g. its name) or of its content (the widgets it contains), deletion of the view or dashboard.

Other Application Elements

In addition to scenarios, workspaces, tasks, jobs, views and dashboards, permission rules can be defined on application preferences and on application permissions. The operations on application preferences and on application permissions are: access them, and modify them. They cannot be deleted nor created (one global instance of each pre-exists). They have no owner.

Operations on application elements can be categorized into groups such as: creating an application element, accessing its properties or its content, modifying its properties or its content, deleting the element, changing its owner or the permission rules attached to it. The permission system defines a set of access rights to control the various operations on an application element.

The access rights are: ACCESS, MODIFY, DELETE, CREATE, and PERMISSIONS. The operations they control are described in detail, per application element type, on another page.

Permission rules are the means by which the administrator of an application defines which operations on which application elements are allowed or forbidden to which users. Permission rules are gathered into rule sets, which are attached either directly to application elements, to permission groups (see below), or to the application itself.

Permission Rules

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) — the rule will only apply to user u;

  • OWNER — the rule will only apply to the user who owns the application element to which the operation is applied;

  • ROLE(r) — the rule will only apply to user who have the role r;

  • EVERYBODY — the rule will apply to all users.

• An access right, that is, either of ACCESS, MODIFY, DELETE, CREATE, or PERMISSIONS.

• An application element type, that is, either of WORKSPACE, SCENARIO, TASK, JOB, VIEW_DASHBOARD, APPLICATION_PREFERENCES, or APPLICATION_PERMISSIONS.

The decision part is a Boolean value.

Permission Groups

A permission group is a collection of application elements. The purpose of a permission group is to gather several elements to which a common set of permission rules apply. Using a permission group is a good way to avoid duplicating the rules from element to element. In this sense, permission groups can be seen as the equivalent for application elements of roles for users.

Permission Rule Sets

Permission rules are attached either to an application element, to a permission group, or to the application itself. The rule set 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.).