Dans cette sous section, nous présentons GACO qui permet principale-ment d’établir une représentation sémantique des situations de collabora-tion. Le but essentiel de cette représentation est de modéliser et d’identifier les besoins de contrôle d’accès de haut niveau dans les sessions de collabo-ration. L’environnement collaboratif se compose d’un ou plusieurs groupes dans lesquels les utilisateurs collaborent dans des sessions de collaboration en fonction des rôles qui leurs sont attribués. Comme nous l’avons men-tionné dans la section3.1.2, nous nous basons sur la notion de session pour
assurer la décentralisation du mécanisme de contrôle d’accès dans les envi-ronnements collaboratifs.
La Figure 3.4 présente les principaux éléments de GACO. Les concepts sont représentés par des ellipses, les propriétés sont représentées par des flèches allant d’un concept vers un autre et les types de données sont repré-sentés avec des lignes hachurées.
Les recommandations de nomenclature des éléments des ontologies ont été résumées par Théreaux [The03]. Les principales recommandations sont :
1. Les URIs doivent être les plus courts possible
2. Utiliser les politiques de nommage (tout en minuscule ou première lettre en majuscule)
3. Utiliser la forme singulière
4. Ne pas utiliser les espaces
Pour le nommage des éléments de l’ontologie, nous respectons ces recom-mandations et nous suivons les principes suivants :
1. Les noms des concepts commencent par une majuscule.
2. Les noms des relations sont en minuscules.
3. Les types de données commencent par une majuscule.
4. Si le nom d’un élément se compose de plusieurs mots, ils sont collés et chacun d’eux commence par une majuscule.
Dans ce qui suit, nous décrivons les concepts et les relations de GACO. Les différents nœuds qui participent aux activités collaboratives sont re-présentés par le concept Node. Un nœud peut représenter un être humain ou une entité logicielle autonome. Nous considérons comme un nœud toute entité qui peut collaborer et accéder à des ressources. Un nœud doit utiliser ou être hébergé dans un dispositif qui fournit une infrastructure matérielle qui assure la communication et l’accès aux ressources. Ces dispositifs sont modélisés par le conceptAccessPoint. La propriété uses relie le conceptNode
au conceptAccessPoint. Cette propriété est déclarée fonctionnelle puisqu’un nœud ne peut pas utiliser plus qu’un dispositif à un instant t. Sa propriété inverse, appelée usedByNode, permet d’identifier le nœud qui utilise un dis-positif donné à un moment donné. Une propriété de type de donnée, appelée
hasId, est associée à chaque AccessPoint. Cette propriété permet d’identifier un AccessPoint par une chaîne de caractère de type String qui représente généralement son adresse IP. Cette adresse IP est utilisée tout au long du processus d’adaptation que nous décrirons dans la section suivante.
Un nœud peut jouer un ou plusieurs rôles qui représentent ses fonc-tions ou ses responsabilités dans un groupe. Les rôles sont modélisés par le concept Role. L’attribution d’un rôle à un nœud est modélisée via la pro-priété non fonctionnellehasRole. La notion de rôle est fondamentale dans les mécanismes de contrôle d’accès qui se base sur le modèle RBAC. En consé-quence, tout changement au niveau de l’attribution des rôles aux utilisateurs peut influer sur leurs droits d’accès.
Ayant un ou plusieurs rôles, un nœud peut appartenir à un ou plusieurs groupes représentés par le conceptGroup. Un nœud donné peut jouer un rôle
Figure 3.4–Principaux éléments de GACO
belongsToGroup, qui relie le conceptRoleau conceptGroup, exprime l’appar-tenance d’un rôle à un groupe. Cette propriété est non fonctionnelle car un rôle peut appartenir à un ou plusieurs groupes. La propriété hasMemberest la relation inverse de la relation belongsToGroup. Dans chaque groupe, des sessions de collaboration sont établies afin d’assurer la collaboration entre les nœuds. Les sessions, représentées par le concept Session, représentent un ensemble de nœuds qui partagent des intérêts communs en partageant un ensemble de ressources. La propriété de type de donnée hasSessionName
permet d’associer à chaque session une chaîne de caractère qui représente son nom. L’association des sessions à chaque groupe est modélisée par la propriétéhasSessionqui relie le conceptGroup au conceptSession. Cette pro-priété est non fonctionnelle car plusieurs sessions peuvent être établies dans un même groupe. Un nœud peut collaborer dans une ou plusieurs sessions en fonction de son rôle. Cela est modélisé par la propriété non fonctionnelle
involvedIn qui relie le concept Role au conceptSession. La propriété inverse
involvesRolepermet de désigner l’ensemble des rôles qui sont impliqués dans l’activité collaborative de la session.
Le contrôle d’accès est effectué dans chacune des sessions indépendam-ment. Pour cela un ensemble de politiques de contrôle d’accès doivent être définies pour chaque session. Ces politiques spécifient les droits d’accès des rôles qui collaborent et partagent des ressources dans la session. Deux pro-priétés de type de donnée sont définies : la propriétéhasResourcesRepository
permet de spécifier l’URI du répertoire qui héberge les ressources partagées dans la session, tandis que la propriété hasPoliciesRepository indique l’URI du répertoire qui héberge les politiques de contrôle d’accès associées à la session.
Les concepts et les propriétés que nous avons détaillés permettent de décrire l’environnement de collaboration à un moment donné. Afin de dé-terminer les besoins de contrôle d’accès, nous définissons le concept Ac-cessControlComponent. Ce concept représente une entité qui doit être mise en place afin de contrôler l’accès d’un nœud aux ressources d’une session donnée. Cela est modélisé par les propriétés fonctionnellesmanagesAccessOf
et managesAccessInsession : la propriétémanagesAccessOf relie le concept Ac-cessControlComponent au conceptNode. Cette propriété indique le besoin de
contrôler l’accès aux ressources d’un nœud donné. La propriété managesA-cessInSessionindique la session dans laquelle l’entitéAccessControlComponent
doit contrôler l’accès. Puisque ces deux propriétés sont fonctionnelles, une entité de contrôle d’accès est associée à un seul nœud et à une seule ses-sion de collaboration. Cette entité traduit le besoin de contrôle d’accès d’un nœud donné dans une session bien déterminée. Cela est pris en compte par le système afin de mettre en place les entités logicielles nécessaires pour sa-tisfaire ce besoin. La propriété accessManagedBy est la propriété inverse de
managesAccessInsession.
GACO ne regroupe qu’un petit nombre de concepts et de relations. Ceci a plusieurs avantages. D’une part, cela simplifie la compréhension et l’utili-sation de GACO par les concepteurs des applications. D’autre part, le trai-tement d’un petit nombre d’éléments rend les moteurs d’inférence et de raisonnement plus performants.