Diagrammes de classes

Les classes d’objets sont décrites dans des diagrammes de classes pour expliciter les relations entre celles-ci. Toutefois dans un métamodèle, les classes sont en fait des métaclasses. Les noms écrits dans la police « machine à écrire » représentent les noms de classe. Le style « italique » est utilisé pour les noms de métaclasses abstraites et les classes abstraites.

Tous les messages sont abstraits dans une classe qui est spécialisée suivant les dif-férents usages qui en sont faits dans le diagramme de séquences de la figure 4.5. Les métaclasses Message, AccessControlMessage et AuthorizationMessage représentent respectivement les messages E(�→

bp), E(�→acp,�→

bp) et AR(E,�→acp,�→

bp), incluant les requêtes et les réponses correspondantes, comme illustré par le diagramme de classes de la figure 4.9. Ce diagramme spécifie aussi la classe des objets qui en-voient et reçoivent des messages. Les instances des métaclasses Interceptor, PEP et PDP différent suivant l’implémentation. Par exemple dans une application SOA, les instances de la métaclasse Interceptor peuvent être des classes de gestion-naires SOAP (SOAP handler classes en anglais), dont les instances s’insèrent de façon

4.2. Spécification du PEM par métamodélisation AbstractMessage AccessControlMessage Message AuthorizationMessage PEP PDP Interceptor 1..* 1..* 1..* ^{1..* 1..*} 1..*

Figure 4.9 – Diagramme de classes : composants du PEM

transparente entre l’application de l’utilisateur et les services Web. Ils ont pour rôle d’injecter les paramètres de contrôle d’accès dans l’en-tête des requêtes encodées avec le protocole SOAP.

Le diagramme de classes de la figure 4.10 présente les différents types de paramètres d’un message. En général, un message contient des paramètres optionnels, qui sont catégorisés suivant le type de message auquel ils sont rattachés. Un paramètre est associé à une valeur d’entrée ou de sortie en fonction du message (requête/réponse de service ou appel/retour de méthode). Cette caractéristique est un attribut de la classe abstraite AbstractParameter. Suivant cet attribut, il existe des messages unidirectionnels qui comportent des paramètres d’entrée seulement et pour lesquels les émetteurs n’attendent pas de réponse du récepteur. Il existe aussi des messages bidirectionnels, avec une requête et une réponse.

La métaclasse AccessControlParameter, qui apparaît dans les diagrammes de classes des figures 4.10 à 4.13, est instanciée lorsqu’un modèle de contrôle d’accès est défini et les paramètres de contrôle d’accès propres à l’application considérée sont explicités (par exemple les classes Organization, Role et User). Tout modèle dérivé du métamodèle peut considérer d’autres paramètres de contrôle d’accès, tel que le moment de l’émission d’une requête par l’utilisateur ou l’origine géographique de celle-ci.

AbstractParameter BusinessParameter AbstractMessage AccessControlMessage AuthorizationMessage AccessControlParameter 1..* ACParameters 0..* BParameters _ACParameters^1..*

Figure 4.10 – Diagramme de classes : hiérarchie de messages

Une politique de contrôle d’accès est définie par un ensemble de règles représen-tées par la métaclasse abstraite Rule dans les figures 4.12 et 4.13. Le métamodèle fait une distinction claire entre les règles statiques et dynamiques. Les règles sta-tiques contraignent à la manière des modèles RBAC, alors que les règles dynamiques prennent en compte l’historique des opérations exécutées avec succès par le système d’information. Les règles statiques comprennent les permissions, qui autorisent une opération à être exécutée, et les interdictions, qui empêchent l’exécution d’une opéra-tion. La séparation des devoirs (SoD), qui impose la contrainte qu’un ensemble

d’opé-AccessControlParameter

User « instance »

Role Organization

4.2. Spécification du PEM par métamodélisation AccessControlParameter Rule Policy Permission Prohibition Filter AbstractFilter AbstractPolicy 1..* 1..* rules 1 policy staAC

Figure 4.12 – Diagramme de classes : contrôle d’accès statique

rations doivent être exécutées par différents utilisateurs ou rôles est l’exemple le plus courant de règle dynamique. Un autre exemple de règle dynamique est l’obligation qui contrairement à la séparation des devoirs, oblige un utilisateur ou un rôle à exécuter un ensemble d’opérations liées. La métaclasse abstraite staAc::Rule (respectivement dynAC::Rule), qui apparaît dans le paquetage staAC dans la figure 4.12 (respec-tivement dynAC dans la figure 4.13), représente les règles statiques (respec(respec-tivement dynamiques), qui sont utilisées pour définir les politiques statiques (respectivement dynamiques).

Les politiques de contrôle d’accès peuvent être séparées en deux, chacune étant asso-ciée à un filtre distinct. Contrairement aux classes Organization, Role et User du diagramme de classes de la figure 4.11, les éléments Permission et Prohibition sont véritablement des sous-métaclasses de staAc::Rule car le métamodèle permet l’instanciation de celles-ci pour modéliser différentes classes de règles de permission

AccessControlParameter Rule Policy Obligation SoD Filter AbstractFilter AbstractPolicy PIP 1..* 1..* rules 1 policy 1 dynAC

Figure 4.13 – Diagramme de classes : contrôle d’accès dynamique

ou règles d’interdiction pour des modèles de contrôle d’accès spécifiques. Par exemple, une règle de permission peut autoriser l’exécution d’opérations en fonction des rôles seulement, ou encore interdire l’exécution des opérations en fonction de l’utilisateur et de son rôle. Les instances de la métaclasse staAC::Filter (respectivement dynAC::Filter), une spécialisation de la métaclasse abstraite AbstractFilter dans le paquetage du niveau supérieur, sont des classes dont les instances utilisent une politique statique (respectivement dynamique) pour calculer une décision après évaluation de tout ou partie des règles de cette politique. En général, un filtre essaie de faire correspondre les paramètres E, �→acp et �→

bp du message d’une requête d’au-torisation avec les valeurs des termes correspondant de chaque règle de la politique associée au filtre. En plus de cette correspondance entre paramètres et valeurs, un filtre associé à une politique dynamique requiert de l’information sur l’historique des opérations exécutées par le système et liées aux règles à considérer. Le PIP, un com-posant auxiliaire du PEM, fournit cette information (voir la figure 4.13). Plusieurs