Permissions

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

• Main principles
• Definition of permissions with EBX.Manager
• Definition of permissions with programmatic rules
• Resolution of permissions
• Illustrations: definition of permissions with EBX.Manager

Main principles

Specification of Permissions

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)

Permissions can be specified in two ways:

• by authorized users, through the use of EBX.Manager (see section Definition of permissions with EBX.Manager);
• by developers, through programmatic permission rules (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 permission rules defined will be able to take into account the information associated to 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.

Users, Roles and Profiles

The definition and the resolution of permissions use largely 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.

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 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 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.
• Under an agreement, permissions cannot be managed. However, instances can still define permissions that were created before a parent instance has been 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 adaptation instances of the parent branch are merged if and only if the user specifies it during the merge process.

Definition of permissions with EBX.Manager

As described below, each level has similar schema that allows the definition of several associations (or rules) of type: "To a given profile, given permissions".

Permissions on branches

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

1. Branch access: defines access rights (read-write, read only, hidden).

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

2. Restriction: indicates if "profile (role or user) - permission (right or action)" associations, for the current branch, should have priority.
3. Create a branch: indicates if it is possible to create a child branch from the current branch.
4. Create a version: indicates if it is possible to create a version of the current branch.
5. Merge a branch: indicates if a profile has the right to merge a branch with its parent branch.
6. Close a branch: indicates if a profile has the right to close the current branch.

If the current profile has the right to create a child branch, one can specify a "template" of permissions related to this child branch. This "template" defines the following information:

• Create a branch
• Create a version
• Merge a branch
• Close a branch
• Change the owner
• Change the permissions

When a user creates a child branch (if he is allowed to do so), these permissions are automatically assigned to the profile "owner" of the new child branch.

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 branch services can also be defined. 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.

Permissions on instances

For a given adaptation instance above an agreement (included), several "profile-permissions" associations 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.
• Duplicate a record: indicates if a profile has the right to duplicate 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

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, and declare this class in the target xml schema under the element xs:annotation/xs:appinfo/osd:extensions, just before the root instance node.

Hence, with these programmatic rules, a field can be updated according to the value of another field, for instance. These rules have to be implemented (through a java interface). For more information, see the Java interfaces AccessRule, ServicePermission and SchemaExtensionsContext.

Note. Only one programmatic access permission can be defined for a given node, instance or occurrence. Hence, a new 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 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.

Profile restriction 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) to 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

General principles for a user

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

• If a user is associated to 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 (cf. tables below).

  Users	Profiles	Access rights	Restriction
  User 1
  	user1	read-write	no
  	roleA	read	yes
  	roleB	hidden	yes
  User 2
  	user2	read-write	no
  	roleC	read	yes
  	roleD	hidden	no
  User 3
  	user3	read-write	no
  	roleE	read	no
  	roleF	hidden	no

  Users	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 the branch will be hidden to him.

Instance 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 the branches level and at the 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

A table node child resolved access permission is computed as follows:

• access right defined on table child node is its specific access right if defined, or its table node specific access right if defined, or the default access right for instance's values;
• at node level, access right resolved on table child node is:
• the minimum of access rights defined for this table child node on all restricted profiles of the target user;
• or the maximum of access rights defined for this table child node on all profiles of the target user, if no restriction is defined;
• the final resolved access right is always the minimum between resolved access rights of: branch, instance, target table node child and programmatic rules.

Consequently, at node level, a table node resolved access permission is always equal to the maximum of the resolved access right of its children. Its final resolved access right is the minimum between resolved access rights of: branch, instance, target table node and programmatic rules.

 

Solving access rights defined with programmatic rules

General principles

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.

Access rule resolution on instance

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

Access 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.

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.

 

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

General principles for a user

When several actions lists are defined for a given profile on an adaptation instance (respectively table), the actions list to considered is dynamically generated after an evaluation of each action type among the different lists (of actions) associated to these user. If some "user-(list of) actions" associations are restricted, then for each action type we verify (among the restricted associations) wether 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).

		Actions lists
Users	Profiles	Create a record	Modify a record	Hide a record	Duplicate a record	Delete a record	Restriction
User 1
	User1	allowed	forbidden	allowed	forbidden	allowed	no
	roleA	allowed	allowed	forbidden	allowed	forbidden	yes
	roleB	allowed	forbidden	allowed	allowed	forbidden	yes
User 2
	User2	allowed	forbidden	forbidden	allowed	forbidden	no
	roleC	allowed	forbidden	forbidden	allowed	forbidden	no
	roleD	allowed	allowed	forbidden	forbidden	forbidden	no

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

 

Illustrations: defining permissions with EBX.Manager

a) Permission on a branch

On the branch page, select the link "Access right":

This link gives access to the following table:

This table presents permissions for the current branch. The button , on this table, allows to add a permission for a given profile in a page similar to the one illustrated thereafter:

The first section, "A" in the figure above, allows to define an access right on the current branch and also possible actions. The second section, "B" in the figure above, allows to define authorized actions on a child branch created by this profile. For example, the owner of the current branch gives permission to profile X for accessing the branch and creating a child branch. Actions allowed for profile X, on the branch he will create, are defined in section "B".

b) Permissions on adaptation instance

In an instance, tab "Permissions" allows to access adaptation instance permissions page:

A first edition page for permissions on adaptation instance appears with the link "Access Rights by Profile" for editing a given profile permissions (cf. figure below):

Afterwards, a second page allows to create instance permissions. For that, you have to click on the button . This page also allows existing permissions modification by users having the right of doing so:

Permissions edition page on instance is illustrated below:

The previous page allows to edit actions on instance (create a child adaptation, manage agreement, etc). It also allows to edit default actions on tables and default access rights on nodes.

This page will also allows to define specific permissions policy for tables or nodes.

c) Specific permissions on nodes

For table nodes, different actions can be defined (create a record, hide a record, etc.) by clicking on the corresponding link "Add an occurrence". A list of actions, similar to the following, then appears:

For all nodes (including table nodes), access rights are defined by selecting the target node in the list (see figure below) and, afterwards, by clicking on the corresponding access right link (ReadOnly, ReadWrite, Hidden or default). The given node is then displayed with its corresponding access right. Hence, one can define an access right for each node of the adaptation instance ( see figure below):

d) Specific permissions on services

Specific permissions on services allow to enable or disable a service (see figure below):

By default, all services are enabled. To disable or enable a service, you only have to click on the corresponding service label in the services list. The service label is grey and crossed when it is disabled.

Permissions

Les permissions spécifient et régulent l'accès de chaque utilisateur aux données de référence et les actions qu'il peut effectuer.

• Principes généraux
• Définition des permissions avec EBX.Manager
• Définition des permissions avec des règles programmatiques
• Résolution des permissions
• Illustrations : définition des permissions avec EBX.Manager

Principes généraux

Spécification des permissions

Les permissions portent sur des actions (action autorisée ou action non autorisée) et des droits d'accès (non visible, lecture et lecture/écriture). Les principales entités contrôlées par les permissions sont :

1. les branches,
2. les instances,
3. les tables,
4. les noeuds terminaux.

Les permissions peuvent être spécifiées de deux manières :

• par les utilisateurs autorisés, au moyen de EBX.Manager (voir section Définition des permissions avec EBX.Manager) ;
• par les développeurs, au moyen des règles de permissions programmatiques et contextuelles (voir section Définition des permissions avec des règles programmatiques).

Résolution des permissions

Les permissions sont toujours résolues dans le contexte d'une session utilisateur authentifiée. Les règles définies pourront ainsi prendre en compte les informations associées à cet utilisateur, en particulier les rôles qui lui sont attribués.

Le processus de résolution est détaillé dans la section Résolution des permissions.

Remarque : A partir d'un environnement Java, la classe SessionPermissions fournit l'accès aux permissions résolues.

Utilisateurs, Rôles et Profils

La définition et la résolution des permissions utilisent largement la notion de profil, terme générique qui permet de désigner soit un identifiant utilisateur, soit un rôle.

Chaque utilisateur peut avoir plusieurs rôles et chaque rôle peut être partagé par plusieurs utilisateurs. Ces informations sont définies dans l'annuaire de EBX.Platform.

Définitions particulières :

• Un utilisateur est un administrateur s'il participe au rôle prédéfini ADMINISTRATOR.
• Un utilisateur est un propriétaire d'une instance s'il participe au profil défini pour l'attribut "propriétaire" de l'instance racine. En ce cas, le rôle prédéfini OWNER sera activé dans le contexte d'une résolution de permission sur l'instance.
• De même, un utilisateur est un propriétaire d'une branche s'il participe au profil défini pour l'attribut "propriétaire" de la branche. En ce cas, le rôle prédéfini OWNER sera activé dans le contexte d'une résolution de permission sur la branche.
• Un utilisateur est un distributeur d'un accord (ou d'une instance sous l'accord), s'il participe au profil défini pour l'attribut "distributeur" de l'accord. En ce cas, le rôle prédéfini DISTRIBUTOR sera activé dans le contexte d'une résolution de permission sur l'instance.

Privilèges particuliers sur les instances

Pour une instance spécifique, les tâches ci-dessous sont accessibles uniquement si l'utilisateur est un administrateur ou un propriétaire de cette instance :

• Gérer les permissions de cette instance ;
• Modifier l'attribut "propriétaire" de l'instance racine ;
• Modifier la documentation de cette instance (libellé et description).

Notes.

• Un administrateur ou un propriétaire d'une instance peuvent avoir un accès restreint à celle-ci au travers des permissions définies, mais dans tous les cas, un tel utilisateur conservera la possibilité d'exécuter les tâches décrites ci-dessus. Cela implique qu'un administrateur voit toujours toutes les instances et que tout utilisateur voit toutes les instances qu'il possède.
• Un administrateur ou le propriétaire de l'adaptation technique nommée "ebx-repository" pourra, dans tous les cas, modifier cette adaptation quelles que soient leurs restrictions sur celle-ci.

Privilèges particuliers sur les branches

Nous disons qu'un utilisateur est un "super propriétaire" d'une branche si :

• il est un propriétaire de cette branche et il est autorisé à gérer ses permissions ;
• ou il est un propriétaire d'une branche ancêtre et il est autorisé à gérer les permissions de cette branche ancêtre.

Pour une branche spécifique, les tâches ci-dessous sont accessibles uniquement si l'utilisateur est un administrateur ou un "super propriétaire" de cette branche :

• Gérer les permissions de la branche ;
• Modifier l'attribut "propriétaire" de la branche ;
• Modifier la documentation de la branche (libellé et description).

Note. Un administrateur ou un "super propriétaire" d'une branche peuvent avoir un accès restreint à celle-ci au travers des permissions définies, mais dans tous les cas, un tel utilisateur conservera la possibilité d'exécuter les tâches décrites ci-dessus. Cela implique qu'un administrateur voit toujours toutes les branches ouvertes et que tout utilisateur voit toutes les branches dont il est le "super propriétaire".

Accords et délégation

Les accords permettent de déléguer la gestion des données de référence au rôle prédéfini DISTRIBUTOR.

Nous avons les comportements spécifiques suivants :

• Sur un accord, si l'utilisateur est un distributeur, cet utilisateur a au minimum un accès en lecture seule au niveau instance ;
• Sous un accord, si l'utilisateur n'est pas un distributeur, il aura au maximum un accès en lecture seule ;
• Sous un accord, aucune permission ne peut être gérée. Cependant, les instances peuvent conserver des permissions définies antérieurement.

Fusion et permissions

Quand une branche est fusionnée, les permissions de niveau branche de la branche parente ne sont pas impactées mais les permissions de niveau instance et inférieures sont fusionnées si l'utilisateur le demande explicitement lors du processus de fusion.

Définition des permissions avec EBX.Manager

Ainsi que détaillé ci-dessous, chaque niveau a un schéma similaire qui permet de définir plusieurs associations (ou règles) de type : "A tel profil sont associées les permissions suivantes".

Permissions sur les branches

Pour une branche donnée, plusieurs associations "profil-permissions" peuvent être spécifiées. Pour chaque profil défini, les permissions possibles sont les suivantes :

1. Accès à la branche : permet de préciser les droits d'accès (lecture-écriture, lecture seule, non visible).

Lecture-écriture	L'utilisateur peut voir la branche. L'utilisateur a le droit d'accéder aux adaptations, en respectant ses droits d'accès sur cette dernière.
Lecture seule	L'utilisateur peut voir la branche et ses versions. Il peut voir les branches filles si les droits sur celles-ci le lui permettent. L'utilisateur peut au plus voir le contenu de la branche. Il ne peut pas modifier le contenu de la branche.
Non visible	L'utilisateur ne peut pas voir la branche ni ses versions. Si l'utilisateur a accès à une sous branche alors il peut voir la branche courante mais ne peut pas la sélectionner. L'utilisateur ne peut pas accéder au contenu de la branche (à ses adaptations). L'utilisateur ne peut pas effectuer d'actions sur la branche.

2. Restriction : elle indique si les associations "profil (rôle ou utilisateur) - permission (droit ou action)", pour la branche courante, doivent être prises en compte de façon prioritaire.
3. Créer une branche : indique s'il est possible de créer une sous-branche à partir de la branche courante.
4. Créer une version : indique s'il est possible de créer une version de la branche courante.
5. Fusionner la branche : indique si un profil a le droit de fusionner la branche courante avec la branche parente.
6. Fermer la branche : indique si un profil a le droit de fermer la branche courante.

Si le profil courant est autorisé à créer une branche fille, on peut de plus préciser un "template" de permissions sur la branche fille. Ce "template" définit les informations suivantes :

• Créer une branche
• Créer une version
• Fusionner la branche
• Fermer la branche
• Changer de propriétaire
• Changer les permissions

Lorsque l'utilisateur crée une branche fille (s'il en a l'autorisation), ces permissions sont automatiquement attribuées au profil "propriétaire" pour la nouvelle branche fille.

Notons que seul l'administrateur et le propriétaire d'une branche peuvent définir un nouveau propriétaire de cette branche ou en modifier les permissions associées. Pour cela, ils doivent modifier les informations générales sur la branche (rôle propriétaire entre autres) ainsi que les permissions des différents utilisateurs.

Les permissions sur les services de niveau branche peuvent également être définies. Par défaut, tous les services de niveau branche sont activés. L'administrateur ou le "super propriétaire" de la branche ou un utilisateur qui est autorisé à changer les permissions de la branche cible, peut modifier les permissions de ces services de niveau branche pour un utilisateur donné.

Permissions sur les instances

Pour une instance d'adaptation donnée située au dessus d'un accord (inclus), plusieurs associations "profil-permissions" peuvent être spécifiées. Pour chaque profil défini, les permissions possibles sont les suivantes :

Actions sur l'instance

• Mode restreint : il indique si les associations "profil (rôle ou utilisateur) - permission (droit, action)", pour l'instance courante, doivent être prises en compte de façon prioritaire.
• Créer une adaptation fille : indique si le profil donné a le droit de créer une adaptation fille.
• Gérer des accords : indique si le profil donné est autorisé à créer un accord à partir de cette adaptation.
• Dupliquer l'adaptation : indique si le profil donné est autorisé à dupliquer l'adaptation.
• Changer le parent de l'adaptation : indique si le profil donné est autorisé à changer l'adaptation parente d'une adaptation fille.

Actions par défaut sur les tables

Pour une table donnée, plusieurs associations "profil-permissions" peuvent être spécifiées. Pour chaque profil défini, les actions possibles sont les suivantes :

• Créer un enregistrement : indique si le profil est autorisé à créer une occurrence dans la table.
• Surcharger un enregistrement : indique si le profil est autorisé à surcharger un enregistrement (dans le cas de l'héritage de données dans un arbre d'adaptation).
• Occulter un enregistrement : indique si le profil est autorisé à cacher un enregistrement de la table.
• Dériver un enregistrement : indique si le profil est autorisé à dupliquer un enregistrement de la table.
• Supprimer un enregistrement : indique si le profil est autorisé supprimer un enregistrement de la table.

Permissions sur les tables

Les actions spécifiées sur les tables surchargent les actions par défaut (voir ci-dessus) sur ces tables dans l'instance.

Droit d'accès par défaut sur les valeurs des noeuds

• Lecture-Ecriture : les noeuds peuvent être consultés et modifiés (mise à jour des valeurs).
• Lecture : les noeuds peuvent uniquement être consultés mais pas modifiés.
• Non visible : les noeuds ne sont pas visibles.

Permissions sur les noeuds terminaux

Les droits définis sur les noeuds terminaux surchargent le droit par défaut (voir ci-dessus) sur les valeurs des noeuds de l'instance.

Permissions sur les services

Des permissions sur des services de niveau instance peuvent être définies. Par défaut, tous les services d'instance sont activés. L'administrateur ou le propriétaire de l'instance peut donc modifier ces permissions pour des profils donnés.

Définition de permissions avec des règles programmatiques

Sur une instance, les droits d'accès peuvent être définis par des règles programmatiques sur des noeuds cibles. Ceci peut être fait pour tous les noeuds de l'instance, pour des occurrences de table, pour un noeud spécifique ainsi que pour un noeud complexe et tous ses descendants. Pour définir des règles programmatiques, il faut créer une classe java qui implémente l'interface SchemaExtensionsContext, et déclarer cette classe dans le schéma xml cible sous l'élément xs:annotation/xs:appinfo/osd:extensions, avant la déclaration du noeud racine de l'instance.

Ainsi, avec les règles programmatiques, un champ peut être ou non mis à jour selon la valeur d'un autre champ, par exemple. Ces règles doivent être implémentées (avec une interface java). Pour plus d'informations, consulter les interfaces Java AccessRule, ServicePermission et SchemaExtensionsContext.

Note. On ne peut définir qu'un seul droit d'accès programmatique pour un noeud, une instance ou une occurrence donné(e). Ainsi, la définition d'un nouveau droit d'accès programmatique remplace l'ancien droit existant.

 

Résolution des permissions

La résolution des permissions est toujours effectuée dans le contexte d'une session utilisateur et de ses rôles associés. De manière générale, il est important de comprendre qu'une résolution restrictive est effectuée entre un niveau et ses niveaux supérieurs. Concrètement, l'utilisateur ne peut pas avoir une permission plus élevée que celle résolue à un niveau supérieur.

Notons également que des permissions programmatiques seront également invoquées si elles sont spécifiées. Le résultat de ces règles programmatiques sera alors systématiquement pris en compte de manière restrictive.

Notion de restriction de profil

Les permissions définies avec EBX.Manager possèdent la notion de restriction. Soient un ensemble de profils auxquels appartient un utilisateur, restreindre certains d'entre eux implique de considérer leurs permissions comme prioritaires sur celles définies pour les profils non restreints. Ainsi, de façon générale :

• si des restrictions sont définies, alors la permission minimale sur les profils restreints est considerée
• si aucune restriction n'est définie, alors la permission maximale sur l'ensemble des profils est prise

Note. Ainsi, pour cacher une branche (respectivement une instance ou un noeud) à tous les utilisateurs, il suffirait à l'administrateur ou au propriétaire de cette branche de définir une restriction sur l'association entre le profil prédéfini "Profile.EVERYONE" et le droit d'accès "non visible".

 

Résolution des droits

 

Résolution des droits d'accès définis avec EBX.Manager

Principes généraux pour un utilisateur

Pour la résolution des droits d'accès définis avec EBX.Manager, il existe trois niveaux de résolution : branche, instance et noeud.

• Si un utilisateur est associé à différents droits d'accès à un niveau donné et si des restrictions ont été définies pour ses associations "utilisateur-droits", alors le minimum des droits est appliqué. S'il n'y a pas de restrictions définies, alors c'est le maximum des droits qui est appliqué pour l'utilisateur considéré (cf. tableaux ci-dessous).

  utilisateurs	profils	Droits d'accès	Restriction
  utilisateur 1
  	utilisateur1	lecture-écriture	non
  	roleA	lecture	oui
  	roleB	non visible	oui
  utilisateur 2
  	utilisateur2	lecture-écriture	non
  	roleC	lecture	oui
  	roleD	non visible	non
  utilisateur 3
  	utilisateur3	lecture-écriture	non
  	roleE	lecture	non
  	roleF	non visible	non

  utilisateurs	Droit appliqué
  utilisateur 1	non visible
  utilisateur 2	lecture
  utilisateur 3	lecture-écriture

• A un niveau donné, le droit le plus restrictif de ce niveau et des niveaux supérieurs est adopté. Par exemple, si une adaptation instance est en lecture-écriture mais que la branche contenante ne permet que la lecture alors l'utilisateur a un droit en lecture seule sur l'adaptation.

Note. Les droits définis sur une adaptation instance seront appliqués sur ses adaptations filles. Il est possible de surcharger ces droits dans une adaptation fille. Le mécanisme d'héritage est ainsi mis en oeuvre non seulement pour les valeurs mais aussi pour les droits.

Résolution du droit d'accès d'une branche/version

Au niveau branche, le droit d'accès considéré sera le suivant : si un utilisateur a plusieurs droits définis (un pour chacun de ses rôles, par exemple) et si des restrictions ont été définies alors le minimum des associations "utilisateur-droits" restreintes est appliqué. Sinon, c'est le maximum des associations "utilisateur-droits" de l'utilisateur considéré qui est appliqué. Par ailleurs, si l'utilisateur n'a aucun droit défini alors par défaut cette branche lui sera cachée.

Résolution du droit d'accès d'une instance

Au niveau instance, le même principe que celui appliqué aux branches est utilisé. De plus, le droit d'accès sur l'instance est défini par le minimum entre le droit sur la branche et le droit sur l'instance (identifié en utilisant un principe de résolution des droits identique à celui appliqué au niveau des branches). Par exemple, si la branche est en lecture seule pour l'utilisateur U et une adaptation de la branche est en écriture pour ce même utilisateur, alors U n'aura qu'un accès en lecture sur l'adaptation.

Résolution du droit d'accès d'un noeud d'instance

Au niveau noeud, le même principe que celui appliqué aux branches et aux instances est utilisé. De plus, le droit sur le noeud est défini par le minimum entre le droit sur l'instance et le droit sur le noeud (identifié en utilisant un principe de résolution des droits identique à celui appliqué au niveau des branches et des instances).

Note. Au niveau noeud, on peut définir un droit d'accès spécifique pour le noeud cible. Si aucun droit d'accès spécifique n'est défini, le droit d'accès par défaut est alors considéré dans le processus de résolution. Cependant, cette procédure est légèrement différente pour les noeuds tables ou fils de tables (voir la section suivante).

Cas spécifique de noeuds tables et de noeuds fils de tables

La résolution du droit d'accès d'un noeud fils de table s'effectue comme suit:

• le droit d'accès défini sur un noeud fils de table est son droit d'accès spécifique s'il existe, ou le droit d'accès spécifique de sa table s'il existe, ou alors le droit d'accès par défaut des noeuds de l'instance ;
• au niveau noeud, le droit d'accès résolu sur un noeud fils de table est :
  • le minimum des droits d'accès définis pour ce noeud fils de table sur tous les profils restreints de l'utilisateur cible ;
  • ou le maximum des droits d'accès définis pour ce noeud fils de table sur tous les profils de l'utilisateur cible, si aucune restriction n'existe ;
• le droit d'accès final résolu est toujours le minimum entre les droits d'accès : de la branche, de l'instance, du noeud fils de table et des règles programmatiques.

Par conséquent, au niveau noeud, le droit d'accès résolu sur une table est toujours égal au maximum des droits d'accès résolus de ses enfants. Son droit d'accès final résolu est le minimum entre les droits d'accès : de la branche, de l'instance, du noeud de la table et des règles programmatiques.

 

Résolution des droits d'accès définis avec des règles programmatiques

Principes généraux

Il existe trois niveaux de résolution: instance, occurrence et noeud. Etant donné que l'on ne peut considérer qu'une seule règle programmatique à un niveau donné, la dernière règle définie est celle qui sera utilisée par la procédure de résolution.

Résolution sur une instance

Pour une instance, la dernière règle définie constitue la règle résolue de cette instance.

Résolution sur une occurrence

Pour une occurrence, la règle résolue est le minimum entre la règle résolue de l'instance et la règle définie pour cette occurrence.

Résolution sur un noeud

Si le noeud est un noeud fils d'occurrence, la règle résolue est le minimum entre la règle résolue sur l'occurrence et la règle définie pour ce noeud. Dans le cas contraire, la règle résolue est le minimum entre la règle résolue de l'instance et celle définie pour ce noeud.

 

Note. Le droit d'accès résolu sur une instance ou un noeud d'instance est le minimum entre la résolution des droits d'accès définis avec EBX.Manager et la résolution des droits d'accès programmatiques s'ils existent.

 

Résolution des actions

Principes généraux pour un utilisateur

Lorsque plusieurs listes d'actions sont définies pour un utilisateur donné sur une instance d'adaptation (respectivement table), la liste d'actions à considérer est générée dynamiquement après évaluation de chaque type d'action dans les différentes listes (d'actions) associées à cet utilisateur. Si certaines associations "utilisateur-(liste) actions" sont restreintes, alors pour chaque action on vérifie si elle est non autorisée au moins une fois pour l'interdir (et ceci se fait à partir de la liste des associations "utilisateur-actions" restreintes). S'il n'y a pas de restriction, il suffit qu'une action soit autorisée au moins une fois pour être validée (cf. tableaux ci-dessous pour des actions sur des tables).

		Liste d'actions
Utilisateurs	Profils	Créer un enregistrement	Surcharger un enregistrement	Occulter un enregistrement	Dériver un enregistrement	Supprimer un enregistrement	Restriction
Utilisateur 1
	Utilisateur1	autorisé	interdit	autorisé	interdit	autorisé	non
	roleA	autorisé	autorisé	interdit	autorisé	interdit	oui
	roleB	autorisé	interdit	autorisé	autorisé	interdit	oui
Utilisateur 2
	Utilisateur2	autorisé	interdit	interdit	autorisé	interdit	non
	roleC	autorisé	interdit	interdit	autorisé	interdit	non
	roleD	autorisé	autorisé	interdit	interdit	interdit	non

Utilisateurs	Liste d'actions appliquées
Utilisateur 1
	Créer un enregistrement
	Dériver un enregistrement
Utilisateur 2
	Créer un enregistrement
	Surcharger un enregistrement
	Dériver un enregistrement

Illustrations : définition de permissions avec EBX.Manager

a) Permissions sur une branche

Sur la page principale de la branche, sélectionnez le lien "Droit d'accès" :

Ce lien permet d'accéder à la page suivante :

Cette page présente les permissions pour la branche en cours. Le bouton , dans cette page, permet d'ajouter une permission pour un profil donné sur une page similaire à celle présentée ci-dessous :

La première section, "A" dans la figure ci-dessus, permet de définir un droit d'accès sur la branche courante ainsi que les actions possibles. La seconde section, "B" dans la figure ci-dessus, permet de définir les actions qui seront autorisées sur la sous branche qui sera créée par ce profil. Par exemple, le propriétaire de la branche courante autorise le profil X à accéder à la branche et à créer une sous branche. Les actions autorisées pour le profil X, sur la branche qu'il créera, sont définies en "B".

b) Permissions sur une instance d'adaptation

Dans une adaptation, l'onglet "Permissions" permet d'accéder à la page des permissions de l'instance :

Une première page d'édition des permissions sur l'instance apparaît avec le lien "Droits d'accès par profil" pour l'édition des permissions pour un profil donné (cf. figure ci-dessous) :

Ensuite, une seconde page qui présente les permissions pour l'instance permet la création de permissions. Pour cela, il faut cliquer sur le bouton . Cette page permet également la modification de permissions existantes, si on en a le pouvoir :

La page d'édition des permissions sur l'instance est présentée ci-dessous :

La page précédente permet d'éditer les actions autorisées sur l'instance (création d'une adaptation fille, gestion des accords, etc.). Elle permet aussi de définir les actions par défaut sur les tables et les droits d'accès par défaut sur les noeuds de l'instance d'adaptation.

Cette page va permettre également de définir des permissions spécifiques pour des tables ou pour des noeuds quelconques de l'instance.

c) Droits spécifiques sur des noeuds

Pour les noeuds table, différentes actions peuvent être définies (créer un enregistrement, occulter un enregistrement, etc.). Après avoir cliqué sur le lien correspondant "Ajouter une occurrence", on obtient une liste d'actions similaires à celle présentée ci-après :

Pour tous les noeuds (y compris les tables), les droits d'accès sont définis en selectionnant le noeud cible dans la liste des noeuds (cf. figure ci-dessous) et, ensuite, en cliquant sur le lien du droit d'accès correspondant (Lecture, Ecriture, Non visible ou défaut). Le noeud cible est alors affiché avec son droit d'accès correspondant. Ainsi, on peut définir un droit d'accès pour chaque noeud de l'instance (cf. figure ci-après) :

d) Droits spécifiques sur les services

Les droits d'accès sur les services permettent d'activer ou de désactiver un service (cf. figure ci-après) :

Par défaut, les services associés à l'adaptation sont tous activés. Pour désactiver ou activer un service, il faut simplement cliquer sur le label correspondant dans la liste des services. Le label du service est grisé et barré si le service est désactivé.