these doctorat une architecture de securité

Chapitre 6. Implantation dans ProActive : une approche transparente
Les entités qui possèdent des sessions établies avec l’objet qui a migré ne sont pas informées
de la migration de ce dernier. On aurait pu choisir d’informer toutes les entités tierces de la
migration d’un objet et ainsi leur faire invalider leur session. Cette approche possède plusieurs
inconvénients :
1. il faut garder des références vers toutes les entités qui ont communiqué avec l’entité qui
a migré, ce qui provoque une augmentation de l’occupation mémoire du gestionnaire de
sécurité ;
2. les communications engendrées pour diffuser l’information qu’une migration a eu lieu prennent
du temps et des ressources systèmes (occupation de la bande passante du réseau).
L’approche que nous avons choisie se positionne comme une approche plus paresseuse (lazy).
Plutôt que d’informer les entités qui ont une session établie avec l’objet mobile, ces entités découviront,
lors leur prochaine interaction avec l’entité mobile que cette dernière a migré. Le respect
des politiques de sécurité est assuré par le fait que s’il existait une session la communication qui
doit révéler que l’objet a migré se fera selon la politique de la session. Après la mise à jour de la
localisation de l’entité cible, une nouvelle session va pouvoir être négociée et la communication
pourra être transmise en accord avec les nouveaux paramètres de sécurité.
tel-00239252, version 1 - 5 Feb 2008
Lors de la migration d’un objet actif, deux mécanismes de localisation peuvent être utilisés, le
répéteur ou le serveur de localisation (voir section 4.4).
L’utilisation du serveur de localisation (figure 6.3) est la méthode la plus facile à gérer au niveau
de la sécurité. Lorsqu’un objet a migré, un appel de méthode sur celui-ci lève une exception
qui sera attrapée au niveau du protocole de communication et qui déclenchera la recherche de
la nouvelle localisation via le serveur de localisation. Au niveau du protocole de sécurité, l’échec
de l’appel de méthode et la recherche via le serveur de localisation vont avoir pour conséquence
l’invalidation de la session. Il est intéressant de noter que le serveur de localisation étant un
objet actif toutes les communications vers et au départ de celui-ci peuvent être sécurisées.
FIG. 6.3 – Serveur de localisation et sécurité
L’utilisation des répéteurs (figure 6.4) et des mécanismes de sécurité est plus délicate. Il n’y a
pas, comme dans le mécanisme avec serveur de localisation, de détection de la migration. Dans le
cas sans sécurité, le répéteur se contente de transmettre la requête à l’objet actif. Dans le cas avec
sécurité, la transmission de la requête de l’émetteur au répéteur se fait de manière normale en
respectant la politique de sécurité négociée. Cependant, une fois sur le répéteur, le message sécurisé
ne peut pas être acheminé directement vers l’objet mobile. En effet, une telle action pourrait
entraîner une brèche au niveau du protocole de sécurité si la politique de sécurité utilisée pour
envoyer le message vers l’ancienne localisation de l’objet diffère de celle qui aurait du être utilisée
pour envoyer le message de l’objet émetteur vers le nouvel emplacement de l’objet qui a migré.
Pour éviter cette brèche, le répéteur a été modifié afin de pouvoir avertir l’objet appelant de la
migration de l’objet appelé. Une fois averti, l’objet appelant peut établir une nouvelle session
vers l’objet appelé qui reflétera les nouveaux paramètres de sécurité. En présence d’une chaîne
106