Soutenance mémoire
Notion de contexte dans l’informatique ubiquitaire
La notion de contexte attire l’attention de plusieurs chercheurs qui traitent des problématiques liées à l’informatique ubiquitaire.
Définitions
Plusieurs définitions du contexte ont été proposées depuis les années 1990 [Cha07]. Schilit et Theimer [ST94] sont les premiers à avoir défini le contexte. Selon eux, le contexte est représenté par la localisation de l’utilisateur et les identités et les états des personnes et des objets qui l’entourent. Brown et al. [BBC97] rajoutent à cette définition l’orientation de l’utilisateur, la saison et la température. Ryan et al. [RPM98] définissent le contexte en tant que la localisation, l’environnement, l’identité de l’utilisateur et ajoutent la notion de temps. Dey [Dey98] ajoute au contexte l’état émotionnel de l’utilisateur. Pascoe [Pas98] définit le contexte comme un ensemble d’états physiques et conceptuels d’une entité donnée. Dey et al. [ADB + 99] définissentle contexte comme suit : « Le contexte est toute information qui peut être utiliséepour caractériser la situation d’une entité. Une entité est une personne, un endroitou un objet qui est considéré pertinent pour l’interaction entre l’utilisateur et l’application, y compris l’utilisateur et l’application ». Winograd [Win01] affirme que cette définition couvre toutes les définitions précédentes du contexte. Cependant il considère qu’elle est trop générale. Il précise que le contexte est un ensemble structuré et partagé d’informations qui peut évoluer dans le temps. Selon lui, la considération d’une information comme contexte dépend de la manière dont elle est utilisée et non de ses propriétés inhérentes. Kulkarni et al. [KAT12] précisent que le contexte est toute situation, de l’environnement physique ou virtuel, qui peut être utilisée par une application pour effectuerune adaptation dynamique.
Nous considérons que les deux dernières définitions sont les plus utiles pour l’exploitation du contexte dans les environnements de travails collaboratif ubiquitaires. Pour cela, nous définissons le contexte comme suit : « Le contexte est toute information pouvant être utilisée pour caractériser lastructure de la collaboration. Les informations de contexte évoluent dans le temps et peuvent être utilisées pour effectuer une adaptation dynamique »
Dans le cas où les sessions de collaboration sont utilisées pour la structuration de la collaboration, le contexte est toute information relative à la structure des sessions.
Sensibilité au contexte
La notion de sensibilité au contexte (Context-Awareness) représente la capacité du système à s’adapter aux changements du contexte afin de mieux répondre aux attentes des utilisateurs. L’objectif principal des applications sensibles au contexte est de réduire le plus possible les interactions entre les utilisateurs et les machines. Plusieurs définitions d’un système sensible au contexte ont été proposées [ST94] [RPM98] [BBC97]. Selon Dey et al. [ADB+ 99], un système est sensible au contexte s’il utilise celui-ci pour fournir à l’utilisateur des informations et des services pertinents. Cette pertinence dépend des tâches et des activités demandées à l’utilisateur.
Les environnements de travail collaboratif ont tendance à utiliser les informations contextuelles afin d’offrir des services et améliorer les fonctionnalités des applications[KAT12]. La conception d’applications de travail collaboratif sensibles au contexte est compliquée pour plusieurs raisons.
Ces applications doivent supporter différents types d’interactions et de politiques de droits d’accès. En outre les utilisateurs de ce type d’environnements changent d’un processus de collaboration à un autre en fonction des besoins. Les processus de collaboration peuvent être représentés par les sessions de collaboration. Plusieurs systèmes ont proposé des mécanismes de sensibilité au contexte pour les applications CSCW [DCME01] [HI04]. Ces systèmes sont destinés à être utilisés dans des environnements bien particuliers et ne supportent pas des modifications pour répondre aux besoins des nouvelles technologies.
Adaptation
Un système est dit adaptatif s’il est capable de s’adapter aux changements. Ces changements peuvent avoir lieu dans le système lui-même ou dans une partie de l’environnement qui peut influer sur le comportement du système [ST09]. Ces systèmes sont souvent appelés auto-adaptatifs. Selon Laddaga [Lad00], la première raison qui justifie le besoin des systèmes adaptatifs est l’augmentation du coût de la gestion des systèmes logiciels. Plusieurs définitions de l’adaptation ont été proposées [OGT + 99]. Selon McKinley et al. [MSKC04], l’adaptation est essentielle dans l’informatique ubiquitaire et ils signalent que les dispositifs mobiles doivent s’adapter aux contraintes des réseaux ad-hoc sans fil. Un système adaptatif doit s’adapter aux changements lors de son exécution [ST09].
Les systèmes adaptatifs sont fortement liés aux systèmes autonomiques [KC03] et il est difficile de distinguer les deux terminologies. En comparant ces deux systèmes, on remarque qu’il y a des points communs et quelques différences [ST09]. Les systèmes adaptatifs sont plus limités et font partie des systèmes autonomes. En effet, si on considère une architecture multi-niveaux composée des niveaux application, middleware, systèmes d’exploitation, réseau et matériel [MSKC04], un système adaptatif peut couvrir les niveaux application et middleware, tandis que les systèmes autonomes peuvent couvrir aussi les niveaux les plus bas.
Contrôle d’accès basé sur les rôles (Role-Based Access Control)
Le contrôle d’accès basé sur les rôles (Role-Based Access Control ou RBAC) [FCAG03] [FSG + 01] est un modèle principal pour la gestion d’accès aux ressources. Il propose une nouvelle méthode pour l’attribution des droits d’accès aux individus. Il a été proposé comme une alternative du contrôle d’accès discrétionnaire et du contrôle d’accès obligatoire afin de réduire la complexité et le coût d’administration des politiques de contrôle [BGBJ05].
Le principe fondamental de RBAC est que la décision d’autorisation d’accès à une ressource est basée sur le rôle de l’utilisateur. Une fois que les rôles dans le système sont définis, des permissions sont attribuées à ses rôles.
Ensuite, les utilisateurs auront des permissions en fonction de leurs rôles.
La Figure 2.1 décrit les relations entre les utilisateurs, les rôles et les permissions dans le modèle RBAC. Cette figure peut être décrite comme suit : un utilisateur peut avoir un ou plusieurs rôles ; et un rôle peut être attribué à un ou plusieurs utilisateurs. Une permission associe un ensemble de droits à un objet. Une permission peut être attribuée à un ou plusieursrôles et un rôle peut avoir plusieurs permissions.
Contrôle d’accès basé sur les équipes (Team-Based Access Control TMAC)
La notion d’équipe permet de grouper les utilisateurs d’une organisation. Dans les modèles RBAC, un groupe est un ensemble d’utilisateurs qui jouent le même rôle. Néanmoins, dans certains environnements, des utilisateurs peuvent avoir plusieurs rôles dans un seul groupe. Le modèle TMAC, proposé par Thomas [Tho97], permet d’associer des droits d’accès à un groupe d’utilisateurs qui peuvent avoir des rôles différents et dont le but est d’atteindre un objectif particulier. TMAC définit deux aspects importants du contexte de collaboration : le contexte des utilisateurs qui permet d’identifier les utilisateurs qui jouent un rôle dans une équipe à un moment donné ;
et le contexte des objets qui permet d’identifier les objets requis dans le processus de collaboration. En 2001, Georgiadis et al. [GMPT01] ont proposé le modèle C-TMAC qui rajoute d’autres informations contextuelles telles que la position géographique de l’utilisateur.
Langage standard de contrôle d’accès : XACML
XACML (eXtensible Access Control Markup Language) est un langage basé sur XML dédié au contrôle d’accès. Il a été standardisé par OASIS en 2005 [Oas05]. Ce langage a été proposé pour l’implémentation du modèle ABAC et l’expression de ses politiques en se basant sur les attributs. XACML définit trois niveaux de politiques : ensemble de politiques (PolicySet), politique (Policy) et règle (Rule). La Figure 2.3 représente la structure des politiques dans XACML. Un PolicySet est une agrégation de plusieurs politiques (Policy) et éventuellement d’autres PolicySet. Une politique se compose d’un ensemble de règles de contrôle d’accès. Chaque règle est composée d’un effet (Effect) et d’une cible (Target). Un effet indique le résultat de l’évaluation d’une règle.
Il peut avoir comme valeur Permit (autorisé) ou Deny (non autorisé). Une cible est un ensemble de propriétés associées aux sujets, aux ressources, aux actions et à l’environnement qui permettent d’identifier les règles et les politiques appropriées pour l’évaluation d’une requête donnée. Cette notion de cible de XACML a été introduite afin de facilité la recherche des règles qui doivent s’appliquer à une requête donnée. En plus de l’effet et de la cible, une règle peut contenir optionnellement une condition qui représente une expression booléenne qui permet de définir des restrictions plus complexes sur les attributs.
Représentation des connaissances
Dans cette section, nous présentons des techniques de représentation de connaissances et nous citons les principaux travaux qui ont utilisé les ontologies pour l’implémentation des systèmes de contrôle d’accès qui se basent sur le modèle RBAC.
Définitions
La représentation des connaissances est un champ d’étude de l’intelligence artificielle. Il se concentre principalement sur les méthodes de représentation de connaissances et le traitement de ces connaissances par des mécanismes de raisonnement d’une façon automatisé [BL04]. L’avantage principal de la représentation des connaissances est qu’elle permet de décrire le comportement des systèmes complexes en utilisant différents vocabulaires.
Une connaissance met en relation un expert, qui peut être un humain, et une formule logique qui peut être une proposition ou un prédicat. Par exemple, dans l’expression « Philippe sait que Julie va aller à la fête », le connaisseur est Philippe,alors que la proposition est « Julie va aller à la fête » [BL04].
La représentation des connaissances consiste à utiliser des symboles formels pour représenter un ensemble de formules logiques.
Le raisonnement est le traitement formel des symboles d’une représentation de connaissances afin de produire une représentation de nouvelles connaissances [BL04]. Le raisonnement est un concept important ; il représente le moyen qui permet d’atteindre l’objectif essentiel de la représentation des connaissances.
L’ensemble des symboles d’une représentation de connaissance est souvent appelé base de connaissances (Knowledge Base – KB). Un système à base de connaissances a la capacité de capturer des changements dans l’environnement et de s’adapter en fonction de ces changements [BL04]. Ce qui fait que la représentation des connaissances et le raisonnement sont des moyensessentiels utilisés par les systèmes adaptatifs.
Les ontologies et la représentation des connaissances
Les ontologies sont parmi les modèles les plus connus dans le domaine de l’ingénierie des connaissances. Ils visent à établir une représentation sémantique des connaissances d’un certain domaine pour qu’elles puissent être traitées et manipulées par les machines. Selon Gruber [Gru93], « une ontologie est une spécification explicite d’une conceptualisation ». « Une conceptualisation est une vue simplifiée et abstraite de l’environnement qu’on veut représenter ». L’étape de conceptualisation consiste à identifier les connaissances spécifiques à un domaine donné. Elle est nécessaire avant la construction d’une ontologie.
Plusieurs classifications des ontologies ont été proposées [GP99] :
– Ontologie de haut niveau [Gua97] : Ce sont des ontologies générales qui représentent les catégories des choses dans le monde. Ces ontologies représentent les concepts de haute abstraction tels que les évènements, le temps, l’espace, etc.
– Ontologies génériques (appelées aussi méta-ontologies ou core ontologies) : Ces ontologies sont moins abstraites que les ontologies de hautniveau. Elles peuvent être réutilisées dans différents domaines.
– Ontologies de domaine [MKSK00] : Une ontologie de domaine est réutilisable dans un domaine spécifique. Ces ontologies utilisent des vocabulaires pour décrire des concepts relatifs à un domaine d’application bien particulier. Perez [GP99] a identifié d’autres classes d’ontologies telles que les ontologies de tâches et les ontologies d’application.
Contrôle d’accès décentralisé
Dans cette sous-section nous analysons les solutions qui proposent des techniques pour la décentralisation du contrôle d’accès dans les environnements ubiquitaires. Zhou et al. [ZMR05] proposent un mécanisme pour combiner les politiques d’autorisation d’une manière sécurisée. Ces politiques peuvent être définies indépendamment et enregistrées dans des certificats appelés AC (Attribute certificates). Ces certificats peuvent être stockés dans un annuaire LDAP, dans un serveur HTTP ou dans un serveur de fichiers. Les auteurs supposent que les mécanismes de sécurité doivent être définis dans chaque domaine indépendamment. Dans chaque domaine, il y a une politique racine et quelques politiques subordonnées. La politique racine spécifie la manière d’utilisation des autres politiques du domaine et la méthode d’authentification pour pouvoir les utiliser. Ce mécanisme ressemble à la notion de »target » du standard XACML qui spécifie quelles politiques et règles doivent être utilisées pour répondre à une requête. Le modèle RBAC est utilisé avec des certificats X.509. Le cœur du système est un moteur de contrôle d’ac- cès qui exécute les fonctions d’authentification et d’autorisation. Bien que les politiques de contrôle d’accès soient distribuées sur plusieurs domaines, l’utilisation d’un seul moteur de contrôle peut présenter des problèmes de passage à l’échelle avec un grand nombre de services et d’utilisateurs. Quinn et al. [QKF+ 06] proposent un framework pour la gestion et la décentralisation des applications dans les environnements ubiquitaires. Dans le framework proposé, le contrôle d’accès ainsi que l’administration des politiques de contrôle d’accès sont décentralisés. Le modèle TBAC est utilisé dans un scénario de conférence afin de décrire les mécanismes de contrôle proposés. Les auteurs montrent que l’approche proposée permet de réduire le temps d’accès et les goulots d’étranglement quand le nombre de ressources augmente d’une manière exponentielle.
Mahalle et al. [MTPP13] proposent une approche floue (Fuzzy) pour le modèle TBAC. Ils utilisent la notion des niveaux de confiance pour la gestion d’identité. Le framework proposé, appelé FTBAC, définit trois niveaux : le niveau dispositif qui contient les dispositifs et la communication entre eux, le niveau requête qui calcule les valeurs de confiance, et le niveau contrôle d’accès qui établit les correspondances entre les valeurs de confiance et les permissions et génère les décisions. Chaque nœud du réseau calcule les valeurs de confiance et les droits d’accès des nœuds avec lesquels il communique. Barolli et Xhafa [BX11] proposent une plateforme, appelé JXTA-Overlay, dont l’objectif est d’améliorer la capacité des technologies Java, JXTA et pair à pair afin de supporter les systèmes collaboratifs et distribués. Dans [AMMBX09], les auteurs proposent un framework de sécurité pour JXTAOverlay. Dans ce framework, le contrôle d’accès est effectué par plusieurs agents dans le réseau. Ce framework est spécifique à JXTA-Overlay et les auteurs ne spécifient pas comment on peut l’utiliser dans d’autres systèmescollaboratifs.
|
Table des matières
Liste des figures
Liste des tableaux
1 Introduction
1.1 Contexte
1.2 Contributions
1.3 Organisation du mémoire
2 État de l ’art
2.1 Environnements collaboratifs ubiquitaires
2.1.1 Informatique ubiquitaire
2.1.2 Notion de collaboration
2.1.3 Notion de contexte dans l’informatique ubiquitaire
2.1.4 Adaptation
2.1.5 Informatique autonomique
2.2 Contrôle d’accès
2.2.1 Exigences des systèmes de contrôle d’accès
2.2.2 Exigences des modèles de contrôle d’accès
2.2.3 Modèles de contrôle d’accès
2.2.4 Langage standard de contrôle d’accès : XACML
2.2.5 Contrôle d’accès et informatique ubiquitaire
2.3 Représentation des connaissances
2.3.1 Définitions .
2.3.2 Les ontologies et la représentation des connaissances
2.3.3 Le langage d’ontologie web (Web Ontology Language – OWL)
2.3.4 Utilisation des ontologies pour le contrôle d’accès
2.4 Synthèse des travaux existants et positionnement
2.4.1 Contrôle d’accès basé sur les informations contextuelles
2.4.2 Mécanismes de contrôle d’accès qui étendent RBAC
2.4.3 Contrôle d’accès décentralisé
2.4.4 Positionnement
Conclusion .
3 Framework pour l ’adaptation des mécanismes de contrôle d’accès
3.1 Architecture de contrôle d’accès
3.1.1 Décentralisation du contrôle d’accès
3.1.2 Choix de l’architecture de contrôle d’accès
3.2 Ontologie générique de contrôle d’accès (GACO)
3.2.1 Ontologies OWL
3.2.2 Raisonnement avec les ontologies OWL
3.2.3 Description de l’ontologie générique de contrôle d’accès GACO
3.2.4 Raisonnement avec GACO
3.2.5 Extension de GACO
3.2.6 Problème de monotonicité d’OWL
3.3 Description du Framework
3.3.1 Approche d’adaptation
3.3.2 Application de l’approche et architecture du framework
3.3.3 Processus d’adaptation : phases d’analyse et de planification
3.3.4 Conception du framework
Conclusion
4 Gestion du Déploiement
4.1 Cadre d’application du déploiement
4.1.1 Phase de conception
4.1.2 Phase d’exécution
4.2 Déploiement des composants .
4.2.1 OSGi .
4.2.2 Processus de déploiement des composants
4.2.3 Politique de sensibilité aux résultats de déploiement
4.2.4 Génération du graphe de déploiement et problème de monotonicité
4.2.5 Déclenchement des processus d’adaptation
Conclusion
5 Expérimentations
5.1 Outils utilisés
5.1.1 Outils pour le traitement des ontologies
5.1.2 Outils pour le traitement des politiques de contrôle d’accès
5.2 Description du projet Galaxy
5.3 Application prototype
5.3.1 Description des phases
5.3.2 Architecture de l’application
5.4 Évaluation fonctionnelle
5.4.1 Scénario
5.4.2 Architecture matérielle
5.4.3 Résultats
5.5 Évaluation des performances
5.5.1 Temps d’exécution du processus d’adaptation
5.5.2 Temps de génération des décisions d’autorisation
Conclusion
Conclusion générale
Liste des publications personnelles
Bibliographie
