Permissions dictate the access each user has to data and actions.
Permissions are related to whether actions are authorized or not. They are also related to access rights, that is, whether an entity is hidden, read, or read-write. The main entities controlled by permissions are:
Dataspace
Dataset
Table
Group
Field
The definition and resolution of permissions make extensive use of the notion of profiles, which is the generic term applied to users or roles.
Each user can participate in several roles, and a role can be shared by several users.
Special definitions:
An administrator is a member of the built-in role 'ADMINISTRATOR'.
An owner of a dataset is a member of the owner attribute specified in the information of a root dataset. In this case, the built-in role 'OWNER' is activated when permissions are resolved in the context of the dataset.
An owner of a dataspace is a member of the owner attribute specified for a dataspace. In this case, the built-in role 'OWNER' is activated when permissions are resolved in the context of the dataspace.
A permission rule defines the authorization granted to a profile for a particular entity.
User-defined permission rules are created through the user interface. See the section Defining user-defined rules.
Permissions are always resolved in the context of an authenticated user session, thus permissions are mainly based on the user profiles.
In general, resolution of permissions is performed restrictively between a given level and its parent level. Thus, at any given level, a user cannot have a higher permission than the one resolved at a parent level.
An administrator or owner of a dataset can perform the following actions:
Manage its permissions
Change its owner, if the dataset is a root dataset
Change its general information (localized labels and descriptions)
While the definition of permissions can restrict an administrator or dataset owner's right to view data or perform certain actions, it remains possible for them to modify their own access, as they will always have access to permissions management.
To be a super owner of a dataspace, a user must either:
Own the dataspace and be allowed to manage its permissions, or
Own a dataspace that is an ancestor of the current dataspace and be allowed to manage the permissions of that ancestor dataspace.
An administrator or super owner of a dataspace can perform the following actions:
Manage its permissions of dataspace.
Change its owner
Lock it or unlock it
Change its general information (localized labels and descriptions)
Furthermore, in a workflow, when using a "Create a dataspace" or "Create a snapshot" built-in script task, resolved permissions are computed using the owner defined in the script task's configuration, rather than the current session. This is because, in these cases, the current session is associated with a system user.
While the definition of permissions can restrict an administrator or dataspace owner's right to view data or perform certain actions, it remains possible for them to modify their own access, as they will always have access to permissions management.
When a dataspace is merged, the permissions of the child dataset are merged with those of the parent dataspace if and only if the user specifies to do so during the merge process. The permissions of its parent dataspace are never impacted.
If some elements are hidden for the profile attempting to perform a merge, it will not be possible to proceed as the impacts of the merge on data will not be fully visible.
The following statements should be kept in mind while working with permissions:
Whenever the hidden permission is returned for a session on a table child node, a user could "guess" sensitive information by filtering or sorting on this node in the following cases:
When defining a custom view on this table in the UI. To avoid this, view definition permissions should be restricted for such users.
Resolution of custom display labels for tables ('defaultLabel' property) and relationships ('display' property) ignores permission, and fields usually hidden due to access rights restrictions will be displayed in such labels. As a result, these labels should not contain any confidential field. Otherwise, a permission strategy should also be defined to restrict the display of the whole label.
To optimize the resolution of permissions for both data and user services, a dedicated cache is implemented at the session level; it only takes user-defined permissions into account, not programmatic rules (which are not cached since they are contextual and dynamic). The session cache life cycle depends on the context, as described hereafter:
In the UI, the cache is cleared for every non-ajax event (i.e on page display, pop-up opening, etc.).
In programmatic procedures, the cache lasts until the end of the procedure, unless explicitly cleared (see below).
Each level has a similar schema, which allows defining permission rules for profiles.
For a given dataspace, the allowable permissions for each profile are as follows:
Dataspace access | Authorization |
|---|---|
Write |
|
Read-only |
|
Hidden |
|
Restriction policy | Indicates whether this dataspace profile-permission association should have priority over other permissions rules. |
Create a child dataspace | Indicates whether the profile can create child dataspaces from the current dataspace. |
Create a child snapshot | Indicates whether the profile can create snapshots of the current dataspace. |
Initiate merge | Indicates whether the profile can merge the current dataspace with its parent dataspace. |
Export archive | Indicates whether the profile can export the current dataspace as an archive. |
Import archive | Indicates whether the profile can import an archive into the current dataspace. |
Close a dataspace | Indicates whether the profile can close the current dataspace. |
Close a snapshot | Indicates whether the profile can close a snapshot of the current dataspace. |
Permissions of child dataspace when created | When a user creates a child dataspace, the permissions of this new dataspace are automatically assigned to the profile's owner, based on the permissions defined under 'Permissions of child dataspace when created' in the parent dataspace. If multiple permissions are defined for the owner through different roles, the owner's profile behaves like any other profile and permissions are resolved as usual. |
For a given dataset, the allowable permissions for each profile are as follows:
Restriction policy | Indicates whether this dataset profile-permission association should have priority over other permissions rules. |
Create a child dataset | Indicates whether the profile has the right to create a child dataset of the current dataset. |
Duplicate dataset | Indicates whether the profile has the right to duplicate the current dataset. |
Change the dataset parent | Indicates whether the profile has the right to change the parent dataset of a given child dataset. |
The action rights on default tables are defined at the dataset level. It is then possible to override these default rights for one or more tables. The allowable permissions for each profile are as follows:
Create a new record | Indicates whether the profile has the right to create records in the table. |
Overwrite inherited record | Indicates whether the profile has the right to overwrite inherited records in the table. |
Occult inherited record | Indicates whether the profile has the right to occult inherited records in the table. |
Delete a record | Indicates whether the profile has the right to delete records in the table. |
Permissions defined on specific terminal nodes override their default access rights.
Read-write | Can view and modify node values. |
Read | Can view nodes, but cannot modify their values. |
Hidden | Cannot view nodes. |
An administrator or an owner of the current dataspace can modify the service default permission to either restrict or grant access to certain profiles.
Enabled | Grants service access to the current profile. |
Disabled | Forbids service access to the current profile. It will not be displayed in menus, nor will it be launchable via web components. |
Default | Sets the service permission to enabled or disabled, according to the default permission defined upon service declaration. |
Access rights defined using the user interface are resolved on four levels: dataspace, dataset, record (if applicable) and node.
If a profile is associated with restrictive access rights at a given level, the minimum of all restrictive rights defined at that level is resolved. If no restrictions are defined at that level, the maximum of all access rights defined at that level is resolved.
When a restrictive permission is defined for a profile, it takes precedence over the other permissions potentially granted by the user's other roles. Generally, for all user-defined permission rules that match the current user session:
If some rules with restrictions are defined, the minimum permissions of these restricted rules are applied.
If no rules having restrictions are defined, the maximum permissions of all matching rules are applied.
Examples:
Given two profiles P1 and P2 concerning the same user, the following table lists the possibilities when resolving that user's permission to a service.
| P1 authorization | P2 authorization | Permission resolution |
|---|---|---|
| Enabled | Enabled | Enabled. Restrictions do not make any difference. |
| Disabled | Disabled | Disabled. Restrictions do not make any difference. |
| Enabled | Disabled | Enabled, unless P2's authorization is a restriction. |
| Disabled | Enabled | Enabled, unless P1's authorization is a restriction. |
The same restriction policy is applied for data access rights resolution.
In another example, a dataspace can be hidden from all users by defining a restrictive association between the built-in profile "Profile.EVERYONE" and the access right "hidden".
At any given level, the most restrictive access rights between those resolved at this level and higher levels are applied. For instance, if a user's dataset access permissions resolve to read-write access, but the container dataspace only allows read access, the user will only have read-only access to this dataset.
The dataset inheritance mechanism applies to both values and access rights. That is, access rights defined on a dataset will be applied to its child datasets. It is possible to override these rights in the child dataset.
In this example, there are three users who belong to the following defined roles and profiles:
User | Profile |
|---|---|
User 1 |
|
User 2 |
|
User 3 |
|
The access rights of the profiles on a given element are as follows:
Profile | Access rights | Restriction policy |
|---|---|---|
user1 | Hidden | Yes |
user3 | Read | No |
Role A | Read/Write | No |
Role B | Read | Yes |
Role C | Hidden | No |
After resolution based on the role and profile access rights above, the rights that are applied to each user are as follows:
User | Resolved access rights |
|---|---|
User 1 | Hidden |
User 2 | Read |
User 3 | Read/Write |
At dataspace level, access rights are resolved as follows:
If a user has several rights defined through multiple profiles:
If the rights include restrictions, the minimum of the restrictive profile-rights associations is applied.
Otherwise, the maximum of the profile-rights associations is applied.
If the user has no rights defined:
If the user is an administrator or owner of the dataspace, read-write access is given for this dataspace.
Otherwise, the dataspace will be hidden.
At the dataset level, the same principle applies as at the dataspace level. After resolving the access rights at the dataset level alone, the final access rights are determined by taking the minimum rights between the resolved dataspace rights and the resolved dataset rights. For example, if a dataspace is resolved to be read-only for a user and one of its datasets is resolved to be read-write, the user will only have read-only access to that dataset.
At the node level, the same principle applies as at the dataspace and dataset levels. After resolving the access rights at the node level alone, the final access rights are determined by taking the minimum rights between the resolved dataset rights and the resolved node rights.
Specific access rights can be defined at the node level. If no specific access right is defined, the default access right is used for the resolution process.
The resolution procedure is slightly different for table and table child nodes.
This describes the resolution process used for a given table node or table record N.
For each user-defined permission rule that matches one of the user's profiles, the access rights for N are either:
The locally defined access rights for N;
Inherited from the access rights defined on the table node;
Inherited from the default access rights for dataset values.
All matching user-defined permission rules are used to resolve the access rights for N. Resolution is done according to the restriction policy.
The final resolved access rights will be the minimum between the dataspace, dataset and the resolved access right for N.