parée en différents domaines. A chaque domaine est attribué un niveau de classifi- cation. Les auteurs étudient en particulier les communications entre les différents domaines. Ils cherchent en particulier à assurer qu’il existe une séparation stricte entre les différents domaines de classification et que le flux d’information entre les différents niveaux est contrôlé. Afin de pouvoir mettre en œuvre ces propriétés dans une architecture distribuée ils définissent trois fonctions principales :
– un service d’activation des serveurs permettant à des entités d’un domaine d’accéder à des serveurs d’autres domaines via la mise en place de proxy ; – un service de coordination permettant à des domaines utilisant des proto-
coles différents de communiquer entre eux ;
– un service cryptographique garantissant l’authentification et la confidentia- lité des messages échangés entre des domaines différents.
Le contrôle des messages échangés entre les domaines de différents niveaux est effectué par un contrôleur placé aux bornes des domaines chargé de vérifier la légalité du flux d’information.
Les auteurs de [KFS+99] et [KFEM00] proposent un modèle théorique s’ap- puyant sur les travaux de [KFE98]. Ils proposent une méthode permettant de trans- former des workflows multi-niveaux en un ensemble de workflows d’un seul niveau de classification. Afin de gérer les interactions entre les niveaux ils s’appuient sur les entités définies dans [KFE98].
A la suite de ces travaux, les auteurs de [RS06] présentent un modèle concep- tuel d’architecture multi-niveaux pour les SOA. Ils considèrent deux dimensions de classification : confidentialité et intégrité.
Leur modèle repose sur deux types d’entités : des entités de simple niveau et des entités multi-niveaux, à la manière des auteurs de [ND96]. Les entités de simple niveau ne peuvent manipuler que des données du même niveau que le leur et les données modifiées ou générées par cette entité héritent du niveau de cette entité.
Afin de permettre les échanges de données entre les niveaux, ils proposent le concept d’entités multi-niveaux qui peuvent générer des données de niveau infé- rieur ou égal à leur niveau en confidentialité ou de niveau supérieur ou égal à leur niveau d’intégrité. Afin de permettre des échanges de données impossibles avec ces entités, ils proposent de mettre en œuvre des entités de confiance chargées de permettre des déclassifications. Cependant ces travaux restent au stade de concept et aucune implémentation de leur modèle n’est proposé.
2.2 Modèle RBAC
Le modèle RBAC [FSG+01] a été conçu pour être plus souple que les mo- dèles présentés précédemment. Il est basé sur trois grandes notions : utilisateur, rôle, et permission. Dans ce modèle, chaque utilisateur est associé à un rôle et à chaque rôle est associé un ensemble de permissions. Ce modèle correspond à la structure des organisations et reste très flexible. Il est en particulier bien adapté aux environnements multi-domaines quand les politiques sont exprimées en utilisant la
hierarchie des rôles ainsi que les contraintes.
Dans [Wea04], les auteurs utilisent le modèle RBAC afin de contrôler l’accès à des Web-Services. Cependant l’essentiel de leurs travaux portent sur la mise en place d’une méthode d’authentification. Ils se basent pour cela sur l’utilisation de WS-Policy en y ajoutant une extension permettant de donner un niveau en fonc- tion des algorithmes de chiffrement et de signature utilisés. Ce niveau permet de déterminer un contexte dans lequel un appel de Web Service est effectué. Ainsi, les règles RBAC appliquées diffèrent selon le contexte d’appel d’un Web-Service. Cette méthode permet également de gérer les méthodes d’authentification de ma- nière hiérarchique. Ainsi, une méthode d’authentification plus forte est acceptée par un Web Service requérant une méthode d’authentification plus faible.
Les auteurs de [LC04] présentent un modèle RBAC étendu afin de prendre en compte certaines contraintes des Web-Services. Ils ajoutent aux traditionnels utili- sateurs et rôles du modèle RBAC quatre notions spécifiques aux Web Services. Les notions de Web-Service, entreprise, processus métier et session sont ainsi ajoutés dans le modèle étendu. Les Web-Services correspondent aux objets à protéger, à chaque Web-Service est assigné un ou plusieurs rôles autorisés à les utiliser. Un processus métier permet l’appel organisé d’un ensemble de Web-Services. Pour chaque processus métier il est défini un certain nombre de rôles autorisés à appeler ce processus métier. Une session correspond à l’exécution d’un processus métier par un utilisateur. Enfin une entreprise est une organisation qui participe aux pro- cessus métiers et qui fournit des Web-Services. Dans ce modèle les contraintes gèrent les relations entre ces différentes notions. Les auteurs expriment ensuite ces contraintes par des politiques de sécurité décrites en WS-Policy.
Dans [BR06], les auteurs s’intéressent à la mise en place d’un modèle RBAC protégeant non l’accès aux services mais aux informations. Ainsi lors de l’utili- sation d’un Web-Service, les informations renvoyées dépendent des autorisations associées à l’utilisateur exécutant ce service. Les auteurs proposent également une méthode permettant de convertir les rôles d’une organisation en ceux d’une autre organisation permettant ainsi la mise en place de processus métier inter- organisationnels.
Les auteurs de [BCP06] proposent une version étendue de BPEL appelée RBAC- WS-BPEL permettant en particulier d’ajouter des contraintes RBAC au langage BPEL. Ce langage présuppose que les organisations fournissant des programmes BPEL mettent en œuvre un système d’identification des utilisateurs leur attribuant un rôle au sein de l’organisation. Les auteurs proposent ainsi d’adosser au langage BPEL, un langage appelé BPCL (Business Process Constraint Language) permet- tant de spécifier pour chaque service appelé par le programme BPEL les contraintes associées. Ces contraintes sont de deux types. Tout d’abord les contraintes propres au modèle RBAC autorisant ou non un utilisateur à accéder à un service en fonc- tion de son rôle. Ils définissent également des contraintes propres à l’exécution du programme BPEL permettant par exemple de définir des contraintes de séparation des obligations permettant de spécifier que deux actions doivent être exécutées par deux utilisateurs différents ou le même. Ces contraintes permettent aussi d’utili-