Conception et réalisation d`un Serveur pour la gestion des

Université de TUNIS II
Ecole Nationale des Sciences de l’Informatique
(Tunisie)
Réalisé par
co-encadré par
(Responsable du stage)
INRIA Sophia-Antipolis
(France) (France)
1999-2000
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Table des Matières
1 REMERCIEMENTS
4
2 MOTS CLES
5
3 INTRODUCTION.
7
4 PRESENTATION GENERALE
8
4.1
L’INRIA.
8
4.1.1
L’INRIA – PRESENTATION GENERALE.
8
4.1.2
L’INRIA – HISTORIQUE.
8
4.1.3
LES CHIFFRES-CLES.
11
4.2
L'UNITE DE RECHERCHE INRIA SOPHIA ANTIPOLIS.
11
4.2.1
LES EQUIPES DE L’UNITE
11
4.2.2
THEME 3 : INTERACTION HOMME-MACHINE, IMAGES, DONNEES, CONNAISSANCES.
12
4.3
ORION - ENVIRONNEMENTS INTELLIGENTS DE RESOLUTION DE PROBLEMES POUR DES SYSTEMES
AUTONOMES.
13
4.3.1
PRESENTATION ET OBJECTIFS GENERAUX.
13
4.3.2
RELATIONS INTERNATIONALES ET INDUSTRIELLES.
14
4.4
LE PILOTAGE DE PROGRAMMES
15
4.4.1
PRESENTATION
15
4.4.2
STRUCTURE DES CONNAISSANCES
15
5 PROBLEMATIQUE
5.1
L’EXISTANT
17
19
6 ETAT DE L’ART
20
6.1
6.2
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.4
6.4.1
6.4.2
6.4.3
6.4.4
20
22
22
23
23
25
25
26
27
27
28
28
28
GESTION DES UTILISATEURS
ORGANISATION DES RESSOURCES (FICHIERS…)
MODELES DE SECURITE
TYPES DE SECURITE
MECANISMES DE PROTECTIONS
LES ACL UNIX
LES ACL WINDOWS NT
LES C-LISTS JAVA
DISTRIBUTION SUR INTERNET
LES SOCKETS
HTTP/CGI
LES SERVLETS JAVA
DCOM
Ecole Nationale des Sciences de l’Informatique de Tunisie
1
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
6.4.5
6.4.6
6.4.7
CORBA
RMI
COMPARAISON ENTRE LES DIFFERENTES TECHNIQUES
INRIA
28
28
29
7 SPECIFICATIONS
31
7.1
MODELISATION DU PROBLEME :
7.2
SPECIFICATION DES BESOINS
7.3
CONTRAINTES LOGICIELLES/MATERIELLES:
7.3.1
LANGAGES ET ENVIRONNEMENTS DE PROGRAMMATIONS:
7.3.2
ENVIRONNENT DE DEVELOPPEMENT :
7.3.3
ENVIRONNEMENT D'EXECUTION :
31
31
33
33
33
33
8 CONCEPTION
34
8.1
ARCHITECTURE GENERALE
8.2
GESTION DES UTILISATEURS
8.2.1
LES DOMAINES
8.2.2
LES UTILISATEURS
8.2.3
LES GROUPES
8.2.4
LES DOMAINES, UTILISATEURS ET GROUPES SPECIAUX
8.2.5
COMPARAISON AVEC LE MODELE D’UNIX
8.2.6
COMPARAISON AVEC LE MODELE DE WINDOWS NT
8.3
ORGANISATION DES RESSOURCES
8.4
LOCALISATION, IDENTIFICATION DES OBJETS
8.5
MODELE DE SECURITE
8.5.1
L’AUTHENTIFICATION
8.5.2
CONTROLE DE L’ACCES ET DE LA MANIPULATION DES RESSOURCES
8.5.3
LA STRUCTURE D’UNE PERMISSION:
8.5.4
LE SIGNATAIRE
8.5.5
LA CIBLE
8.5.6
LES CONTRAINTES
8.6
DISTRIBUTION DES OBJETS
8.6.1
FONCTIONNEMENT DU SOUS-SYSTEME LOCAL
8.6.2
FONCTIONNEMENT DU SOUS-SYSTEME EXPORTE
8.6.3
MIGRATION DES OBJETS
8.6.3.1
Problème de sécurité
8.6.3.2
Problème au niveau du RMI
8.7
APPLICATION AU PILOTAGE DE PROGRAMME
8.8
MODELE OBJET
8.8.1
TOUT EST DOBJECTINTERFACE :
8.8.2
UML DE LOCALSYSTEMMANAGERINTERFACE
8.8.3
UML DE DOBJECTINTERFACE
HIERARCHIE DES OBJETS
34
37
37
38
38
39
40
41
41
41
43
43
44
44
45
45
47
51
53
55
56
57
57
58
60
60
61
61
62
9 REALISATION
63
9.1
L’API DOOVOS
9.2
LA SERVLET PROGRAMSUPERVISIONSERVLET
9.3
LES OUTILS COMPLEMENTAIRES
9.3.1
HANDLER_GENERATOR
9.3.2
TEMPLATEGENERATOR
9.3.3
JHTML_GENERATOR
9.3.4
DOOVOS LAUNCHER
9.3.5
DDEBUGGER
63
64
66
66
66
67
67
69
Ecole Nationale des Sciences de l’Informatique de Tunisie
2
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
9.4
9.5
INTEGRATION DANS L’APPLET
PERFORMANCES DU SYSTEME
INRIA
70
70
10 CONCLUSION
72
11 BIBLIOGRAPHIE
73
11.1
11.2
11.3
73
73
74
ARTICLES
OUVRAGES
ADRESSES INTERNET
ANNEXE A : LA HIERARCHIE DES CLASSES ET DES INTERFACES DEVELOPPEES
76
12 ANNEXE B : COMPARATIF ENTRE MOTEURS DE SERVLETS
80
13 ANNEXE C : UTILISATION DE L’API DOOVOS, EXEMPLE
81
14 ANNEXE D : CONFIGURATION DES SERVEURS, EXEMPLE
83
Ecole Nationale des Sciences de l’Informatique de Tunisie
3
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
1 Remerciements
Je remercie tout particulièrement Mme Sabine Moisan, mon responsable de stage, ainsi
que Mme Monique Thonnat, directeur du projet, pour leurs précieux conseils et leur
patience face à mes nombreuses questions.
Je voudrais également remercier Mr Francis Avnaim, avec qui j’ai collaboré durant
toute la durée du stage et qui m’a été d’une aide considérable en ce qui concerne Unix et
Java.
Mme Wided Chaari m’a permis d’effectuer ce stage, qu’elle en soit remerciée.
Enfin, je remercie toute l’équipe
ORION (Alain Boucher, Robert Stahr,
Francois Bermond et tous les autres sans exception).
Ecole Nationale des Sciences de l’Informatique de Tunisie
4
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
2 Mots clés
Pilotage de programmes
Base de connaissances
Distribution
Utilisateur
Ressource
Java
Applet
RMI
Activation
Sécurité
Serialisation
Servlet
HTML
Client-Serveur
Ecole Nationale des Sciences de l’Informatique de Tunisie
5
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Résumé :
Ce projet, réalisé à l’INRIA Sophia Antipolis, porte sur la spécification, la
conception et la réalisation d’un serveur permettant via Internet de gérer de façon
distribuée des ressources et les utilisateurs de ces ressources, tout en garantissant un
niveau acceptable de sécurité.
Il a été décidé de développer un outil permettant à des scientifiques de bénéficier à
travers un site Internet des outils développés par l’équipe de recherche Orion et tout
particulièrement l’équipe de pilotage de programmes.
Mon travail a consisté à concevoir un modèle de gestion des utilisateurs, des
ressources et de la sécurité.
Ce modèle a été implanté en un système comprenant essentiellement :
- une API Java évolutive permettant de manipuler des ressources réparties, ou encore
de définir de nouveaux types de ressources.
- des Servlet permettant, via Internet et de façon interactive, l’administration du
système à partir de pages HTML sur un navigateur.
Des outils de développements ont également été réalisés et le système a été utilisé pour
la distribution d’une application liée au pilotage de programmes.
Abstract :
This project, done at INRIA Sophia Antipolis, deals with the specification, the
design and the developpment of a server which allows via Internet the management of
distributed resources and users while garanteeing and acceptable level of security.
We have developped a tool that allows scientists from all over the world to access to
tools and resources in the ORION team (especially in Program Supervision).
My work has consisted in the design of a management model of either users or
resources, taking into account security concerns.
The corresponding developped system is based on :
- a Java API for the management of distributed resources or the definition of new
resource types;
- Java Servlets for the administration of the system via a WEB browser.
Depeloppment tools have been also realized and the system has been used to implement
a distributed application related to Program Supervision.
Ecole Nationale des Sciences de l’Informatique de Tunisie
6
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
3 Introduction.
Dans le cadre du projet de fin d’études pour l’obtention du diplôme d’Ingénieur
en Informatique, j’ai passé un peu moins de quatre mois (du 10 mars au 30 juin 2000)
au sein de l’équipe ORION à Sophia Antipolis (France).
Ce projet porte sur la spécification, la conception et la réalisation d’un serveur
permettant au niveau d’Internet de gérer de façon distribuée des ressources - en
l’occurrence des bases de connaissances pour le pilotage de programmes – et les
utilisateurs de ces ressources, tout en garantissant un niveau acceptable de sécurité.
Les domaines abordés au cours de ce projet sont nombreux. Citons la sécurité, les
systèmes distribués les bases de données distribuées orientées objet...
Dans un premier temps, je présenterai mon environnement de travail, à savoir
l’INRIA, ainsi que le projet Orion. Celui-ci comporte plusieurs axes de recherches, dont
le pilotage de programmes. Ce thème étant à la base de mon travail, je le présenterai
dans un deuxième temps. Un état de l’art sera esquissé et je montrerai ce qu’apporte la
littérature à mon problème. Suivront alors une description des spécifications et de la
conception du serveur, puis les développements réalisés seront détaillés.
Ecole Nationale des Sciences de l’Informatique de Tunisie
7
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
4 Présentation générale
4.1 L’INRIA.
4.1.1
L’INRIA – Présentation générale.
Créé en 1967 à Rocquencourt près de Paris, l'INRIA (Institut national de recherche en
informatique et en automatique) est un établissement public à caractère scientifique et
technologique (EPST) placé sous la double tutelle du ministère de l'éducation nationale,
de la recherche et de la technologie et du ministère de l'économie, des finances et de
l'industrie.
Les principales missions de l'INRIA sont (selon le décret du 2 août 1985 portant sur
l'organisation et le fonctionnement de l'institut) :
- entreprendre des recherches fondamentales et appliquées ;
- réaliser des systèmes expérimentaux ;
- organiser des échanges scientifiques internationaux ;
- assurer le transfert et la diffusion des connaissances et du savoir-faire ;
- contribuer à la valorisation des résultats de la recherche ;
- contribuer, notamment par la formation, à des programmes de coopération pour le
développement ;
- effectuer des expertises scientifiques ;
- contribuer à la normalisation.
4.1.2
L’INRIA – Historique.
1967-1972 : les premiers pas de l'IRIA
Sur l’initiative de la Direction générale de la recherche scientifique et technique
(DGRST), un groupe de dix personnalités indépendantes, choisies pour leur compétence
scientifique ou économique, se réunissait, à la fin de l'année 1964 et courant 1965, sous
la présidence du professeur Lelong pour conduire une réflexion sur l'importance des
nouvelles techniques du traitement de l'information.
Le mot informatique n'avait pas encore cours ; il devait être proposé à quelque temps de
là, mais le rapport que le groupe adressait en février 1966 au Comité consultatif de la
recherche scientifique et technique (CCRST) mettait en lumière tous les concepts de
base de cette nouvelle science et attirait l'attention sur l'influence décisive qu'elle allait
jouer dans tous les domaines d'activités humaines.
Un peu plus tard, les instances politiques intéressées mettaient en œuvre l'ensemble des
mesures connues sous le terme de « Plan Calcul ».
L'Institut de recherche d'informatique et d'automatique, IRIA, créé par le décret 67-722
du 25 août 1967, constituait l'un des organes principaux d'exécution de ce Plan Calcul.
Ecole Nationale des Sciences de l’Informatique de Tunisie
8
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
L'étendue de ses missions faisait participer l'IRIA à tous les aspects de l'opération.
L'institut jouait, en effet, le rôle majeur, aussi bien pour la recherche que pour la
formation des hommes et pour la diffusion de la connaissance scientifique et technique.
1972-1980 : de l'IRIA à l'INRIA
Le 25 février 1972, un conseil interministériel, sur proposition du Comité consultatif de
la recherche scientifique et technique (CCRST), confirmait l'IRIA dans ses vocations et
arrêtait une série de décisions propres à en amplifier les actions, notamment dans le
domaine de la synthèse et orientation de la recherche française en informatique et dans
le domaine de l'assistance technique donnée à la pénétration de l'informatique dans
toutes les activités d'intérêt national :
regroupement de la recherche au sein d'un « Laboratoire de recherche d'informatique et
d'automatique », le Laboria ;
développement des interventions ayant la nature d'une assistance technique à des
applications exemplaires de l'informatique dans les différents secteurs d'activités
d'intérêt national ;
rattachement direct à l'institut, qui en devient ordonnateur, des crédits d'irrigation de la
recherche.
Les statuts de l'IRIA ont été partiellement modifiés suivant ces dispositions par le décret
73-338 du 13 mars 1973.
La réforme de structure s'appuyait sur une pièce maîtresse, la création d'un Comité
consultatif de la recherche en informatique, le CCRI, chargé d'élaborer les propositions
d'une politique nationale de la recherche dans les domaines de l'informatique et de
l'automatique. Le décret portant création du CCRI est le 73-130 du 12 février 1973.
Parmi les missions auxiliaires de l'IRIA, intimement liées aux missions principales, on
trouvait l'animation et la conduite de projets pilotes ; le premier étant la réalisation d'un
réseau permettant l'interconnexion de plusieurs grands centres de calcul (Projet
Cyclades).
Dans son action, l'IRIA se souciait non seulement d'accroître le potentiel en chercheurs,
mais aussi d'orienter l'implantation des équipes, selon les préoccupations de la
Délégation à l'aménagement du territoire (DATAR). Il mettait ainsi à la disposition
d'équipes de province, des postes budgétaires de chercheurs, notamment à Rennes. Ces
équipes portaient le nom d'équipes associées de l'IRIA.
En 1975, à partir des équipes de Rennes, était créé l'Irisa, laboratoire de recherche
associé à l'université de Rennes 1 et au CNRS.
Fin 1979, l'institut se recentre sur sa mission de recherche et de transfert et devient par
décret du 27 décembre 1979, l'INRIA (Institut national de recherche en informatique et
en automatique), établissement public à caractère administratif sous la tutelle du
ministre de l'industrie.
Parallèlement est créée, par décret du 27 septembre 1979, l'Agence pour le
développement de l'informatique qui est chargée, pour ce qui concerne les applications
de l'informatique, de mener des expérimentations, des actions de sensibilisation, de
formation et de prospection de nouveaux secteurs d'activité concernés. Elle est
Ecole Nationale des Sciences de l’Informatique de Tunisie
9
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
également chargée d'une mission d'animation et de développement de la recherche
publique et privée sur les applications de l'informatique, sur les techniques susceptibles
de favoriser leur développement. Cette agence sera supprimée en 1986.
Après 1980 : l'essor de l'INRIA
Depuis les années 80, l'INRIA n'a cessé de se développer.
En 1980, l'unité de recherche de Rennes voit le jour en tant qu'une des composantes de
l'Irisa.
En 1982, est créée l'unité de recherche de Sophia Antipolis.
En 1983, Alain Bensoussan devient président directeur général de l'INRIA.
En 1984, est créée l'unité de recherche de Lorraine, conjointement avec l'université de
Nancy et le Centre de recherche en informatique de Nancy (Crin) du CNRS.
En 1984, Simulog voit le jour. Il s'agit de la première filiale industrielle de l'INRIA,
dans le domaine de l'ingénierie assistée par ordinateur. C'est la première d'une série qui
conduira à la création de 19 autres sociétés de technologie issues de l'INRIA.
En 1985, l'INRIA devient établissement public à caractère scientifique et technologique
(EPST) placé sous la double tutelle du ministère chargé de la recherche et du ministère
chargé de l'industrie.
Le décret 85-831 du 2 août 1985, portant sur l'organisation et le fonctionnement de
l'institut, rappelle ses principales missions :
- entreprendre des recherches fondamentales et appliquées ;
- réaliser des systèmes expérimentaux ;
- organiser des échanges scientifiques internationaux ;
- assurer le transfert et la diffusion des connaissances et du savoir-faire ;
- contribuer à la valorisation des résultats des recherches ;
- contribuer, notamment par la formation, à des programmes de coopération pour le
développement ;
- effectuer des expertises scientifiques ;
- contribuer à la normalisation.
En 1987, l'INRIA célèbre son 20e anniversaire : Alain Bensoussan déclare que la plus
grande spécificité de l'institut consiste à obtenir que les résultats de la recherche soient
transférés aussi vite que possible dans le secteur économique.
En 1987, la deuxième filiale de l'INRIA, Ilog, chargée de l'industrialisation de produits
INRIA en intelligence logicielle, voit le jour.
En 1989, l'INRIA est un des fondateurs du consortium européen Ercim qui regroupe
actuellement quatorze organismes de recherche.
En 1990, la troisième filiale industrielle de l'INRIA, O2 Technology, est créée dans le
domaine des systèmes de gestion de bases de données orientées objet.
En 1992, l'unité de recherche de Rhône-Alpes voit le jour.
En mars 1994, l'INRIA adopte un plan stratégique visant à définir les principaux axes de
la politique générale menée par l'institut.
Le 31 janvier 1995, l'INRIA est le premier organisme de recherche à signer avec le
ministère de l'enseignement supérieur et de la recherche un contrat d'objectifs. Ce
Ecole Nationale des Sciences de l’Informatique de Tunisie
10
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
contrat associe également le ministère de l'industrie, des postes et des
télécommunications, autre tutelle de l'institut.
En 1995, l'INRIA est choisi comme pilote européen du consortium W3C, créé en 1994,
aux côtés du MIT pour les Etats-Unis.
En 1996, Bernard Larrouturou devient président directeur général de l'INRIA. En
décembre, il fait adopter par le Conseil d'administration les principales orientations de la
politique de l'institut pour les prochaines années.
En décembre 1997, un essai prospectif rédigé par Bernard Larrouturou en juillet 1997 et
intitulé « Inria 2007, l’INRIA dans dix ans » est diffusé aux partenaires de l'institut.
4.1.3
Les chiffres-clés.
L'INRIA, c'est :
 2 100 personnes, dont 1 700 scientifiques :
 715 postes permanents
 550 doctorants
 200 chercheurs d'autres organismes
 40 post-doc
 70 ingénieurs-experts
 100 stagiaires
 650 visiteurs étrangers
 200 collaborateurs extérieurs universitaires ou industriels
 5 unités de recherche réparties sur toute la France
 un budget de 495 MF (hors taxes) en 1997
 300 contrats actifs
 20 sociétés de technologie.
4.2 L'unité de recherche INRIA Sophia Antipolis.
Au cœur de la plus grande technopole européenne, l'unité de recherche INRIA Sophia
Antipolis représente un potentiel de 400 personnes, dont 140 sur poste budgétaire.
Cette unité entretient de nombreuses collaborations avec les laboratoires de la région
ainsi qu'avec le milieu industriel comme peuvent en témoigner les sociétés de
technologie créées par d'anciens chercheurs du site.
4.2.1
Les équipes de l’unité
Thème 1 : Réseaux et systèmes
MEIJE - Parallélisme, synchronisation et temps réel
MISTRAL - Modélisation en informatique et systèmes de télécommunication :
recherche et applications logicielles
RODEO - Réseaux à hauts débits, réseaux ouverts
SLOOP - Simulation, langages à objets et parallélisme
Ecole Nationale des Sciences de l’Informatique de Tunisie
11
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
TROPICS - TRansformations et Outils Informatiques Pour le Calcul Scientifique
(PLANETE - Protocoles et applications pour l'Internet)
Thème 2 : Génie logiciel et calcul symbolique
CAFE - Calcul Formel et équations
LEMME - Logiciels et Mathématiques
OASIS - Objets Actifs, Sémantique, Internet et Sécurité
PRISME - Géométrie, algorithmes et robotique
SAGA - Systèmes algébriques, géométrie et applications
(CERTILAB- Spécifications formelles, certification de logiciel)
(LETOOL - Environnements de programmation orientés objets et interfaces visuelles)
Thème 3 : Interaction homme-machine, images, données, connaissances
ACACIA - Acquisition des connaissances pour l'assistance à la conception par
interaction entre agents
ARIANA - Problèmes inverses en observation de la Terre
EPIDAURE - Imagerie et robotique médicale
ORION - Environnements intelligents de résolution de problèmes pour des systèmes
autonomes
ROBOTVIS - Vision par ordinateur et robotique
(AID - Gestion des connaissances pour l'aide à la conception coopérative)
Thème 4 : Simulation et optimisation de systèmes complexes
CAIMAN - Calcul scientifique, modélisation et analyse numérique
COMORE - Contrôle et modélisation de ressources renouvelables
ICARE - Instrumentation, commande et architecture des robots évolués
MIAOU - Mathématiques et informatique de l'automatique et de l'optimisation pour
l'utilisateur
OMEGA - Méthodes numériques probabilistes
SINUS - Simulation numérique dans les sciences de l'ingénieur
SYSDYS - Systèmes dynamiques stochastiques
(CHIR - Chirurgie, Informatique et Robotique)
4.2.2
Thème
3 :
Interaction
données, connaissances.
homme-machine,
images,
Les travaux dans ce domaine tendent à améliorer l'interaction entre l'homme et la
machine. La psychologie cognitive et l'ergonomie permettent de mieux adapter les
systèmes informatiques à leurs utilisateurs (aide à l'apprentissage, assistance à la
conduite d'installations, postes de pilotage). L'intelligence artificielle joue un rôle
central, d'une part sur le plan du dialogue (parole, langage naturel, graphismes et vision,
Ecole Nationale des Sciences de l’Informatique de Tunisie
12
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
données multilingues), d'autre part pour la conception d'outils avancés (raisonnements,
représentation des connaissances, architectures multi-experts).
La modélisation d'objets tridimensionnels et la reconnaissance de scènes, en prenant
éventuellement en compte le mouvement, fournissent des techniques de vision par
ordinateur nécessaires au pilotage de robots (robots mobiles, véhicules routiers
autonomes, robotique médicale) et interagissent avec la synthèse d'images (simulateurs,
illumination artificielle, production audiovisuelle). À l'aide en particulier de ces mêmes
techniques, des algorithmes de compression d'images ou de séquences d'images sont
développés. La géométrie et les statistiques sont à la base de ces travaux.
4.3 ORION - Environnements intelligents de
résolution de problèmes pour des systèmes
autonomes.
4.3.1
Présentation et objectifs généraux.
Sous la responsabilité scientifique de Mme Monique Thonnat, L’objectif d’ORION est
de concevoir et de développer des techniques et des logiciels pour, d'une part, le
pilotage automatique de programmes et, d'autre part, l'interprétation automatique
d'images.
ORION focalise ses travaux sur l'étude des connaissances qui interviennent dans ces
deux types de problèmes : connaissances sur les programmes et leur utilisation pour le
pilotage automatique de programmes, et connaissances sur les objets et les scénarios à
reconnaître pour l'interprétation automatique d'images. Thématiquement, Orion est une
équipe pluridisciplinaire, à la frontière des domaines de la vision par ordinateur, des
systèmes à base de connaissances et du génie logiciel. Les techniques utilisées relèvent
donc de ces trois disciplines.
Les applications qui intéressent ORION sont principalement du domaine de la vision
par ordinateur. Plus précisément, l’objectif est de faciliter la construction de systèmes
intelligents automatiques et adaptatifs, c'est-à-dire des systèmes incorporant
explicitement une expertise (intelligents), fonctionnant sans intervention humaine pour
les prises de décisions (automatiques) et ayant des capacités de réaction vis-à-vis des
changements de leur environnement (adaptatifs).
Parmi les applications qui nécessitent un fort degré d'autonomie, ORION a identifié,
d'une part, les problèmes d'automatisation de l'utilisation de programmes, et, d'autre
part, les problèmes d'interprétation automatique d'images. L'automatisation de
l'utilisation de programmes nécessite de planifier les traitements et de contrôler
l'exécution de codes de calcul. On utilisera le terme pilotage automatique de
programmes pour désigner ce type de problèmes. Dans de nombreuses applications,
Ecole Nationale des Sciences de l’Informatique de Tunisie
13
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
l'utilisateur ne peut pas interpréter les résultats des logiciels de traitements de données,
soit parce qu'il n'en est pas capable (manque de compétence), soit parce qu'il n'en a pas
le temps (saturation de ses capacités), soit enfin parce qu'il n'est pas présent (systèmes
embarqués). Ceci correspond à un sous-problème de la perception, celui de
l'interprétation des résultats des traitements d'images. On utilisera le terme
d'interprétation automatique d'images pour désigner ce type de problèmes.
4.3.2
Relations internationales et industrielles.
 Participation au projet européen Climat et Environnement ASTHMA pour la
reconnaissance automatique d'images de pollens avec Zambon (Italie), ACRI
(France), les universités de Barcelone (Espagne), de Cordoba (Espagne), de
Clermont (France), le CHU de Nice (France), le FISBAT (Italie) et le PAMOC
(France).
 Coopération avec Bull dans le cadre de l'action de développement Dyade Télescope
pour le développement d'un système intelligent de vidéo-surveillance.
 Participation à l'action coopérative LIRE regroupant les projets SYCO et OMEGA
de Nancy, le projet SHERPA de Grenoble et le projet ORION sur le thème de la
résolution de problèmes avec limitation de ressources.
 Collaborations avec l'Inserm/La Pitié Salpétrière U494, les universités d'Amsterdam
et de Maryland.
Ecole Nationale des Sciences de l’Informatique de Tunisie
14
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
4.4 Le pilotage de programmes
4.4.1
Présentation
L’objectif du pilotage de programmes est de pouvoir utiliser de façon optimale un
ensemble de programmes préexistants, indépendamment d’un domaine applicatif
particulier.
Pour cela, les systèmes de pilotage automatisent - partiellement ou totalement - les
étapes nécessaires à la construction d’un certain séquencement de programmes de
traitement qui résout l’objectif d’un utilisateur.
Il est toutefois à noter que le but du pilotage n’est pas d’optimiser les programmes euxmêmes, mais leur utilisation, qui peut être délicate pour l’utilisateur non-spécialiste.
En effet, les programmes ne s’appliquent que sous certaines conditions qui dépendent
de la nature ou du contenu de leurs données en entrée. Leur syntaxe d’appel peut être
complexe et leur exécution nécessite souvent la détermination préalable de valeurs de
paramètres d’entrée ou le formatage de certaines données.
Dans un système de pilotage de programmes, on distingue deux types d’intervenants.
D’abord, l’expert. Son rôle est de construire une base de connaissances sur l’utilisation
et les caractéristiques des programmes.
Ensuite, l’utilisateur final (ou applicatif). Il utilise le système pour une application
donnée en spécifiant un problème.
Requête utilisateur
Système de pilotage de programmes
Données
I/O
programmes
Moteur
Base de connaissances
I/O
Fig 1: système de pilotage
4.4.2
Structure des connaissances
Les connaissances intervenant dans le raisonnement (moteur) en pilotage de
programmes sont variées, et peuvent se présenter de diverses façons. Elles décrivent en
fait, l’enchaînement des tâches exécutées par le moteur. Ces tâches peuvent être
primitives (liées à un programme concret) ou composites regroupant plusieurs autres
sous-tâches suivant un certain opérateur : séquence, choix, spécialisation, itération,
optionnalité, etc.
Ecole Nationale des Sciences de l’Informatique de Tunisie
15
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Par ailleurs, pour la sélection de la (ou les) sous-tâche, au niveau d’un opérateur (de
choix par exemple), se fait moyennant des critères de sélection sous forme de règles
dans une base de règles.
Composite
séquence
séquence
choix
itération
primitif
programmes
programmes
programmes
Fig 2: les tâches dans une base de pilotage de programmes
Au niveau du groupe Orion, une base de connaissances est un ensemble de fichiers
(essentiellement des fichiers YAKL qui est un langage semi-formel pour la description
des bases de connaissances en pilotage).
Ecole Nationale des Sciences de l’Informatique de Tunisie
16
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
5 Problématique
Les ressources de la communauté scientifique sont très souvent éparpillées. C’est le
cas des bibliothèques de programmes. En fait, de part le monde, plusieurs équipes de
recherches développent leurs propres outils très souvent indépendamment les uns des
autres, au risque de refaire ce qui a déjà été fait.
Cela est essentiellement dû :
- aux différents engagements des scientifiques :
- engagement temporaire : difficulté de trouver quand se réunir.
- engagement géographique : difficulté de trouver où se réunir.
- et à la difficulté de retrouver avec précision les informations requises. Par
exemple, si pour un tel problème une solution a déjà été développée.
Il y a donc un manque d’outils de coopération qui pourraient permettre aux scientifiques
de mettre en commun leurs ressources.
Par ailleurs, Internet possède de nombreux avantages:
- simplicité d’utilisation car ne demandant ni des connaissances pointues en un
quelconque domaine, ni des ressources logicielles (seulement un navigateur)
encore moins matérielles (une station de travail suffit).
- accessibilité : désormais Internet est à la portée du citoyen moyen dans la
majorité des pays : dans les écoles, dans des lieux publics (publinet, cybercafés…), dans les locaux administratifs, etc.
- et surtout une expansion phénoménale : en effet, le nombre de techniciens, de
développeurs et sponsors ne cesse de croître. Il en va de même quant aux
ressources informatiques logicielles et matérielles : des serveurs superpuissants, des logiciels et des API très développées, etc. C’est ainsi que les
Applets Java, par exemple, combinent toute la puissance d’un programme avec
la portabilité proposée par le navigateur totalement indépendant de la plateforme (système d’exploitation, matériel utilisé…)
Internet est donc un excellent candidat pour tout outil de coopération et de partage des
ressources.
Cependant, au niveau de l’utilisateur, il est clair que la distribution des ressources sur
plusieurs sites pose un certain nombre de problèmes. En effet cela requiert :
- la connaissance de l’emplacement (URL) des différents sites.
Ecole Nationale des Sciences de l’Informatique de Tunisie
17
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
- la connaissance des différentes façons de présenter les produits spécifiques à chaque
site (IHM pas forcément la même)
- une perte de temps pour passer de l’un à l’autre
- l’impossibilité de combiner les ressources et les produits (exemple : moteur
d’inférence sur un site X et base de connaissance sur un autre site Y).
Il a donc été décidé de développer un outil permettant à des scientifiques (du monde
entier), via Internet, de bénéficier à travers un seul point d’entrée (un seul site) des
outils développés par l’équipe de recherche Orion et tout particulièrement l’équipe de
pilotage de programmes, mais aussi, toute autre équipe désirant apporter son expérience
et ses ressources et coopérer avec les autres.
C’est ainsi que, les groupes Orion (INRIA France) et GRIFT (ENSI Tunisie) pourront
se partager un même espace de travail (quoi que virtuel) permettant à l’un et à l’autre
d’avoir une vision globale des apports des deux groupes à la fois au sens des bases de
connaissances, moteurs d’inférences, etc.
Néanmoins, comme pour tout système distribué, cela soulève essentiellement quatre
problèmes :
- d’abord de sécurité,
en effet, la sécurité et un facteur décisif dès que plusieurs utilisateurs évoluent dans
un même système et aient droit aux mêmes ressources.
- ensuite de performance,
effectivement, même si la distribution est assez souvent un bonus favorisant la
performance de quelques systèmes (essentiellement lorsqu’il s’agit d’une
distribution de tâches et non de ressources), elle demeure cependant le goulot
d’étranglement de bien d’autres ; surtout s’il s’agit d’un réseau de caractéristiques
médiocres au plan des qualités de services comme c’est le cas d’Internet.
- puis d’interopérabilité,
c’est le problème lié au fait que les ressources distribuées ne sont pas
nécessairement sur des plates-formes compatibles (systèmes d’exploitations
différents). Le plus souvent, on convient, cependant, d’homogénéiser le système
en ne choisissant par exemple que des machines Unix.
- enfin de disponibilité et de cohérence,
en fait, cela est dû à des limitations purement techniques : une ressource n’est
jamais partout à la fois ; pourtant, elle doit le paraître uniformément
(identiquement) au niveau de chaque utilisateur d’un sous-système du système
distribué.
Mon travail consistera donc à essayer de trouver des solutions admissibles (dans la
mesure du possible et du temps du stage qui dure moins de 4 mois) pour les problèmes
Ecole Nationale des Sciences de l’Informatique de Tunisie
18
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
cités ci-dessus. Mais, dans un tout premier temps, on va d’abord prendre connaissance
de ce qui a déjà été fait au niveau de l’équipe de pilotage de programmes d’Orion pour
survoler ensuite ce que propose la littérature en relation plus ou moins directe avec ce
projet.
5.1 L’existant
L’équipe de pilotage de programmes, coordonnée par Mme Sabine Moisan, a déjà
développé un moteur d’inférence (PEGASE), des bases de connaissances ainsi qu’une
application Java (réalisée par Mr Francis Avnaim) capable de visualiser ces bases sous
forme de graphes et permettant par-là même de les modifier de façon interactive.
L’intérêt de cette application est qu’elle propose de manipuler des données complexes
de façon très intuitive (glisser - déposer…) et de mieux comprendre le mécanisme de
résolutions de problèmes effectués par le moteur d’inférence grâce au graphe des tâches
qui schématise le séquencement des différentes tâches (programmes) appliquées aux
données pour retrouver le résultat attendu.
Pour rendre cette application accessible à d’autres chercheurs, il a été décidé de la
transformer en Applet Java disponible, via Internet, à partir d’un serveur dédié.
Une première version de l’Applet était déjà en cours de développement lorsque je suis
arrivé. Celle-ci ne permettait que la visualisation de bases déjà existantes et nullement
de les modifier ou d’en créer des nouvelles.
Il a donc été décidé d’étendre les possibilités
de l’Applet en ce sens, ce qui pose le
problème de la gestion des utilisateurs (organisation, droits d’accès…) et des ressources
qui doivent être modifiables à distance.
Fig 3 : l’application de pilotage de programmes
Ecole Nationale des Sciences de l’Informatique de Tunisie
19
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
6 Etat de l’art
Comme dans la plupart des cas, une solution parfaitement adaptée à notre besoin
n’est pas citée dans la littérature. Ce sont plutôt des solutions pour des problèmes
semblables et/ou plus spécifiques que l’on retrouve le plus souvent.
En effet, la gestion des utilisateurs ou celle des ressources, les mécanismes de sécurité,
ou encore la distribution sur le WEB, sont très communs et ont fait couler beaucoup
d’encre.
En ce qui concerne les deux premiers points, on essayera de comparer et discuter les
approches des systèmes d’exploitations les plus répandus essentiellement Unix, et
Windows NT.
En ce qui concerne la sécurité, on se penchera toujours sur les mêmes systèmes mais
également sur le modèle de sécurité proposé par Java.
Au niveau de la distribution, plusieurs techniques seront présentées et discutées
6.1 Gestion des utilisateurs
Parce qu’un utilisateur effectif (humain) ne peut être authentifié au niveau d’une
machine, il a toujours été question d’attribuer un « compte utilisateur » à chacun de ces
utilisateurs. Ce compte permettra de définir entièrement les ressources et les droits
relatifs à telle ou telle personne.
Dans Unix, les utilisateurs sont gérés par les notions d’utilisateur (user) et de groupe
(group).
En fait, tout utilisateur effectif est représenté par :
D’abord un login (userName) : c'est une chaîne de caractère de longueur limitée qui
identifie logiquement l'utilisateur (ex. : tbensala).
Ensuite, un mot de passe qui est également une chaîne de caractères. Celle-ci ne doit
être connue que par son utilisateur. Il garantit son authentification vis-à-vis du système.
Puis, un identifiant (UID) : comme la manipulation des entiers est de loin plus simple et
plus performante que celle des chaînes de caractères, les implémentations d'UNIX ont
toujours utilisé un entier pour définir de façon unique l'utilisateur. Cependant, ce dernier
reste quand même manipulable à un niveau plus élevé : le login et l'UID sont
équivalents et très souvent interchangeables.
Enfin, un identifiant de groupe GID: la notion de groupe a été introduite essentiellement
pour des raisons de simplification de l'administration. En effet, un administrateur a
souvent besoin de manipuler un ensemble de comptes à la fois. Par exemple, donner le
droit en écriture sur un fichier à plusieurs utilisateurs. Pour cela, la notion de groupe
permet alors d'identifier les droits d'un utilisateur non seulement par son UID, mais
aussi par le ou les groupes auxquels il appartient.
En fait, les droits de l'utilisateur sont équivalents à l'union des droits alloués à l'UID et à
l'ensemble des groupes auxquels il est inscrit.
Ecole Nationale des Sciences de l’Informatique de Tunisie
20
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Toutefois, il est intéressant de préciser qu'avant la version SVR4, un utilisateur ne
pouvait appartenir qu'à un seul groupe à la fois.
Alors que dans les versions récentes, le système calcule au login de l'utilisateur
l'ensemble des droits qui lui sont allouées en énumérant tous les groupes auxquels il
appartient (sachant que la correspondance entre utilisateurs et groupes est précisée dans
un seul fichier).
Par ailleurs, Unix définit par défaut 3 utilisateurs:
- root : c'est le super-utilisateur qui peut créer les comptes et réaliser les fonctions
systèmes de bas niveau.
- uucp : pour la gestion du système UUCP
- deamon : pour la gestion des aspects réseaux (spooler de l'imprimante réseau,
etc.)
Quant à Windows, la notion de multi-utilisateurs n'est apparue qu'avec Windows NT.
En effet, même si au niveau de Windows 95 et 98 on gérait déjà la notion de profile pour
définir différents comptes sur la même machine, cette gestion ne dépassait pas la
possibilité d'avoir différents espaces de travail pour chacun, sans se préoccuper - de
quelque façon que ce soit - de tout ce qui est sécurité : tout le monde a tous les droits.
Avec l’avènement de la technologie NT, Windows permet désormais de gérer les
utilisateurs et la sécurité grâce à trois notions : utilisateur (user), groupe (group) et
domaine (domain). Un utilisateur est alors défini avec son login, son mot de passe mais
aussi son domaine.
Un domaine est un ensemble d'utilisateurs et de groupes de ces utilisateurs. Le système
gère un ensemble de domaines totalement indépendants les un des autres et ne
possédant, chacun, aucune connaissance des autres domaines sauf si explicitement
précisé. Les modèles de domaines peuvent être influencés par de nombreux paramètres
(géographiques, limitation matérielle, sécurité ou toute autre politique de gestion).
Ainsi, un domaine est une autre façon de regrouper les utilisateurs plus générale que les
groupes car un domaine peut aussi contenir des groupes à la manière d’Unix.
De plus, Windows NT propose deux types d’interactions entre domaines :
- one-way Trust-Relationship : dans cette relation (non symétrique) les utilisateurs
d’un domaine A peuvent également être reconnus par un domaine B mais pas le
contraire.
- two-way Trust-Relationship : dans ce cas, c’est une relation symétrique qui
permet à l’un ou l’autre des deux domaines, de reconnaître les utilisateurs de
son homologue.
Ajoutons à cela que, tout domaine contient par défaut deux utilisateurs et un groupe:
Ecole Nationale des Sciences de l’Informatique de Tunisie
21
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
- Adm account: le compte de l'administrateur. C’est celui qui se charge de la
création et maintenance des comptes utilisateurs et groupes du domaine en
question, tout en se voyant accorder tous les privilèges (sur ce domaine).
- guest: le compte de l’utilisateur externe qui n'a donc pas à s'identifier par un
mot de passe.
- Domain Users Group: le groupe qui contient tous les utilisateurs du domaine. Ce
groupe est par ailleurs considéré comme le groupe par défaut ou groupe
primaire de tout utilisateur du domaine. Cette nouvelle notion est requise pour
l’interopérabilité avec les utilisateurs Macintosh ou toute application POSIX.
6.2 Organisation des ressources (Fichiers…)
Bien qu’on puisse imaginer plusieurs modèles de présentation, d’organisation et de
gestion des ressources (modèle plan : pas de répertoires, modèle hiérarchique :
répertoires et sous répertoires, modèle graphe…), le modèle hiérarchique c’est très
souvent imposé pour sa simplicité et sa souplesse à la fois.
Ainsi, aussi bien Unix que Windows gèrent leurs ressources comme une arborescence
dont les nœuds sont des conteneurs (répertoires, directory) - créés pour des besoins
d’organisation - et les feuilles sont des fichiers encapsulant les informations réelles de
l’utilisateur.
De plus, la notion de lien symbolique a été introduite dans l’un et l’autre pour permettre
une plus grande extensibilité et généralité. Cela rapproche évidemment le modèle
hiérarchique du modèle graphe.
6.3 Modèles de sécurité
Un utilisateur chez lui, muni d’un PC ne se pose même pas la question «c’est quoi un
utilisateur ? » et «comment protéger mes documents confidentiels ? » puisqu’il connaît
très bien les personnes éventuelles qui pourrait avoir accès à ses documents.
Mais malheureusement, cela ne peut être aussi simple dans un réseau regroupant plus de
10 personnes, parfois même des milliers.
La sécurisation des ressources a donc été traitée par plusieurs systèmes d’exploitations
dont Unix et Windows NT.
Par ailleurs, toutes les techniques citées dans la littérature et traitant de la sécurité et de
la protection des ressources font une claire distinction entre la politique suivie (protéger
quoi et de qui?) et les mécanismes (comment le système applique-t-il cette politique).
On s’intéressera essentiellement au deuxième point.
Mais, tout d’abord, présentons quelques types de sécurité.
Ecole Nationale des Sciences de l’Informatique de Tunisie
22
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
6.3.1
INRIA
Types de sécurité
On définit plusieurs types de sécurité :
 confidentialité : protéger l’information de peur qu’elle ne soit lue par une personne
n’ayant pas été explicitement autorisée par le propriétaire. Cela inclut également les
informations non importantes en soit mais qui peuvent servir à déchiffrer d’autres
documents plus confidentiels.
 intégrité : ne pas permettre toute altération (modification et/ou destruction) de toute
information tant qu’on n’en a pas le droit.
 disponibilité : toute information doit toujours être disponible à l’utilisateur qui a le
droit d’en avoir usage. Il est souvent plus contraignant d’avoir des informations non
accessibles que de ne pas en avoir du tout.
 consistance : veiller à ce que le système réagisse comme prévu, aussi bien pour les
utilisateurs autorisés que pour les autres.
 isolation : régulation de l’accès au système. Il s’agit de rendre compte de qui quand
et comment un accès frauduleux a pu avoir lieu.
 audit : se rendre compte des erreurs ou actes malsains commis par les utilisateurs. [6]
6.3.2
Mécanismes de protections
Dans certains systèmes, la protection se fait grâce à un programme appelé reference
monitor. A chaque fois qu’on tente d’accéder à une ressource potentielle protégée, c’est
à ce moniteur que le système s’adresse pour vérifier la légitimité d’une telle opération.
En fait, de façon abstraite, ce moniteur gère ce qu’on appelle des domaines de
protections dont chacun est un ensemble de couples (objet, droit) ; chaque couple
définissant un objet (une ressource) et un sous-ensemble d’opérations permises.
Dans ce contexte, un objet (qui ne doit pas être interprété au sens de la programmation
objet) peut être matériel (CPU, segment de mémoire, imprimante…) ou logiciel
(processus, fichier, sémaphore…) alors que les droits représentent les permissions sur
cet objet.
Domaine1
Fichier 1 [R]
Fichier 2[RW]
Fichier 3[W]
Domaine2
Fichier 3[R]
Fichier 4[RWX]
Fichier 5[RW]
Domaine3
Imprimante[W]
Fichier6[RWX]
Imprimante 2[W]
Fig 4 : Domaines de protections
Ecole Nationale des Sciences de l’Informatique de Tunisie
23
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Il existe différentes approches pour gérer une telle notion. L’information pourrait par
exemple être stockée sous forme de matrice dont les lignes sont les domaines et les
colonnes sont les ressources.
Domaine
1
2
3
Fichier1
R
Fichier2
RW
Fichier3
Fichier4
Fichier5
R
RWX
RW
Fichier6
Imprimante1
Imp2
RWX
W
W
W
Matrice des permissions
Mais, pratiquement, utiliser une telle matrice est coûteux en mémoire d’autant plus que
la plupart de ses cases seront vides. On a alors pensé à découper la matrice en lignes ou
en colonnes.
 Découpage en lignes : Capabilities ou C-List
Dans un pareil cas, on associe à chaque processus (ou objet) la liste des objets qu’il peut
accéder, tout en indiquant les permissions qui lui sont permises sur chacun d’eux.
0
1
2
3
Type
Fichier
Fichier
Fichier
Pointeur
Droits
Objets
R
Pointeur vers Fichier3
RWX
Pointeur vers Fichier4
RW
Pointeur vers Fichier5
W
Pointeur vers l’imprimante
C-List du domaine 2
 Découpages en colonne : Access Control List ou ACL
Dans ce second cas, on associe à chaque objet, et de façon ordonnée, une liste de tous
les domaines qui peuvent l’accéder et les permissions qui leur sont accordées.
Ainsi, en supposant qu’on a 4 utilisateurs Ali, Selim, Wassim et Razi, appartenant,
respectivement, aux groupes system, staff, student et student, on pourrait alors imaginer
une structure des ACL comme :
-
Fichier0 : (Ali,*,RWX)
Fichier1 : (Ali,system,RWX)
Fichier2 : (Ali,*,RW-),(Selim,staff,RW-),(Razi,*,RW-)
Fichier3 : (*,student,R--)
Fichier4 : (Wassim,*,---),(*,student,R--)
Chaque entrée ACL est notée entre parenthèses en spécifiant, dans l’ordre, l’utilisateur,
le groupe et les droits qui leurs sont accordés.
Par exemple, pour Fichier4 on indique que l’utilisateur nommé Wassim n’a aucun
droit, les autres utilisateurs du groupe student ayant le droit de lire ce fichier.
Ecole Nationale des Sciences de l’Informatique de Tunisie
24
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Par ailleurs, il est intéressant de remarque qu’Unix et Windows NT ont opté pour ce
type de protections alors que Java (les spécifications de la sécurité) gère des C-lists.
6.3.3
Les ACL Unix
Pour des raisons de simplification, de performances et de stockage, l’implémentation
des ACL dans Unix est sous forme de 9 bits au niveau du descripteur de chaque fichier :
3 pour le propriétaire, 3 pour le groupe et le reste pour tous les autres utilisateurs.
Chaque 3 bits correspondent aux fameux RWX : R étant pour la lecture (Read), W pour
l’écriture (Write) et X pour l’exécution.
Ces mêmes bits sont également utilisés au niveau des répertoires pour donner les droits
pour lister le contenu (R), changer ce contenu (W) et y accéder (X).
R
Propriétaire
W
X
Groupe du propriétaire
R
W
X
R
Tous les autres
X
X
Bien que ce soit beaucoup plus restrictif que le concept général des ACL, on a souvent
trouvé cela suffisant.
6.3.4
Les ACL Windows NT
Windows NT, gère, pour chaque ressource, un descripteur : le Security Descriptor.
Security Descriptor
Owner (propriétaire)
Primary Group (groupe primaire)
Discretionary ACL (pour le propriétaire)
ACE (Access Control Entry)
ACE
ACE
System ACL (pour les autres)
ACE
ACE
ACE
Fig 5 : Structure du Security Descriptor (Win NT)
Ce descripteur gère une ACL pour le propriétaire lui-même (qui voudrait par exemple
s’interdire de détruire un fichier dans une fausse manœuvre) et une ACL pour les autres
utilisateurs.
Ecole Nationale des Sciences de l’Informatique de Tunisie
25
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Un utilisateur pourra avoir accès à la ressource si et seulement s’il vérifie les deux
conditions :
- l’utilisateur ou l’un des groupes auxquels il appartient à la permission de le
faire par la System ACL.
- ni l’utilisateur ni aucun des groupes auxquels il appartient n’ont interdiction de
le faire par la System ACL.
6.3.5
Les C-lists Java
La machine virtuelle Java utilise un objet nomme AccessController (équivalant
au reference monitor) pour gérer la protection de l’accès à des ressources critiques
(essentiellement les ressources systèmes comme les fichiers, ou les ports des
Sockets…).
Cet objet réalise la vérification à partir d’une suite de C-lists décrites le plus souvent
dans un fichier du répertoire principal de l’utilisateur (HOME DIRECTORY). Ce
fichier porte le nom par défaut de « .java.policy ».
grant {
Permission java.io.FilePermission(«*.dat », « read ») ;
};
grant codeBase « http://www.ensi.edu.tn» signedBy « Ali»{
Permission java.net.SocketPermission («localHost :1024- », « listen») ;
Permission java.io.FilePermission(«- », « read,write ») ;
};
Fig 6 : Exemple de fichier .java.policy
Chaque C-list est donnée par un «grant…{…} ; ».
On y définit alors
- le codeBase (« codeBase ») qui désigne la localisation (la machine ou le soussystème de fichiers) du code source (les fichiers.class) concerné par ces
permissions.
- le signataire («signedBy») qui est celui qui certifie l’authenticité de ce code.
- et les permissions elles-mêmes («permission … ; »).
Chaque permission est donnée par la classe Java correspondante et deux
paramètres qui sont la cible (sur laquelle on définit les permissions) et les
actions sur cette cible (ce qu’elle peut faire).
Ainsi, la première C-list de la figure 6 correspond au premier « grant » qui accorde
anonymement le droit à toutes les classes Java exécutées sur la machine locale de lire
les fichiers d’extension « .dat »
La seconde C-list, un peu plus riche, accorde à toute classe Java provenant de l’URL
«http://www.ensi.edu.tn» et qui a été signée par «Ali» de lire et d’écrire sur toute
l’arborescence du système de fichiers (ce qui est précisé par «-») et de pouvoir utiliser
des Sockets en écoute du port 1024 de la machine locale.
Ecole Nationale des Sciences de l’Informatique de Tunisie
26
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
En fait, l’AccessController construit à partir de ce fichier une liste de ces C-lists en
regroupant, au niveau de chaque entrée, les permissions par classes Java.
Au niveau de l’implémentation, une Permission prévoit une méthode dont la signature
est :
public boolean implies(Permission otherPermission) ;
qui retourne un booléen VRAI lorsque cette permission implique celle passée en
paramètre.
De façon simplifiée, « la permission p1 implique la permission p2 » signifie que tout
utilisateur qui se voit allouer p1 se voit par la même allouer p2, mais pas
nécessairement le contraire. »
Par exemple la permission FilePermission(« *.dat », « read ») implique
FilePermission(« monfichier.dat », « read »)
mais
n’implique
FilePermission(« monFichier.dat », «write»).
bien
pas
C’est sur cette méthode que repose tout le mécanisme de la vérification des protections.
En fait, lorsqu’un utilisateur U veut, par exemple, lire un fichier F, le système construit
un objet permission Preq décrivant les permissions requises par cet utilisateur et le
passe à AccessController qui vérifie alors si les permissions déclarées Pdec
(éventuellement dans le fichier.java.policy) impliquent bien la première.
L’opération se déroulera avec succès si et seulement si Pdec.implies(Preq)==VRAI.
Dans le cas contraire une Exception Java sera générée.
Dans la suite, nous abordons le problème de la distribution des ressources sur Internet.
6.4 Distribution sur Internet
Quand on parle de distribution, on ne doit pas perdre de vue deux points essentiels :
- d’abord, le système (au sens des serveurs à développer, Applets, pages
HTML…) devra évoluer sur Internet.
- ensuite, tout le développement doit se faire à un niveau très indépendant de la
ou les plates-formes d’exécution (en Java).
C’est la raison pour laquelle on ne peut pas compter sur NIS (les pages jaunes pour la
distribution de la gestion des utilisateurs), NFS ou NTFS (pour la distribution des
systèmes de fichiers) ou encore POSIX qui sont purement liés à leurs systèmes
d’exploitation (Unix, Windows…).
Inévitablement, le modèle Client/Serveur s’impose avec 6 techniques concurrentes :
6.4.1
Les Sockets
Le bas niveau des Sockets leur confère, ipso facto, l’avantage de la performance.
Ecole Nationale des Sciences de l’Informatique de Tunisie
27
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
6.4.2
HTTP/CGI
Commun Gateway Interface - ou plus couramment CGI - est le modèle pris en charge
par la quasi-totalité des serveurs WEB permettant de répondre au niveau du serveur à
des requêtes introduites au niveau du client (dans des formulaires HTML par exemple).
Ce sont en fait des programmes qui seront exécutés sur ce serveur, pour chaque
nouvelle requête d’un client, qui peut être n’importe où sur le WEB.
6.4.3
Les Servlets Java
Comme les CGI, Les Servlets Java permettent de répondre à des requêtes d’un client sur
le WEB en générant dynamiquement les pages HTML (au niveau du serveur) qui
prennent en considération les informations précisées par le client (éventuellement dans
un formulaire).
La seule différence consiste en le fait qu’une Servlet est un objet Java qui peut très bien
coexister avec d’autres objets Java (éventuellement d’autres Servlets) au sein de la
même machine virtuelle et donc du même processus, améliorant alors nettement les
performances.
6.4.4
DCOM
Distributed Component Object Model (DCOM) est la solution proposée par Microsoft
pour gérer de façon distribuée des Objets. Ainsi, Windows NT utilise exclusivement
DCOM pour gérer la distribution des informations sur le réseau et entre les applications
(ActiveX est DCOM).
6.4.5
CORBA
Commun Object Request Broker Architecture (CORBA) est sans doute, le projet
middleware le plus important et le plus ambitieux permettant de faire interagir des
objets issus de différents langages de programmation, indépendamment des outils
utilisés et des systèmes d’exploitation et des réseaux.
CORBA utilise en fait un langage déclaratif : IDL pour la spécification de chaque objet
(indépendamment de son implémentation).
Java propose une API incluse dans la version standard du SDK 1.2 pour le support de
CORBA.
6.4.6
RMI
Sun Micro Systems propose RMI (Remote Method Invocation) comme mécanisme
purement Java pour distribuer des objets (Java) entre plusieurs machines virtuelles
éventuellement distribuées physiquement sur un réseau.
Dans son concept de base, RMI est plus proche du RPC (Remote Procedure Call) que
de CORBA ou DCOM. La différence essentielle (qui n’est pas négligeable) est que
l’appel distant des procédures (les méthodes de l’objet) ne se fait pas sur du code
statique mais sur des instances d’objets.
En fait, ces instances sont maintenues accessibles grâce à un mécanisme
d’enregistrement sur un serveur d’enregistrement et de deux autres instances crées
Ecole Nationale des Sciences de l’Informatique de Tunisie
28
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
automatiquement par ce serveur : l’une à l’emplacement même de l’objet distant qu’on
veut accéder, notée SKELETON ; l’autre au niveau du client appelant et notée STUB.
Il est à remarquer que le STUB possède toutes les méthodes de l’objet en question.
Pour utiliser cet objet distant, celui ci doit au préalable être inscrit au serveur
d’enregistrement sous un identificateur (nom) que le client doit connaître. Moyennant
cet identificateur, le client récupère le STUB correspondant qu’il manipule exactement
comme si c’était l’objet lui-même(car le STUB et l’objet ont les mêmes méthodes).
Par ailleurs, le RMI standard ne gère pas la persistance des objets. Ce manque dégrade
considérablement les performances et les capacités du serveur d’enregistrement qui ne
peut pas gérer beaucoup d’objets à la fois car ils doivent tous être en mémoire.
Pour combler ce manque, Java, dès le JDK 1.2, propose le RMI Activation. Son
principe est d’enregistrer non plus les objets eux-mêmes, mais des objets beaucoup plus
légers (des descripteurs) capables de charger la version persistante de l’objet
correspondant lorsqu’un client demande explicitement l’utilisation de cet objet.
6.4.7
Comparaison entre les différentes techniques
Le tableau qui suit récapitule succinctement un comparatif entre les techniques citées cidessus [7]:
CORBA
Aspect/technique
****
Niveau d’abstraction
****
Intégration de Java
****
Indépendance du Sys. Exp.
****
Implémentation 100% Java
****
Support des paramètres typés
***
Simplicité de configuration
****
Invocation de méthodes distrib.
****
Mémorisation des appels
Support
des
métadata
et
****
découverte dynamique
****
Appel dynamique
Performance (remote pings) en ms ***(3,5)
****
Sécurité réseau
****
Transactions réseau
****
Référence persistantes d’objets
****
Nomenclature en URL
Invocation d’objets par plusieurs
****
langages de programmation
Protocole réseau indépendant du
****
Langage de programmation
****
Standard ouvert
DCOM
RMI
HTTP/CGI
Servlet
Sockets
****
****
**
*
****
***
***
***
****
****
****
****
****
***
***
***
**
**
****
**
*
***
**
**
****
****
*
***
*
**
****
****
*
***
**
**
***
**
****
***(3,8)
****
***
*
**
*
***(3,3)
***
(827,9)
***
*(55,6)
***
****(2,1)
***
****
**
****
****
***
Ecole Nationale des Sciences de l’Informatique de Tunisie
*
****
***
****
****
****
****
**
**
**
****
****
29
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
On remarque, alors, que CORBA est bien celui qui est le moins spécifique et le plus
complet. DCOM demeure également un concurrent redoutable mais il garde
l’inconvénient d’être lié à Windows. Quant à RMI, il présente plusieurs avantages tant
qu’on reste purement Java. Les CGI, de leurs coté, présentent un handicap très net au
niveau des performances. Par contre, les Sockets sont très performantes mais trop bas
niveau. Enfin, Les Servlets donnent des résultats convainquant mais restent liées au
domaine particulier de répondre aux requêtes HTTP(tout comme les CGI d’ailleurs).
Ecole Nationale des Sciences de l’Informatique de Tunisie
30
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
7 Spécifications
7.1 Modélisation du problème :
La problématique citée au paragraphe 5 peut être modélisée par :
Soit  le système but à atteindre (ou solution).
Soit l’ensemble ={ 1, 2 … n } des différents sites géographiquement distants et qui
proposent de servir les ressources de .
Chaque site i propose un ensemble de ressources i={ i1, i2,…. iri } (des bases de
connaissances, des moteurs d’inférences….).
On note = i l’ensemble de toutes les ressources.
Soit l’ensemble  ={1,… m }des utilisateurs de  (éventuellement sur aucun des
sites de  ).
Chaque utilisateur  veut et / ou peut accéder à un sous ensemble  des toutes les
ressources pour réaliser un ensemble d’opérations parmi:
-
créer une nouvelle ressource (base de connaissances)
visualiser (lire) une ressource
modifier une ressource
détruire une ressource
appliquer des opérations plus complexes sur une ressource (exécuter un moteur
d’inférence sur une base de connaissance de pilotage de programmes)
Pour tout ij correspond au moins un utilisateur  qui est son propriétaire ou plus
généralement qui le supervise.
L’ensemble des propriétaires p est un sous-ensemble de .
7.2 Spécification des besoins
Compte tenu de cette modélisation, notre travail revient à :
 Concevoir un modèle de gestion des utilisateurs :
Il s'agit de définir le contexte dans lequel un utilisateur réel peut utiliser le système.
Pour cela, il est essentiel de préciser non seulement la façon dont il est perçu par ce
système, mais aussi les étapes et les mécanismes requis pour que ce dernier puisse le
reconnaître.
Ecole Nationale des Sciences de l’Informatique de Tunisie
31
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Il va sans dire qu'il faut également préciser toute interaction de cet utilisateur avec
les différents composants évoluant dans le système comme par exemples les autres
utilisateurs et surtout les ressources (donc définir p).
 Concevoir un modèle de gestion des ressources :
Nous devons, pour cela, proposer une architecture virtuelle permettant d'avoir accès
à toute ressource  de .
Cette architecture devra prendre en considération deux points essentiels :
- l'accès à toute ressource doit se faire de façon identique indépendamment de la
localisation physique de cette ressource, en l’occurrence indépendamment du
site i qui la sert.
- l'ajout des ressources relatives à un nouveau site voulant s’intégrer au système
doit être le plus simple possible. Ainsi, on ne tolère aucun arrêt ni aucun
"redémarrage" du système sous prétexte qu'on désire intégrer un nouveau site
ou retrancher un site déjà existant.
 Concevoir un modèle de Sécurité :
Cela est d'autant plus essentiel car Internet n'est pas sécurisé.
Nous devons alors proposer un modèle qui possède les caractéristiques suivantes :
- efficacité : il doit permettre de sécuriser les ressources à un niveau de
granularité le plus fin possible.
Ainsi, il ne faut pas se contenter de définir des protections uniquement au
niveau de la ressource comme entité mais, permettre par exemple de protéger
des sous-parties de la ressources de façon indépendante les unes des autres.
- flexibilité : il doit permettre de s'appliquer à toute ressource de n'importe quel
type.
- fiabilité : il doit être conforme à ses spécifications.
- évolutivité et maintenabilié: il est essentiel de prévoir des mécanismes simples
permettant de faire évoluer le système sans trop de changements.
 En se basant sur les trois modèles cités ci-dessus, développer le système  qui
permet à un utilisateur, à travers Internet d'accéder et de manipuler toutes les
ressources abstraction faite du nombre et de la localisation physique des différents
sites.
Ecole Nationale des Sciences de l’Informatique de Tunisie
32
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Navigateur
Ou autre
application
Gestion de la sécurité
Gestion des ressources
Site 1
Gestion des utilisateurs
Site N
Fig 5 : Architecture générale du système à développer
7.3 Contraintes logicielles/matérielles:
7.3.1
Langages et environnements de programmations:
Tout le développement devra se faire en Java. Cela assure cohérence et
portabilité. De plus c’est le langage parfaitement adapté à Internet.
7.3.2
Environnent de développement :
Le développement se déroulera sous Solaris 2.5 muni de GNU xemacs (éditeur &
environnement de programmation), Java (JDK 1.2.2) et Netscape 4.73.
7.3.3
Environnement d'exécution :
Tous les programmes à développer s’exécuteront sur une machine (CARINAE)
localisée à Sophia sous Solaris 2.5.
Ecole Nationale des Sciences de l’Informatique de Tunisie
33
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8 Conception
Avec un langage purement objet, comme Java, la conception est, elle aussi,
naturellement objet.
A chacune des notions introduites correspond une interface (au sens Java) qui la
matérialise et une ou plusieurs implémentations de ces interfaces. Au niveau de la
conception c’est toujours des interfaces dont on parlera (indépendamment de
l’implémentation).
Ces
interfaces
seront
précisées
sous
le
format
« (LeNomDeLInterface) » pour chaque notion nouvellement introduite.
Dans les paragraphes suivants, je présenterai d’abord l’architecture générale de la
solution proposée et préciserai la répartition des tâches entres les différents composants
du système.
Ensuite, j’aborderai plus en détail le modèle de gestion des utilisateurs et celui des
ressources pour lesquels j’ai opté.
Puis, je m’intéresserai à la façon d’identifier les objets du système, pour pouvoir les
utiliser.
Le paragraphe suivant traitera de la sécurité et du modèle de protection retenu, avant
d’entamer le problème de la distribution des différents objets du système.
Un avant dernier paragraphe fera le point sur la migration de ces objets.
Finalement le modèle objet général sera explicité.
8.1 Architecture Générale
L’architecture générale proposée est explicitée dans la figure suivante :
Ecole Nationale des Sciences de l’Informatique de Tunisie
34
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
Navigateur (Pages HTML)
INRIA
Application
Java
Navigateur
(Applets)
Serveur HTTP
Client sur Servlet
Client sur Applet
Client sur
Application
Maître
Gestion des utilisateurs, gestion (empirique) des ressources
Esclave 1
(sur le Site 1)
Gestion des ressources locales
Esclave 2
(sur le Site 2)
Gestion des ressources locales
Esclave N
(sur le Site
N)
Gestion des ressources locales
Une ressource R
Protections
informations
Fig 7 : Architecture générale
On peut alors remarquer que :
1. Cette architecture permet l’utilisation du système, via Internet, que l’on soit sur
navigateur ou simplement à travers une application Java.
Dans le cas d’un navigateur, il a été prévu aussi bien l’accès par utilisation d’Applets
que celui par des pages HTML : la communication avec le système se fera alors,
essentiellement, moyennant les Servlets Java.
Ecole Nationale des Sciences de l’Informatique de Tunisie
35
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
2. Cette architecture est une architecture Multi-niveaux (3-4 niveaux) :
On dégage 3 niveaux principaux correspondants aux trois composants de base de  :
Esclave, Maître et Client:
- les Esclaves :
Un Esclave est la partie du système responsable de gérer toutes les
ressources servies par un des différents sites composants ce système. Il s’en
suit alors qu’à chaque site i correspond un Esclave.
Tous les Esclaves sont intimement liés à un seul Maître.
- le Maître :
Celui-ci est sans doute le composant le plus important du système car il
propose une vue globale de toutes les ressources (de tous les Esclaves)
réunies. Il a également pour mission de gérer les utilisateurs.
En ce sens, Toute requête pour une utilisation d’un quelconque objet du
système (ressources ou utilisateurs) doit essentiellement passer par le
Maître qui se charge toujours de retrouver l’information et de répondre à la
requête.
De plus, le choix de charger le Maître de la gestion de tous les utilisateurs
et non pas, par exemple, de définir au niveau de chaque Esclave un
ensemble d’utilisateurs, découle du fait qu’un utilisateur est susceptible
d’avoir accès à toute ressource du système et par suite c’est une notion
totalement indépendante de la localisation des ressources.
- le Client :
C’est le système vu localement par un utilisateur distant. Ce niveau
d’abstraction a été ajouté pour que l’utilisateur agisse identiquement sur une
application ou sur un navigateur sans tenir compte du fait que les objets
(ressources) qu’il va utiliser sont distants.
Les fonctions principales de ce composant reviennent donc à :
- se charger de la communication avec le Maître rendant transparente
l’utilisation des objets distants.
- masquer les particularités de l’environnement de l’utilisateur.
Il est à remarquer qu’un Client n’a même pas à connaître l’existence des
Esclaves : il ne communique qu’avec le Maître.
3. Pour une utilisation du système à partir de simples pages HTML, un quatrième
niveau est rajouté : celui des Servlets sur le Serveur HTTP.
En fait, partant d’une requête (grâce à un formulaire HTML par exemple), les
Servlets – au niveau de ce serveur – utilisent un Client pour communiquer avec le
système et répondre à la requête en générant, dynamiquement, la page HTML
résultat.
4. Les protections (sécurité) se font au niveau de la ressource de façon décentralisée.
Ecole Nationale des Sciences de l’Informatique de Tunisie
36
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8.2 Gestion des utilisateurs
Un système distribué étant inévitablement plus complexe à administrer pour des
raisons géographiques (le système est géographiquement distribué), de compétences
(nécessitant plusieurs compétences à la fois), de sécurité (il est plus sûr de partager les
privilèges), le choix de concevoir un modèle hiérarchique pour la gestion des
utilisateurs m’a semblé le plus adapté. Ainsi, toute administration peut à tout moment
être subdivisées entre plusieurs administrateurs à chacun sera affectée la sous tâche de
gérer une sous arborescence de la hiérarchie.
Pour cela, le système gère des domaines (DdomainInterface) dont chacun peut très
bien se subdiviser en sous-domaines (d’où la notion de hiérarchie).
Chacun de ces domaines regroupe, outre ses sous-domaines, un ensemble d’utilisateurs
(DuserInterface) et un ensemble de groupes (DgroupInterface) d’utilisateurs (non
forcément de ce domaine).
8.2.1
Les Domaines
La notion de domaine permet, entre autre, de diminuer la charge d’un administrateur en
limitant son champ d’action. En effet, parmi les utilisateurs directs d’un domaine (c’est
à dire n’appartenant pas à ses sous-domaines), on définit un utilisateur particulier appelé
superviseur qui aura pour tâche de l’administrer et par conséquent bénéficiera de tous
les droits sur ce domaine et seulement ce domaine (ces sous-domaines inclus).
En particulier, le superviseur est responsable de l’ouverture et de la fermeture de
comptes clients c’est à dire de l’ajout ou du retrait d’utilisateurs à ce domaine. Il est
également responsable de la création et de la destruction des groupes du domaine et
surtout de celles des sous-domaines éventuels et de l’attribution de leurs superviseurs.
De ce même fait, un domaine contient zéro ou plusieurs sous-domaines mais encore, un
ou plusieurs utilisateurs (dont le superviseur) et zéro ou plusieurs groupes.
Domaine
Utilisateurs
dont le
superviseur
Groupes
d’utilisateurs
Sous
domaines
Sous Domaine
Groupes
d’utilisateurs
Utilisateurs
dont le
superviseur
Sous
domaines
Sous Domaine
Groupes
d’utilisateurs
Utilisateurs
dont le
superviseur
Sous
domaines
Fig 8 : structure et hiérarchie des domaines
Ecole Nationale des Sciences de l’Informatique de Tunisie
37
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8.2.2
Les utilisateurs
Pour des besoins d’authentification, à chaque utilisateur réel on associe un compte
utilisateur (théoriquement, on peut associer plus d’un compte utilisateur à un seul
utilisateur physique mais on remarquera que grâce à la notion de groupes in n’en aura
nullement besoin). On parlera dans toute la suite d’« utilisateur » pour signifier le
compte utilisateur relatif à un utilisateur physique.
Un utilisateur est propre à un et un seul domaine. Il est alors défini non seulement par
son nom (login) et son mot de passe, mais aussi par le domaine auquel il appartient.
Ainsi l’existence même de l’utilisateur se fonde sur l’existence du domaine
correspondant. Conceptuellement, un utilisateur n’existe plus dès que son domaine
parent est supprimé par l’administrateur. Mais pour des raisons de convenances, cet
utilisateur migrera vers le domaine parent de l’un de ses autres groupes (tant qu’il est
inscrit à un groupe) lors de la destruction de son domaine parent. Il faut tout de même
préciser qu’au niveau du système c’est d’un nouvel utilisateur qu’il s’agit (il est
forcement différent de l’ancien vu qu’ils n’appartiennent nécessairement pas au même
domaine).
8.2.3
Les groupes
La notion de groupe a été introduite principalement pour répondre à deux besoins :
D’une part, appliquer les mécanismes de protection des ressources sur tout un ensemble
d’utilisateurs à la fois suivant un certain critère qui ne dépend forcément pas de
l’appartenance physique à un des domaines existants. C’est le cas, par exemple, si on
veut protéger momentanément une ressource en inhibant sa modification de la part des
utilisateurs qui y ont toujours eu droit.
D’autre part, trouver un mécanisme pour l’interaction entres les différents domaines (un
peu comme les one-way Trust-Relationship et two-way Trust-Relationship de Windows
NT).
Dans ce contexte, un groupe est présenté comme étant un ensemble d’utilisateurs de
tout le système (et pas seulement ceux du domaine parent à ce groupe) définissant un
profil de sécurité pour certaines ressources du domaine (i.e. des utilisateurs du
domaine).
Ainsi, un domaine est un groupement d’ordre logique sur les utilisateurs alors qu’un
groupe est un groupement d’ordre logique sur les droits des utilisateurs.
Exemples :
 le domaine ProgramSupervison est un domaine qui regroupe tous les
utilisateurs qui s’intéressent au pilotage de programme.
 les domaines FranceDomain et TunisaDomain sont deux domaines qui
regroupent chacun les utilisateurs du pays en question.
Ecole Nationale des Sciences de l’Informatique de Tunisie
38
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
 par contre, le groupe ProgramSupervison.readers est le groupe de tous les
utilisateurs (qui n’appartiennent pas forcement à ProgramSupervison) qui ont
le droit de lire les ressources relatives au domaine ProgramSupervison (donc
relatives aux utilisateurs de ce domaine).
 et le groupe FranceDomain.previlegiedUsers est le groupe de tous les
utilisateurs (qui n’appartiennent pas forcement à FranceDomain) qui sont
privilégiés au niveau du domaine FranceDomain et peuvent alors avoir accès
à des ressources non publiques.
Notons enfin, que pour donner encore plus de souplesse au niveau de l’administration,
le superviseur du domaine parent à un groupe peut déléguer la tâche d’inscrire ou de
retirer les utilisateurs de ce groupe à l’un des autres utilisateurs directs du même
domaine membre (nécessairement) du groupe. Cet utilisateur sera baptisé le superviseur
du groupe.
8.2.4
Les domaines, utilisateurs et groupes spéciaux
Le système comprend également quelques domaines, utilisateurs et groupes spéciaux
pour permettre une utilisation plus souple.
Ainsi, la notion de super utilisateur a été introduite pour caractériser un utilisateur qui
aura tous les droits sur tout et qui sera le dernier recours pour les tâches délicates où
nécessitant plusieurs qualités (permissions) à la fois.
Et pour rester cohérent, cet utilisateur appartient à un domaine spécial appelé super
domaine qui englobe tous les autres domaines. ainsi, le fait que le super utilisateur ait
tous les droits devient légitime (grâce à la récursion au sein du graphe des domaines).
Par ailleurs, le super domaine contient également un autre utilisateur et deux groupes qui
sont :
 l’invité (guest): c’est l’utilisateur par défaut . Il est équivalent au
ANONYMOUS du FTP. Son mot de passe est anonymous. Il n’a aucun droit
sur aucune ressource sauf si explicitement précisé par le propriétaire de la
ressource. Il faut donc être très vigilant en attribuant un quelconque privilège
à cet utilisateur. Pour des raisons de sécurité, les privilèges donnés au guest ne
sont pas cumulés avec les privilèges attribués à un autre utilisateur. Ainsi, si
un droit X est donné à l’invité, ce droit n’est pas attribué ipso facto à tous les
utilisateurs.
 Le super groupe: c’est le groupe de tous les superviseurs des domaines du
système. Il a été créé pour des besoins de simplification de l’administration.
 Le groupe par défaut (nogroup): c’est le groupe de tous les utilisateurs inscrit
aux systèmes, l’invité n’en faisant pas partie. Il a également été créé pour des
besoins de simplification de l’administration.
Ecole Nationale des Sciences de l’Informatique de Tunisie
39
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
La structure globale du système de gestion des utilisateurs devient donc la suivante :
superdomain
Groupes dont
supergroup &
nogroup
Utilisateurs dont
superuser & guest
Sous
domaines
Sous Domaine
Utilisateurs
dont le
superviseur
Groupes
d’utilisateurs
Sous Domaine
Utilisateurs
dont le
superviseur
Groupes
d’utilisateurs
Sous
domaines
Sous
domaines
Fig 9 : modèle de gestion des utilisateurs
8.2.5
Comparaison avec le modèle d’Unix
Le modèle qu’on propose est une généralisation du modèle d’Unix : chaque domaine est
pratiquement un système de gestion d’utilisateurs Unix en gardant la notion de
superviseur (root) et de groupes.
A noter également que, comme les versions ultérieures à V5R4, il est possible à un
utilisateur d’appartenir à zéro ou plusieurs groupes à la fois.
En outre, grâce à la notion de hiérarchie des domaines, de nouvelles fonctionnalités sont
possibles, comme par exemple créer des groupes contenant des utilisateurs hétérogènes
(de plusieurs domaines) .
Cela permet également de ne plus avoir à définir un utilisateur plus d’une fois ni avoir à
ajouter une couche supplémentaire (comme NIS par exemple) pour faire interagir
plusieurs systèmes et gérer de façon centralisée les comptes utilisateurs.
Ecole Nationale des Sciences de l’Informatique de Tunisie
40
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8.2.6
Comparaison avec le modèle de Windows NT
Ce modèle est également une généralisation du modèle présenté par Windows NT en
gardant (avec quelques modifications) les notions de domaines, d’utilisateurs et de
groupes.
De plus, et puisque qu’ici un groupe définit un profil de sécurité qui peut correspondre à
n’importe quel utilisateur de n’importe quel domaine et donc peut regrouper des
utilisateurs de tout domaine, l’interaction entre domaines est encore plus amplifiée tout
en permettant de réaliser plus souplement des one-way Trust-Relationship ou two-way
Trust-Relationship.
8.3 Organisation des ressources
Comme la plupart des systèmes de fichiers qui sont cités dans la littérature sont
hiérarchiques, et comme le modèle hiérarchique nous permet de rester cohérent avec le
modèle de gestion des utilisateurs cité ci-dessus, et vu la simplicité et la souplesse
qu’apporte ce modèle, on a encore une fois opté pour un modèle hiérarchique pour
l’organisation des ressources.
Mais, étant dans un environnement purement objet, il faut quand même définir ce qu’est
une ressource et quels sont les différents types de ressources.
Nous définirons une ressource comme étant tout objet (en tant qu’entité
informationnelle) susceptible d’être requis par un utilisateur du système .
A la limite, tout objet du système (i.e. que le système peut gérer de façon distribuée)
même un utilisateur, domaine, ou groupe est considéré comme ressource.
Ce choix confère une grande évolutivité.
Notons que la définition d’une ressource comme étant toute information persistante n’a
pas été retenue car, par essence, toutes les informations (objets) gérées par  sont
persistantes.
Donc une ressource peut très bien être un ensemble de fichiers physiques (un seul
éventuellement) que l’utilisateur manipule de façon totalement transparente (sans avoir
à connaître l’existence même de ces fichiers).
Une ressource peut également être un conteneur qu’on appelle aussi un répertoire. Ce
qui correspond au nœud de l’arbre hiérarchique du système des ressources.
8.4 Localisation, identification des objets
Un même modèle, aussi bien pour les utilisateurs, domaines et groupes que pour
n’importe quelle autre ressource, a été choisi pour identifier un objet de . Cet
identificateur, appelé DobjectLocator, abstraction faite de son implémentation, peut
être considéré comme une chaîne de caractères caractérisant, de contenant à contenu, le
chemin complet (dans l'arbre hiérarchique de tous les objets) de l'objet en question.
Ecole Nationale des Sciences de l’Informatique de Tunisie
41
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Ainsi, l’identificateur de l'utilisateur Ali du domaine Sousse qui est un sous-domaine
direct de superdomain est « superdomain.Sousse.Ali » et l’identificateur du fichier
monFichier du répertoire monRep sur l’Esclave nomme slave1 (dont le répertoire
principal est par convention nommé slave1 aussi) est « root.slave1.monRep.Ali »
De façon plus pragmatique, le DobjectLocator de tous les utilisateurs, domaines et
groupes commence par superdomain, alors que pour toutes les autres ressources, il
commence par root suivi du nom du serveur Esclave qui les héberge.
De plus, pour gérer les conflits (un groupe et un domaine ayant même nom par
exemple), au niveau de chaque élément de la liste donnée par cet identificateur (un
élément est limité par les points), des propriétés peuvent être rajoutées entres
parenthèses comme le montrent les exemples ci-dessous :
-
superdomain.(group)orion
superdomain.(domain)orion
En effet l’identificateur superdomain.orion est dans ce cas ambigu, on doit alors
spécifier une propriété permettant de discriminer l‘objet dont on parle. Pour cela, nous
avons juste spécifié le type qui pour l’un est group et pour l’autre est domain.
Les objets peuvent en fait être indexés sur plusieurs propriétés qui devront être au
niveau de cet identificateur ; ce qui permettra au système d’optimiser les accès disques
et de savoir - n'ayant en main que cet identificateur - si cet objet est bien celui qu'on
cherche ou pas.
Ces propriétés ne sont utilisées qu'en cas de conflit et doivent figurer comme suit :
(property1Key1=property1Value1, property1Key2=property1Value2, ...)name1. 
(property2Key1=property2Value1, …)name2…
Ex : superdomain.(domain)myDomain.([email protected], type=user)Ali
Dans cet exemple, on indexe l'utilisateur Ali suivant son adresse électronique.
Noter que "user" n'est pas sous la forme propertyKey1=propertyValue1, en fait, pour
des raisons de simplifications d’écriture, on peut mentionner - exceptionnellement - le
type directement. Cela est équivalent à type=user.
Ecole Nationale des Sciences de l’Informatique de Tunisie
42
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8.5 Modèle de sécurité
Le modèle de sécurité qui à été retenu pour le système se base essentiellement sur :
8.5.1
L’authentification
Le cycle d’authentification pour l’utilisation de  se compose de 5 étapes:
1- Inscription (sign up) : toute personne voulant utiliser le système (c’est à dire
un ou plusieurs objets du système) doit être déclarée comme utilisateur défini
par son domaine, son nom, et son mot de passe. Pour cela, elle doit contacter le
superviseur du domaine qui correspond à son intérêt (par exemple Pilotage de
programme, traitement d’image…) et lui donner toutes les informations
nécessaires à l’ouverture de son compte.
2- Ouverture d’une session : pour chaque utilisation du système, l’utilisateur doit
ouvrir une session. Elle se fait en s’identifiant par son domaine, son nom et son
mot de passe. Après avoir été reconnu par ce système, il se verra alors attribuer
un objet temporaire valable uniquement durant cette session. Cet objet, noté
Dconnection, lui permettra de bénéficier des privilèges qui lui ont été accordés
en encapsulant toutes les informations nécessaires pour valider ou inhiber tout
accès à toute ressource comme par exemple l’heure exacte de l’ouverture de la
session, l’adresse IP à partir de laquelle le client s’est connecté au
système…etc.
3- Utilisation du système : il s’agit de la manipulation des objets distribués du
système. Cela se fait toujours moyennant l’objet Dconnection obtenu pendant
l’ouverture de la cession.
4- Fermeture de la session : il s’agit de libérer l’objet Dconnection pour qu’il ne
soit plus utilisé par d’autres personnes.
5- Désinscription (sign out) : rejeter l’inscription de cet utilisateur du système : il
n’aura plus le droit de se connecter.
inscription
Ouverture
d’une
session
Utilisation
du système
Fermeture
de la
session
désinscription
Fig 10 : les 5 étapes d’authentification
Ecole Nationale des Sciences de l’Informatique de Tunisie
43
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
8.5.2
Contrôle
ressources
de
l’accès
et
de
la
manipulation
INRIA
des
Le modèle proposé ressemble plus ou moins à celui fourni par la machine
virtuelle Java. Néanmoins, c’est le modèle des ACL qui a été retenu.
En effet, chaque objet du système gère une liste (ACL) de permissions accordées par un
signataire à une cible.
De plus, il n’y a pas de contrôleur de permission (AccessController) qui gère de façon
centralisée la manipulation des ressources.
Cette gestion décentralisée permet surtout d’augmenter les performances et l’évolution
du système. Effectivement, dans un pareil cas, seules les permissions propres aux objets
en cours d’utilisation sont en mémoire. De plus chaque objet peut définir des
permissions qui lui sont propres et les gérer à sa manière (éventuellement avec des
optimisations).
Par ailleurs, un autre point de divergence avec le modèle de sécurité de Java consiste en
le fait que, désormais, toutes les opérations élémentaires sont critiques. Donc, les
permissions sont vérifiées pour toutes les actions sans exception.
Ce choix a été retenu en considérant que, dans un environnement distribué, il nécessaire
de sécuriser toutes les actions à un niveau de granularité le plus fin possible.
Quant aux mécanismes de vérification des permissions, ils restent - à un certain niveau
– identique à ceux déployés par Java VM : il s’agit de valider les permissions requises
par l’utilisateur pour chaque opération critique. Pour cela on vérifie si ces permissions
sont bien impliquées par celles qui leur ont été accordées (cf. 6.3.5).
Ainsi, l’opération de modification d’un fichier requiert les permissions read et write.
Cette opération est donc réalisable si et seulement si l’ACL le permet, par exemple dans
le cas où le superviseur donnerait le droit à cette personne sur ce fichier en lecture
(read), et que son propriétaire lui accorde le droit write.
Dans la suite, la structure des permissions est abordée plus profondément.
8.5.3
La structure d’une permission:
Une permission peut être représentée par un triplet (signataire, cible, contraintes):
- Signataire: c’est celui qui a donné la permission : il peut être aussi bien l’objet
lui-même (si l’objet est un utilisateur), tout superviseur de cet utilisateur, le
propriétaire de l’objet (si c’est une ressource comme fichier...) ou tout
superviseur de ce propriétaire.
- Cible: c’est l’utilisateur, le groupe ou le domaine à qui on veut spécifier les
droits.
- Contraintes: c’est les permissions proprement dites, c’est-à-dire les droits
qu’on donne ou qu’on retire à la cible.
Toutefois, il est très important de signaler qu’une permission n’est pas ce qu’on donne
comme droit à un utilisateur, mais ce qu’on veut lui donner comme droit.
Ecole Nationale des Sciences de l’Informatique de Tunisie
44
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Ainsi, si l’utilisateur Wassim donne à l’utilisateur Ali les droits read et write sur un
fichier et que Wassim n’a que le droit read sur ce fichier, Ali n’aura que le droit de lire
le fichier.
En fait, une façon de résoudre ce problème est d’interdire déjà à Wassim de donner les
droits read et write lors de la création de ces permissions.
Mais, imaginons le scénario suivant : si, un autre utilisateur Selim, avait donné les
droits en lecture et en écriture sur ce même fichier à Wassim. Ce dernier, ayant le droit
de le faire, a fait alors passer ces mêmes doits à Ali. Imaginons ensuite que Selim
décide de retirer à Wassim le privilège d’écriture toujours sur ce même fichier. On
aboutit alors à une incohérence puisque Ali possède toujours la permission d’écriture.
La solution qui a été adoptée pour pallier un pareil problème est de vérifier,
récursivement, toutes les permissions et de ne permettre une action que si cette action a
été accordée par un utilisateur qui possède bien ce privilège.
Dans ce qui suit, je vais aborder comment définir le signataire, la cible et les
contraintes : les 3 entités définissant une permission.
8.5.4
Le signataire
C’est ce qui est le plus facile à faire car, par essence, le mécanisme d’authentification
permet d’identifier les utilisateurs voulant signer une permission grâce au
Dconnection : le client n’a rien à préciser de particulier.
8.5.5
La cible
Afin de rester cohérent avec ce qui a déjà été précisé au niveau de l’identification des
objets distribués, ce même identifiant (DobjectLocator) sera utilisé pour définir le ou
les utilisateurs cibles.
Ainsi, pour définir de nouvelles permissions pour l’utilisateur Ali du domaine
superdomain.inria, il suffit d’introduire la chaîne de caractères ‘superdomain.inria.Ali’
au niveau de la cible.
De plus, quelques caractères spéciaux permettent de définir des cibles génériques (un
peu comme les * du shell Unix ou Dos).
Ces caractères sont :
 * (étoile) : pour remplacer 0 ou plusieurs caractères partout où un label est requit
(nom de domaine, type, propriété…)
exemples :
superdomain.(group)*grp
tous les groupes du domaine superdomain dont le nom se termine par grp.
superdomain.(profession =*student*, user)*
tous les utilisateurs du domaine superdomain dont la profession contient
student
Ecole Nationale des Sciences de l’Informatique de Tunisie
45
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
 ? (point d’interrogation) : pour remplacer exactement un caractère
exemple :
superdomain.(group)???
tous les groupes du domaine superdomain dont le nom a une longueur de 3
caractères.
 - (tiret) : pour remplacer 0 ou plusieurs parties du chemin (plusieurs noms de
domaines ou de répertoires…)
exemples :
-.(group)*grp
tous les groupes dont le nom se termine par grp.
superdomain.inria.-.(user)*
tous les utilisateurs de la sous arborescence superdomain.inria dont par exemple
superdomain.inria.Ali et superdomain.inria.orion.selim mais pas superdomain.wassim.
Bien évidemment, on peut les combiner ensemble pour générer des cibles du genre
superdomain.*.-.(profession=student,user)???*
tous les utilisateurs dont le nom est d’au moins 3 caractères et dont la profession
est student et qui appartiennent à un domaine du deuxième niveau de hiérarchie
au moins.
dont par exemple :
superdomain.inria.(profession=student)Ali et superdoamin.inria.orion.(profession=student)Ali
mais pas superdomain.(profession=student,Ali)
Par ailleurs, pour éliminer toute ambiguïté, au niveau d’une ACL d’un même objet, on
ne permet pas l’introduction de plus d’une permission ayant les mêmes signataire et
cible.
C’est à dire que l’utilisateur Wassim ne peut pas donner deux permissions différentes à
la même cible Ali.
Par contre, il peut très bien entrer plusieurs permissions du genre :
Signer= superdomain.Wassim, target=superdomain.inria.Ali, constraints= write
Signer= superdomain.Wassim, target=superdomain.iniria.*, constraints=read
Signer=superdomain.Wassim, target=superdomain.inria.(group)orion, constraints= write,read
Signer= superdomain.Wassim, target=superdomain.inria, constraints= write
Dans un pareil cas, Ali correspond bien aux quatre cibles des quatre permissions mais
seule la première sera prise en compte car, lorsqu’il y a un conflit entre permissions et
qu’un utilisateur dont on veut connaître les droits (éventuellement pour lui permettre ou
pas une opération) correspond à la cible de plus d’une permission, seule une unique
permission parmi celles en conflit reste en vigueur : la plus spécifique.
Ecole Nationale des Sciences de l’Informatique de Tunisie
46
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Une permission P1 est plus spécifique qu’une permission P2 lorsque la cible C1 de P1
est plus spécifique que la cible C2 de P2.
Une cible C1 est dite plus spécifique qu’une autre C2 si elle est plus faible suivant
l’ordre (USER, GROUP, DOMAIN), puis suivant l’ordre d’implication c’est-à-dire C2
implique C1.
Donc si deux cibles C1 et C2 sont en conflit et si, par exemple, l’une d’elles est un
utilisateur (ex. C1: superdomain.inria.(user)Ali) et que l’autre est un groupe (ex. C2 :
superdomain.inria.(group)groupeDeAli) alors c’est C1 qui est la plus spécifique. Si par contre C2
est aussi du type USER (ex. C2 : superdomain.inria.(user)*) dans ce cas la plus spécifique est
celle qui est impliquée par l’autre (dans l’exemple superdomain.inria.(user)* 
superdomain.inria.(user)Ali donc c’est toujours C1 la plus spécifique).
Cette règle permet (entre autres) de résoudre le problème explicité par l’exemple
suivant :
on veut donner les permissions en lecture et écriture à tout le groupe Orion sauf à
Ali à qui on ne donne que le droit en lecture. Cela est d’autant plus souple à
utiliser lorsqu’il est question d’attribution momentanée de permissions.
En effet, si on veut momentanément retirer les droits donnés à un utilisateur il suffit
alors d’ajouter une entrée qui spécifie qu’il n’a plus ce droit. Cette période dépassée,
pour réattribuer les mêmes droits à cette personne, il suffit de supprimer la permission
dernièrement introduite.
8.5.6
Les contraintes
Le troisième champ du vecteur des permissions constitue les permissions proprement
dites (les droits) que le signataire attribue à la cible.
De ce même fait, cela rend cette entité très importante à plusieurs niveaux :
- au niveau de l’utilisateur final : il faut que ce soit simple à utiliser mais
puissant et maniable.
- au niveau du programmeur, cette entité doit être flexible. En terme de
programmation Java, la classe qui spécifie ces contraintes doit être simple
mais évolutive.
 Au niveau de l’utilisateur final
Comme le DobjectLocator, une contrainte peut être considérée (abstraction faite de
son implémentation) comme une chaîne de caractères.
Cette chaîne peut aussi bien être simplement une énumération des droits comme :
read, write
Ecole Nationale des Sciences de l’Informatique de Tunisie
47
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
ou plus élaborée avec les opérateurs or et and et les fonctions prédéfinies comme
property, method, content, DateIntervalle…etc.
Ex:
or(and(property(firstName),read),and(method(add),exec,DateIntervalle(12/05/2000,13/05/2000))
Ce qui veut dire (en supposant que l’objet contenant cette permission est un
répertoire) qu’on accorde à la cible les droits en lecture seulement et à n’importe
quel moment pour la propriété (property) firstName
Par contre, on lui donne le droit d’ajouter des entrées (fichiers ou sous-répertoires)
mais uniquement entre les dates 12/05/2000 et 13/05/2000.
La liste complète des fonctions - que j’ai implémenté - est la suivante :
always : accorder TOUS les droits
never : retirer tous les droits
not(a,b,c…) : retirer les droits a,b,c …
or(a,b,c,…) ou a,b,c… ou (a,b,c…) : l’union des droits a,b,c…
and(a,b,c…) : l’intersection des droits a,b,c…
first(a,b,c…) : les droits a,b,c… sont vérifiés dans l’ordre, le premier droit qui
accorde explicitement ou qui rejette explicitement la requête du client est
considéré comme le résultat final.
property(propertyName) : spécifie que l’on est en train de définir les contraintes
relatives à la propriété propertyName. Elle est souvent utilisée conjointement
avec and(…).
Les droits qui vont alors avec sont read, write et see.
method(methodName) : spécifie que l’on est en train de définir les contraintes
relatives à la méthode methodName de l’objet en question. Elle est souvent
utilisée conjointement avec and(…).
les droits qui vont alors avec sont exec.
Son utilisation n’est pas courante mais elle peut servir pour spécifier une
permission d’un niveau de granularité très pointu : la méthode. Pour cela il
est essentiel de connaître le nom (et éventuellement les paramètres) de la
méthode en question.
content(contentName) : spécifie qu’on est en train de définir les contraintes
relatives à l’accès du contenu contentName de cet objet. Dans le cas d’un
répertoire d’un domaine ou d’un groupe, cela permet de préciser si telle ou
telle personne peu savoir que contentName appartient bien à ce conteneur.
Elle est souvent utilise conjointement avec and(…).
les droits qui vont alors avec sont see.
dateIntervalle(date1,date2) : spécifie que ces droits ne sont valables qu’entre les
dates date1 et date2. Une étoile (*) voudrait dire que la limite n’est pas
spécifiée (ex : dateIntervalle(*,1/1/2000)).
 Du point de vue du développeur (pour la maintenance et l’évolutivité)
Ecole Nationale des Sciences de l’Informatique de Tunisie
48
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Au niveau du programmeur, une contrainte est spécifiée par l’une des deux interfaces
Deductive ou ReverseDeductive.
La première définit une unique méthode :
int implies(Deductive other)
pendant que ReverseDeductive définit deux méthodes dont la première est héritée de
Deductive
int implies(Deductive other)
int impliedBy(Deductive other)
D’où l’aspect simple et évolutif des contraintes : à tout moment on peut ajouter un
nouveau genre de contraintes rien qu’en implémentant l’une ou l’autre de ces interfaces
ce qui n’est pas coûteux du moment qu’il n’y a - au pire des cas - que deux méthodes à
définir.
Par ailleurs, il est très important de remarquer que ces deux méthodes sont différentes
de celles proposées par le modèle de sécurité Java : la variable résultat étant du type int
et non plus boolean.
En fait, ce résultat entier a la valeur de l’une des constantes :
- YES pour dire que « oui cette contrainte implique bien la contrainte
other ».
- NO pour dire que « cette contrainte n’implique pas other » .
- et NO_MATCH pour dire que les deux objets ne sont pas comparables
et donc on ne peut pas trancher. Cela se produit par exemple lorsqu’on
veut savoir si la contrainte dateIntervalle(…) implique une contrainte
comme property(…). Donc essentiellement si other n’est pas du même
type que ces contraintes. Cela ne doit pas être interprété en « Classes
d’Objets » car deux contraintes de classes Java différentes peuvent
rester comparables. Ainsi, on peut savoir si une collection de plusieurs
contraintes (and(…) ou or(…)) implique une contrainte simple
(property(…) par exemple).
En réalité, l’inconvénient majeur avec le modèle proposé par Java est que nous ne
pouvons pas réaliser l’union ou l’intersection de différentes permissions : les
permissions sont automatiquement regroupées suivant leurs classes : l’implication se
fait entre classes identiques.
Ecole Nationale des Sciences de l’Informatique de Tunisie
49
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Par contre, ici, nous pouvons définir notre propre collection des contraintes. Chose qui a
été faite à trois reprises : pour la fonction or (Collection_OR), la fonction and
(Collection_AND) et la fonction first (Collection_FIRST).
Le principe de la vérification des droits d’accès est le suivant : toutes les méthodes des
objets gérés par le système  ont (par convention) comme premier paramètre
l’identificateur Dconnection de l’utilisateur désirant effectuer l’opération.
Par exemple la signature de la méthode permettant de lister le contenu d’un répertoire
est :
public Collection list(Dconnection caller, DobjectFilter filter, boolean recurse) ;
où le premier paramètre (caller) désigne l’utilisateur qui a appelé la méthode.
Chaque objet, peut alors effectuer le test sur la légitimité de cette action en créant –
compte tenu de ‘caller’ – un objet contrainte (implémentant Deductive ou
ReverseDeductive) qui décrit l’intention de cet utilisateur, puis essayer de démontrer
cette contrainte à partir de celles des permissions qui ont été accordées par le
propriétaire de la ressource ou un de ses administrateurs.
Le fonctionnement des deux interfaces, citées ci-dessus, permet de réaliser cette
démonstration par un chaînage avant (Deductive) et/ou un chaînage arrière
(ReverseDeductive).
Pour mieux saisir l’importance du chaînage arrière, prenons l’exemple de deux
contraintes X et Y.
Supposons que Y est une collection (union, intersection ou toute autre) d’autres
contraintes y1,y2,… yn.
Cherchons à démontrer que XY autrement écrit X.implies(Y)=?
Comme X ne sait pas que Y est une collection, on ne peut donc pas démonter dans le
sens direct.
Par contre, Y sait très bien qu’il en est une, il prend alors l’initiative de démontrer dans
l’autre sens, c’est à dire que pour chacun de ses yi, yi X autrement écrit
yi.impliedBy(X)= ?
Ecole Nationale des Sciences de l’Informatique de Tunisie
50
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8.6 Distribution des objets
Au niveau de la distribution des objets, j’ai préféré la technologie RMI standard aux
technologies RMI activation et CORBA pour les raisons qui suivent :
- RMI est
purement Java (à l’inverse de CORBA): rester dans un
environnement 100% Java facilite la phase de tests et de debuggage du
système et augmente la lisibilité et la compréhensibilité du code. Ajoutons à
cela que CORBA est à un niveau d’abstraction tellement élevé qu’il requiert
un effort non négligeable rien que pour comprendre les mécanismes de base
avant même de penser à utiliser son implémentation sous Java.
- RMI standard est beaucoup plus simple, et moins spécifique que RMI
activation qui, en dépit du fait qu’il offre la persistance des objets Remote
(distant) et leur exportation sur demande, reste quand même très complexe à
utiliser (introduction de 14 nouvelles classes) sans résoudre parfaitement le
problème crucial de la gestion de la mémoire. En effet, la technologie
Activation propose d’exporter des objets de faible taille (des descripteurs) au
lieu des objets eux-mêmes. Cela peut être très avantageux lorsque, les objets
sont de taille considérables par rapport à leur descripteurs. Néanmoins, dans le
cas contraire, son utilisation n’est pas justifiée.
En outre, pour ce qui est de la communication avec les pages HTML d’un navigateur du
coté d’un client, les Servlets Java sont les favoris, par soucis de cohérence (solution
100% Java) et en raison de leur performances.
Pour ce qui est de la communication entre les différentes entités (Maître, Esclave, Client
sur Applet ou Application), la solution proposée se base purement sur du RMI standard
pour réellement exporter et désexporter un objet sur demande. Mieux encore, au niveau
de l’utilisateur, il n’a même pas besoin de le savoir : le sous-système Client se charge de
retrouver cet objet et de lui en donner directement une référence.
En fait, tout ce que permet le RMI c’est de récupérer sur le Client, moyennant un
identifiant qui est une chaîne de caractères, une référence à un objet distant sur le Maître
qui a déjà été enregistré (donc exporté) au niveau du Maître.
A ce stade, trois problèmes se posent :
- Comment savoir quel est l’identifiant de l’objet dont on veut avoir une
référence ?
- Comment faire si l’objet n’est pas encore exporté par la machine
distante ?
- Comment et quand est-ce que l’objet est désexporté ?
Ecole Nationale des Sciences de l’Informatique de Tunisie
51
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Pour le premier point, deux solutions existent : soit que de part et d’autre on applique
une même fonction de correspondance entre objet et identificateur. L’un (Maître) pour
exporter et l’autre (Client) pour importer. L’inconvénient avec cette façon de faire est la
difficulté de trouver une surjection d’un ensemble vaste (les objets) vers un ensemble
moins vaste (une chaîne doit forcément être limitée en longueur). Mais surtout pour des
raisons de sécurité : si on connaît la fonction on peut parfaitement savoir quels sont les
objets exportés.
Une deuxième méthode (qui a été retenue) consiste à laisser le système distant (Maître)
décider de la valeur de l’identifiant (qui pourrait par exemple être aléatoire), passer cette
valeur au système local (Client) qui utilisera alors le RMI pour récupérer la référence.
Quant aux deux derniers points, c’est sur demande du système Client (et non pas
explicitement de l’utilisateur lui-même) que le système distant (Maître) doit exporter ou
désexporter un objet.
Par ailleurs, comme tout objet du système peut en utiliser un autre (c’est le principe
même de la programmation objet), il aura nécessairement à demander au système qui
l’héberge (que ce soit Client, Maître ou Esclave) de lui procurer l’objet désiré. Mais un
système ne peut pas se comporter identiquement face à une demande locale (par un de
ses objets) et une demande distante (par un système distant).
C’est pour cela que deux nouvelles notions ont été introduites:
- le sous-système local (LocalSystemManagerInterface)
- le sous-système exporté (ExportedSystemInterface)
Ce sont en fait deux vues du même système : une vue pour les objets locaux une autre
pour les systèmes distants.
LocalSystemManager
ExportedSystemManager
B
ExportedSystemManager
LocalSystemManager
A
Fig 11 : interaction entre les vues des différents systèmes
Ecole Nationale des Sciences de l’Informatique de Tunisie
52
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8.6.1
Fonctionnement du sous-système local
L’utilisateur ne voit que le sous-système local. C’est à lui qu’il s’adresse pour
récupérer n’importe quel objet de  .Ce sous-système ira d’abord vérifier si l’objet est
local. Dans un pareil cas, il n’y a nullement besoin de la technologie RMI : si l’objet est
en mémoire, il est directement passé à l’utilisateur, sinon, il est chargé du disque pour
en créer une instance en mémoire, laquelle instance sera passée toujours à l’utilisateur.
Si par contre l’objet n’est pas local, il vérifie quand même s’il a déjà une référence RMI
de cet objet (créée lors d’une précédente demande), sinon, il retrouve le système distant
qui est capable de lui passer une référence RMI (éventuellement la créer) de cet objet
qu’il passe alors à l’utilisateur.
Quand l’utilisateur n’a plus besoin de cette référence, il l’indique explicitement au soussystème qui appellera (si nécessaire) le système distant pour désexporter l’objet.
Les deux schémas ci-après explicitent ce scénario.
Utilisateur demande l’objet Obj au sous-système local
Retourner
L’instance
À l’utilisateur
oui
oui
Obj est en
Memoire ?
Obj est local ?
non
non
oui
Obj a déjà été
importé ?
Créer une nouvelle instance
en chargeant Obj
non
Importer l’objet (du serveur
d’enregistrement RMI)
Système local
Retrouver le système distant qui
sert cet objet
Système distant
Retourner l’dentificateur RMI
de Obj au système local
oui
Obj est déjà
exporté ?
Exporter Obj sur le serveur
d’enregistrement RMI
oui
Obj est en
Mémoire ?
Créer une nouvelle instance
en chargeant Obj
Fig 12 : Demande d’un objet
Ecole Nationale des Sciences de l’Informatique de Tunisie
53
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
Utilisateur libère l’objet Obj
Système local
Système distant
sauvegarder l’instance d’Obj
sur le disque.
Obj est encore
utilisé par d’autres
utilisateurs (locaux
ou distants)?
non
non
INRIA
Désexporter Obj du serveur
d’enregistrement RMI
oui
Obj est local
?
sauvegarder
l’instance d’Obj
sur le disque.
Retrouver le système distant qui
sert cet objet
non
Obj est encore
utilisé par d’autres
utilisateurs (locaux
ou distants)?
Fig 13 : Libération d’un objet
Pour des raisons de performances le sous-système local gère 4 listes :
- LiveObjects : c’est la liste des objets locaux « en vie ». Ce sont les objets en
mémoire et en cours d’utilisation soit localement soit en distant. En fait pour
résoudre le problème de l’incohérence des objets (deux instances différentes
du même objet), le système crée une seule instance qui sera utilisée par tout le
monde aussi bien localement qu’en distant. Cependant, des copies de cette
instance peuvent également exister mais ne pourront jamais altérer la valeur de
cette instance .Cette dernière (qui peut être un utilisateur, un groupe, un
domaine, ou toute ressource…) est dite «en vie » car c’est la seule qui reflète
l’état courant de l’objet et c’est la seule qui sera persistante (sauvée sur le
disque).
- CachedObjects : c’est la liste des copies des objets locaux et non locaux qui
ont dernièrement été utilisés par les utilisateurs de ce système. Ces instances
ne sont que des copies donc peuvent contenir une information qui n’est pas à
jour.
- ImportedObjects : c’est la liste d’objets non locaux et déjà importés. Cela
évite d’importer plus d’une fois le même objet. Ce dernier sera libéré lorsque
tous les utilisateurs locaux l’auront libéré.
Ecole Nationale des Sciences de l’Informatique de Tunisie
54
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
- ExportedObjects : c’est la liste des objets locaux et déjà exportés .A chacun
correspond donc un identificateur RMI. Cela évite d’exporter plus d’une fois
le même objet. Ce dernier sera libéré lorsque tous les utilisateurs distant
l’auront libéré.
Il est toutefois à noter que le fonctionnement du sous-système local est également
dépendant du fait qu’il soit sur un système Maître, Esclave ou Client. En effet, ces 4 listes
ne sont pas utilisées en totalité pour tous les systèmes : un système Client par exemple
ne possède ni d’objets Live ni d’objets exportés puisqu’il n’a aucune ressource locale.
8.6.2
Fonctionnement du sous-système exporté
Il correspond à un système (du système distribué ) vu par un autre système distant.
En fait, son fonctionnement dépend fortement du fait qu’il soit sur un Maître ou Esclave
(en effet un Client n’est jamais exporté !).
Lorsqu’un système distant lui demande un objet, le sous-système exporté, sur un
esclave, vérifie que l’objet requit est bien local. Cela provient du fait qu’un esclave ne
doit être qu’un serveur de ressources locales.
Par contre, un Maître doit répondre à toutes les requêtes et doit servir l’objet requit où
qu’il soit.
C’est ainsi alors, qu’un Maître sert de pont entre l’utilisateur et le système Esclave.
Imaginons le scénario suivant :
Un utilisateur U sur un Client requiert deux ressources R1 et R2.
R1 est un domaine. Elle est donc sur le Maître.
R2 est un fichier. Elle est donc sur un Esclave.
L’utilisateur demande au Client R1 puis R2.
Pour R1, le Client demande au Maître ce domaine. Maître reconnaît que R1 est local
donc exporte directement cet objet au serveur d’enregistrements RMI et passe
l’identificateur (la chaîne de caractères) au Client qui se servira de la technologie RMI
pour récupérer l’instance et la passer à U.
Pour R2, idem au niveau du Client, sauf que le Maître reconnaît que R2 n’est pas local.
Il récupère alors une référence RMI de cet objet de son système local (un des Esclaves),
réexporte cet objet en le réenregistrant au niveau du serveur RMI local au Maître. Le
reste se passe exactement comme pour R1 c’est-à-dire qu’il passe la référence au Client
grâce à l’identificateur.
Ecole Nationale des Sciences de l’Informatique de Tunisie
55
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
R. locales
Fichiers,
répertoires
…
Ressources Locale
Utilisateurs,
domaines, groupes…
LocalSystemManager
ExportedSystemManager
Esclave B
ExportedSystemManager
Maître
LocalSystemManager
ExportedSystemManager
LocalSystemManager
Esclave A
INRIA
R. locales
Fichiers,
répertoires…
LocalSystemManager
NON EXPORTE
Client
Utilisateur
Pas de R.
Locales
Fig 14 : communication entre Client, Maître et Esclaves
8.6.3
Migration des objets
Il est clair qu’il est très important de pouvoir manipuler des instances d’objets à distance
sans avoir à se préoccuper de leurs emplacements physiques. Il n’en demeure pas moins
vrai que très souvent on besoin de faire migrer un objet vers un emplacement précis,
éventuellement pour y travailler localement. C’est essentiellement le cas lorsque, par
exemple, on veut avoir une copie de l’objet car on ne va pas le modifier. Ou encore,
pour déplacer carrément l’objet d’un système A vers un système B (déplacement de
fichiers…).
Ecole Nationale des Sciences de l’Informatique de Tunisie
56
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Pratiquement, l’unique façon permettant cette migration est de faire migrer des copies
des objets et non les objets eux-mêmes parce qu’un objet est un pointeur et qu’un
pointeur n’a de sens que sur la machine où il a été créé.
Cependant, cela soulève tout particulièrement deux problèmes : l’un au niveau de la
sécurité, l’autre au niveau du fonctionnement de la technologie RMI.
8.6.3.1 Problème de sécurité
Pour ce qui est de la sécurité, l’exemple suivant peut mieux présenter la problématique :
supposons qu’une ressource R utilise un fichier F sur un Esclave A et un tableau T (en
mémoire). Supposons encore qu’à une date D1, l’utilisateur Selim avait le droit en
lecture et en écriture sur cette ressource mais qu’a la date D2 il ne bénéficie plus de ces
privilèges.
En imaginant que Selim est arrivé à avoir une copie de la ressource R entre D1 et D2 (ce
qui est absolument légal), ce serait une faille que de laisser cet utilisateur utiliser cette
copie pour changer le contenu du fichier F après la date D2. Remarquez cependant que
même s’il changeait le tableau T de la copie cela n’affecterait que cette copie (car c’est
en mémoire et donc non persistant).
Donc les copies d’objets ne doivent aucunement altérer les informations originales :
elles ne doivent être utilisées qu’en lecture et jamais en écriture.
La solution adoptée pour pallier cette faille est d’interdire à toute copie d’avoir accès au
disque. Comme tout utilisateur n’est jamais local ni à un Maître ni à un Esclave car il
n’est local qu’au système Client qu’il utilise, il suffit d’interdire à tout objet d’avoir
accès au disque tant qu’il n’est pas local.
Ainsi, lorsque Selim voudra utiliser la copie R’ de R pour changer F, le système Client
est capable de savoir que R n’est pas local et donc d’interdire cette opération.
8.6.3.2 Problème au niveau du RMI
Par ailleurs, l’utilisation du RMI nous contraint à avoir des objets immobiles car un
objet Remote utilise les Sockets pour répondre aux requêtes des utilisateurs distants. Or,
comme les pointeurs, une Socket n’a aucun sens sur une autre machine.
C’est dans ce sens que la notion du Handler a été introduite.
Un Handler est un objet Remote (accessible à distance) qui encapsule un objet nonRemote.
Ainsi, tous les objets gérés par le système distribué seront des objets non-Remote (donc
non accessibles á distance) par contre, ils seront persistants et migrateurs.
Le système se chargera, à chaque fois qu’un objet Remote est requis (évidemment lors
de l’exportation d’un objet vers un autre système), de créer un Handler qui encapsulera
cet objet.
Ecole Nationale des Sciences de l’Informatique de Tunisie
57
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Cela permet au niveau de l’utilisateur de manipuler les objets de façon totalement
transparente sans se soucier de quelque façon que ce soit de tout ce qui est en relation
avec Remote, Handler…etc.
En effet un Handler est une classe qui adopte toutes les méthodes de la classe qu’elle
encapsule en ajoutant les méthodes nécessaires au fonctionnement RMI (à la manière de
l’héritage multiple qui est banni par Java), de telle sorte que l’utilisateur en appelant une
méthode M d’un objet O n’a pas à se soucier si c’est un Handler ou non.
Pour rendre le développement plus aisé un outil Java a été créé (Handler_Generator)
dans le but d’automatiser la génération de ces Handlers.
8.7 Application au pilotage de programme
Le pilotage de programme traite essentiellement de quatre entités :
- (1) les bases de connaissances encapsulant formellement l’expérience
d’un ou de plusieurs experts dans un certain domaine.
- (2) Les programmes permettant de réaliser des tâches élémentaires
- (3) Le moteur d’inférence réalisant le raisonnement nécessaire pour
retrouver un enchaînement acceptables des différents programmes afin
d’aboutir au but précisé par l’utilisateur final.
- (4) Les informations à traiter, qui sont entrées par cet utilisateur final.
La dernière entité (4) est une simple donnée ponctuelle, donnée par le client au cours
d’une utilisation du système de pilotage de programmes. Elle est considérée comme
information simple qui peut être représentée par les objets Java standard (des chaînes
de caractères, des entiers…)
Les trois premières, par contre, sont considérées comme des ressources au niveau du
système  .
En effet, à chacune d’entre elles, on fait correspondre un objet (persistant) du système.
Pour les bases de connaissance (1), par exemple, on associe la classe Java
KnowledgeBase qui manipule toutes les informations de celle-ci.
Cette dernière prévoit des méthodes permettant de gérer tous les fichiers physiques
formant la base comme une seule entité et de les lire ou de les modifier à distance.
Dans un premier temps, l’objet qui a été développé gère uniquement l’aspect
« utilisation à distance » pour permettre, à partir de l’Applet de pilotage de programme
(développée par F. Avnaim) de lire et de modifier la base, ainsi que l’accès concurrent
grâce à la notion de verrou.
Ecole Nationale des Sciences de l’Informatique de Tunisie
58
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
En fait, cet objet ne gère pas les traitements spécifiques à la base (création d’un nouvel
opérateur, modification de l’enchaînement des programmes…) car cette partie a déjà été
réalisée au niveau d’autres classes Java (du même développeur). Ainsi, pour des raisons
de réutilisabilité, cette partie a été gardée sans altération. On pourrait prévoir que dans
une version ultérieure, KnowledgeBase se chargera totalement des aspects liés à la
base.
Plus précisément, KnowledgeBase permet, à distance, de lire et de modifier les
fichiers composant la base de connaissance, mais ne précise pas comment cette
modification doit s’effectuer.
En ce qui concerne le moteur d’inférence (3) (écrit en C, C++), la solution la plus
raisonnable est de créer un objet Java qui, grâce à JNI (Java Native Interface) propose
les services de ce moteur sous forme de méthodes Java. Cet objet, également considéré
comme ressource, reste local au programme « Moteur d’inférence » correspondant (sur
la même machine), mais permet grâce aux mécanismes apportés par  de manipuler de
façon transparente toute base de connaissances (1) et tout programme (2) du système.
Les programmes (qu’ils soient des binaires ou des bibliothèques en C, C++), sont
également des ressources et peuvent être exécutés à distance moyennant la même
procédure énoncée pour le moteur d’inférence i.e. grâce au JNI.
Notons toutefois que les objets modélisant les moteurs d’inférence et les programmes
n’ont pas été développés car l’Applet ne permet pas encore de lancer un moteur
d’inférence sur les données.
Ecole Nationale des Sciences de l’Informatique de Tunisie
59
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
8.8 Modèle Objet
Il est à souligner que tout a été développé en utilisant les interfaces. Cette notion
procure un plus haut niveau d'abstraction se rapprochant de la programmation par
composants. Elle permet par exemple, à tout moment, de remplacer tout objet par tout
autre proposant les mêmes services (les mêmes méthodes). Elle permet également, de
faire coexister différentes implémentations pour la même notion mais tenant compte de
la particularité de l'objet qu'elle caractérise.
Ainsi, deux ressources telles que Image et Texte, bien que prévoyant un même service
AFFICHER_CONTENU, doivent agir différemment.
8.8.1
Tout est DobjectInterface :
Toute ressource (au sens de fichier, utilisateur, domaine ou groupe,…) doit être :
- persistante
- accessible à distance (un objet groupe est toujours sur le Maître)
- protégée par le même mécanisme de sécurité déjà énoncé.
De plus, un même mécanisme d'identification a été choisi pour la localisation de tous
ces objets.
C'est pour cela qu’ils héritent tous d'une même interface appelée DobjectInterface
(autrement dit, l'interface pour un objet du système Distribué).
DobjectInterface prévoit plusieurs méthodes pour identifier l'objet (getLocation),
gérer des propriétés(get/setProperties et listPropertiesNames), gérer des permissions
(set/unset/listPermissions), gérer l’accès au disque (load/unloadContent) et interagir
avec les autres composants (add/removeOperationListener, operationPerformed).
Dans ce sens, tout objet est parfaitement maître de sa décision en ce qui concerne tous
ces aspects. Ainsi, une ressource File peut très bien être stockée sous forme d’un ou de
plusieurs fichiers et même tout un répertoire.
Cependant, une implémentation par défaut a été réalisée : Dobject.
Ainsi, lorsqu’on veut redéfinir cet objet, on a le choix entre dériver le nouvel objet de
Dobject et redéfinir les méthodes en question avec un faible coût de développement, ou
implémenter directement DobjectInterface et définir un fonctionnement tout autre.
A titre indicatif, les schémas UML des interface DobjectLocator et
LocalSystemInteface seront explicités dans la suite, avant de présenter la hiérarchie
des différentes interfaces et implémentations concernant, d’abord, les objets du
systèmes qui sont les ressources et les authentificateurs (domaines, groupes et
utilisateurs), ensuite, celle relative aux interfaces et implémentations du système luimême.
Ecole Nationale des Sciences de l’Informatique de Tunisie
60
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
8.8.2
INRIA
UML de LocalSystemManagerInterface
Interface LocalSystemManagerInterface
void start() throws DoovosGeneralFailureException;
void stop() throws DoovosGeneralFailureException;
String getName();
DdomainInterface superdomain() ;
DuserInterface superuser();
DuserInterface guest();
DgroupInterface supergroup();
DgroupInterface nogroup();
DdirectoryInterface root();
DdirectoryInterface localroot() ;
Dconnection connect(DobjectLocator userLocation, String password);
void disconnect(Dconnection connection);
boolean
isConnected(Dconnection connection);
String getProperty(String propertyName);
DobjectInterface getObjectCopy(DobjectLocator ol);
DobjectInterface getObjectCopy(DobjectLocator ol,boolean forceReload);
DobjectInterface getObject(DobjectLocator ol);
void
freeObject(DobjectInterface location);
boolean
exists(DobjectLocator locator);
boolean
isLocal(DobjectLocator locator);
8.8.3
UML de DobjectInterface
Interface DobjectInterface
DobjectInterface THIS() throws RemoteException;
String getName(Dconnection caller) throws RemoteException;
String getType(Dconnection caller) throws RemoteException;
DobjectLocator getLocation(Dconnection caller) throws RemoteException;
DuserInterface getCreator(Dconnection caller) throws RemoteException;
void setPermission(Dconnection caller,DobjectLocator target,Deductive constraints,boolean override)
throws RemoteException;
boolean unsetPermission(Dconnection caller,DobjectLocator target) throws RemoteException;
Permissions.Entry getPermission(Dconnection caller,DobjectLocator target) throws RemoteException;
Collection listPermissions(Dconnection caller) throws RemoteException;
Object getProperty(Dconnection caller, String property) throws RemoteException;
void setProperty(Dconnection caller,String property,Object Value,boolean override,boolean isIndexed)
throws RemoteException;
boolean unsetProperty(Dconnection caller,String property) throws RemoteException;
Collection listPropertiesNames(Dconnection caller) throws RemoteException;
void addOperationListener(DobjectInterface listener,String operationsFilter) throws RemoteException;
void removeOperationListener(DobjectInterface
listener,String operationsFilter)
throws
RemoteException;
Ecole Nationale des Sciences de l’Informatique de Tunisie
61
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
void operationPerformed(OperationEvent oEvent) throws RemoteException;
void wakeUp() throws RemoteException;
void sleep() throws RemoteException;
void dispose() throws RemoteException;
Component getComponent(Object parameters,boolean isSelected) throws RemoteException;
DobjectInterface
loadContent
(DobjectLocator
childLocation)
throws
IOException,
ClassNotFoundException, RemoteException;
Void unloadContent(DobjectInterface child) throws IOException,RemoteException;
8.8.4
Hiérarchie des objets
DobjectInterface
DauthentificatorInterface
DgroupInteface
DresourceInterface
DuserInteface
DdomainInteface
Duser
Ddomain
Dgroup
DEFAULT_NOGROUP
DEFAULT_GUEST
DEFAULT_SUPER_GROUP
Dresource
DdirectoryInterface
Dfile
Ddirectory
ByteFileInterface
DEFAULT_SUPER_DOMAIN
ObjectFileInterface
DEFAULT_ROOT
DEFAULT_SUPER_USER
DFileInterface
KnowledgeBaseInetface
DEFAULT_LOCAL_ROOT
KnowledgeBase
Fig 15 : Hiérarchie des objets du système
LocalSystemManagerInterface
ImportedObjects
ExportedObjects
MasterSystemManager
LiveObjects
AbstractSystemManager
GenericClientSystemManager
MonoClientSystemManager
AutoSaveThread
CachedObjects
SlaveSystemManager
MultiClientSystemManager
Fig 16 : Hiérarchie des classes et interfaces du Système
local.
Héritage
Classe
Légende
Interface
Ecole Nationale des Sciences de l’Informatique de Tunisie
Agrégation
62
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
9 Réalisation
Le travail qui a été effectué peut se résumer en le développement :
- d’une API (ensemble de classes Java) appelée Doovos permettant par la
programmation Java, d’utiliser le système pour manipuler des objets répartis sur les
différents Esclaves et de les faire coopérer, ou encore de définir de nouveaux objets
(nouveau types de ressources). Elle permet également de faire évoluer le système (par
une réimplémentation des interfaces définissant ce dernier).
- d’un serveur Maître et d’un serveur Esclave piliers de l’architecture présentée.
- de plusieurs outils de développement facilitant et automatisant la création de certaines
classe Java.
- d’une Servlet permettant, via Internet et de façon interactive, l’administration du
système à partir d’une simple page HTML sur un navigateur.
- des objets dédiés au pilotage de programmes et leur intégration dans l’Applet.
9.1 L’API Doovos
L’API doovos (Distributed Object Oriented Virtual Operating System) est composée de
41 interfaces implémentées par 93 classes (outre celles générées automatiquement)
répartis dans 7 paquetages.
Ces paquetages sont :
- vpc.www.html.servlet : comprend une interface pour la définition des
SubServlet qui sont des classes déléguées par une Servlet pour réaliser un
certaine tâche particulière.
- vpc.www.html : comprend une classe (EasyTable) permettant de générer des
Tableaux Html.
- vpc.doovos : comprend toutes les interfaces définissant les objets du système.
Entre autres, nous retrouvons DuserInterface, DdomainInterface, etc. De
plus, on y trouve également les classes de base que sont DobjectLocator et
Permissions.
- vpc.doovos.object : contient toutes les implémentations par défaut des
interfaces de vpc.doovos.
- vpc.doovos.system : contient les interfaces et implémentations du système luimême, telle que LocalSystemManagerInterface, ExportedMaster, etc.
- vpc.doovos.tool : contient des applications utilitaires Java (comme le lanceur
des serveurs Maître et Esclave).
- vpc.doovos.util : contient des classes et interfaces à utilité générale comme par
exemple Grep qui permet de vérifier si une chaîne de caractère (modèle
pouvant contenir des * et de ?) correspond à une autre.
Ecole Nationale des Sciences de l’Informatique de Tunisie
63
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
9.2 La Servlet ProgramSupervisionServlet
La Servlet ProgramSupervisionServlet a été développée pour permettre une
administration interactive du système. En effet, via des pages HTML dynamiques,
un superviseur peut créer ou supprimer des domaines, utilisateurs ou groupes, ou
encore définir les permissions relatives au différentes ressources, etc.
Fig 17 : Administration du système via Internet
Ecole Nationale des Sciences de l’Informatique de Tunisie
64
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Cette Servlet permet, pour chaque objet du système, d’exécuter ses propres méthodes à
partir d’un simple formulaire.
Ainsi, pour un objet du type Domaine, un administrateur peut ajouter un nouvel
utilisateur, lister son contenu, etc.
Fig 18 : Ajout d’un utilisateur à un domaine
Fig 19 : Lister le contenu d’un domaine
Ecole Nationale des Sciences de l’Informatique de Tunisie
65
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
9.3 Les outils complémentaires
Le développement m’a amené à produire également quelques outils facilitant et
automatisant certaines tâches. Tous ces outils sont des applications Java dans le
paquetage vpc.doovos.util .
9.3.1
Handler_Generator
Handler_Generator permet de générer automatiquement des classes Handler énoncées
au niveau du paragraphe 8.6.3.2.
A cette application, on doit spécifier juste le nom des classes Java pour lesquels on veut
créer les Handlers (l’option –verbose permet de suivre le processus de génération pas à
pas).
Exemple :
Java vpc.doovos.tool.Handler_Generator my.package.firstClass my.package.secondClass
deux nouvelles classes seront alors générées automatiquement :
my.package.firstClass_Handler et my.package.secondClass_Handler.
Ces classes seront utilisées par le système pour servir à distance les objets qu’il gère.
9.3.2
TemplateGenerator
Les pages HTML n’ont aucune interaction avec les classes Java qu’on peut écrire.
Seulement, on pourrait cependant avoir besoin d’intégrer par exemple des constantes
Java dans ces pages.
Pour remédier à cela deux solutions existent :
Une solution très rudimentaire consiste à copier manuellement la valeur de cette
constante dans la page HTML et pour chaque occurrence, sous le risque de se tromper
bien sur, mais aussi, d’être obligé de refaire la même chose chaque fois que la valeur de
la constante change au cours de la période de développement.
Une solution beaucoup plus «propre » est d’utiliser les Servlets pour remplacer la
constante par sa valeur pendant l’exécution même de cette Servlet (au Runtime).
Néanmoins, par essence, les pages HTML dynamiques n’ont de raison d’être que si on
ne connaît pas l’information à l’avance. Or dans notre cas la valeur de la constante ne
change pas au cours du Runtime. De plus, pour des raisons de performances, il est plus
intéressant de minimiser la génération dynamique de ces pages.
TemplateGenerator a été créé pour résoudre efficacement ce problème.
Il permet de remplacer dans les pages HTML toutes les occurrences des constantes Java
avec leurs valeurs. Cette opération se fait à chaque fois que l’on fait une modification
dans le fichier et non plus à chaque fois que ce fichier est appelé par le serveur http.
Ecole Nationale des Sciences de l’Informatique de Tunisie
66
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
Mieux encore, TemplateGenerator permet même de construire un fichier à partir d’un
ensemble d’autres fichiers de telle sorte que si par exemple, toutes les pages d’un site
utilisent le même entête et les mêmes styles, (couleurs et polices…) cette partie
commune peut être mise dans un fichier a part qui sera inclus automatiquement dans
tous les fichiers du site.
C’est donc une façon de factoriser le code pour ne pas avoir changer dans chacun des
fichiers composant le site si on a besoin, par exemple, de modifier quelque chose au
niveau de l’entête.
9.3.3
JHTML_Generator
Pour générer des pages HTML dynamiques avec les Servlets, il y a deux façons de
faire :
soit intégrer du code HTML dans du code Java, soit le contraire.
Le premier cas donne un code qui ressemble à :
String Variable = « bonjour»
out.println(« <FONT SIZE=’10’> »+Variable) ;
Le second cas donne un code qui ressemble à
<HTML><BODY>
<JAVA>
for (int i=0 ; i<20 ; ++i) out.println(i) ;
</JAVA>
</BODY></HTML>
En réalité, chaque solution a ses avantages et ses inconvénients. La première est
meilleure si on a peu de code HTML d’affilé. La seconde se montre beaucoup plus
raisonnable dans le cas où on a des blocs séparés de codes JAVA et de code HTML.
Le cas de la Servlet ProgramSupervisionServlet, correspond clairement au deuxième
cas : un traitement purement JAVA pour questionner le Serveur des objets et répondre à
la requête du client puis un formatage de cette information en HTML.
JHTML_Generator permet de générer une classe JAVA à partir d’un fichier HTML qui
contient du code JAVA.
9.3.4
Doovos Launcher
Doovos Launcher est une application qui permet de lancer et stopper les serveurs
d’objets Maître et Esclave ainsi que de gérer la synchronisation entre eux car l’Esclave
ne doit pas se lancer avant que le Maître ait fini sa phase d’initialisation (l’Esclave doit
s’enregistrer auprès du Maître).
Son principe est de créer un fichier verrou temporaire quand le Maître est lancé et de le
supprimer quand ce dernier aura terminé sa phase d’initialisation. D’un autre coté
l’Esclave ne se lancera que si ce fichier n’existe plus.
Ecole Nationale des Sciences de l’Informatique de Tunisie
67
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
De plus, cette application permet de configurer les serveurs Maître et Esclaves grâce au
options données au niveau de la ligne de commande :
-start=master : lancer le serveur Maître
-stop=master : stopper le serveur Maître
-start=slave : lancer le serveur Esclave
-stop=slave : stopper le serveur Esclave
-config=configFileName : spécifier le nom du fichier de configuration (voir annexe D)
-wait=mmm : spécifier qu’il faut lancer le serveur après mmm milli-secondes
-temp=lockFileName : spécifier le nom du fichier VERROU qui permettra de savoir si le
Maître a fini de se lancer ou pas
-period=mmm : spécifier la fréquence de vérification si le fichier verrou existe ou pas
-help : afficher de l’aide
-showWarning : spécifier que le serveur doit afficher les messages de type avertissement.
-showError : spécifier que le serveur doit afficher les messages d’erreurs
-showTrace : spécifier que le serveur doit afficher les messages de trace (pour debuggage)
-showMethod : spécifier que le serveur doit afficher le nom et le paramètres de toutes les
méthodes exécutées.
-show : spécifier que le serveur peut prendre en considération les options showXXX. Pour les
inhiber utiliser -!showXXX.
-throwRT et -throwRemote : afficher les exceptions localement (avant de les passer au client)
Voici alors le résultat du lancement du Maître (nommé master)suivi de celui de
l'Esclave (nommé base) avec les options –showWarning et –showMessage
**************************************************************
*
*
* MASTER master Starting...(Tue Jun 20 10:06:08 CEST 2000) *
*
*
**************************************************************
master:0
MESSAGE: loading superdomain...
master:1
WARNING:
not found... Creating new Instance of
DEFAULT_SUPER_DOMAIN...
master:2
MESSAGE: loading superuser...
master:3
WARNING:
not found...
Creating new Instance of
DEFAULT_SUPER_USER...
master:4
MESSAGE: loading guest...
master:5
WARNING: not found... Creating new Instance of DEFAULT_GUEST...
master:6
MESSAGE: loading supergroup...
master:7
WARNING:
not found...
Creating new Instance of
DEFAULT_SUPER_GROUP...
master:8
MESSAGE: loading noGroup...
master:9
WARNING:
not found...
Creating new Instance of
DEFAULT_NO_GROUP...
master:10
MESSAGE: Creating new instance of DEFAULT_ROOT...
master:11
MESSAGE: configurating CachedObjects...
master:12
MESSAGE: configurating ImportedObjects...
master:13
MESSAGE: configurating ExportedObjects...
master:14
MESSAGE: configurating LiveObjects...
master:15
MESSAGE: starting autoSaveThread...
master:16
MESSAGE: Launching the ExportedMaster
master:17
MESSAGE: Master is ready!
Ecole Nationale des Sciences de l’Informatique de Tunisie
68
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
***********************************************************
*
*
* SLAVE base Starting...(Tue Jun 20 10:06:20 CEST 2000) *
*
*
***********************************************************
base:0 MESSAGE: loading localroot...
base:1 WARNING: not found... Creating new Instance of DEFAULT_LOCAL_ROOT...
base:2 MESSAGE: configurating CachedObjects...
base:3 MESSAGE: configurating ImportedObjects...
base:4 MESSAGE: configurating ExportedObjects...
base:5 MESSAGE: configurating LiveObjects...
base:6 MESSAGE: starting autoSaveThread...
base:7 MESSAGE: Launching the ExportedSlave
base:8 MESSAGE: localRoot exported !
master:18
MESSAGE: registrating rmi://carinae.inria.fr:7799/slave ...
base:9 MESSAGE: registration was successful !
base:10 MESSAGE: slave base ready!
9.3.5
Ddebugger
Ddebugger a été développé dans un pur besoin d’implémentation, de test et de
debuggage des serveurs Maître et Esclave. Il permet d’avoir une idée sur leur objets
importés, exportée, live et caches ainsi que les objets RMI qui ont été enregistrés.
Ddebugger (version 1.0)
Type !help for help
>!help
! exit
: exit from Ddebugger
! help
: get this help
! connect RMI_LOCATION : connects to the Exported System at the specified location
! disconnects : disconnects from the Exported System
! list RMI_LOCATION : list rmi bound IDs at the specified location.
Nota bene :
Commands begenning with (!) are interpreted locally by the debugger,
While others are dispatched to the Exported System.
>!list rmi://carinae.inria.fr
master
superuser
superdomain
supergroup
nogroup
guest
oneSlave
oneSlaveLocalroot
>! Connect master
>cachedObjects max
30
>cachedObjects size
2
>cachedObjects list
CACHED OBJECTS ON master{
Superdomain.inria.Ali
Root.oneSlave.AliFile
}
>!exit
exiting doovos
Ecole Nationale des Sciences de l’Informatique de Tunisie
69
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
9.4 Intégration dans l’Applet
Au niveau de l’Applet, une base de connaissance est désormais vue et manipulée
comme un objet du système  . Elle est représentée par un objet appelé
KnowledgeBase. Les informations peuvent alors être manipulées si et seulement si,
l’utilisateur (défini par son nom, son mot de passe et son domaine parent pendant la
phase d’initialisation de l‘Applet) a le droit de le faire.
9.5 Performances du Système
Au niveau logiciel, j’ai choisi, compte tenu de publications sur Internet concernant les
moteurs de Servlets, un serveur HTTP 100 % Java (Jetty) permettant d’optimiser
nettement les performances du système. En effet utiliser des Servlets Java sur un
Serveur HTTP en code natif (C ou C++) comme un serveur Apache par exemple,
rajoute un certain handicap au serveur à cause de la nécessité du passage du code Java
au code natif et réciproquement (via la Java Native Interface JNI). On trouvera au
niveau de l’annexe une comparaison entre quelques serveurs HTTP du marché, dont
Jetty.
En ce qui concerne le développement, j’ai essayé d’optimiser les performances à chaque
fois que le temps et l’occasion le permettaient. Ainsi, pour la vérification d’une
permission par exemple, un cache a été utilisé ce qui accélère énormément ce processus.
En effet, la vérification des permissions est récursive car si on trouve qu’il y a bien un
signataire qui a accordé des droits à un utilisateur, il faut aussi vérifier que ces mêmes
droits ont bien été accordées à ce signataire. Sans cache cela peut alourdir
considérablement le système, surtout que la vérification des permissions se fait pour
toute opération sur tout objet du système.
Ce cache se construit au fur et à mesure qu’on vérifie les permissions et est ré-initialisé
(à la liste vide) à chaque altération de ces permissions (ajout, retrait, modification de
permissions).
Le cache a également été utilisé au niveau de LocalSystemManagerInterface
(implémentée par AbstractSystemManager) pour ne pas avoir à réimporter,
réexporter ou recharger du disque les mêmes objets avec les listes cahedObjects,
LiveObjects, ImportedObjects et exportedObjects.
En outre, vu que DobjectLocator est l’objet le plus utilisé au niveau du système puis
qu’il est l’identifiant de tout objet, le plus grand soin a alors été pris - au niveau de son
implémentation – pour optimiser son code en utilisant par exemple la notion de code de
hachage et de tri des attributs pour que la comparaison entre deux DobjectLocator soit
suffisamment rapide.
De plus la gestion des Handlers a également été optimisée aussi bien au niveau du code
qu’au niveau de l’exécution : on n’a pas besoin de créer un Handler pour chaque classe,
Ecole Nationale des Sciences de l’Informatique de Tunisie
70
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
il suffit de créer un Handler par interface (ce qui n’est pas le cas avec le rmic, le
compilateur du RMI) . De plus, le système en cours d’exécution est capable de
reconnaître quel est le meilleur Handler pour un objet donné et d’en créer
automatiquement une nouvelle instance.
Ecole Nationale des Sciences de l’Informatique de Tunisie
71
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
10 Conclusion
En conclusion, le système (des serveurs suivant une certaine architecture) qui a été
développé:
 permet à plusieurs groupes de scientifiques de partager leurs ressources.
 propose la protection de ces ressources via des mécanismes d’authentifications et
d’attribution de permissions.
 permet une administration partagée entre plusieurs administrateurs.
 est parfaitement portable sur tout environnement et plate-forme reconnaissant Java.
 se base sur une conception par composants (grâce au interfaces Java).
 Simplement paramétrable et configurable (avec un fichier externe de configuration).
 simplifie un futur développement avec plusieurs paquetages riches en classes et
interfaces réutilisables ainsi que plusieurs outils pour la génération automatiques de
certaines classes.
Le projet est très ambitieux et perfectible, des améliorations pourraient être réalisées en
ce qui concerne:
 l’optimisation - encore - des performances.
 l’amélioration de l’interface Homme-Machine pour l’administration du système
(ProgramSupervisionServlet)
 éventuellement, remplacement de la partie RMI avec CORBA pour encore plus
d’interopérabilité.
 définition de la politique de sécurité (seuls les mécanismes de protection ont été
définit).
Enfin, je tiens à exprimer mon réel plaisir d’avoir travaillé dans un établissement tel que
l’INRIA avec ces capacités intellectuelle (des scientifiques de très haut niveaux) et
matérielles (des machines très performantes). En effet, cela m’a permis, sur le plan
scientifique d’améliorer nettement mes connaissances (surtout en Unix) mais aussi sur
le plan social, en travaillant avec de grands spécialistes et de véritables scientifiques
acharnés (toujours des projets et des conférences).
Ecole Nationale des Sciences de l’Informatique de Tunisie
72
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
11 Bibliographie
11.1
Articles
 Résolution de problèmes en pilotage de programmes
S. Moisan & D. Ziéblin (RFIA 2000)
 Experience in Integerating Image Processing Programs
M. Thonnat, S. Moisan & M. Crubézy (1st international Conference on ICVS’99),
1997
 Knowledge-based control of vision systems
C. Shechar, S.Moisan, R. Vincent, P. Burlina & R. Chellapa (Image and vision
computing), 1998
 Une plate-forme pour une programmation par composants de systèmes à base de
connaissances
S. Moisan (Habilitation à diriger les recherches, Université de Nice), 1998
 Program Supervision under Resource Constraints
S. Moisan & M. Thonnat (3rd Europeen Conference on Artificial Intelligence
ECAI98. Workshop on Monitoring and Control of Real-Time Intelligent
Systems), 1998
11.2
Ouvrages
 [1] Open Systems
Gary J. Nutt, Prentice Hall, Englewood Cliffs, 1992
 [2] Java threads
Scott Oaks & Henry Wong, …
 [3] Windows NT User Administration
Ashley J.Meggih & Timothy D.Ritchey, O’Reilly, 1997
 [4] Practical File System : Design for the Be File System
Dominic Giampaolo, …, …
 [5] Password Security : A Case History
Robert Morris & Ken Thompson
Ecole Nationale des Sciences de l’Informatique de Tunisie
73
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
 [6] Practical Unix Security
Simpson Grafinkel & Gene Spafford, O’Reilly & Associates Inc., 1991
 [7] Client/Server Programming with Java and Corba
Robert Orfali & Dan Harkey
 [8] The Java language Spécifications
James Gosling, Bill Joy & Guy Steele, Addison-Wesley 1996
 [9] Windows NT in a nutShell
Eric Pearce, O’Reilly 1997
11.3
Adresses Internet
 Java
http://java.sun.com/products/jdk/1.2/docs/index.html
http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/java.html
http://java.sun.com/products/jdk/1.1/docs/
http://www.javasoft.com/products/jdk/1.1/docs/guide/serialization/spec/serialTOC.d
oc.html
http://java.sun.com/docs/books/tutorial/essential/
 RMI
spécifications
http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html
 Servlets Java
- spécifications
http://java.sun.com/products/servlet/2.1/api/packages.html
- serveurs
http://www.mortbay.com/software/Jetty.html
http://www.tapsellferrier.co.uk/gnupaperclips/index.html
- tutorial
http://www.desertwind.com/Abbey/mm/jserv/jservBasics01/httpServlet.htm
http://www.e-oasis.com/rmiug-jobs/
http://nt-server-0.npu.edu/advjava/servlet/index_servlet.html
-comparatif
http://www.mortbay.com/software/iX.html
 html
http://labrocca.com/htmlementary/
http://java.sun.com/docs/books/jls/html/index.html
http://alumni.chihlee.edu.tw/htmltag/tagsix.htm
Ecole Nationale des Sciences de l’Informatique de Tunisie
74
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
http://www.cafe.edu/www-tags/
http://scitsc.wlv.ac.uk/encyc/th.html
- spécifications
http://www.w3.org/TR/REC-CSS1
 java script
http://developer.netscape.com/docs/manuals/js/client/index.html
 applets, tag EMBED (pour Java 1.2)
http://java.sun.com/docs/books/tutorial/uiswing/start/AppletDemo.html
http://java.sun.com/products/jfc/tsc/articles/plugin/
http://java.sun.com/docs/books/tutorial/uiswing/start/swingApplet.html
http://java.sun.com/products/plugin/1.3/docs/intranet.html
http://java.sun.com/docs/codeconv/html/
 Systèmes d’exploitations orientés objets
http://web-sites.co.uk/jules/moscow/
Ecole Nationale des Sciences de l’Informatique de Tunisie
75
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
12 Annexe A : la hiérarchie des classes et des
interfaces développées
Notations :
Les notations qui suivent sont applicables aussi bien aux classes qu’aux interfaces :
 Les niveaux de hiérarchie sont à interpréter suivant l’indentation : une
indentation a droite signifie que la classe en question dérive (au sens de
l’héritage objet) de la classe qui la précède.
 Les classes développées dans le cadre de ce stage sont précédées du mot clé
class (ou interface pour les interfaces) en gras. Les autres (de la bibliothèque
standard Java ou d’autres bibliothèques comme ce) sont sans le gras. Elles ont
été rajoutées à titre indicatif.
 La nomenclature des classes sera en absolu, c’est-à-dire précédée par le nom
de paquetage auquel appartient cette classe. Le nom effectif de la classe sera
en gras.
Exemple : dans « vpc.doovos.system.AbstractSystemManager », vpc.doovos.system
est le paquetage et AbstractSystemManager est le nom de la classe.
 Pour chaque classe on spécifiera entre parenthèses, le cas échéant, les
interfaces qu’elle implémente. Et pour chaque interface, on spécifiera entre
parenthèses, le cas échéant, les interfaces qu’elle étend.
Hiérarchie des classes
class java.lang.Object
class vpc.doovos.system.AbstractSystemManager (implements vpc.doovos.Dconstants,
vpc.doovos.system.LocalSystemManagerInterface, java.io.Serializable)
class vpc.doovos.system.GenericClientSystemManager
class vpc.doovos.system.MonoClientSystemManager
class vpc.doovos.system.MultiClientSystemManager
class vpc.doovos.system.MasterSystemManager (implements java.io.Serializable)
class vpc.doovos.system.SlaveSystemManager (implements java.io.Serializable)
class vpc.doovos.system.AbstractSystemManager.AbstractTable (implements java.io.Serializable)
class vpc.doovos.system.AbstractSystemManager.CachedObjects
class vpc.doovos.system.AbstractSystemManager.ExportedObjects
class vpc.doovos.system.AbstractSystemManager.ImportedObjects
class vpc.doovos.system.AbstractSystemManager.LiveObjects
class vpc.doovos.util.ArraysComparator (implements java.util.Comparator)
class vpc.doovos.util.ArrayTable
class vpc.doovos.util.CommandLineArguments
class vpc.doovos.Dconnection (implements java.lang.Comparable, java.io.Serializable)
class vpc.doovos.tool.Ddebugger
class vpc.doovos.system.DdebuggerHandler (implements java.io.Serializable)
Ecole Nationale des Sciences de l’Informatique de Tunisie
76
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
class vpc.doovos.util.DeductiveFactory
class vpc.doovos.util.DeductiveFactory.AbstractCollection (implements
vpc.doovos.util.DeductiveFactory.CollectionInterface,
vpc.doovos.util.ReverseDeductive)
class vpc.doovos.util.DeductiveFactory.Collection_AND
class vpc.doovos.util.DeductiveFactory.Collection_FIRST
class vpc.doovos.util.DeductiveFactory.SortedCollection_FIRST
class vpc.doovos.util.DeductiveFactory.Collection_OR
class vpc.doovos.util.DeductiveFactory.Always (implements vpc.doovos.util.Deductive)
class vpc.doovos.util.DeductiveFactory.Collection_CANONIC (implements
vpc.doovos.util.DeductiveFactory.CollectionInterface,
vpc.doovos.util.ReverseDeductive)
class vpc.doovos.util.DeductiveFactory.Criteria (implements vpc.doovos.util.Deductive)
class vpc.doovos.util.DeductiveFactory.DateIntervalle (implements vpc.doovos.util.Deductive)
class vpc.doovos.util.DeductiveFactory.MultipleCriteria (implements vpc.doovos.util.Deductive)
class vpc.doovos.util.DeductiveFactory.Mute (implements vpc.doovos.util.Deductive)
class vpc.doovos.util.DeductiveFactory.Never (implements vpc.doovos.util.Deductive)
class vpc.doovos.util.DeductiveFactory.Not (implements vpc.doovos.util.ReverseDeductive)
class vpc.doovos.object.Dobject (implements java.lang.Comparable, vpc.doovos.Dconstants,
vpc.doovos.DobjectInterface, java.io.Serializable)
class vpc.doovos.object.AbstractContainer (implements vpc.doovos.DcontainerInterface)
class vpc.doovos.object.Ddirectory (implements vpc.doovos.DdirectoryInterface)
class vpc.doovos.system.DEFAULT_LOCAL_ROOT
class vpc.doovos.system.DEFAULT_ROOT (implements vpc.doovos.DdirectoryInterface)
class vpc.doovos.object.Ddomain (implements java.lang.Comparable, vpc.doovos.DdomainInterface)
class vpc.doovos.system.DEFAULT_SUPER_DOMAIN (implements vpc.doovos.DdomainInterface)
class vpc.doovos.object.Dresource (implements vpc.doovos.DresourceInterface)
class vpc.doovos.object.Dfile (implements vpc.doovos.DfileInterface)
class vpc.doovos.object.KnowledgeBase (implements vpc.doovos.KnowledgeBaseInterface)
class vpc.doovos.object.Dgroup (implements vpc.doovos.DgroupInterface)
class vpc.doovos.system.DEFAULT_NO_GROUP (implements vpc.doovos.DgroupInterface)
class vpc.doovos.system.DEFAULT_SUPER_GROUP (implements vpc.doovos.DgroupInterface)
class vpc.doovos.object.Duser (implements vpc.doovos.DuserInterface)
class vpc.doovos.system.DEFAULT_GUEST (implements vpc.doovos.DuserInterface)
class vpc.doovos.system.DEFAULT_SUPER_USER (implements vpc.doovos.DuserInterface)
class vpc.doovos.DobjectLocator (implements java.lang.Comparable, vpc.doovos.Dconstants,
vpc.doovos.util.Deductive, java.io.Serializable)
class vpc.doovos.DobjectLocator.Tokenizer
class vpc.doovos.util.DobjectLocatorFactory
class vpc.doovos.util.DobjectLocatorFactory.Double_Matcher (implements vpc.doovos.util.Matcher)
class vpc.doovos.util.DobjectLocatorFactory.Reverse_Matcher (implements vpc.doovos.util.Matcher)
class vpc.doovos.util.DobjectLocatorFactory.Simple_Matcher (implements vpc.doovos.util.Matcher)
class vpc.doovos.tool.Doovos
class vpc.doovos.Dsystem (implements vpc.doovos.Dconstants)
class com.mortbay.HTML.Element
class com.mortbay.HTML.Composite
class com.mortbay.HTML.Block
class com.mortbay.HTML.Table
class vpc.www.html.EasyTable
class vpc.doovos.util.FileFactory
class vpc.doovos.util.FileFactory.ByName (implements java.io.FilenameFilter)
class vpc.doovos.util.FilterFactory
class vpc.doovos.util.FilterFactory.ByClass (implements vpc.doovos.DobjectFilter)
class vpc.doovos.util.FilterFactory.ByLocation (implements vpc.doovos.DobjectFilter)
class vpc.doovos.util.FilterFactory.Collection_AND (implements vpc.doovos.DobjectFilter)
class vpc.doovos.util.FilterFactory.Collection_OR (implements vpc.doovos.DobjectFilter)
class vpc.doovos.util.FilterFactory.NoFilter (implements vpc.doovos.DobjectFilter)
class vpc.doovos.util.FilterFactory.SupervisedBy (implements vpc.doovos.DobjectFilter)
class vpc.doovos.util.FilterFactory.Supervisor (implements vpc.doovos.DobjectFilter)
class vpc.doovos.util.Grep
class vpc.doovos.tool.Handler_Generator
class vpc.doovos.util.Lock
class vpc.doovos.OperationEvent (implements java.io.Serializable)
Ecole Nationale des Sciences de l’Informatique de Tunisie
77
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
class vpc.doovos.util.OUT
class vpc.doovos.util.Parser
class vpc.doovos.tool.JHTML_Generator
class vpc.doovos.tool.TemplateGenerator
class vpc.doovos.Permissions (implements vpc.doovos.Dconstants, java.io.Serializable)
class vpc.doovos.Permissions.Entry (implements java.io.Serializable)
class java.rmi.server.RemoteObject (implements java.rmi.Remote, java.io.Serializable)
class java.rmi.server.RemoteServer
class java.rmi.server.UnicastRemoteObject
class vpc.doovos.system.ExportedMaster (implements vpc.doovos.Dconstants,
vpc.doovos.system.ExportedMasterInterface,
java.io.Serializable)
class vpc.doovos.system.ExportedSlave (implements vpc.doovos.Dconstants,
vpc.doovos.system.ExportedSystemInterface, java.io.Serializable)
class vpc.doovos.util.RenderingManager
class vpc.doovos.util.SimpleRenderer (implements javax.swing.Renderer)
class vpc.doovos.util.StreamTranslator
class vpc.doovos.util.StringComparator (implements java.util.Comparator)
class java.lang.Thread (implements java.lang.Runnable)
class vpc.doovos.system.AbstractSystemManager.AutoSaveThread
class java.lang.Throwable (implements java.io.Serializable)
class java.lang.Exception
class vpc.doovos.util.AlreadyLockedException
class vpc.doovos.DoovosGeneralFailureException
class vpc.doovos.util.WClass
class vpc.doovos.util.WDeductive
class vpc.doovos.util.WException
class vpc.doovos.util.Wizard (implements vpc.doovos.Dconstants)
class vpc.doovos.util.WNumber
class vpc.doovos.util.Wrmi
class vpc.doovos.util.WString
class vpc.doovos.util.WString.Formatter (implements vpc.doovos.util.WString.FormatterInterface)
Hiérarchie des interfaces
interface java.lang.Cloneable
interface vpc.doovos.util.Deductive(also extends java.io.Serializable)
interface vpc.doovos.util.DeductiveFactory.CollectionInterface
interface vpc.doovos.util.ReverseDeductive
interface vpc.doovos.Dconstants
interface vpc.doovos.DcontainerInterface
interface vpc.doovos.DdirectoryInterface(also extends vpc.doovos.DresourceInterface)
interface vpc.doovos.DdomainInterface(also extends vpc.doovos.DauthentificatorInterface)
interface vpc.doovos.system.LocalSystemManagerInterface
interface vpc.doovos.util.Matcher
interface vpc.doovos.util.ParsableAsStringInterface
interface java.rmi.Remote
interface vpc.doovos.DobjectInterface(also extends java.io.Serializable)
interface vpc.doovos.DauthentificatorInterface
interface vpc.doovos.DdomainInterface(also extends vpc.doovos.DcontainerInterface)
interface vpc.doovos.DgroupInterface
interface vpc.doovos.DuserInterface
interface vpc.doovos.DresourceInterface
interface vpc.doovos.DdirectoryInterface(also extends vpc.doovos.DcontainerInterface)
interface vpc.doovos.DfileInterface
interface vpc.doovos.BytesFileInterface
interface vpc.doovos.KnowledgeBaseInterface
interface vpc.doovos.ObjectFileInterface
interface vpc.doovos.system.ExportedSystemInterface
interface vpc.doovos.system.ExportedMasterInterface
interface vpc.doovos.util.RenderedObjectInterface
Ecole Nationale des Sciences de l’Informatique de Tunisie
78
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
interface java.io.Serializable
interface vpc.doovos.util.Deductive(also extends java.lang.Cloneable)
interface vpc.doovos.util.DeductiveFactory.CollectionInterface
interface vpc.doovos.util.ReverseDeductive
interface vpc.doovos.DobjectFilter
interface vpc.doovos.DobjectInterface(also extends java.rmi.Remote)
interface vpc.doovos.DauthentificatorInterface
interface vpc.doovos.DdomainInterface(also extends vpc.doovos.DcontainerInterface)
interface vpc.doovos.DgroupInterface
interface vpc.doovos.DuserInterface
interface vpc.doovos.DresourceInterface
interface vpc.doovos.DdirectoryInterface(also extends vpc.doovos.DcontainerInterface)
interface vpc.doovos.DfileInterface
interface vpc.doovos.BytesFileInterface
interface vpc.doovos.KnowledgeBaseInterface
interface vpc.doovos.ObjectFileInterface
interface vpc.www.servlet.SubServletInterface
interface vpc.doovos.util.WString.FormatterInterface
Ecole Nationale des Sciences de l’Informatique de Tunisie
79
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
13 Annexe B : Comparatif entre moteurs de
Servlets
Le magazine Allemand "iX Magazine" a réalisé un comparatif entre 6 moteurs de
Servlet (servlet Engine)
 ServletExec 2.2 (sur Apache 1.3.9)
 Jetty 2.2.4
 Java Webserver 2.0
 Jserv 1.0 (sur Apache 1.3.6)
 Jigsaw 2.0.3
 JRun Pro 2.3.2 (sur Apache 1.3.6)
Les résultats sont à interpréter en nombre maximum atteint des requêtes par seconde
indépendamment du protocole (FTP,HTTP…).
Server
Jetty 2.2.4
Jigsaw 2.0.3
Java Webserver
2.0
JSERV 1.0
JRUN
PRO
2.3.2
Servlet Exec 2.2
FileServlet with
FileServlet
Contentwithout ContentLength set
Length header
189
210
181
184
HelloWorld
servlet
APIMethodTe
st Servlet
250
262
175
137
166
152
105
174
93
91
104
99
68
72
115
72
54
53
70
67
Discussion:
On remarqu’alors que les serveur 100% java sont 2 fois plus rapides, Jetty étant (en
somme) le plus rapide (quoi que Jigsaw soit arrivé à le surpasser avec "Hello world").
Ecole Nationale des Sciences de l’Informatique de Tunisie
80
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
14 Annexe C : utilisation de l’API
exemple
INRIA
doovos,
Voici un exemple de l’utilisation de l’API developpée.
Il permet de lister récursivement le contenu du repertoire root.esclave1.Kbrep et de
changer les permissions de la ressource root.esclave1.Kbrep.kb1
Une numérotation des lignes a été ajoutée par soucis de clarté
1. Dsystem.setSystem(new MonoClientSystemManager());
2. Dconnection moi = Dsystem.connect(‘superdomain.mondomaine.monNom’, ’monMot2Passe’);
3. DdirectoryInterface KBrep = Dsystem.getObjectCopy(‘root.esclave1.KBrep’);
4. Collection toutesLesBases = KBrep.list(moi,NO_FILTER,true);
5. KnowledgeBaseInterface kb1 = Dsystem.getObject(‘root.esclave1.Kbrep.kb1’);
6. kb1.setPermissions(moi, ‘-.(user)Ali’, ’read’, true);
7. Dsystem.freeObject(kb1);
8. Dsystem.disconnect(moi);
9. Dsystem.unsetSystem();
Le scénario est le suivant :
D’abord, on se déclare comme étant un client en mono-utilisateur (donc au niveau de
cette application on ne peut pas avoir deux utilisateurs qui ont accès au système en
même temps) (1). Cela permet au système local de s’initialiser. En l’occurrence,
contacter le Maître et réaliser la communication.
Cette opération est réalisée une seule fois au niveau de l’application.
Ensuite (2), pour ouvrir une session (pour accéder au ressources du système), on se
logge en donnant l’identificateur complet de l’utilisateur ainsi que son mot de passe.
On récupère alors un objet temporaire (moi) permettant de bénéficier des droits qui sont
accordée à cet utilisateur.
Puis, pour lister le contenu du répertoire KBrep(3), il suffit d’en demander une copie au
système local (Attention : elle peut ne pas être à jour), puis d’appliquer la méthode list
sur l’objet obtenu (4). Les paramètres de cette méthode indiquent, dans l’ordre,
l’utilisateur qui désire réaliser l’action, le modèle que doit vérifier une ressource de
KBrep pourqu’elle sot listée (ici toutes les entrées peuvent être listée à condition que les
permissions le permette) et si le listing doit se faire récursivement (lister aussi le
contenu des sous répertoires vérifiant le filtre).
Au niveau de (5), on obtient une référence ‘live’ root.esclave1.Kbrep.kb1’ c’est à dire qui
est forcément à jour et qu’on peut réellement modifier à distance. Ainsi, au niveau de
Ecole Nationale des Sciences de l’Informatique de Tunisie
81
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
(7), les permissions pourraient être changée (s’il y a droit) pour accorder les permissions
de lire cette ressource à tout utilisateur nommé Ali.
Il est essentiel de noter que Kb1 doit être libéré explicitement (7). Ce qui n’est pas le
cas de KBrep qui est juste une copie.
Ensuite, on doit se déconnecter(8) pour éventuellement ouvrir une nouvelle session sous
un autre nom.
Avant de quitter l’application, il faut libérer le système(9) ce qui revient à l’interruption
de toute communication avec le Maître.
Ecole Nationale des Sciences de l’Informatique de Tunisie
82
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
15 Annexe D : configuration des Serveurs,
exemple
Les serveurs Maître, et Esclaves peuvent être configurés grâce à plusieurs propriétés.
Cela permet par exemple de limiter le nombre d’objets qu’on peut importer ou qu’on
peut exporter par crainte que le processus Serveur utilise trop de ressources système
(mémoire). Cela permet également de paramétrer les adresses réseau du serveur, les
ports utilisées, etc., nécessaires à la communication.
Ainsi, la propriété cachedObjects.maxObjects donne le nombre maximum des objets en
cache.
La configuration peut se faire au niveau du code, grâce à la méthode
Dsystem.setProperties(…) ;
Ou plus souplement dans un fichier sous forme d’une suite de nom=valeur
Ce qui suit est un fichier de configuration du serveur Maître donné à titre d’exemple.
Notons, seulement que plusieurs propriétés sont commentées. Elles indiquent les
valeurs par défaut.
##### the name of the system
## it must correspond to the "rmi.master.name" entry of a Client
## and/or Slave configuration file
##
name=master
##### the remote location in which all remote objects
## will be looked for.
## it must correspond to the "rmi.master" entry of a Client
## and/or Slave configuration file
##
rmi=rmi://comete:7799
##### the remote identifiers of the basic objects exported by the master
## it will be more secure if they are not significative!
##
rmi.name=master
rmi.superuser=superuser
rmi.guest=guest
rmi.supergroup=supergroup
rmi.nogroup=nogroup
rmi.superdomain=superdomain
rmi.root=root
## other possible options
##### the root directory for all serialized objects
##
#serialisation.root=.
##### name patterns for the serialized objects
## for example when serialisation.class.DdomainInterface=*.__D
## all DomainInterface objects will be serialized in files with
## extension .__D
##
Ecole Nationale des Sciences de l’Informatique de Tunisie
83
Conception & réalisation d’un outil sécurisé pour la gestion des ressources distribuées sur Internet :
Application au pilotage de programmes
INRIA
#serialisation.class.DdomainInterface=*.__D
#serialisation.class.DuserInterface=*.__U
#serialisation.class.DgroupInterface=*.__G
##### when an object is serialized as a directory, a file with
## the following pattern will contains the serialized form of
## that object. This file will be directly in the directory
##
#serialisation.dirinfo=.__I
##### limits for the object tables
## -1 means there is no limit
## example cachedObjects.maxObjects=30 means that the cached object
## is limited to 30
##
#importedObjects.maxObjects=-1
#exportedObjects.maxObjects=-1
#liveObjects.maxObjects=-1
#cachedObjects.maxObjects=30
##### the period for auto saving objects
## it is considered in milliseconds (a long)
##
#autoSaveThread.sleepingPeriod=300000
Ecole Nationale des Sciences de l’Informatique de Tunisie
84