these doctorat une architecture de securité

Chapitre 6. Implantation dans ProActive : une approche transparente
Le composant parallèle (schéma (c) figure 6.13) est construit au-dessus du mécanisme de
communication de groupe. Les composants du composant parallèle sont regroupés au sein d’un
groupe. La communication sécurisée au sein d’un composant parallèle se comporte de manière
identique à celle d’une communication de groupe. Selon le fait que le groupe est un groupe simple,
hiérarchique ou actif, le gestionnaire de sécurité s’adaptera aux propriétés des communications
sécurisées au sein d’un groupe d’objets actifs telles que présentées dans la section 6.4.
6.8 Sémantique des communications sécurisées
tel-00239252, version 1 - 5 Feb 2008
6.8.1 Communications locales et distantes
Dans la partie 4.3, nous avons présenté la sémantique des communications telle qu’elle existe
au sein de la bibliothèque. Nous allons reprendre les points et montrer comment l’introduction
de la sécurité s’intègre avec le modèle existant.
Lorsque deux objets actifs se trouvent dans le même espace d’adressage (i.e. dans la même
machine virtuelle), ils doivent pouvoir communiquer directement sans passer par la pile des
protocoles réseaux, tout en conservant une sémantique identique. Cette optimisation existe dans
ProActive cependant elle maintient la sémantique de passage de paramètres par copie profonde,
garantissant ainsi l’absence d’objets passifs partagés.
Au niveau du protocole de sécurité, on peut se demander si, lors d’un appel de méthode local,
le chiffrement de la communication n’est pas superflu vu l’inexistence du risque d’interception de
la communication par une tierce partie. Cependant, nous avons fait le choix de chiffrer les communications
même à l’intérieur du même espace adressage. Si, du point de vue des performances,
cette solution n’est pas optimale, elle a l’avantage de garantir la sémantique du mécanisme de sécurité
: toute communication qu’elle soit locale ou distante sera chiffrée si la politique de sécurité
l’impose.
6.8.2 Sécurisation des messages
Nous allons présenter ici les techniques mises en œuvre pour appliquer le principe de transparence
de la sécurité par rapport au code application. Un des effets de bord positifs de cette
approche est d’étendre la transparence de la sécurité bien au delà du code applicatif et de d’implanter
la transparence dans les méta-objets eux-mêmes.
Pour cela, nous avons étendu l’interface Message qui est l’interface mère de tous les messages
échangés entre les diverses entités composant une application. La principale modification a fait
en sorte que le message puisse gérer lui-même sa sécurité. En effet, lorsqu’un message va être
envoyé sur le réseau, il doit être sérialisé. Un objet sérialisable est capable de gérer lui-même
sa propre sérialisation. À partir de ce moment, le message est capable de détecter qu’il va être
envoyé sur le réseau. Il va ainsi pouvoir sécuriser les diverses données sensibles qu’il contient en
fonction de la politique de sécurité qui aura été négociée par le gestionnaire de sécurité.
Pour chaque classe implantant l’interface Message, il est nécessaire de spécialiser les méthodes
gérant la sécurisation du message. Effectivement, selon le type de la classe, les données
sensibles ne seront pas les mêmes. Par exemple, la classe RequestImpl contient une variable
d’instance correspondant à l’appel de méthode et à ses paramètres. Cette variable n’existe bien
évidemment pas dans la classe ReplyImpl qui contient une autre variable représentant le résultat
d’un précédent appel de méthode.
6.8.3 Appel de méthode sécurisé
La figure 6.14 présente les divers objets et méta-objets traversés lors d’un appel de méthode
sécurisé d’un objet actif sur un autre.
On s’aperçoit en premier lieu que le chemin suivi par l’appel de méthode sécurisé est ressemble
fortement à celui d’un appel de méthode non sécurisé. On a rajouté en fait deux indirections
supplémentaires. La première se situe au moment de l’envoi du message vers le body
120