Étape 5 : Définition des URLs des ressources et des politiques
3.3.4 Conception du framework
Dans cette section, nous présentons la conception de notre framework à travers un diagramme de classe UML. Ensuite, nous décrivons comment il peut être utilisé dans les systèmes collaboratifs ubiquitaires pour sécuriser
l’accès aux ressources. Gamma et al. [GHJV95] définissent le terme frame-work comme suit :
«un framework est un ensemble de classes qui définissent une architecture qui peut être réutilisée par des logiciels spécifiques.»
Un framework est une boite à outil destiné à être utilisée par les déve-loppeurs de logiciels. Il joue le rôle d’un patron de conception pour faci-liter le développement d’applications bien spécifiques. Les framework sont plus ou moins similaires aux patrons de conception. Néanmoins, les patrons de conception sont plus abstraits et moins spécifiques que les framework. L’avantage des frameworks est qu’ils peuvent être développés en utilisant des langages de programmation et ils peuvent être exécutés et réutilisés. Un framework dicte l’architecture des applications qui l’utilisent. En effet, il définit la structure globale de l’application, les relations entre les classes et leurs responsabilités.
Diagramme de classe du framework
Le diagramme de classes UML, illustré par la Figure3.18, représente une vue simplifiée des principales classes qui constituent notre framework. La conception du framework est guidée par la boucle de traitement autono-mique. En effet, chaque fonction de la boucle est modélisée par une classe qui coopère avec d’autres classes afin d’atteindre des objectifs bien définis.
La classeAnalyzer permet d’effectuer la fonction d’analyse de la boucle autonomique. Elle contient principalement un attribut qui représente une instance de l’ontologie de domaine. Elle contient également une méthode
model_changed()qui permet de mettre à jour l’instance en fonction des chan-gements effectués dans l’application et de notifier le framework de contrôle d’accès du changement. Cette classe peut être étendue par l’application qui utilise le framework afin de redéfinir la méthode qui permet la mise à jour de l’instance de l’ontologie.
La fonction de planification de la boucle est représentée par les deux classesAccessControlReqGeneratoretDeploymentGraphGenerator. La classe Ac-cessControlReqGeneratorutilise la classeOntologyManagerqui permet d’effec-tuer les inférences et exécuter les règles SWRL afin d’obtenir une nouvelle instance qui traduit les besoins de contrôle d’accès. La classe AccessControl-GraphGenerator est aussi utilisée par la classeAccessControlReqGenerator afin de générer un graphe de contrôle d’accès. Ce graphe est une instance de la classe Graph qui consiste en un ensemble d’instances de la classe Node
et un ensemble d’instances de la classe Edge. La deuxième classe associée à la fonction de planification est la classe DeploymentGraphGenerator. Cette classe utilise le moteur de transformation de graphe GMTE pour la généra-tion d’un ou plusieurs graphes de déploiement, et la classeSelector pour la sélection.
La classe Handler permet de coordonner les échanges entre les trois classesAnalyzer,AccessControlReqGeneratoretDeploymentGraphGenerator. Les relations entre la classe Handler et ces trois classes sont bidirectionnelles. Cela veut dire que la classe Handlera une référence vers chacune des trois classes qui ont à leurs tours une référence vers la classe Handler. Quand un objet de la classe Analyzer produit une instance de l’ontologie de do-maine, elle le passe à un objet de la classe Handler, qui a son tour le passe à
F igure 3 . 18 – Diagramme de classe UML du framework
un objet de la classe AccessControlReqGenerator. Cet objet génère un graphe de contrôle d’accès et le retourne à l’objet Handler qui le passe à un objet de la classeDeploymentGraphGenerator. Ce dernier génère un graphe de dé-ploiement qui sera intercepté par un objet de la classe DeploymentManager
afin de déployer les composants de contrôle d’accès sur les machines des utilisateurs. Ces étapes constituent un processus d’adaptation qui sera exé-cuté dans un thread. Nous discutons dans le chapitre suivant le mécanisme de traitement des threads afin d’éviter les incohérences de déploiement des composants.
Utilisation du framework
Notre framework définit une structure sur laquelle peuvent se baser les applications qui offrent des moyens de collaboration. Il est destiné à être utilisé dans les applications collaboratives qui se basent sur une architecture client-serveur. Les serveurs des applications gère la communication entre les clients et contrôle l’accès aux ressources à travers notre framework. Les composants de contrôle d’accès sont répartis sur la machine centrale et sur les différents dispositifs des utilisateurs. Nous décrivons dans ce qui suit les étapes que doivent suivre les concepteurs des applications collaboratives afin d’utiliser notre framework.
Étape 1 : Création de l’ontologie de domaine Le concepteur de l’appli-cation doit définir l’ontologie de domaine qui contient tous les éléments spécifiques au domaine de l’application considérée. Cette ontologie contient également les règles qui expriment les situations de collaboration. La créa-tion de l’ontologie de domaine peut être réalisée en utilisant un éditeur d’ontologie OWL tel que Protégé2
.
Étape 2 : Prise en compte des changements de l’état de l’application
Le serveur de l’application doit implémenter la méthodemodelChanged() de la classe Analyzer. Cela peut se faire à travers une classe qui hérite de la classeAnalyzeret qui implémente la méthodemodelChanged(). Cette méthode doit être appelée par le serveur de l’application suite aux changements qui nécessitent l’exécution un processus adaptation. Cette méthode peut être implémentée de différentes façons selon la logique métier de l’application.
Il existe des APIs pour la création et la modification des instances des ontologies telles qu’OWL API3
. Les développeurs des applications colla-boratives doivent maîtriser ces APIs afin de pouvoir les utiliser. Pour cela, nous proposons une API qui peut être utilisée par les développeurs pour la création et la mise à jour de l’instance de l’ontologie de domaine. Cette API est indépendante de l’ontologie de domaine. Cela veut dire que plu-sieurs applications appartenant à différents domaines peuvent l’utiliser. En conséquence, le code de l’application reste inchangé et cohérent même si l’ontologie de domaine change.
Les services proposés par cette API sont :
– connect (String userId, String ip, List<String> roles, List<String> groups) : Cette fonction est utilisée quand un utilisateur se connecte
2. Disponible surhttp://protege.stanford.edu/
au serveur d’application. Elle utilise son identifiant, l’adresse IP de son dispositif, la liste de ses rôles et la liste des groupes qu’il veut re-joindre. Notamment, elle crée des instances des concepts Node, Role,
AccessPointet les relations entre elles.
– quit (String userId) : cette fonction est utilisée quand un utilisateur ayant l’identifiantuserIdse déconnecte. Elle prend en charge la mise à jour de l’instance de l’ontologie en supprimant le nœud de l’utilisateur, son dispositif et ses rôles.
– addToGroup (String userId, String group) : cette fonction est utilisée quand un utilisateur demande de rejoindre un groupe, elle se charge d’ajouter tous les rôles de cet utilisateur au groupe indiqué.
– removeFromGroup (String userId, String group) : cette fonction est appelée quand un utilisateur quitte un groupe donné. Elle permet de supprimer tous les rôles d’un utilisateur ayant l’identifiant userId du groupe indiqué par l’argument group.
– addRole (String userId, String role) : cette fonction est utilisée pour ajouter un rôle role à un utilisateur ayant l’identifiant userId. Ce rôle sera ajouté à tous les groupes auxquels appartient cet utilisateur. – removeRole (String userId, String role) : cette fonction est utilisée pour
retirer le rôlerolede l’utilisateur ayant l’identifiantuserId. Ce rôle sera retiré de tous les groupes auxquels appartient l’utilisateur.
– changeRole (String userId, String previousRole, String newRole) : Cette fonction est utilisée quand un utilisateur ayant l’identifiant userId
change de rôle au cours de la collaboration. L’ancien rôle sera retiré de tous les groupes auxquels il appartient. Tandis que le nouveau rôle sera ajouté à tous les groupes auxquels il appartient.
Étape3: Instanciation du frameworkAfin de pouvoir exécuter les pro-cessus d’adaptation du framework, un serveur d’application doit créer une instance de la classe Handler qui sera utilisée pour créer une instance de la classe Analyzer. Le serveur doit également initialiser l’ontologie de do-maine en utilisant la méthodeinitialize()fournie par l’API. Une fois cela fait, le framework est prêt à effectuer des processus d’adaptation et de mettre en place et reconfigurer les composants de contrôle d’accès. A chaque fois qu’un changement de l’état de l’application a lieu, la méthodemodelChanged()de la classe Analyzerest appelée afin de mettre à jour l’instance de l’ontologie de domaine et effectuer un processus d’adaptation.
Conclusion du chapitre
Dans ce chapitre, nous avons présenté notre approche pour l’adapta-tion de l’architecture de contrôle d’accès. D’abord, nous avons décrit nos choix conceptuels pour la décentralisation des composants de contrôle d’ac-cès dans les environnements collaboratifs ubiquitaires. Nous avons justifié le choix de répartition des entités du standard XACML afin de décentraliser le contrôle et assurer des échanges standard de requêtes d’accès et de déci-sions d’autorisation. Ensuite, nous avons présenté l’ontologie GACO et nous avons expliqué comment les concepteurs d’applications peuvent l’étendre
pour exprimer les concepts et les relations spécifiques au domaine considéré. Dans la troisième partie du chapitre, nous avons décrit notre framework de contrôle d’accès et nous avons détaillé le processus d’adaptation qui assure la reconfiguration dynamique de l’architecture logicielle de contrôle d’accès en fonction du changement du contexte. Dans le chapitre suivant nous dé-taillons le processus de déploiement des composants dans les machines qui constituent le réseau.
4
Sommaire
4.1 Cadre d’application du déploiement . . . . 75 4.1.1 Phase de conception . . . . 75 4.1.2 Phase d’exécution. . . . 76
4.2 Déploiement des composants. . . . 79 4.2.1 OSGi . . . . 79 4.2.2 Processus de déploiement des composants . . . . 81 4.2.3 Politique de sensibilité aux résultats de déploiement . . . . . 86 4.2.4 Génération du graphe de déploiement et problème de
mo-notonicité . . . . 88 4.2.5 Déclenchement des processus d’adaptation . . . . 94 Conclusion . . . . 96