Home > References

Permissions

Permissions specify and regulate the access of each user to Master Data and the actions he can execute.

• Main principles
  • Users, Roles and Profiles
  • Permission Rules
  • Resolution of Permissions
  • Particular privileges on instances
  • Particular privileges on branches
  • Agreements and delegation
  • Merge and permissions
• Definition of permissions with EBX.Manager
  • Permissions on branches
  • Permissions on a new branch
  • Permissions on adaptation instances
• Definition of permissions with programmatic rules
• Resolution of permissions
  • Restriction policy notion
• Solving access rights
  • Solving access rights defined with EBX.Manager
  • Solving access rights defined with programmatic rules
• Solving actions

Main principles

Permissions are related to actions (action authorized or not) and to access rights (hidden, read, read-write). The main entities controlled by permissions are:

• branches,

• adaptation instances,

• tables,

• terminal nodes (which hold Master Data values).

Users, Roles and Profiles

The definition and the resolution of permissions make extensive use of the profile notion, a generic term that references either a user or a role.

Each user can participate in several roles and a role can be shared by several users. Such information is defined by EBX.Platform Directory .

Particular definitions:

• A user is an administrator when he participates in the built-in role ADMINISTRATOR.

• A user is an owner of an instance when he participates in the "owner" attribute specified on the root instance ("Infos" tab). In this case, the built-in role OWNER is activated when permissions are resolved in the context of the instance.

• A user is an owner of a branch when he participates in the "owner" attribute specified on the branch. In this case, the built-in role OWNER is activated when permissions are resolved in the context of the branch.

• A user is a distributor of an agreement (or of an instance under the agreement) , when he participates in the "distributor" attribute specified on the agreement ("Infos" tab). In this case, the built-in role DISTRIBUTOR is activated when permissions are resolved in the context of the instance.

Permission Rules

A permission rule defines the authorization granted to a profile on an entity.

Two kinds of permission rules exist:

• user-defined permission rules, created through the use of EBX.Manager (see section Definition of permissions with EBX.Manager );

• programmatic permission rules, created by developers (see section Definition of permissions with programmatic rules ).

Resolution of Permissions

Permissions are always resolved in the context of an authenticated user session. Hence, the defined permission rules will be able to take into account the information associated with the current user, more particularly the roles in which he participates.

The resolution process is further detailed in section Resolution of permissions .

Note. From Java environment, the class SessionPermissions provides access to the resolved permissions.

Particular privileges on instances

For a specific adaptation instance, the following tasks are accessible only if the user is an administrator or an owner of this instance:

• Manage permissions of instance.

• Change the owner of the root instance.

• Change the documentation of instance (label and description).

Notes.

• An administrator or an owner of an adaptation can have a restricted access to an instance through permissions definitions, but in any case, he will keep the possibility to perform the tasks defined above. This implies that an administrator always sees all adaptation instances and that any user sees all adaptation instances that he owns.

• An administrator or the owner of the technical adaptation named " ebx-repository " can modify in any case this one, whatever their restrictions on it are.

Particular privileges on branches

A user is a "super owner" of a branch when:

• He is an owner of the branch and he is allowed to manage its permissions;

• or he is an owner of an ancestor branch and he is allowed to manage the permissions of this ancestor.

For a specific branch, the general rule is that only an administrator or a "super owner" may perform the following administration tasks:

• Manage permissions of branch.

• Change owner of branch.

• Lock and unlock branch.

• Change the documentation of branch (label and description).

Notes. An administrator or an owner of a branch can have a restricted access to it through permissions definitions, but in any case, he will keep the possibility to perform administration tasks defined above. This implies that an administrator always sees all open branches and that any user sees all the branches that he owns.

Agreements and delegation

Agreements allow to delegate Master Data Management to the built-in dynamic DISTRIBUTOR role.

We have the following specific behaviors:

• On an agreement itself, if the user is a distributor, this user has at least a read-only access at instance level.

• Under an agreement, a user that is not a distributor has at most a read-only access and cannot execute any service.

• Under an agreement, permissions cannot be managed. However, instances can still define permissions that were created before a parent instance was set as an agreement.

Merge and permissions

When a branch is merged, the permissions of its parent branch are not impacted but the permissions of the adaptation instances of the parent branch are merged if and only if the user specifies it during the merge process. However when some nodes are hidden for a profile, this profile will not be able to merge since he would not be aware of the actual impacts on data.

Definition of permissions with EBX.Manager

As described below, each level has a similar schema that allows the definition of several permission rules.

Permissions on branches

For a given branch, several permission rules can be specified. For each defined profile, the allowed permissions are the following:

1. Branch access: defines access rights (read-write, read-only or hidden, see below for definition).

2. Restriction: indicates if "profile (role or user) - permission (right or action)" associations, for the current branch, should have priority.

3. Create a child branch: indicates if it is possible to create a child branch from the current branch.

4. Create a child version: indicates if it is possible to create a version of the current branch.

5. Initiate merge: indicates if a profile has the right to merge a branch with its parent branch.

6. Export archive: indicates if a profile has the right to export the current branch as an archive.

7. Import archive: indicates if a profile has the right to import an archive into the current branch.

8. Close a branch: indicates if a profile has the right to close the current branch.

9. Close a version: indicates if a profile has the right to close a version of the current branch.

10. Rights on services: indicates if a profile has the right to execute some home services. By default, all branch services are enabled. The administrator or the "super owner" of the target branch or a given user who is allowed to change permissions on the target branch can then modify these branch services permissions for a given profile.

11. Permissions of child branch when created: defined the same permissions as above but on current branch children.

Read-write	The user can see the branch. The user has the right to access adaptations according to his rights on these.
Read-only	The user can visualize the branch and its versions. He can see the child branches if he has the right to do so. The user can at most visualize the contents of the branch. He cannot modify the branch contents.
Hidden	The user can see neither the branch nor its versions. If the user has access to a child branch, then he can see the current branch but he cannot select it. The user cannot access the branch contents (adaptations contents). The user cannot perform any action on the branch.

Permissions on a new branch

When a user creates a child branch (if he is allowed to do so), the permissions of this new branch are automatically assigned to the profile "owner" and are determined from the Permissions of child branch when created section defined on the parent branch, according to the permissions resolution process. i.e if the session's current user has one or several roles restricted by the restriction policy node, then the more restrictive permissions will be used. If no restriction is defined for the current user, the less restrictive permissions will be used.

Please note that only the administrator and the owner of a branch can define a new owner for this branch or modify the associated permissions. They can also modify general information on the branch ("owner role" for instance) and also permissions of the different users.

Permissions on adaptation instances

For a given adaptation instance above an (included) agreement, several permission rules can be specified. For each defined profile, permissions are the following:

Actions on instance

• Restricted mode: indicates if "profile (role or user) - permission (right or action)" associations, for the current instance, should have priority.

• Create a child adaptation: indicates if a given profile has the right to create a child adaptation.

• Manage agreement: indicates if a given profile has the right to create an agreement from a given adaptation.

• Duplicate adaptation: indicates if a given profile has the right to duplicate an adaptation.

• Change the adaptation parent: indicates if a given profile has the right to change the parent adaptation of a given child adaptation.

Default actions on tables

For a given table, several "profile-permissions" associations can be specified. For each defined profile, possible actions are the following:

• Create a record: indicates if a profile has the right to create records in a table.

• Modify a record: indicates if a profile has the right to modify a record (in case of inheritance of data in an adaptation tree).

• Hide a record: indicates if a profile has the right to hide a record in a table.

• Delete a record: indicates if a profile has the right to delete a record in a table.

Permissions on tables

The actions specified on tables modify the default actions ( cf. above) on these tables in the adaptation instance.

Default access right on nodes values

• Read-write: nodes can be consulted and modified (modification of values).

• Read: nodes can only be consulted, not modified.

• Hidden: nodes are hidden.

Permissions on terminal nodes

Rights specified on terminal nodes modify the default rights ( cf. above) on these terminal nodes.

Permissions on services

Permissions on instance services can also be defined. By default, all instance services are enabled. The administrator or the owner of the instance can modify these services permissions for a given profile.

Definition of permissions with programmatic rules

On an instance, access permissions can be defined with programmatic rules on target nodes. This can be done for all instance's nodes, for table's occurrences, for a specific node and for a given complex node and its child nodes. To define programmatic rules, one should create a class that implements the java interface SchemaExtensionsContext .

It is also possible to define a permission for a service by means of a programmatic rule. In order to do so, one should create a class that implements the java interface ServicePermission

Hence, with these programmatic rules, a field can be updated according to the value of another field, for instance.

Note. Only one programmatic access permission can be defined for a given node, instance or occurrence. Hence, a newly defined programmatic access permission replaces the old existing one.

Resolution of permissions

The resolution of permissions is always done in the context of a user's session and his associated roles. In general, a restrictive resolution is performed between a given level and its parent level. Hence at a given level, a user cannot have a permission higher than the one resolved at a parent level.

We can also notice that programmatic permissions can be invoked as well. These programmatic permissions are always restrictive.

Restriction policy notion

Permissions defined with EBX.Manager can be restricted. Given a set of profiles to which a user belongs to, restricting some of them means to consider their permissions more important than those defined for non restricted profiles. Hence, generally:

• if restrictions are defined, the minimum permission over the restricted profiles is considered

• if no restriction is defined, the maximum permission over profiles is then taken

Note. Hence, for hiding a branch (respectively an instance or a node) from all users, the administrator or the owner of this branch should define a restriction on the association between the built-in profile "Profile.EVERYONE" and the access right "hidden".

Solving access rights

Solving access rights defined with EBX.Manager

For access rights resolution defined with EBX.Manager, there are three levels of resolution: branch, instance and node.

If a user is associated with different access rights at a given level and if restrictions have been defined for these "user-rights" associations, then the minimum of the restricted rights is applied. If there is no restriction, then the maximum access right is applied for the given user. The following tables illustrate the resolution mechanism.

Three users exist and each one of them participates in different roles or profiles:

• User 1: user1 - role A - role B

• User 2: role A - role B - role C

• User 3: user3 - role A - role C

This table indicates the rights associated with those different profiles on a specific object

Role/Profile	Rights	Restriction policy
user1	Hidden	Yes
user3	Read	No
Role A	Read/Write	No
Role B	Read	Yes
Role C	Hidden	No

This table lists the right which will be applied for each user after rights resolution.

User	Right applied
User 1	hidden
User 2	read
User 3	read-write

At a given level, the most restrictive right of this level and of the higher levels is applied. For instance, if an adaptation instance is in read-write access and the container branch allows only reading, then the user will have a read-only access right on this adaptation.

Note. Rights defined on an adaptation instance will be applied on its child adaptations. It is possible to modify these rights on the child adaptations. The inheritance mechanism is therefore applied for either values or access rights.

Branch/Version access right resolution

At branch level, the access right will be the following: if a user has several rights defined (one for each of his roles) and if restrictions have been defined, then the minimum of the restricted "user-rights" associations is applied. Otherwise, the maximum of the "user-rights" associations of the given user is applied.

On the other hand, if the user has no right defined, then if he is administrator or owner of the branch, he will have a read-write access to this branch, otherwise the branch will be hidden from him.

Instant access right resolution

At instance level, the same principle as the one applied to branches is used. Moreover, access right on instance is defined by the minimum between the right on the branch and the right on the instance (identified by using the "solving rights" principle similar to the one applied at the branches level). For instance, if a branch is in read-only access for the user U and an adaptation of the branch is in read-write access for the same user, then U will have a read-only access on the adaptation.

Node access right resolution

At node level, the same principle as the one applied to branches and to instances is used. Moreover, the right on the node is defined by the minimum between the right on the instance and the right on the node (identified by using the "solving rights" principle similar to the one applied at branches level and at instances level).

Note. At node level, one can define a specific access right for the target node. If no specific access right is defined, the default access right is then considered for the resolution process. However, the procedure is slightly different for table and table child node (see next section).

Specific case of table and table child node

This section describes the resolution process applied for a given table node or table record N . 

For each user-defined permission rules that matches one of the user's profiles, the access right for N is either:

1. The locally defined access right for N ;

2. Inherited from the access right defined on the table node;

3. Inherited from the default access right for instance's values.

Then, all matching user-defined permission rules will provide the resolved access right for N . Resolution is done according to restriction policy .

The final resolved access right will be the minimum between branch, instance, the resolved access right for N and existing programmatic permission rules according to resolution of permission .

Solving access rights defined with programmatic rules

For programmatic rules resolution, there are three levels of resolution: instance, occurrence and node. Since only one programmatic access rule can be set for a given level, the last rule set is the one considered in the resolution procedure.

Rule resolution on instance

On an instance, the last rule set is considered as the resolved rule for the instance.

Rule resolution on occurrence

On an occurrence, the resolved rule is the minimum between the resolved rule on instance and the rule set on this occurrence. See setAccessRuleOnNode in SchemaExtensionContext for more details.

Access rule resolution on node

If the node is an occurrence child node, the resolved rule is the minimum between the resolved rule on occurrence and the rule set on this node. If not, the resolved rule is the minimum between the resolved rule on instance and the rule set on this node. See setAccessRuleOnOccurrence in SchemaExtensionContext for more details.

Display policy in tableRef with access rules on rows

If a row is hidden due to an access rule, it will not appear in tableRef drop-down.

Note. The resolved access right on an instance or an instance's node is the minimum between the resolved access rights defined with EBX.Manager and the resolved programmatic rules if they exist.

Solving actions

When several actions lists are defined for a given profile on an adaptation instance (respectively table), the actions list to consider is dynamically generated after an evaluation of each action type among the different lists (of actions) associated with this user. If some "user-(list of) actions" associations are restricted, then for each action type we verify (among the restricted associations) whether it is forbidden at least once to forbid it at all. If there is no restriction, then if at least one action type is authorized then the action is finally allowed ( cf. tables below for actions on tables).

Two users exist and each one of them participates in different roles or profiles:

• User 1: user1 - role A - role B

• User 2: role C - role D

This table indicates the rights associated with those different profiles on a table

Role/Profile	Create a record	Modify a record	Hide a record	Duplicate a record	Delete a record	Restriction policy
user1	Allowed	Forbidden	Allowed	Forbidden	Allowed	No
Role A	Allowed	Allowed	Forbidden	Allowed	Forbidden	Yes
Role B	Allowed	Forbidden	Allowed	Allowed	Forbidden	Yes
Role C	Allowed	Allowed	Forbidden	Forbidden	Forbidden	No
Role D	Allowed	Forbidden	Forbidden	Allowed	Forbidden	No

This table lists the actions that will be allowed for each user after rights resolution.

Users	Actions list applied
User 1	Create a record
	Duplicate a record
User 2	Create a record
	Modify a record
	Duplicate a record

Home > References