Accorder des droits conditionnels

• Tipo non definito

Ce document s’adresse aux administrateurs de sécurité, responsables fonctionnels et intégrateurs. Il présente le principe des droits conditionnels, leur évaluation, l’interface de gestion et la façade d’administration associée.

1. À quoi sert un droit conditionnel ?

Un droit conditionnel accorde une permission à un groupe seulement lorsque l’utilisateur possède déjà une autre permission sur le même objet sécurisé.

Dans la configuration de sécurité, ce comportement est représenté par un objet ConditionalPermissionGrant, appelé droit conditionnel dans l’interface. Cet objet ne contient pas une liste d’équipements : il décrit une règle réutilisable en reliant :

• un titre et une description qui expliquent son objectif métier ;
• un groupe bénéficiaire ;
• un type d’objet sécurisé ;
• une permission accordée ;
• une permission requise, qui doit déjà être effective sur le même objet.

La règle portée par cet objet se lit ainsi :

SI l’utilisateur appartient au groupe bénéficiaire
ET s’il possède la permission requise sur l’objet X
ALORS il reçoit la permission accordée sur ce même objet X

Imaginons le cas suivant dans Immersive : un utilisateur doit consulter les cartes de son périmètre et gérer uniquement les fiches des équipements qu’il est déjà autorisé à voir.

Ses droits reposent sur trois familles de groupes indépendantes :

• le profil de sécurité Gestion Fiches représente la capacité fonctionnelle à gérer les fiches des équipements ;
• les groupes géographiques, organisés du niveau national jusqu’aux régions, départements et gares, déterminent les cartes et les lieux auxquels il peut accéder ;
• les groupes d’équipements, comme Éclairage, VMC ou Ascenseur, déterminent les familles d’équipements sur lesquelles la permission See est effective.

Deux membres de Gestion Fiches peuvent donc avoir des périmètres différents : l’un peut voir les équipements d’éclairage d’une région, tandis qu’un autre peut voir les ascenseurs d’un seul département.

La question métier devient alors : comment accorder aux membres de Gestion Fiches la permission Modify sans élargir leur périmètre See ?

Une première approche consisterait à accorder directement Modify au groupe Gestion Fiches sur toutes les familles d’équipements. Ce droit serait cependant beaucoup trop large : tous les gestionnaires de fiches pourraient modifier toutes les familles concernées, indépendamment de leur propre périmètre de visibilité.

Voir le document Permissions et droits des objets sécurisés

Il serait possible d’accorder manuellement Modify à chaque utilisateur sur chaque équipement qu’il voit. Cette solution demanderait cependant une maintenance considérable et chaque évolution des droits deviendrait une source potentielle d’erreurs.

C’est ici qu’intervient le droit conditionnel. Pour le groupe Gestion Fiches, la règle se lit ainsi :

• si l’utilisateur appartient au groupe Gestion Fiches ;
• et s’il possède déjà See sur un équipement ;
• alors lui accorder Modify sur ce même équipement.

Gestion Fiches peut ainsi rester un groupe purement fonctionnel. L’appartenance à ce groupe n’élargit pas, à elle seule, les équipements visibles. Elle devient un chemin d’autorisation vers Modify uniquement lorsqu’un droit conditionnel applicable trouve déjà See sur l’équipement testé.

On peut alors créer le droit conditionnel suivant :

Élément	Valeur
Titre	Modification des équipements visibles par les gestionnaires de fiches
Description	Permet aux membres de Gestion Fiches de modifier uniquement les équipements sur lesquels See est déjà effectif.
Groupe bénéficiaire	Gestion Fiches
Type d’objet sécurisé	Equipment
Permission accordée	Modify
Permission requise	See
Portée	Le même équipement

Si See est effectif sur un équipement — grâce à une appartenance directe ou indirecte à un groupe, ou grâce à une permission directe — l’appartenance à Gestion Fiches permet alors d’obtenir Modify sur ce même équipement. Si See n’est pas effectif, Modify reste refusé.

2. Comment le périmètre de visibilité est-il conservé ?

Le droit conditionnel ne référence directement ni une région, ni un département, ni une gare, ni une famille d’équipements particulière. Pour chaque équipement testé, la sécurité détermine d’abord si la permission See est effective pour l’utilisateur. Dans cet exemple, ce See résulte du croisement de deux dimensions :

• les groupes géographiques déterminent où l’utilisateur peut accéder aux équipements ;
• les groupes d’équipements déterminent quelles familles d’équipements lui sont visibles.

Ces groupes ne sont pas enregistrés dans le droit conditionnel. Ils contribuent en amont au calcul de See. La règle conditionnelle vérifie ensuite seulement deux éléments sur l’équipement concerné :

• l’utilisateur appartient-il au groupe fonctionnel Gestion Fiches ?
• possède-t-il déjà See sur ce même équipement ?

Prenons l’exemple d’Alice :

• Alice est membre du groupe Gestion Fiches ;
• sa hiérarchie géographique lui donne accès à une région ;
• ses groupes d’équipements lui permettent de voir les équipements d’éclairage de cette région.

Avec la règle Gestion Fiches : Modify si See, le résultat varie pour chaque équipement :

Équipement testé	Périmètre géographique	Famille visible	See	Modify
Éclairage dans sa région	Autorisé	Oui	Effectif	Accordé
Ascenseur dans sa région	Autorisé	Non	Absent	Refusé
Éclairage hors de sa région	Hors périmètre	Oui	Absent	Refusé

Dans les trois cas, Alice appartient toujours à Gestion Fiches. C’est la présence ou l’absence de See sur l’équipement testé qui détermine si Modify est accordé. Un autre membre de Gestion Fiches peut donc obtenir un résultat différent selon ses propres groupes géographiques et ses propres familles d’équipements visibles.

3. Comment une permission est-elle évaluée ?

Pour un utilisateur ordinaire, l’évaluation suit cet ordre :

1. rechercher un refus explicite de la permission demandée ;
2. si un refus s’applique, refuser l’accès ;
3. sinon, rechercher une autorisation directe ;
4. si aucune autorisation directe ne s’applique, examiner les droits conditionnels actifs ;
5. autoriser si au moins une règle applicable remplit sa condition ;
6. sinon, refuser l’accès.

Pour qu’une règle conditionnelle s’applique, toutes les conditions suivantes doivent être réunies :

• la règle est active ;
• le type de l’objet correspond au type configuré dans la règle ;
• la permission demandée correspond à la permission accordée ;
• l’utilisateur appartient au groupe bénéficiaire, directement ou par l’intermédiaire de groupes imbriqués ;
• la permission requise est effective sur le même objet.

Plusieurs règles peuvent accorder la même permission. Elles fonctionnent comme des alternatives : il suffit qu’une règle applicable réussisse. Une règle ne peut exprimer qu’une seule permission requise. Les dépendances peuvent être enchaînées. Par exemple, une permission peut dépendre de Modify, qui dépend elle-même de See. Les cycles tels que Modify si See et See si Modify sont interdits.

4. Portée des règles

Une règle est définie pour un type d’objet sécurisé, mais sa condition est évaluée sur un objet précis de ce type.

Si l’utilisateur possède See sur l’équipement 125, la règle peut lui accorder Modify sur l’équipement 125. Le fait de posséder See sur l’équipement 126 n’accorde rien sur l’équipement 125.

La version actuelle prend uniquement en charge la portée même objet :

• la permission accordée et la permission requise appartiennent au même type sécurisé ;
• elles sont évaluées avec le même identifiant d’objet ;
• une permission possédée sur une gare, un département ou un autre équipement ne satisfait pas la condition à la place de l’objet testé.

5. Modèle conceptuel de données

ConditionalPermissionGrant est l’objet qui représente une règle de droit conditionnel. Chaque occurrence répond à la question suivante :

Pour les membres de quel groupe, sur quel type d’objet, quelle permission faut-il accorder si quelle autre permission est déjà effective sur le même objet ?

La règle ne contient ni identifiant d’utilisateur ni identifiant d’équipement. Elle décrit une relation réutilisable entre des objets de sécurité ; le résultat est ensuite calculé pour l’utilisateur et l’objet concernés au moment du contrôle d’accès.

5.1 Objets reliés et cardinalités

Chaque droit conditionnel est relié à exactement :

• un Group, qui désigne le groupe bénéficiaire ;
• un SecurizedObjectTypeDefinition, qui désigne le type d’objet concerné ;
• une Permission dans le rôle accordée ;
• une Permission dans le rôle requise.

Inversement, chacun de ces objets peut être utilisé par zéro, un ou plusieurs droits conditionnels.

Objet de sécurité	Rôle dans le droit conditionnel	Cardinalité pour une règle
Group	Groupe dont les membres peuvent bénéficier de la règle.	Exactement un
SecurizedObjectTypeDefinition	Type des objets sur lesquels la règle est évaluée.	Exactement un
Permission — rôle accordée	Permission obtenue lorsque la condition est satisfaite.	Exactement une
Permission — rôle requise	Permission qui doit déjà être effective sur le même objet.	Exactement une

5.2 Données portées par la règle

Donnée	Signification
Identifier	Identifiant technique unique du droit conditionnel.
Title	Titre obligatoire, limité à 255 caractères, qui résume l’intention métier.
Description	Explication facultative, limitée à 2 048 caractères, qui apporte le contexte utile aux administrateurs.
BeneficiaryGroupIdentifier	Référence du groupe bénéficiaire. L’appartenance directe ou indirecte de l’utilisateur à ce groupe est vérifiée lors de l’évaluation.
SecuredObjectTypeIdentifier	Référence du type d’objet sécurisé, par exemple Equipment.
GrantedPermissionIdentifier	Référence de la permission que la règle peut produire, par exemple Modify.
RequiredPermissionIdentifier	Référence de la permission qui doit déjà être effective sur le même objet, par exemple See.
IsEnabled	État actif ou inactif. Seules les règles actives participent à l’évaluation.
RowVersion	Version utilisée pour détecter une modification concurrente et éviter qu’un administrateur n’écrase silencieusement une action plus récente.

Le titre et la description servent uniquement à identifier et expliquer la règle dans l’interface d’administration. Ils ne participent pas au calcul du droit. IsEnabled, en revanche, détermine si la règle peut être utilisée.

5.3 Règles d’intégrité

La configuration protège les règles suivantes :

• le groupe, le type sécurisé et les deux permissions sont obligatoires et doivent exister ;
• le type sécurisé doit être actif lors de la création d’une règle ;
• les permissions accordée et requise doivent être différentes et appartenir toutes les deux au type sélectionné ;
• une même combinaison groupe + type + permission accordée + permission requise ne peut être enregistrée qu’une fois, y compris si la règle existante est inactive ;
• la création ou la réactivation d’une règle est refusée si elle introduit un cycle de dépendances entre permissions ;
• la suppression d’un groupe, d’un type ou d’une permission encore référencé par une règle est bloquée ;
• lors d’un changement d’état ou d’une suppression, la version connue de la règle permet de détecter une modification concurrente.

Ainsi, une seule règle Gestion Fiches : Modify si See peut s’appliquer à tous les équipements présents et futurs. Elle ne produit toutefois Modify que pour les équipements sur lesquels See est effectivement obtenu par l’utilisateur.

6. Interface de gestion

La page est accessible depuis Sécurité, puis Droits conditionnels. Un accès existe également depuis Configuration des droits avec l’action Administrer les droits conditionnels.

Dans l’interface actuelle, cette page est réservée au compte Cerebrate.

6.1 Choisir le type d’objet

Le type d’objet sécurisé est présenté sous la forme d’un lien cliquable.

1. cliquer sur le type affiché ;
2. choisir un type dans la fenêtre de sélection ;
3. la fenêtre se ferme automatiquement ;
4. la page recharge les règles du type choisi.

La fenêtre propose uniquement les types configurés dans la sécurité.

6.2 Lire les règles existantes

Pour le type sélectionné, le tableau affiche :

Colonne	Contenu
État	Actif ou Inactif.
Groupe bénéficiaire	Nom du groupe et, lorsqu’il est disponible, son Distinguished Name.
Permission accordée	Permission produite par la règle.
Condition sur le même objet	Permission que l’utilisateur doit déjà posséder.
Actions	Activer, désactiver ou supprimer la règle.

Les règles actives sont affichées avant les règles inactives.

6.3 Ajouter une règle

Comment ajouter une regle ?

1. sélectionner le type d’objet sécurisé ;
2. dans Nouveau droit conditionnel, cliquer sur Choisir un groupe ;
3. sélectionner le groupe bénéficiaire dans la fenêtre qui ne présente que les groupes ;
4. choisir la permission accordée ;
5. choisir une permission requise différente ;
6. cliquer sur Ajouter ;
7. vérifier le message de confirmation et la nouvelle ligne active.

Le bouton d’ajout devient disponible après le choix du groupe, à condition que le type soit actif et possède au moins deux permissions.

6.4 Désactiver, réactiver ou supprimer

Désactiver retire immédiatement la contribution conditionnelle sans effacer la définition. Cette action est adaptée à un test ou à une suspension temporaire.

Activer remet la règle en service après une nouvelle vérification des cycles de dépendances.

Supprimer efface la définition après confirmation. Pour la restaurer, il faut la recréer.

Si un autre administrateur a modifié la règle entre son affichage et l’action demandée, l’enregistrement est refusé. Il faut alors recharger la page avant de recommencer.

7. Façade d’administration et API de sécurité

L’interface de gestion de l’Enhancer ne modifie jamais directement les données de sécurité. Ses actions passent par une façade d’administration commune qui constitue la frontière entre l’interface et le domaine de sécurité. Les mêmes ordres de gestion sont désormais accessibles aux intégrations par la Web API HTTP de SecurityController. Qu’un ordre provienne de l’Enhancer ou de l’API, il est transmis à la même façade et bénéficie donc des mêmes validations.

7.1 Ordres de gestion disponibles

Opération	Route HTTP	Informations attendues	Résultat
Consulter	GET /api/Security/ConditionalPermissionGrants	Filtre facultatif securedObjectTypeIdentifier.	Liste de toutes les règles correspondantes, actives ou inactives, avec leur identifiant et leur version.
Créer	POST /api/Security/ConditionalPermissionGrants	Titre, description facultative, groupe, type sécurisé, permission accordée et permission requise.	Création d’une règle active et retour de sa version.
Changer l’état	PATCH /api/Security/ConditionalPermissionGrants/{identifier}/Enabled	Nouvel état et version connue de la règle.	Activation ou désactivation et retour de la nouvelle version.
Supprimer	DELETE /api/Security/ConditionalPermissionGrants/{identifier}	Version connue de la règle.	Suppression de la règle.

La RowVersion est représentée en Base64 dans les échanges JSON. Après une création ou un changement d’état, l’appelant doit conserver la nouvelle valeur renvoyée pour sa prochaine opération sur la règle.

Il n’existe pas d’ordre permettant de modifier globalement une définition existante. Pour changer le groupe, le type ou l’une des permissions, il faut créer la nouvelle règle, la valider, puis désactiver ou supprimer l’ancienne.

7.2 Contrôles appliqués par la façade

La façade applique systématiquement les protections suivantes :

• l’auteur est déterminé à partir du contexte authentifié ;
• seuls Cerebrate et les administrateurs racine de plateforme peuvent modifier cette configuration ;
• le groupe et le type doivent exister ;
• le type doit être actif lors de la création ;
• les deux permissions doivent exister, être distinctes et appartenir au type choisi ;
• les doublons et les cycles sont refusés ;
• chaque changement est enregistré dans une transaction atomique ;
• une version devenue obsolète entraîne une réponse 409 Conflict plutôt que l’écrasement d’une modification plus récente ;
• après validation, le domaine de sécurité est rechargé et le changement est signalé aux autres instances ;
• la source de l’opération et l’auteur sont inscrits dans les journaux du serveur.

8. Effet des changements

Changement	Effet attendu
Création d’une règle	La règle devient active pour les objets existants et futurs dès l’actualisation du domaine de sécurité.
Ajout d’un utilisateur au groupe bénéficiaire	L’utilisateur peut bénéficier de la règle selon ses permissions requises.
Retrait du groupe bénéficiaire	L’utilisateur ne bénéficie plus de la règle par ce chemin d’appartenance.
Ajout ou retrait de la permission requise sur un objet	La permission conditionnelle apparaît ou disparaît pour ce même objet.
Désactivation	La définition reste visible mais ne participe plus aux décisions.
Réactivation	La règle participe de nouveau aux décisions après validation.
Suppression	La règle disparaît ; les droits directs restent inchangés.

9. Limites actuelles

Le mécanisme actuel ne permet pas :

• de choisir un utilisateur individuel comme bénéficiaire ;
• d’exiger plusieurs permissions simultanément dans une seule règle ;
• d’utiliser une permission portée par un autre objet comme condition ;
• de relier deux types d’objets différents dans une même règle ;
• d’ignorer un refus explicite ;
• de créer une dépendance cyclique ;
• d’exposer directement la gestion par une route Web API publique dédiée.

Pour exprimer deux conditions obligatoires, par exemple See et Approve, il faut faire évoluer le modèle. Deux règles séparées signifieraient actuellement See ou Approve.

10. Résolution des problèmes

Symptôme	Vérifications
Un membre de CP voit l’équipement mais ne peut pas le modifier	Vérifier que la règle est active, que son type et ses permissions sont corrects, que l’utilisateur appartient bien à CP et qu’aucun refus Modify ne s’applique.
Un membre de CP peut modifier trop d’équipements	Rechercher un droit direct Modify trop large, puis vérifier l’origine de ses droits See.
Le groupe attendu n’apparaît pas dans la sélection	Vérifier que l’objet existe bien comme groupe dans le domaine de sécurité et recharger la page.
Le bouton Ajouter reste indisponible	Vérifier le choix du groupe, l’état actif du type et la présence d’au moins deux permissions.
L’ajout est refusé	Vérifier que les permissions sont distinctes, qu’elles appartiennent au type choisi, que la règle n’existe pas déjà et qu’elle ne crée pas de cycle.
Une action est refusée après un affichage ancien	Recharger la page : une autre modification a probablement changé la version de la règle.
La désactivation semble sans effet	Vérifier si un droit direct ou une autre règle conditionnelle accorde encore la permission.

11. Checklist de mise en service

• Le type sécurisé concerné est actif.
• Les permissions accordée et requise appartiennent à ce type.
• Le groupe bénéficiaire correspond au profil fonctionnel attendu.
• La permission requise représente correctement la portée à conserver.
• La règle ne duplique pas une règle existante.
• Aucun cycle de dépendances n’est introduit.
• Les droits directs trop larges ont été identifiés.
• Les refus explicites ont été contrôlés.
• Les groupes imbriqués ont été vérifiés.
• Le testeur de droits confirme le résultat sur un objet visible et un objet non visible.
• La règle a été validée avec un utilisateur réel de CP ou Gestion Fiches.