Gérer les permissions d’un type d’objet sécurisé

• Undefined type

Ce document explique comment consulter, tester, créer et renommer les permissions d’un type d’objet sécurisé.

1. Principe d’une permission

Une permission décrit une action testable sur un type d’objet, par exemple voir une carte, modifier un équipement ou administrer le contenu d’un dossier.

Elle ne donne aucun accès à elle seule. Les accès réels sont portés par des droits attribués à des utilisateurs ou à des groupes sur des objets précis.

Champ	Rôle
Nom	Libellé fonctionnel affiché aux administrateurs.
Description	Explication de l’action protégée.
Masque ou Flag	Bits qui doivent être présents dans AuthorizedFlags pour autoriser la permission.
Masque refusé ou DeniedFlag	Bits recherchés dans DeniedFlags pour refuser la permission. S’il est vide, le Flag est utilisé.

2. Ouvrir la gestion des permissions

1. Ouvrir /Security/Configuration avec le compte Cerebrate.
2. Repérer le type concerné.
3. Cliquer sur Permissions.

La fenêtre présente successivement :

• un rappel sur l’immutabilité des masques existants ;
• le testeur de flags ;
• les permissions existantes ;
• le formulaire de création d’une permission.

3. Comprendre Flag et DeniedFlag

Une permission peut fournir un masque d’autorisation composite et un masque de refus plus ciblé.

Exemple avec Modify Map :

Flag       = 5 = 0101 = lire + modifier
DeniedFlag = 4 = 0100 = modifier

La permission n’interdit rien par elle-même. Le masque employé dépend de l’action administrative :

Action	Masque inscrit dans le droit
Autoriser Modify Map	AuthorizedFlags reçoit Flag, donc 5.
Refuser Modify Map	DeniedFlags reçoit DeniedFlag, donc 4.

Cette séparation permet de refuser la modification tout en conservant une éventuelle autorisation de lecture.

Le DeniedFlag, lorsqu’il est renseigné, doit être un sous-ensemble positif du Flag.

4. Tester des flags

Le testeur décode une paire de valeurs comme si elle provenait d’un Right :

• AuthorizedFlags contient les capacités accordées ;
• DeniedFlags contient les capacités explicitement refusées.

Il accepte des nombres décimaux, des nombres hexadécimaux et des combinaisons avec | :

1
0x3
1 | 5
0x3 | 65

Pour chaque permission, le résultat peut être :

Résultat	Signification
Autorisée	Tous les bits du Flag sont présents et aucun refus applicable n’est présent.
Refusée	Tous les bits du masque refusé sont présents dans DeniedFlags.
Refusée (prioritaire)	Les masques autorisé et refusé correspondent tous les deux ; le refus gagne.
Non définie	L’autorisation complète n’est pas présente et aucun refus complet ne correspond.

Le testeur ne consulte ni les utilisateurs, ni les groupes, ni un objet sécurisé réel. Il sert uniquement à comprendre les masques.

5. Créer une permission

Le type doit être actif.

1. Saisir un nom fonctionnel précis.
2. Ajouter une description indiquant l’opération protégée.
3. Saisir un masque positif dans Masque.
4. Saisir éventuellement un sous-masque positif dans Masque refusé.
5. Cliquer sur Ajouter.

Le formulaire de création attend actuellement des entiers décimaux. Les écritures hexadécimales et les expressions avec | sont acceptées par le testeur, mais pas par ce formulaire numérique.

Pour un même type :

• le nom doit être unique ;
• le Flag doit être unique ;
• le DeniedFlag, lorsqu’il existe, doit être contenu dans le Flag ;
• le nom est limité à 255 caractères ;
• la description est limitée à 2 048 caractères.

6. Modifier une permission existante

Le nom et la description peuvent être modifiés lorsque le type est actif :

1. modifier le texte directement dans la ligne ;
2. cliquer sur Mettre à jour.

Le Flag et le DeniedFlag sont affichés mais ne sont pas modifiables.

Les droits enregistrés contiennent directement les masques numériques. Ils ne conservent pas une référence vers la permission choisie. Modifier le masque d’une permission existante changerait donc rétroactivement le sens de droits déjà attribués.

Pour changer un masque :

1. créer une nouvelle permission ;
2. migrer les droits concernés vers le nouveau masque ;
3. adapter les règles automatiques et les contrôles métier ;
4. vérifier les objets existants avec les outils d’audit.

L’interface ne propose pas actuellement de suppression de permission.

7. Effet du type actif ou inactif

État du type	Consultation	Testeur	Création	Modification du nom ou de la description
Actif	Oui	Oui	Oui	Oui
Inactif	Oui	Oui	Non	Refusée par le serveur

Désactiver le type ne supprime pas ses permissions et ne modifie pas les droits qui utilisent déjà leurs masques.

8. Après la création

Vérifier les points suivants :

1. le contrôleur ou le service métier teste cette permission avec le calcul central ;
2. les groupes ou utilisateurs adéquats reçoivent les flags nécessaires ;
3. une règle automatique est créée si les nouveaux objets doivent recevoir ce droit dès leur création ;
4. les objets déjà existants sont audités et, si nécessaire, régularisés.

9. Règles à retenir

• Une permission décrit une action mais n’accorde aucun accès.
• Flag est utilisé pour autoriser.
• DeniedFlag est utilisé uniquement lors d’un refus explicite.
• Un refus applicable est prioritaire sur une autorisation.
• Les masques d’une permission existante sont immuables.
• Une nouvelle permission doit être branchée dans le code métier pour devenir réellement utile.