these doctorat une architecture de securité

Chapitre 6. Implantation dans ProActive : une approche transparente
6.1 Création des entités sécurisées
6.1.1 Le runtime sécurisé
Comme toute entité sécurisée, un runtime possède une identité et une politique de sécurité.
Ces paramètres peuvent être imposés au runtime soit lors de sa création (cas 1 et 2) comme
paramètres du programme qui lance le runtime, soit lors de la création effective du runtime,
dans le code (cas 3).
1. en utilisant les descripteurs de déploiement. Il est possible lors de la définition du processus
qui lancera un runtime de spécifier le descripteur de sécurité que le runtime devra utiliser.
tel-00239252, version 1 - 5 Feb 2008
2. en utilisant les scripts de démarrage fournis avec la bibliothèque. Par exemple, sous Linux
la commande serait la suivante :
# ./startRuntime.sh runtime_policy.xml
3. en utilisant de manière fonctionnelle l’interface de programmation prévue à cet effet.
// creation du gestionnaire de securite
// le descripteur de securite "runtime_policy.xml" contient les parametres
// du runtime securise
ProActiveSecurityManager psm = new ProActiveSecurityManager("runtime_policy.
xml");
// creation du runtime et affectation du gestionnaire de securite
((ProActiveRuntimeImpl)ProActiveRuntimeImpl.getDefaultRuntime()).
setSecurityManager(psm);
le fichier "runtime_policy.xml" contient le descripteur de sécurité du runtime, Cette commande
démarre un runtime et l’enregistre sur une URL donnée qui peut être définie statiquement
ou créer dynamiquement le processus. Par la suite, le runtime être référencé dans
un descripteur de déploiement via son URL.
Cependant, contrairement à un nœud dont la création est due à un appel de méthode sur un runtime,
la création d’un runtime implique la création d’un nouveau processus qui peut être local ou
distant via l’utilisation d’une commande externe à la bibliothèque et à la plate-forme Java. Nous
sommes confrontés au problème de transfert des paramètres de sécurité (identité, politiques de
sécurité) entre les processus. La solution actuelle suppose que les fichiers requis aient été préalablement
copiés dans des endroits accessibles par chaque runtime. Ces fichiers ne sont nécessaire
que lors du démarrage du runtime. Un fois, le runtime démarré ces fichiers peuvent être supprimés.
6.1.2 Le nœud sécurisé
La sémantique de création d’un nœud distant a dû être revue et modifiée pour coller aux
contraintes de sécurité. Initialement, lorsqu’un objet demandait la création d’un nombre x de
nœuds à un runtime, le runtime créait les nœuds et renvoyait les URLs des nœuds à l’objet ayant
initié la demande. On se retrouvait avec des nœuds sur lesquels il était impossible de spécifier
une politique de sécurité propre. La politique de sécurité de ces nœuds ne pouvaient dépendre
que du runtime qui les accueillait.
Après modification, la sémantique sécurisée permet d’introduire le fait que, lors de l’appel de
méthode demandant la création du nœud distant, un paramètre supplémentaire, le gestionnaire
de sécurité associé à ce nœud, puisse être passé.
100