2.2.1 Données partagées
Objet partagé. Nous considérons les objets collaboratifs partagés par de nombreux utilisateurs afin d’effectuer une tâche commune. Les opérations modifiant l’objet partagé sont appelées opé-rations coopératives. Par exemple, un objet partagé peut être un document qui est une suite de caractères, de mots ou de paragraphes. Pratiquement, les éditeurs collaboratifs manipulent un tel document et le modifient moyennant deux opérations coopératives : (i) Ins(p, e) où p est la position d’insertion et e l’élément (c-à-d caractère, mot, paragraphe, etc.) à ajouter à la posi-tion p. (ii) Del(p, e) qui supprime l’élément e à la posiposi-tion p. Les opéraposi-tions coopératives sont générées localement par chaque site, puis diffusées à d’autres collaborateurs.
2.2. Modèle de Coordination
Nous considérons que chaque site exécute et stocke des opérations coopératives dans un jour-nal appelé jourjour-nal coopératif (voir le chapitre 1). Notre objectif est d’étendre l’objet collaboratif avec une couche de sécurité pour contrôler l’accès aux différentes copies manipulées par différents collaborateurs.
Politique partagée. Nous considérons un modèle de contrôle d’accès basé sur des politiques d’autorisation et utilisant trois ensembles pour spécifier ces politiques, à savoir :
1. S est l’ensemble des sujets. Un sujet peut être un utilisateur ou un groupe d’utilisateurs. 2. O est l’ensemble des objets. Il peut s’agir de tout l’objet partagé, d’un ou plusieurs éléments
constitutifs de cet objet partagé.
3. R est l’ensemble des droits d’accès. Chaque droit est associé à une opération que le sujet peut effectuer sur l’objet partagé. Par exemple, nous pouvons considérer le droit d’ajouter un nouvel élément (i), de supprimer un élément (d) et de mettre à jour un élément (u). Une politique d’autorisation spécifie donc les opérations qu’un utilisateur peut exécuter sur un objet partagé.
Définition 2.1 (Politique) Une politique P : 2S× 2O → 2R× {+, −} associe un ensemble de sujets et un ensemble de d’objets à un ensemble de droits signés. Le signe “+” représente l’attribution d’un droit et le signe “−” représente la révocation d’un droit. Nous représentons une politique P comme une liste indexée d’autorisations. Chaque autori-sation li ∈ P est un quadruplet hSi, Oi, Ri, ωii où Si ⊆ S, Oi ⊆ O, Ri ⊆ R et ωi ∈ {−, +}. Par exemple, l’autorisation l = h∗, ∗, i, +i attribue un droit positif pour insérer de nouveaux objets pour tous les utilisateurs (Le symbole ∗ désigne une quantification universelle).
Une autorisation est dite positive (resp. négative) lorsque ω = + (resp. ω = −). Les auto-risations négatives sont utilisées pour accélérer le processus de vérification. Nous utilisons une sémantique basée sur la première correspondance (ou en anglais “first match”) : quand une opé-ration coopérative est générée, le système vérifie sa politique d’accès en commençant à partir de la première autorisation et il s’arrête lorsqu’il trouve la première autorisation l qui correspond à l’opération coopérative. Si aucune correspondance n’est trouvée, alors l’opération est rejetée.
Nous supposons que l’utilisateur qui attribue des autorisations est en mesure d’effectuer des opérations administratives. Une opération administrative consiste tout simplement à modifier la politique en ajoutant ou en supprimant des autorisations.
Définition 2.2 (Opérations administratives) L’état d’une politique est représenté par un triplet hP, S, Oi où P est la liste des autorisations. L’administrateur peut modifier l’état de la politique en utilisant l’ensemble suivant des opérations administratives :
— AddAuth(p, l) pour insérer une autorisation l à la position p ;
— DelAuth(p, l) pour enlever une autorisation l se trouvant à la position p ;
Une opération administrative a est dite restrictive ssi a = AddAuth(p, l) et l est négative ou
a = DelAuth(p, l) et l est positive.
La politique peut être considérée comme un objet partagé par le groupe d’utilisateurs. Elle est donc répliquée chez chaque utilisateur afin d’éviter des latences élevées dues à la vérification de la validité d’une opération coopérative par rapport à la politique. La réplication vise à améliorer la disponibilité de l’objet partagé ainsi que sa politique.
2.2.2 Modèle de Collaboration
Nous considérons le modèle suivant de collaboration :
1. Lorsqu’un utilisateur génère une opération coopérative sur la copie locale de l’objet partagé, cette opération sera validée ou rejetée en la contrôlant uniquement par rapport à la copie locale de l’objet de la politique.
2. Une fois accordées et exécutées, les opérations coopératives sont ensuite diffusées à d’autres utilisateurs qui doivent à leur tour vérifier si ces opérations distantes sont autorisées par la politique locale avant de les exécuter.
3. Lorsqu’un administrateur modifie sa copie de la politique locale en ajoutant ou supprimant des autorisations, il envoie ses modifications aux autres utilisateurs afin de mettre à jour les autres copies de la politique.
Nous supposons que les messages sont envoyés via un réseau de communication sécurisé et fiable, et les utilisateurs sont identifiés et authentifiés afin d’associer correctement l’accès à ces utilisateurs.
Un autre aspect important de la politique de contrôle d’accès est de savoir si le modèle est obligatoire ou discrétionnaire. En effet, deux approches sont possibles lors de la construction de la couche de sécurité basé sur le modèle présenté ci-dessus : mono-administrateur et multi-administrateurs. Ainsi, il est préférable pour notre modèle de contrôle d’accès d’être flexible et facilement extensible du mono au multi-administrateurs afin de satisfaire une grande variété d’applications. Chaque approche a des avantages et des inconvénients.
Mono-administrateur. De nombreuses applications distribuées ne nécessitent qu’un seul ad-ministrateur dans le groupe, telles que la gestion en ligne des examens et des environnements coopératives des programmation où le superviseur de l’application dispose d’une pleine autorité sur le groupe de collaboration. Cette forme de contrôle est utile pour maintenir l’attention du groupe sur le travail à fournir, en particulier lorsque l’on a des délais à respecter [75]. Dans de telles applications, l’administrateur se charge de la création et la supervision des groupes.
Le principal avantage d’un tel modèle est sa simplicité. En effet, il permet une mise à jour facile de la politique comme seul l’administrateur change les droits d’accès. Cependant, d’un point de vue de sécurité, il est plus difficile de contrôler tous les utilisateurs, particulièrement dans le cas des groupes volumineux de collaboration. En outre, l’absence du site de l’administrateur en raison de pannes matérielles ou logicielles pourrait laisser la politique dans un état statique. Multi-administrateurs. Il existe plusieurs applications collaboratives qui nécessitent une ap-proche discrétionnaire en ce sens que le propriétaire d’un objet est le seul a avoir le droit d’attri-buer des autorisations à d’autres utilisateurs sur cet objet. Sinon, l’opération administrative est rejetée. Par exemple, les agendas partagés sont des applications collaboratives où une politique multi-administrateurs serait appropriée [2]. En effet, dans le contexte professionnel, une secré-taire peut avoir besoin de voir instantanément l’activité de son responsable en vue d’organiser ses réunions. Il serait plus pratique si le secrétaire était en mesure de mettre à jour les informations relatives à une réunion dans le calendrier du responsable. Il est donc intéressant de donner au responsable la possibilité d’accorder le droit de modification à la secrétaire sur tout ou une partie de son calendrier partagé.
Ainsi dans une approche discrétionnaire, chaque utilisateur u dispose d’une politique Pu sur ses propres objets, qui évolue indépendamment des autres politiques. Chaque administrateur peut donc spécifier des droits d’accès à d’autres utilisateurs sur ses objets.