these doctorat une architecture de securité

Chapitre 6. Implantation dans ProActive : une approche transparente
Il est nécessaire de rappeler ici que la validité de notre mécanisme de sécurité peut être mise
en péril si les hôtes ne sont pas de confiance. Un hôte malicieux pourrait accéder aux certificats
et clés privées d’une entité et compromettre la sécurité de l’application. De toutes les ressources
disponibles via le réseau pair-à-pair, seules celles qui de part leur identité et leur localisation
seront autorisées par les politiques du ou des gestionnaires de sécurité pourront être utilisées
par l’application.
L’architecture pair-à-pair [30], développée au-dessus de la bibliothèque ProActive, permet la
mise à disposition de nœuds, donc de puissance de calcul, aux applications qui en ont besoin.
L’infrastructure du réseau est dite à auto-organisation continue et paramétrée. La construction
et la maintenance de ce réseau repose sur un jeu d’échanges de messages entre les divers pairs.
Chaque pair du réseau est un objet actif qui possède une liste de nœuds qu’il peut mettre à la
disposition des applications utilisant le réseau pair-à-pair. Selon sa puissance, une machine peut
mettre un ou plusieurs nœuds à disposition.
tel-00239252, version 1 - 5 Feb 2008
Cette architecture nous permet de tester notre modèle de sécurité dans un environnement qui
possède les caractéristiques suivantes :
– l’environnement est dynamique. Les ressources dont va disposer l’application vont varier au
cours du temps. De nouvelles ressources vont pouvoir être acquises pendant que d’autres
disparaissent, il est également possible d’acquérir à nouveau des ressources qui avaient
disparues ;
– la nature des ressources (runtimes, nœuds, objet actifs) ainsi que leur localisation sont variées.
Du point de vue de la sécurité, on se retrouve avec des ressources externes, sans lien
direct avec l’identité de l’application. Chacune de ces ressources possède sa propre identité
et ses propres règles de sécurité. Nous nous trouvons dans la cas d’un environnement où la
gestion de la sécurité peut être considérée comme décentralisée.
Un serveur pair-à-pair est composé de plusieurs objets actifs :
– le P2PService est l’objet actif principal d’un pair. Il créé les autres objets actifs . Il sert les
requêtes d’enregistrement ou les demandes de ressources.
– le P2PNodeManager gère les nœuds partagés par le pair qu’il représente. Il gère également
le système de réservation des nœuds.
– le P2PAcqManager permet de maintenir à jour les connexions avec les autres pairs.
– le P2PNodeLookup sert d’intermédiaire lorsque le P2PService demande un ensemble de
nœuds.
– le FirstContact sert lors du démarrage du pair. Il permet d’initier les premiers contacts
avec les autres pairs du réseau.
Le P2PService étant un objet actif, il est possible de le transformer en objet actif sécurisé.
// chargement d’un gestionnaire de securite
ProActiveSecurityManager psm = new ProActiveSecurityManager("p2p.xml");
// creation des meta objets du futur objet actif
MetaObjectFactory factory = ProActiveMetaObjectFactory.newInstance();
// ajout du gestionnaire de securite aux meta objets
factory.setProActiveSecurityManager(psm);
// P2PService Active Object Creation
P2PService p2pService = (P2PService) ProActive.newActive(P2PService.class.getName
(), null, url, null, factory );
Grâce au mécanisme de propagation dynamique du contexte de sécurité, les objets actifs créés
par le P2PService héritent du contexte de sécurité de leur créateur. Ce contexte sera également
propagé aux nœuds créés par le P2PNodeManager.
Ainsi, les ressources disponibles dans un réseau pair-à-pair sont vues par le mécanisme de sé-
112