Attribuer automatiquement des droits avec les groupes de permission

• Nicht definierter Typ

Ce document explique la convention de nommage des groupes de permission et la manière dont ces groupes reçoivent automatiquement des droits sur les objets sécurisés.

1. Principe

Pour chaque permission d’un type d’objet sécurisé, RestFrontage peut rechercher un groupe portant un nom conventionnel. Si ce groupe existe dans l’organisation de l’objet, un droit lui est attribué lors de la création de l’objet.

La formule de nommage est :

<Permission.Name><NomTechniqueDuType>

Les deux valeurs sont concaténées telles quelles. Aucun espace, tiret ou autre séparateur n’est ajouté par le serveur.

Nom de la permission	Type technique	Groupe recherché
Read	Map	ReadMap
See	Workspace	SeeWorkspace
Read	Equipment	ReadEquipment
Folder Read	Folder	Folder ReadFolder
Folder FullControl	Folder	Folder FullControlFolder

Pour plus d'informations sur les permissions et leur fonctionnement consultez le document Permissions et droits des objets sécurisés

2. Emplacement attendu du groupe

Le groupe doit se trouver directement dans l’unité organizationnelle Groups du sous-domaine de sécurité associé à l’organisation de l’objet.

Son DistinguishedName est construit ainsi :

RN=<Permission.Name><NomTechniqueDuType>, OU=Groups, <DistinguishedNameDuSousDomaine>

Pour une carte de l’organisation Paris, dont le sous-domaine vaut OU=Paris, DC=Immersive, le groupe de lecture attendu est par exemple :

RN=ReadMap, OU=Groups, OU=Paris, DC=Immersive

Un groupe du même nom placé dans une autre organisation ou dans une autre unité n’est pas le groupe recherché pour cet objet.

3. Ce qui est réellement attribué

Le groupe n’est pas ajouté comme membre de l’objet métier. RestFrontage crée ou complète un Right, c’est-à-dire une ligne de droit reliant trois éléments :

Élément du Right	Valeur
Bénéficiaire	Identifiant du groupe de permission.
Objet sécurisé	Identifiant de l’objet créé.
Type sécurisé	Identifiant du type de l’objet.
Autorisation	Flag de la permission ajouté à AuthorizedFlags.
Refus	Aucun refus ajouté par cette convention.

Si un droit existe déjà pour ce groupe et cet objet, le Flag de la permission est fusionné avec les autorisations existantes. Les autres autorisations portées par le même droit sont conservées.

4. Application lors de la création

Lorsqu’un objet est créé par un parcours branché au mécanisme de sécurité, RestFrontage effectue les opérations suivantes :

1. enregistrer l’objet métier ;
2. déterminer son type sécurisé et son nom technique ;
3. retrouver l’organisation et son sous-domaine de sécurité ;
4. charger toutes les permissions du type ;
5. construire le nom de groupe attendu pour chaque permission ;
6. ignorer les groupes qui n’existent pas ;
7. créer ou compléter les droits des groupes trouvés ;
8. enregistrer les modifications de sécurité et actualiser le domaine et les caches concernés.

Toutes les permissions valides du type sont examinées. Si plusieurs groupes conventionnels existent, chacun reçoit le droit correspondant sur le nouvel objet.

Le même calcul applique également les règles configurées dans Droits automatiques. Les droits produits par les règles et ceux produits par les groupes conventionnels sont fusionnés par bénéficiaire.

4.1 Création par les contrôleurs OData sécurisés

La façade OData d'un objet sécurisé déclenche le calcul après l’enregistrement du nouvel objet.

Ce mécanisme est notamment utilisé par les parcours sécurisés des cartes, équipements, workspaces, dossiers et scopes de supervision qui sont des objets sécurisés de base.

4.2 Création d’un dossier dans l’Explorer

La création de dossier depuis l’Explorer appelle explicitement le même calcul. Le dossier doit être associé à une organisation correspondant à un sous-domaine de sécurité actif.

5. Conditions nécessaires

Le droit conventionnel est produit seulement si toutes les conditions suivantes sont réunies :

• le type de l’objet est reconnu comme type sécurisé par le parcours utilisé ;
• au moins une permission existe pour ce type dans le Domain chargé ;
• la permission possède un nom non vide et un Flag différent de 0 ;
• l’organisation de l’objet permet de retrouver un sous-domaine de sécurité ;
• le groupe existe dans OU=Groups de ce sous-domaine avec le nom attendu ;
• le parcours de création appelle le resolver de droits automatiques.

6. Objets déjà existants

La création d’un groupe de permission n’est pas rétroactive. Les objets qui existaient avant le groupe ne reçoivent pas automatiquement son droit.

Pour traiter l’existant :

1. ouvrir Sécurité, puis Outils de sécurité ;
2. ouvrir Droits automatiques des objets existants ;
3. sélectionner le type d’objet et, si nécessaire, l’organisation ;
4. lancer l’audit ;
5. contrôler les objets marqués Incomplet ;
6. utiliser Régulariser ou Régulariser la sélection.

L’audit utilise le même nom technique de type, les mêmes permissions, les mêmes groupes conventionnels et les mêmes règles de droits automatiques que le parcours de création.

La régularisation ajoute ou complète les droits attendus. Elle ne supprime pas les droits supplémentaires déjà présents.

7. Exemple avec une carte

Configuration :

Information	Valeur
Type sécurisé	Map, identifiant 15
Nom de permission	Read
Flag	1
Organisation	Paris
Groupe	RN=ReadMap, OU=Groups, OU=Paris, DC=Immersive

Lorsqu’une nouvelle carte de l’organisation Paris est créée par le contrôleur sécurisé :

1. RestFrontage construit le nom ReadMap ;
2. il retrouve ce groupe dans le sous-domaine Paris ;
3. il crée un Right entre le groupe et la nouvelle carte ;
4. il ajoute le masque 1 dans AuthorizedFlags.

Un utilisateur membre de ReadMap, directement ou par l’intermédiaire d’un autre groupe, peut alors bénéficier de cette autorisation sur la carte.

8. Exemple avec un dossier

Les noms de permission historiques des dossiers contiennent déjà le mot Folder. Le nom technique du type est néanmoins ajouté une seconde fois par la convention.

Permission.Name	Type technique	Groupe attendu
Folder See	Folder	Folder SeeFolder
Folder Read	Folder	Folder ReadFolder
Folder Modify	Folder	Folder ModifyFolder
Folder Write	Folder	Folder WriteFolder
Folder FullControl	Folder	Folder FullControlFolder

Ces noms peuvent sembler redondants, mais ils correspondent exactement au calcul actuel. Créer par exemple un groupe ReadFolder ne remplace pas Folder ReadFolder.

9. Renommer une permission

Le nom du groupe est recalculé à partir de la valeur courante de Permission.Name. Renommer une permission modifie donc immédiatement le groupe recherché pour les prochaines créations et pour les prochains audits.

Le renommage ne supprime pas automatiquement les droits déjà enregistrés avec l’ancien groupe. Avant de renommer une permission :

1. déterminer le nouveau nom conventionnel ;
2. créer ou renommer les groupes nécessaires dans chaque organisation ;
3. contrôler leurs membres ;
4. lancer l’audit des objets existants ;
5. vérifier séparément les anciens droits devenus inutiles avant toute suppression.

10. Ce que le mécanisme ne fait pas

La convention de groupe ne réalise pas automatiquement les opérations suivantes :

• créer le groupe manquant ;
• ajouter des utilisateurs au groupe ;
• traiter immédiatement tous les objets existants lors de la création du groupe ;
• protéger un objet créé par un parcours qui ne déclenche pas les droits automatiques ;
• créer un refus d’accès ;
• retirer les anciens droits lorsqu’un groupe ou une permission est renommé ou supprimé.

11. Résolution des problèmes

Symptôme	Vérifications
Le groupe existe mais aucun droit n’est créé	Vérifier son nom exact, son emplacement dans OU=Groups, l’organisation de l’objet, le nom technique du type et le parcours de création.
Le groupe ReadMap fonctionne dans une organisation mais pas une autre	Chaque sous-domaine doit posséder son propre groupe sous son unité Groups.
Les nouveaux objets sont corrects mais pas les anciens	Lancer l’audit puis la régularisation des droits automatiques.
Le droit existe mais l’utilisateur reste refusé	Vérifier l’appartenance au groupe, les groupes imbriqués, les éventuels DeniedFlags et la permission réellement testée par le parcours.
Le fonctionnement change après le renommage d’une permission	Recalculer le nom avec la nouvelle valeur de Permission.Name, puis régulariser l’existant.
Un groupe de dossier au nom simplifié n’est pas reconnu	Utiliser le nom complet, par exemple Folder ReadFolder.

12. Checklist de mise en service

• Le type technique de l’objet est identifié.
• La valeur exacte de Permission.Name est connue.
• Le nom du groupe est la concaténation exacte des deux valeurs.
• Le groupe se trouve sous OU=Groups dans chaque organisation concernée.
• Les utilisateurs ou groupes métiers sont membres du groupe de permission.
• Un nouvel objet de test reçoit le droit attendu.
• Les objets existants ont été audités et régularisés.
• Les refus éventuels ont été contrôlés séparément.
• Toute création réalisée hors du pipeline standard applique explicitement les droits automatiques.