PermissionScript¶
Exemples¶
Version anglaise
permission model CyberCompagnie
import class model from '../classes/classes.cl1'
import usecase model from '../usecase/usecase.uss'
EmbaucherUnEmploye can create Employe, EstEmployeeDans
EmbaucherUnEmploye can create, update Compagnie.budget, Compagnie.quota
LicencierUnEmploye can delete Employe
Responsable, Secretaire can R Employee.salaire
Directeur can read, update Employee.salaire
Version française
permission model CyberCompagnie
import class model from '../classes/classes.cl1'
import usecase model from '../usecase/usecase.uss'
EmbaucherUnEmploye peut créer Employe, EstEmployeeDans
EmbaucherUnEmploye peut lire, modifier Compagnie.budget, Compagnie.quota
LicencierUnEmploye peut détruire Employe
Responsable, Secretaire peut L Employee.salary
Directeur peut lire, modifier Employee.salary
Note
can
peut être remplacé parpeut
.- Les actions peuvent être abbréviées ou pas (“C” ou “create”).
- Les actions peuvent être traduites. Voir la section actions.
Concepts¶
Conceptuellement le modèle de permissions est basé sur une suite de triplets :
(sujets, actions, ressources)
Ce triplet signifie : ” les <sujets> peuvent effectuer les <actions> sur les <ressources>.”
Exemple :
EmbaucherUnEmploye peut LM Compagnie.budget, Compagnie.quota
EmbaucherUnEmploye
est le sujet. L
et M
sont les
actions. Compagnie.budget
, Compagnie.quota
sont les ressources.
Le triplet signifie : “le cas d’utilisation EmbaucherUnEmploye
peut lire et modifier les attributs budget
et quota
de la classe Compagnie
”.
Sujets¶
Un sujet est soit:
- un acteur (provenant du
modèle de participants),
par exemple
Directeur
, - un cas d’utilisation (provenant du
modèle de cas d’utilisation),
par exemple
CreerUnDepartement
.
Actions¶
Les actions correspondent essentiellement au modèle CRUD (voir wikipedia). Les actions peuvent être écrites en entier ou sous forme abbréviées, en anglais ou en français.
En anglais | En français |
---|---|
C / create | C / créer |
R / read | L / lire |
U / update | M / modifier |
D / delete | D / détruire |
X / execute | X / exécuter |
La signification des opérations dépend des ressources. Voir la section ressources.
Ressources¶
Pour un modèle de classe une ressource est soit :
- une classe, par exemple
Employe
, - un attribut, par exemple
Employe.salaire
, - une opération, par exemple
Employe.augmenter()
. - une association, par exemple
EstAffecteA
, - une role, par exemple
Employe.responsable
.
Le type de ressources définit les actions autorisées :
- l’opération create/créer s’applique à une classe ou à une association.
Par exemple
créer Employe
oucréer EstEmployePar
. Créer un attribut, un role ou une opération ne fait pas de sens. - l’operation read/lire s’applique à un attribut ou à un role. Par
exemple
lire Employe.salaire
oulire Employe.responsable
.- Lorsque cette action est associée à une classe (par exemple
lire Employe
alors n’importe quel attribut de la classe peut être lu (dans l’exemple l’accès est donné à tous les attributs de la classeEmploye
). - Lorsque cette action est associée à une association (par exemple
lire EstEmployePar
), alors celle-ci peut être traversée dans n’importe quel sens.
- Lorsque cette action est associée à une classe (par exemple
- l’opération update/modifie s’applique à un attribut (ou à une classe, de manière analogue à read/lire).
- l’opération delete/détruire s’applique à une classe ou à association
- l’opératop, execute/exécuter s’applique à une operation uniquement.
action/resc. | classe | attribut | operation | association | role |
---|---|---|---|---|---|
create | X | X | |||
read | [X] | X | X | ||
update | [X] | X | |||
delete | X | X | |||
execute | X |
Méthode¶
Les tâches listées par la suite ne peuvent que difficilement être réalisées en séquentiel. Cependant plusieurs pratiques existent, selon que l’on part d’un modèle ou d’un autre.
Classes en premier¶
Dans la méthode “classes en premier” il s’agit de partir d’un modèle de classes, de lister chaque classes, attributs et associations, et dans chaque cas de répondre à la question “qui change telle ou telle ressource ?”. Le résultat pourrait être comme ci-dessous (résultats “triés” par la deuxième colonne) :
... peut C Departement
... peut L Departement.budget
... peut M Departement.budget
... peut D Departement
...
... peut C Projet
Cette méthode permet de vérifier que toutes les parties du modèle de classes (à droite) sont utilisées “correctement”.
Participants en premier¶
Considèrer le modèle de participants en premier revient à répondre à la question “que peut faire tel ou tel acteur ?” :
Directeur peut C ...
Directeur peut R ...
Directeur peut U ...
Directeur peut D ...
Secretaire peut C ...
Secretaire ...
...
Cette méthode permet de visualiser rapidemment les permissions associées à chaque acteur. Par contre le détail des cas d’utilisation est manquant.
Cas d’utilisation en premier¶
Partir des “cas d’utilisation en premier” revient à répondre à la question “que peut faire tel ou tel cas d’utilisation ?” :
ReserverUneSalle peut C ...
ReserverUneSalle peut R ...
ReserverUneSalle peut U ...
ReserverUneSalle peut D ...
AugmenterUnEmploye peut C ...
AugmenterUnEmploye ...
...
Matrice¶
Les différentes techniques ci-dessus peuvent être combinées en produisant d’abord une matrice listant d’un coté toutes les resources (classes, etc.) et de l’autre tous les sujets (acteurs, etc.). Il s’agit ensuite de répondre pour chaque élément de la matrice à la question “quelles actions peut être réalisées par ce sujet sur cette ressource”.
Dépendances¶
Le graphe ci-dessous montre les dépendances entre langages.