Du Client/Serveur aux architectures de grilles de calculs et de données Laurent Bobelin, CS-SI

Plan du cours Motivation générale Les différents types de parallélisme Les architectures parallèles et distribuées Les environnements de programmation parallèle Les paradigmes systèmes distribués grande échelle et de grille Architecture des grilles de calcul et de données Perspectives pour les grilles de calcul et de données

Plan : Motivation générale Les besoins Physique Des confins de la matière jusqu’à la simulation des surfaces Sciences de la terre Observation de la terre Biologie Analyse du génome humain Conception Assistée par Ordinateur Modélisation automobile Autres Débouchés industriels Industriels intéressés Les fournisseurs de services Les fournisseurs de ressources Les applications Les profils industriels Conseil Maîtrise d’œuvre Conception, déploiement et administration Middlewares Application Exploitation

Motivation générale : Les besoins : Physique Large Hadron Collider Modélisation de surface Applications nucléaires

Motivation générale : Les besoins : Physique : LHC Le CERN (Centre d’Etude et de Recherche Nucléaire) basé en Suisse, est le plus grand centre mondial de recherche en Physique des Hautes Energies et en physique des particules. Le Large Hadron Collider (LHC) est un projet du CERN : construire le plus puissant accélérateur de particule au monde, qui devrait être achevé en 2007. Le but : faire entrer en collision des protons et analyser les traces de cette collision pour prouver l’existence de particules sous-jacente, les bosons de Higgs

Motivation générale : Les besoins : Physique : LHC Le LHC est constitué d’une boucle de 20km de diamètre, dans laquelle sont injectés des protons. Le long de cette boucle, des capteurs sont disposés pour percevoir les traces de particules.

~103 batch and interactive users Le LHC : The LHC Detectors CMS ATLAS ~6-8 PetaBytes / year ~108 events/year ~103 batch and interactive users LHCb

Motivation générale : Les besoins : Physique : LHC L’ensemble des capteurs une fois le LHC opérationnel générera plusieurs péta-octets de données par an, qu’il faudra analyser et stocker. Le CERN est donc de facto un des plus grands acteurs des projets de recherche de grille européen.

Motivation générale : Les besoins : Physique : Modélisation de surface Modéliser une surface permet de prédire les changements climatiques. La structure des sols peut varier et induit des changements La végétation à une influence Plus le modèle est fin, plus la modélisation de surface est pertinente.  Plus les ressources informatiques mises à disposition de l’application sont importantes, meilleure sera la modélisation.

Motivation générale : Les besoins : Physique : Application nucléaire Modéliser le comportement du cœur d’un réacteur nucléaire Analyse des points chauds Modélisation des matériaux et de leur résistance Prédire le comportement en cas d’incident  De même que pour le cas précédent, plus les ressources informatiques mises à disposition de l’application sont importantes, meilleure sera la modélisation.

Motivation générale : Les besoins : Observation de la terre Envoi de satellite pour observer la terre Les challenges des projets ESA : Environ 100 Gbytes de données par jour pour la mission(ERS 1/2) 500 Gbytes, pour la mission ENVISAT (2002). Source: L. Fusco, June 2001

Motivation générale : Les besoins : Biologie Bio-informatique : Phylogenetique Search for primers Statistiques génétiques Parasitologie Data-mining sur des bases ADN Comparaison géometrique protéinique Imagerie Médicale Modélisation et imagerie numérique Medical data and metadata management Analyse de mammographies Medical images Exam image patient key ACL ... 1. Query the medical image database and retrieve a patient image Metadata 3. Retrieve most similar cases Similar images Low score images 2. Compute similarity measures over the database images Submit 1 job per image

Motivation générale : Les besoins : Conception Assistée par Ordinateur Automobile : Construire un prototype est d’un coût très élevé Des défauts de conception peuvent apparaître à la construction du prototype De nombreux tests sur la sécurité, la vitesse, etc, peuvent demander de construire de nombreux prototypes.  Nécessité de modéliser finement les prototypes pour baisser le coût de conception d’un nouveau modèle

Motivation générale : Les besoins : Autres Renault : simulations, modélisation, Météorologie et climatologie Industries Aéronautiques simulation et modélisation, réalité virtuelle Simulation grandes échelle : tectonique, modèles atmosphériques… EDF : simulation Temps-réel ONERA : simulation de phénomènes physiques

Motivation générale : Débouchés industriels Industriels intéressés Les fournisseurs de services Les fournisseurs de ressources Les applications Profils industriels Conseil Maîtrise d’œuvre Conception, déploiement et administration Middlewares Application Exploitation

Motivation générale : Débouchés industriels : Industriels intéressés Les fournisseurs de services : Entreprise ayant pour activité de vendre des services (stockage, calcul, hébergement) IBM par exemple. Les fournisseurs de ressources Entreprise voulant rentabiliser les ressources informatiques qu’elle possède, comme CGG. Les applications Entreprise voulant entreprendre des calculs de grande échelle

Motivation générale : Débouchés industriels : Industriels intéressés : Les fournisseurs de services Les besoins des ressources sont multiples : calcul, stockage, intégration, portage, administration, mise en œuvre, développement de solutions logicielles ad-hoc. Quatre types : Ressources : Grandes entreprises informatiques proposant des solutions « tout-en-un » (IBM) Logiciels : Entreprises fournissant des logiciels génériques pour les grilles (Sun, Microsoft, …) et voulant dominer le marché. Les SSII : conseil, développement,maintenance, migration, etc. (CSSI, Atos, …)

Motivation générale : Débouchés industriels : Industriels intéressés : Les fournisseurs de ressources Certains industriels possèdent un grand nombre de ressources (calcul, stockage) inutilisées : Ordinateurs « personnels » Ressources aléatoires dans leur nombre et leur disponibilités Ressources contraintes par le temps Analyse à un instant T demandant beaucoup de ressources, mais peu utilisées le reste de la journée CGG, météorologie Ces ressources peuvent être vendues aux applications nécessitant beaucoup de ressources.

Motivation générale : Débouchés industriels : Industriels intéressés : Les applications Industriels ayant besoin d’un grand nombre de ressources : Simulation : PSA, EDF, CEA, … Prédiction : météorologie (Méteo de France, CGG) Nécessité de migrer leurs applications Nécessité d’améliorer les performances de leurs applications Rester/devenir les leaders sur leur marché

Motivation générale : Débouchés industriels : Les profils industriels Conseil :étude d’opportunité, expression des besoins, réalisation de cahier des charges. Maîtrise d’œuvre et assistance à la maîtrise d’ouvrage. Conception, déploiement et administration des infrastructures de grille. Middlewares : développement,adaptation, installation. Application : développement, adaptation. Exploitation :gestion, évolution.

Motivation générale : Débouchés industriels : Les profils industriels : conseil étude d’opportunité : est-il utile pour une application d’être migrée vers une technologie de grille ? expression des besoins : quels sont les besoins d’une application ? réalisation de cahier des charges : comment peut-on faire, et dans quel délais peut on obtenir un résultat ?

Motivation générale : Débouchés industriels : Les profils industriels : maîtrise d’œuvre et assistance à la maîtrise d’ouvrage Maîtrise d’œuvre : Coordination, relations entre la problématique applicative et les technologies de grille Besoins lors de la migration ou du portage d’application sur grille

Motivation générale : Débouchés industriels : Les profils industriels : Conception, déploiement et administration des infrastructures de grille Conception : quelle est la meilleure architecture pour un ensemble d’applications donné ? Déploiement : comment utiliser les ressources ? Administration : comment faire en sorte que les ressources restent opérationnelles ?

Motivation générale : Débouchés industriels : Les profils industriels : middleware Développement : un middleware adapté aux besoins Adaptation : un middleware existant, l’adapter aux besoins Déploiement : rendre l’utilisation effective

Motivation générale : Débouchés industriels : Les profils industriels : Applications Développement : Les grilles ont des spécificités qui sortent du domaine du calcul parallèle classique Nécessité de développer des applications tirant un profit maximum des ressources Adaptation : Des applications peuvent bénéficier d’une « gridification » : comment l’adapter aux problématiques grilles ?

Motivation générale : Débouchés industriels : Les profils industriels Exploitation : Gestion : gérer et administrer une grille dans une entreprise, veiller a son bon fonctionnement, gérer les utilisateurs Évolution : redimensionner une grille, faire évoluer son middleware et les logiciels associés.

Plan : Les différents types de parallélisme Introduction au parallélisme Les différents types de parallélisme Granularité

Introduction au parallélisme utiliser plusieurs ordinateurs ensemble pour résoudre des problèmes plus gros (taille mémoire, espace disque) plus rapidement (puissance CPU) Mot clé : efficacité Différents domaines théoriques algorithmique ordonnancement pratiques supports modèles si on veut de l ’efficacité les deux sont évidemment liées

Les différents types de parallélisme Client/serveur Parallélisme de tâche : application exhibant un graphe de tâches dont certaines peuvent être effectuées en parallèle Parallélisme de données : application qui traite de la même façon plusieurs jeux de données. Parallélisme mixte : application exhibant du parallélisme de données et de tâches Parallélisme massif : application exhibant un gros potentiel parallèle

Granularité On appelle granularité la « taille » d’un traitement séquentiel dans une application parallèle Cette granularité dépend non seulement de l’application, mais aussi de son implémentation On parle de « gros grain » pour les applications ayant une forte exécution séquentielle Fréquence de communication moins grande Pas forcement moins gourmande en débit ! On parle de « grain fin » pour les applications ayant une forte exécution parallèle de tâche Plus sensible à la latence du réseau

Granularité Sous-Populations Parallélisation à gros grain SP1 SP2 Division SP4 SP3 Parallélisation à grain fin Processeurs A B C Pour paralléliser un algorithme évolutionnaire, il y a principalement deux approches : La première à gros grain, consiste à diviser la population en autant de sous-populations que de processeurs, chaque processeur exécutant ensuite l ’algorithme considéré sur sa sous-population. Il peut éventuellement y avoir des communications afin de permettre la migration d ’individus entre sous-populations. La seconde approche, qui est à grain fin, se traduit par un algorithme dit data-parallèle. Elle repose sur la distribution de la population à raison d ’un individu par processeur et la parallélisation des différentes étapes de l ’algorithme évolutionnaire. Individus A B C D E F Distribution D E F

Plan : Les architectures parallèles et distribuées Les multiprocesseurs Les clusters Les environnements hétérogènes Les centres de calcul

Les multiprocesseurs – pourquoi En supposant que les microprocesseurs demeurent la technologie dominante pour les uniprocesseurs, il semble naturel d’imaginer en connecter plusieurs ensemble pour augmenter la performance Il n’est pas clair que le taux d’innovation au niveau de l’architecture pourra se continuer longtemps Il semble qu’il y ait des progrès constants dans les 2 domaines où les machines parallèles ont le plus de difficulté: le logiciel et les interconnexions

Notion d’accélération Accélération = gain de temps obtenu lors de la parallélisation du programme séquentiel. Définition : Soit T1 le temps nécessaire à un programme pour résoudre le problème A sur un ordinateur séquentiel et soit Tp le temps nécessaire à un programme pour résoudre le même problème A sur un ordinateur parallèle contenant p processeurs, alors l ’accélération (Speed-Up) est le rapport : S(p) = T1 / Tp Cette définition n’est pas très précise Pour obtenir des résultats comparables il faut utiliser les mêmes définitions d ’Ordinateur Séquentiel et de Programme Séquentiel …

Notion d’accélération S(p) Région des accélérations sur-linéaires accélération linéaire Région des accélérations sub-linéaires P = nombre de processeurs

Notion d’efficacité Soit T1(n) le temps nécessaire à l’algorithme pour résoudre une instance de problème de taille n avec un seul processeur, soit Tp(n) celui que la résolution prend avec p processeurs et soit s(n,p) = T1(n) / Tp(n) le facteur d’accélération. On appelle efficacité de l ’algorithme le nombre E(n,p) = S(n,p) / p Efficacité = normalisation du facteur d ’accélération

Efficacité/Accélération Multiplication de matrices ( A moins bon que B) Algorithme A Temps en séquentiel : 10 minutes Nombre de processeurs : 10 Temps en // : 2 minutes Accélération : 10/2 = 5 (l'application va 5 fois plus vite) Efficacité : 5/10 = 1/2 Algorithme B Nombre de processeurs : 3 Temps en // : 4 minutes Accélération : 10/4 = 5/2 = 2,5 < 5 Efficacité : (5/2)/3 = 0,8 > 0,5

Remarques Une accélération linéaire correspond à un gain de temps égal au nombre de processeurs (100% activité) Une accélération sub-linéaire implique un taux d ’activité des processeurs < 100 % (communication, coût du parallélisme...) Une accélération sur-linéaire implique un taux d’utilisation des processeurs > à 100 % ce qui paraît impossible (en accord avec la loi d ’Amdhal) Cela se produit parfois (architecture, mémoire cache mieux adaptée que les machines mono-processeurs…)

Puissance de calcul Nous retrouvons couramment MIPS ou FLOPS MIPS (Machine Instructions Per Second) représente le nombre d ’instructions effectuées par seconde FLOPS (FLoating Point Operations Per Second) représente le nombre d ’opérations en virgule flottante effectuées par seconde Les multiplicatifs : K = 210 ; M = 220 ; G = 230 Certains processeurs vectoriels ont une puissance de calcul de 300 Mflops par exemple.

Les types de multiprocesseurs Taxonomie proposée par Flynn dans les années 60: SISD (Single Instruction Single Data): uniprocesseur SIMD (Single Instruction Multiple Data): plusieurs processeurs, qui exécutent en parallèle les mêmes instructions sur plusieurs données MISD (Multiple Instruction Single Data): pas d’exemple connu MIMD (Multiple Instruction Multiple Data): plusieurs processeurs qui opèrent de façon indépendantes ou semi-indépendantes sur leurs données

Les types de multiprocesseurs

Les types de multiprocesseurs SIMD (Single Instruction Multiple Data) séquenceur unique tableau de processeurs MISD (Multiple Instruction Single Data) classe bizarre pipeline ? MIMD (Multiple Instruction Multiple Data) Classe la plus importante processeurs autonomes Mémoire partagée ou distribuée Cette classification n’est pas en corrélation avec les machines réelles

MIMD: la mémoire Les deux classes de multiprocesseurs MIMD sont largement répandus ; le choix de MIMD-SD ou MIMD-DM dépendant du nombre de processeurs dans la machine Mémoire partagée centralisée (centralized shared memory) : « petit » nombre de processeurs. Mémoire distribuée : «grand » nombre de processeurs.

Classification unifiée des types de multiprocesseurs SIMD-SM Contrôle centralisé de données centralisées Machine vectorielles mono-processeurs Instruction unique appliquée de manière séquentielle à des données de type vecteur Fonctionnement en mode pipeline Pipeline : Décomposition de l ’opérateur f = f3 ° f2 ° f1 On applique successivement f1, f2 puis f3 sur cette donnée circuits dans les processeurs circuit = composant électronique qui prend d en entrée et donne f(d) en sortie séquence de circuits en étages

Classification unifiée des types de multiprocesseurs SIMD-DM : Contrôle centralisé, données distribuées Processeurs de faible puissance = éléments de calcul Séquenceur unique MIMD-DM : Contrôle distribué, données distribuées Un processeur = entité de calcul autonome (processeur + mémoire) Communication par envoi de messages : importance du réseau d ’interconnexion Avantage : facile d ’augmenter le nb de proc Inconvénients : performances étroitement liées au réseau et besoin d ’OS nouveaux.

Classification unifiée des types de multiprocesseurs MIMD-SM : Mémoire divisée en plusieurs bancs Synchronisation des accès à la mémoire, un seul processeur peut accéder en lecture ou écriture à un banc Machine multi-processeurs : Cray 2, NEC SX-3 Faible nombre de processeurs Puissance de la machine repose sur la puissance des processeurs et non sur le nombre

Types de multiprocesseurs utilisés Les premiers multiprocesseurs étaient du type SIMD, et cette architecture est encore utilisée pour certaines machines spécialisées Le type MIMD semble être la cible de choix de nos jours pour des ordinateurs d’application courante: Les MIMD sont flexibles: on peut les utiliser comme machines à un seul utilisateur, ou comme machines multi-programmées Les MIMD peuvent être bâties à partir de processeurs existants

Architectures parallèles : exemple MIMD IBM SP IBM SP-2 (from MHPCC) IBM SP 680 IBM SP 680 specs IBM X server Cray T3E Compaq (DEC) Alpha Chips ( Alpha white paper ) Cray white paper SGI Origin 2000 , (3000) performance Tuning for the Origin2000 R10000 Chip , R10000 Brief , Other MIPS Chips , MIPS

Architectures parallèles : exemple MIMD Compaq Servers, GS320 server Distributed Memory Vector NEC (Japan) Fujitsu (Japan) Hitachi (Japan) Beowulf Projects Beowulf slides (Modi) Intel Teraflop Machine , ( Performance Tuning ) Linux Intro , Installing Linux , Linux Palmtops Windows NT/2000 based Beowulf Systems , ( MPICH )

Architectures parallèles : exemple MIMD : le Cray T3E La machine de chez CRAY, deux types de modèles, refroidissement à air (pas plus de 128 processeurs) ou par un liquide (jusqu'à 2048 processeurs). En amalgamant les deux de 16 à 2048 nœuds comprenant chacun : un DEC Alpha EV5 (600 MFlops) de 64 Mo à 2 Go de mémoire vive un réseau d'interconnexion en tore 3D (bande passante de 2 à 128 Go/s). Performance de crête de 9.6 GFlops à 1.2 TFlops, jusqu'à 4 To de mémoire vive.

Architectures parallèles : exemple SIMD CM-1, CM-2, & CM-200 ( NPAC ) Maspar MP-1 & MP-2 Cambridge Parallel Processing ( NPAC pages , Overview ) Oxford Micro Pentium 4 Intel SIMD Intel MMX SIMD (UBC) Motorola 7450 Motorola 7400 processor Motorola Altivec

Architectures parallèles : exemple SIMD

Architectures de grappes de PC

Définition Une grappe (cluster) est une collection de machines interconnectées, utilisée comme une ressource de calcul unifiée Une grappe « Beowulf » se définit par les propriétés suivantes : composants à grande diffusion composants réseau à faible coût système d ’exploitation « open source » hardware non propriétaire logiciel « open source »

Des grappes de référence : le Top500 Sandia 592 procs alphas, myrinet, linux, #44 NCSA 256 pentiums, myrinet, NT, #68 Cornell 256 pentiums, giganet, NT, #198 Los Alamos 140 alphas, Ether100/1000, linux, #265 Paderborn 192 pentiums, SCI, solaris, #351 Bonn 144 pentiums, myrinet, linux, #454 Chiba, Los Lobos, CEA, FSL, … en 2000

Technologies : SMP biproc quadriproc Mono ? IA64 Processeur Pentium Alpha SCI Réseau Ethernet Giganet, ServerNet, ... Myrinet NT Linux OS Solaris,...

L’interconnexion réseau Infiniband SCI HIPPI VIA ATM Fibre Channel Myrinet WDM PCI ... Ethernet FDDI SCSI ... ... SAN LAN WAN MAN

La technologie Myrinet Commutation de paquets Topologie très souple Carte réseau muni d ’un processeur RISC pilotant plusieurs contrôleurs DMA Local memory PCI bus PCI BRIDGE DMA controller Host interface RISC processor Packet Interface network

La technologie SCI réseau à capacité d’adressage adressage des mémoires distantes lecture/écriture distante sans interrompre le processeur distant plus de nécessité de programmation par échanges de messages Topologie en grille

Peut être implémentée en hardware La technologie VIA Une interface logicielle dont l’objectif est de limiter les accès au système et les copies de buffers. Peut être implémentée en hardware application application données VI contrôle contrôle Standard industriel proposé par Microsoft, Intel, Compaq. Aujourd’hui par Dell, Intel, Compaq Système d ’exploitation Système d ’exploitation données Contrôleur réseau Contrôleur réseau VIA Architecture TCP/IP Architecture VIA

Les autres Memory channel : espace d ’adressage mémoire unique bonne latence passage à l ’échelle par SMP donc limité SupperHIPPI, FibreChannel, Infiniband, ATM, WDM, Quadrics, ... offre cluster balbutiante ou de luxe

SCI : pour/contre Myrinet : pour/contre manque de maturité monopolise le CPU quelle fiabilité en cas de panne d ’un nœud espace d ’adressage mémoire unique latence/messages de petite taille Myrinet : pour/contre Plus grande maturité intégrateurs en France bande passante Autant de MPI/drivers/firmware que de grappes

Mais quelle maturité ? Quel avenir pour VIA ? Les autres possibles ServerNet II VIA orienté haute disponibilité : contrôle d ’erreurs en hardware, redondance support de Compaq Giganet disponible sur NT/linux débit/messages de grande taille Mais quelle maturité ? Quel avenir pour VIA ?

Mais latence importante Les autres possibles (Double) Fast Ethernet standard le moins cher Mais latence importante et très forte utilisation du CPU (en attendant VIA et des cartes avec processeur) Gigabit Ethernet standard, plusieurs fournisseurs de moins en moins cher switches 64 ports

L’intégrateur/vendeur support scientifique support technique maintenance intégration hardware intégration software Minimum : intégration hardware et validation par déploiement du système et de benchmarks

Des options coûteuses : Racks contrôle souhaité (BIOS, wake on line, boot PXE, lien série, …) concentrateurs d ’alimentation électrique écrans, switchs d ’écran ? disques locaux des serveurs supplémentaires : contrôle, login, fichier, développement, scheduler

Les environnements hétérogènes

Les environnements hétérogènes : définition Un environnement distribué hétérogène est le regroupement de ressources informatiques (CPU, Disk, mémoire) d’origine, de taille et de type divers. Absence de réseau de communication spécifique Souvent appelé « le cluster du pauvre », la récupération de ressources informatique inutilisée, par exemple les stations de travail la nuit, pour former une machine multiprocesseurs virtuelle hétérogène, est une pratique courante des laboratoires

Les environnements hétérogènes : Caractéristiques Hétérogénéité Réseaux (couches de communications multi-protocoles), processeurs, hiérarchies mémoire profondes Systèmes Équilibrage des charges (ordonnancement) Distribution des données (statique et dynamique) Évaluation des performances, modélisation des architectures Simulation

Les environnements hétérogènes : Problématique spécifique Hétérogénéité des performances : L’hétérogénéité des performances induit d’avoir un modèle de description des performances pour chaque architecture et des algorithmes d’ordonnancements ad hoc. Hétérogénéité des systèmes : Les machines peuvent être sous Linux, Windows Perte de fiabilité : Les réseaux locaux sont moins fiables qu’un réseau dédié et les machines plus sujettes aux pannes. Perturbation par les utilisateurs

Les centres de calcul une architecture pour le calcul intensif et le stockage de masse : le centre de calcul de la Doua

Centre de calcul de l’IN2P3 IN2P3 : Institut National de la Physique Nucléaire et de la Physique des Particules Centre de calcul crée en 1986. Situé à Lyon sur le campus de la DOUA 35 ingénieurs pour la conception, la mise en place et l’exploitation de l’infrastructure informatique

Qui sont les utilisateurs ? 2500 utilisateurs réguliers issus de la physique des particules, nucléaire et astrophysique 50 expériences, dont : - LHC : CERN à Genève 3 Po/an à partir de 2008 - D0 : FERMILAB à Chicago 150 To/an - BABAR : SLAC en Californie 150 To/an

Architecture Architecture distribuée Stockage et calcul sont séparés Réseau local Gbits Ethernet

Cluster 1000 processeurs (90% Linux Redhat 7.2) 500 KSpecInt2000 (P3 1GHz = 400 SpecInt2000) Soumission de job : BQS Calcul parallèle

Données accessibles par HPSS Stockage sur bande 6 silos gérant 36000 cartouches 720 To avec cartouche 20 Go Données accessibles par HPSS

Espace occupé sur serveur Serveur AFS 3 To Montage NFS 1,5 To Cache HPSS 6 To Serveur Objectivity 20 To Capacité totale 60 To

Réseau Hébergement d’un nœud Renater International NRI Très bonne connectivité Domaine in2p3.fr

La bio-informatique au centre de calcul de la Doua Biométrie évolutive - CPU pour calcul d’arbre de philogénie Prédiction de structure de protéine - CPU pour comparaison de séquences Aide au diagnostic pour dépistage cancer du sein - STOCKAGE des images et des métadonnées Recherche des facteurs génétiques impliqués dans la polyarthrite rhumatoïde - CPU pour identifier les régions candidates

Le CC-IN2P3 est un centre multi-services : Conclusion Le CC-IN2P3 est un centre multi-services : Calcul, stockage de masse Réseau à haut-débit, User Support Service annexe : Hébergement de service web (SFP,…), webcasting et visioconférence Base de donnée, informatique administrative (DSI du CNRS

Les environnements de programmation parallèle

Logiciels gestionnaire de batch/ressources Compilateurs MPI, OpenMP : bibliothèques outils de trace et de debug outils de déploiement et d ’administration systèmes de fichiers image unique de système

gestionnaire de batch/ressources Logiciel coordonnant l’activité des nœuds d’une architecture distribuée Responsable de l’ordonnancement effectif, et du partage des ressources entre utilisateur Fournit une abstraction d’un ensemble de queues dans lesquelles sont mises en attente les applications des utilisateurs PBS, BQS, Mosix, Sun Grid Engine …

Programmation parallèle et répartie Conception Modélisation Algorithmique Langage Compilation Exécution Gestion d’activités Communications Mise au point Régulation de charge Gestion de données Sécurité … Application Programme parallèle Proc. 0 Proc. 1 Proc. 2 Proc. 3

Systèmes d’exploitation (OS) Supports et environnements d’exécution (1) Pour les utilisateurs et leurs applications Abstractions de haut niveau Portabilité Efficacité ! Applications Interface de programmation (API) Support d’exécution Systèmes d’exploitation (OS) Grappes, grilles, machines parallèles, réseaux,…

Systèmes d’exploitation (OS) Supports et environnements d’exécution (2) Etendre et spécialiser les OS Centralisés et complétés pour le “distribué” Nouveaux modèles (tâches, communication, fichiers,…) Exemple: Stockage de fichiers, réplication, cache, … Applications Interface de programmation (API) Support d’exécution Systèmes d’exploitation (OS) Grappes, grilles, machines parallèles, réseaux

Plan : Les paradigmes systèmes distribués grande échelle et de grille LDAP Les systèmes peer to peer Internet computing Metacomputing Grille de service Grille ASP Grille de calcul Grille de données

Pourquoi vous parler de LDAP ? Des qu’on passe d’une échelle locale à une échelle plus large, apparaît le besoin de centraliser les connaissances à propos des ressources qui sont à disposition LDAP est un protocole standardisé d’annuaire, utilisée dans la plupart des entreprises qui ont au moins plusieurs agences LDAP est utilisé comme protocole de communication dans plusieurs produits d’annuaires (Active Directory de Microsoft, Novell Directory Server (NDS), Sun One)

LDAP Lightweight Directory Access Protocol A l’origine un projet de l’Université du Michigan Popularisé par Netscape Normalisé par l’IETF LDAP v2 : RFCs 1777 à 1779, RFC 1798, RFC 1960 LDAP v3 Core : RFCs 2251 à 2256 LDAP C API : RFC 1823 3 groupes de travail : LDAPEXT, LDUP, LSD Initialement: version «light» de DAP sur TCP/IP Evolution vers un service d’annuaire complet communications serveur/serveur, sécurité… Acceptation quasi globale comme protocole d’accès à un annuaire ...

LDAP On parle d’annuaire pour un système d’information permettant de stocker des données relativement statiques sur un grand nombre d’entités (ressources, utilisateur) Structure arborescente Standard de communication pour l’interrogation d’un annuaire Implémentation : open LDAP, Active Directory

Problématiques Accès à l’information ? Administration ? Utilisateurs Comptes Privilèges Profils Stratégies Postes Profils Réseau Stratégies Serveurs Profils Réseau Services Imprimantes Partages Stratégies Accès à l’information ? Administration ? Applications Configuration Sécurité Paramètres Stratégies Données Réseau Téléphonie Configuration QoS Sécurité Messagerie Boîtes aux lettres Stratégies Carnets d’adresses Internet Firewall Configuration Sécurité Stratégie VPN Annuaires Utilisateurs Postes Serveurs Au sein des Fortune 500, il existe en moyenne plus de 150 référentiels stockant des données sur les composants du système d’information (source Gartner Group)

Référentiel de sécurité unique Intranet Autorisation Authentification Kerberos Ressources Windows 2000 RADIUS X.509/PKI Tickets Kerberos Active Directory Extranet Certificats Windows 2000 supporte plusieurs modèles d’authentification et un modèle d’autorisation unique Active Directory fournit un point focal d’administration, des services de certificats et un serveur de clés Kerberos Facilite la liaison des Intranets & Extranets

Administration des ressources Donner aux personnes de RH accès au menu ‘Modif Salaire’ de l’appli de gestion des ressources humaines Déléguer l’administration des utilisateurs au Helpdesk Domaine Utilisateurs Machines Périphériques Applications Finance RH Déployer l’application Ressources Humaines

Disponibilité globale des données Domaine d’entreprise Réplique A Boston Seattle Chicago Réplique B Boston Chicago Seattle Réplique C Boston Chicago Seattle Trouver: ‘Tous les Dupont’ Réplication Réponse Chaque réplique stocke une copie des données du domaine Chaque réplique peut résoudre une requête Support idéal des données d’identité des utilisateurs…

Intégration des applications Exchange: stockage des informations de B.A.L. de l’utilisateur Domaine Utilisateurs Machines Périphériques Applications Application RH: Stockage du profil métier de l’utilisateur Finance RH

Active Directory au cœur de l’entreprise Utilisateurs Informations compte Privilèges Profils Stratégies Clients Profils de gestion Infos réseau Stratégies Serveurs Profils de gestion Infos réseau Services Imprimantes Ressources partagées Stratégies Active Directory Point Central de Gestion Utilisateurs & ressources Securité Délégation Stratégie

Services de l’Active Directory Stockage hiérarchique des données Création d’arborescences possible S’adapter à la structure de l’organisation Modélisation des éléments sous forme d’objets Ressources vues comme des objets Dotés d’attributs définis ds 1 Schéma Interrogation souple Modes d’accès aux données multiples Optimisé pour traiter les requêtes Contrôle d’accès évolué et granulaire Sécurisation au niveau des attributs Délégation d’administration Réplication multi-maître Serveurs accessibles en lecture/écriture Optimisé pour un fonctionnement WAN

Stockage hiérarchique Domaine Utilisateurs Machines Périphériques Applications Marketing RH = Organizational Unit = Objet L’arborescence fournie un support pour modéliser, chercher et administrer les informations au moyen de stratégies

Modélisation sous forme d’objets Domaine Utilisateurs Machines Périphériques Applications C C C D D D A A A Marketing Object Class: User Name: Jean Dupont Email: JeanD@abc.fr Phone: 555-1234 Object Class: Computer Name: JEAND01 IP Address: 12.34.56.78 OS: Windows 2000 U U U

Méthodes d’accès à l’information LDAP Version 3 Standard de l’industrie des protocoles d’accès aux annuaires Support natif Expose l’ensemble des fonctionnalités

Ajout Utilisateur: Bill Réplication Site de Seattle Limite du domaine Site de Boston DC 1 WAN DC 8 DC 7 DC 3 DC 2 DC 4 DC 9 Ajout Utilisateur: Bill DC 5 DC 6 Site de Chicago

LDAP Utilisation de LDP

LDAP Utilisation de LDP

LDAP : quelques mots sur LDIF LDIF est le format le plus répandu de stockage de LDAP. Format texte, assez lisible Autant de versions des objets présents que d’implémentation de ldap.

Exemple de LDIF: # Define top-level entry dn: dc=mycompany,dc=com objectClass: dcObject dc:mycompany # Define an entry to contain people # searches for users are based on this entry dn: ou=people,dc=mycompany,dc=com objectClass: organizationalUnit ou: people # Define a user entry for Janet Jones dn: uid=jjones,ou=people,dc=mycompany,dc=com objectClass: inetOrgPerson uid: jjones sn: jones cn: janet jones mail: j.jones@mycompany.com userPassword: janet

LDIF : exemple (suite) # Define an entry to contain LDAP groups # searches for roles are based on this entry dn: ou=groups,dc=mycompany,dc=com objectClass: organizationalUnit ou: groups # Define an entry for the "tomcat" role dn: cn=tomcat,ou=groups,dc=mycompany,dc=com objectClass: groupOfUniqueNames cn: tomcat uniqueMember: uid=jjones,ou=people,dc=mycompany,dc=com uniqueMember: uid=fbloggs,ou=people,dc=mycompany,dc=com # Define an entry for the "role1" role dn: cn=role1,ou=groups,dc=mycompany,dc=com cn: role1

Cas pratique : utilisation de java pour l’authentification et l’autorisation en Java avec JAAS

Plan Les différents aspects de la sécurité JAVA. Évolution de la sécurité depuis JAVA 1.0 La protection de l’utilisateur. La protection du système (JAAS). Authentification Autorisation Étude détaillé Démo

La sécurité JAVA. Aspect fondamentale, dès la première version. Principe de Sand-Box. Évolution => Granularité très fine: Définition de stratégies de sécurité.

La sécurité JAVA. Nouveaux dans JDK 1.4 : JCE 1.2 (Java Cryptography Extension). JSSE (Java Secure Socket Extension). JAAS (Java Authentification & Autorisation Service).

Évolution de la sécurité JAVA But : Protéger l’utilisateur du système. Concernait principalement les applets. Apparition du principe « SandBox » . Un code non approuvé est limité Pas d’accès aux systèmes de fichiers. Pas d’accès réseaux.

Évolution de la sécurité JAVA La SandBox 1.0

Évolution de la sécurité JAVA Raffinement du modèle de SandBox. Possibilité de «signer» une applet. Le code approuvé possède alors les même droits qu’un code local. Problème : Violation du principe du « moindre privilège ».

Évolution de la sécurité JAVA

Évolution de la sécurité JAVA Évolution majeure en terme de sécurité Possibilité de définir une politique de sécurité par l’intermédiaire des fichiers « policy ».

Évolution de la sécurité JAVA

La protection de l’utilisateur

La protection de l’utilisateur Quelques exemples de tout cela : Une applet critique exécutée localement fonctionne sans problème. C:\> java WriteFileApplet 

La protection de l’utilisateur Quelques exemples de tout cela : Une applet critique exécutée localement fonctionne sans problème. Si on ajoute un « Security Manager », rien ne va plus. C:\>java -Djava.security.manager WriteFileApplet 

La protection de l’utilisateur Quelques exemples de tout cela : - Un outil permettant d’écrire facilement des fichiers « policy » : Policytool.exe

La protection de l’utilisateur Quelques exemples de tout cela : Avec un fichier de configuration, le SecurityManager ne pose plus de problème. grant { permission java.io.FilePermission "<<ALL FILES>>", "write"; }; java -Djava.security.manager -Djava.security.policy=all.policy WriteFileApplet

La protection de l’utilisateur Quelques exemples de tout cela : Un dernier exemple avec un browser. Il est plus difficile de spécifier le fichier « policy » à utiliser…..

Java Authentification & Autorisation But : Protéger le système de l’utilisateur. Comment : Créer un objet partagé par l’authentification et l’autorisation. Étendre le modèle de sécurité standard ( security policy) pour gérer cet objet. Authentification Autorisation Subject Interactions

Java Authentification & Autorisation Comment ça marche ? Authentification On « branche » des modules de connexion à une entité. Si l’utilisateur « passe » tout ces modules, il acquière alors une identité virtuelle. Autorisation Il peut alors tenter d’exécuter des actions « critiques ». Ces actions sont soumises au système de restrictions d’accès.

JAAS : L’authentification Les classes importantes pour l’identification: Subject: Représente un individu ou une organisation avec plusieurs identités de principal ; les décisions en matières d’autorisation sont prises en fonction d’un sujet authentifié. Logincontext: Fournit une API de base, permettant aux sujets de se connecter/déconnecter du système. LoginModule: Définit l’interface que les fournisseurs de services d’authentifications qui supportent JAAS doivent implémenter. Configuration: Encapsule l’entité utilisée pour configurer une application avec des connexion particulièrs.

JAAS : L’authentification Les classes importantes pour l’identification: CallbackHandler: Définit l’interface à implémenter par les applications qui souhaitent autoriser le service d’authentification à leur passer des informations. Callback: Définit une interface de marqueurs implémentée par les objets qui sont passés à une implémentation CallbackHandler. L’objet Callback contient les données à passer à l’application. PrivilegedAction: Les actions critiques y sont stockées

JAAS : L’authentification (chronologie) LoginContext Configuration Configuration.jaas (liste des modules new LoginContext( "Nom de configuration", MyCallbackHandler);

JAAS : L’authentification (chronologie) LoginContext Configuration Configuration.jaas (liste des modules) LoginModule 1 LoginModule 2

JAAS : L’authentification (chronologie) LoginContext Configuration Configuration.jaas (liste des modules) Login( ) Login( ) LoginModule 1 USER CallBackHandler Login( ) LoginModule 2

JAAS : L’authentification (chronologie) LoginContext Login( ) LoginModule 1 USER CallBackHandler LoginModule 2 Subject Droits.policy

JAAS : L’authentification (chronologie) LoginContext Login( ) LoginModule 1 USER CallBackHandler LoginModule 2 Subject DoAsPrivileged( ) PrivilegedAction

Focus sur les CallbackHandler Le but de l’authentification est de créer un objet « Subject ». Pour communiquer, les objects utilisent des Callback. Ces Callback sont gérés par les CallbackHandler.

Focus sur les CallbackHandler - Le dialogue est délégué : LoginContext LoginModule CallbackHandler USER CallBack[]

Focus sur les CallbackHandler Les callback sont utilisés pour compléter le « Subject ». LoginContext LoginModule CallbackHandler CallBack[] Subject GetSubject()

Focus sur les Callback Les differents types de Callbacks : Language Callback Name Callback Password Callback TextInput Callback TextOutput Callback Choice Callback Confirmation Callback

JAAS : L’authentification Le fichier de configuration des modules de connexion: configuration.jaas Nom de configuration { JndiLoginModule Requisite Krb5LoginModule Sufficient NTLoginModule Optional UnixLoginModule Optional SampleLoginModule Required debug=true; }; Autre type d’analyse{ AnalyseRetineModule Required

JAAS : L’authentification Les mots clés du fichier .jaas : Required : non bloquant Requisite : bloquant Sufficient : bloquant Optional : non bloquant

JAAS : L’authentification Failed JAAS : L’authentification Exemple : Module Criterion Pass/Fail SampleLoginModule Required OK NTLoginModule Sufficient !OK SmartCard Requisite Kerberos Optional Overall authentication

JAAS : L’authentification Failed JAAS : L’authentification Exemple : Module Criterion Pass/Fail SampleLoginModule Required !OK NTLoginModule Sufficient OK SmartCard Requisite Kerberos Optional Overall authentication

JAAS : L’authentification Comment définir l’emplacement du fichier .jaas ? Ligne de commande : Java –Djava.security.auth.login.config=<location> Modification du fichier java.security : Login.config.url.1=<location>

Une fois l’utilisateur reconnu... JAAS : L’ autorisation Une fois l’utilisateur reconnu... JAAS étend le modèle de sécurité JAVA2. On définit donc une politique de sécurité pour un utilisateur spécifique ou pour un domaine.

JAAS : L’ autorisation Pour cela, on utilise des fichiers .policy : Exemple : grant Principal Administrateur "root" { permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "user.home", "read"; permission java.io.FilePermission "c:\\foo.txt", "write,read"; }; grant Principal Etudiant { permission java.io.FilePermission "c:\\foo.txt", "read";

Static Subject.doAsPrivileged(SujetCourant s, PrivilegeAction x); JAAS : L’ autorisation Une fois identifié, le «Subject » utilise des « PrivilegedAction ». On lance le traitement avec la méthode static suivante : Static Subject.doAsPrivileged(SujetCourant s, PrivilegeAction x);

Exemple : JAAS : L’ autorisation public class SampleAction implements PrivilegedAction { public Object run() { try{ FileWriter writer = new FileWriter(new File("c:/foo.txt")); writer.write("blabla"); }catch (IOException ioe){} return null; }

Comment définir la source du fichier .policy ? JAAS : L’ autorisation Comment définir la source du fichier .policy ? Ligne de commande : Java –Djava.security.policy=<location> Modification du fichier java.security : auth.policy.url1=<location>

Mise en place d’une authentification JAAS : JAAS : Mise en place Mise en place d’une authentification JAAS : Implémenter les interfaces suivants : CallBackHandler Handle() LoginModule initialize() login() commit() Abort()

Mise en place d’une authentification JAAS : JAAS : Mise en place Mise en place d’une authentification JAAS : Implémenter les interfaces suivants : Principal getName() PrivilegedAction run()

Java Authentification & Autorisation Où trouver JAAS ? API d’extension pour JAVA 1.3 Incorporé à JAVA 1.4 Incorporé aux spécifications J2EE 1.3

Cas pratique : sécuriser une application via JAAS par un LDAP

Example import javax.security.auth.*; import javax.security.auth.login.*; public class CountFiles { public static void main(String[] args) { LoginContext lc = null; try { lc = new LoginContext(“CountFiles”); } catch (LoginException le) { // handle it } lc.login(); } catch (Exception e) { // login failed -- handle and exit Object o = Subject.doAs (lc.getSubject(), new CountFilesAction()); System.out.println(“User ”+lc.getSubject()+ ” found ”+o+” files.”);

Establish a context by which a user can be authenticated Example import javax.security.auth.*; import javax.security.auth.login.*; public class CountFiles { public static void main(String[] args) { LoginContext lc = null; try { lc = new LoginContext(“CountFiles”); } catch (LoginException le) { // handle it } lc.login(); } catch (Exception e) { // login failed -- handle and exit Object o = Subject.doAs (lc.getSubject(), new CountFilesAction()); System.out.println(“User ”+lc.getSubject()+ ” found ”+o+” files.”); Establish a context by which a user can be authenticated Argument references a line in a config file (later)

Authenticate the user following steps in configuration file Example import javax.security.auth.*; import javax.security.auth.login.*; public class CountFiles { public static void main(String[] args) { LoginContext lc = null; try { lc = new LoginContext(“CountFiles”); } catch (LoginException le) { // handle it } lc.login(); } catch (Exception e) { // login failed -- handle and exit Object o = Subject.doAs (lc.getSubject(), new CountFilesAction()); System.out.println(“User ”+lc.getSubject()+ ” found ”+o+” files.”); Authenticate the user following steps in configuration file

A Subject represents an authenticated user Example import javax.security.auth.*; import javax.security.auth.login.*; public class CountFiles { public static void main(String[] args) { LoginContext lc = null; try { lc = new LoginContext(“CountFiles”); } catch (LoginException le) { // handle it } lc.login(); } catch (Exception e) { // login failed -- handle and exit Object o = Subject.doAs (lc.getSubject(), new CountFilesAction()); System.out.println(“User ”+lc.getSubject()+ ” found ”+o+” files.”); A Subject represents an authenticated user Uses an array of Principal objects A Principal is an identifying characteristic Username Group Database username doAs attempts to execute the run method of the named object on behalf of the Subject

Note partitioning of development into checks and actions An example action import java.security.*; class CountFilesAction implements PrivilegedAction { public Object run() { File f = new File(File.separatorChar+”files”); File farray[] = f.listFiles(); return new Integer(farray.length); } Note partitioning of development into checks and actions

more than one can be specified each returns one or more Principals Configuration 1. Login CountFiles { com.sun.security.auth.module.LDAPLoginModule required; } pluggable: loaded dynamically, poss 3rd party, so code is not tied to a particular type of authentication, and can introduce new ones as technology improves (eg retinal scans, fingerprints) stackable: more than one can be specified each returns one or more Principals

Configuration 1. Login required: user must pass authentication CountFiles { com.sun.security.auth.module.SolarisLoginModule required; com.sun.security.auth.module.JndiLoginModule optional; } required: user must pass authentication sufficient: if user passes this, no others need to be called requisite: if user passes, others called but don’t need to pass optional: user allowed to fail this (but must pass at least one!)

Cas pratique : Utilisation de LDAP pour une authentification/autorisation avec JAAS avec JBoss

Introduction aux Entreprise Java Beans Objectif : présenter un exemple d’architecture à base de composants distribués (point de vue développeur) Petit retour sur les motivations Petite introduction à J2EE

Problème Construire des applications pour entreprises Sures Sécurisées Supportant la montée en charge (scalable) Disponibles Favorisant la réutilisation Maintenables et extensibles Pour moins cher

Moyen Utiliser une architecture distribuée Plusieurs tiers Les clients (front end) Les sources de données (back end) Un ou plusieurs tiers entre eux pour Implanter les nouveaux services Intégrer les différentes sources de données Masquer la complexité de l’entreprise aux clients

Architecture à composants distribués Permettent la construction d’applications multi-tiers Objectif Simplifier la création d’application à base d’objets distribués. Promouvoir la programmation par composant pour le coté serveur Une façon d’atteindre ces objectifs est d’utiliser une architecture à composants distribués… Architecture permettant d’associer des composants et d’intégrer des ressources potentiellement distribués sur un réseau

Composant logiciel Doit permettre la construction de logiciel par composition Exporte des propriétés et des méthodes Peut être configuré de façon externe Un composant peut être réutilisable à différent degré Composants connus : COM/DCOM Java Beans Enterprise Java Beans Composants Corba

Objet distribué (rmi)

Middleware Explicite transfer(Account account1, Account account2, long amount) { // 1: Call middleware API to perform a security check // 2: Call middleware API to start a transaction // 3: Call middleware API to load rows from the database // 4: Subtract the balance from one account, add to the other // 5: Call middleware API to store rows In the database // 6: Call middleware API to end the transaction }

Middleware implicite

Architecture multi-tiers

Les solutions existantes Microsoft DNA (Distributed interNet Applications Architecture) Windows NT + DCOM + MSMQ (message queue) + MTS (transactions) + Wolfpack (clustering) + IIS (web server)+ MMC (administration et déploiement) Sun J2EE (spécification) OMG Corba (specification) et les composants Corba.

J2EE Définit une architecture standard incluant Un modèle de programmation (application multi-tiers, client légers) Une plate-forme (ensemble de spécifications et de politiques requises) Un ensemble de test de compatibilité Une implantation de référence

Architecture d’une application J2EE

La plateforme J2EE EJB : définit la façon dont les composant doivent être écrit et le contrat qu’ils doivent respecter avec le serveur d’application RMI : communication inter procédés JNDI : service de nommage JDBC : connection vec les bases de données JTA : service de transaction JMS : service de messagerie JSP : servlet et Java Server Page adapté à la construction de composant réseau Java IDL : permet l’intégration avec d’autres langages (en particulier à travers CORBA) JavaMail Connectors : intégration à des systèmes d’information existant XML

Les technologies

Enterprise Java Beans (EJB) Modèle client/serveur distribué Code exécuté sur le serveur proche des données serveur souvent plus puissant que le client Code localisé sur le serveur changer le code du serveur ne change pas le code du client Un EJB est juste une collection de classes Java et d’un fichier XML. Les classes Java suivent un certains nombre de règles et fournissent des callbacks comme définis dans l’environnement J2EE et les spécifications EJB.

Container EJB Un container EJB est un environnement d’exécution pour un composant EJB. Un EJB s’exécute sur un container EJB. Un container EJB s’exécute par un serveur d’applications et prend la responsabilité des problèmes au niveau système Le container EJB gère le cycle de vie de l’EJB. Le container EJB fournit aussi un nombre de services additionnels Gestion de la persistance Transactions Sécurité Cadre de travail Dimensionnement Portabilité Gestion des erreurs

Beans entité Un bean entité est un objet persistant Un bean entité peut avoir plusieurs clients Bean Managed Persistance (BMP) : le container EJB est responsable de la persistance du bean. Container Manager Persistance (CMP) : le bean est responsable de sa propre persistance.

Beans session Un bean session pour chaque client Il y a deux types de beans session sans état pas d ’état entre les invocations rapide et efficace avec état maintient les états entre les invocations persistance limitée

Structure EJB Interface home Interface distante Code EJB fournit un moyen pour le client EJB de récupérer une instance d’un EJB Interface distante expose les méthodes que le client EJB peut utiliser Code EJB implémente l’interface distante et l’interface EJB approprié (SessionBean ou EntityBean par exemple)

Les Enterprise JavaBeans Spécification d’une architecture permettant la création d’applications distribuées 2 versions 1.1 : la plus courante 2.0 : la plus récente Implantations de la spec : BEA WebLogic, Jonas, Borland Appserver, IBM Websphere, Jboss (open source) Composant développé pour être exécuté sur un serveur d’EJB Ne pas confondre avec un java bean

Objectifs des EJB Fournir une plate-forme standard pour la construction d’applications distribuées en Java Simplifier l’écriture de composants serveurs Portabilité Considérer le développement, le déploiement et l’exécution des applications

Division des responsabilités Le fournisseur de bean Produit les composants métier Le fournisseur de conteneur EJB Fournit l’environnement permettant l’exécution des beans Le fournisseur de serveur EJB Fournit l’environnement d’exécution pour un ou plusieurs conteneurs L’assembleur d’application Le déployeur (installateur) L’administrateur

Exposent une interface qui peut être appelé par ses clients Les Enterprise Beans Composants qui peuvent être déployés dans un environnement multi-tiers et distribué. Exposent une interface qui peut être appelé par ses clients Configurés de façon externe L’interface et l’implantation du bean doivent être conforme à la spécification EJB Les clients peuvent être Un servlet Une applet Un autre bean

Session Beans : contiennent la logique métier de l’application Les types de Beans Session Beans : contiennent la logique métier de l’application Stateful session bean Stateless session bean Entity Beans : contiennent la logique de gestion des données persistantes Message bean : contiennent la logique orientée message

Session Bean Fournit un service à un client Durée de vie limitée à celle du client Effectue des calculs ou des accès à une base de donnée Peut être transactionnel Non recouvrable Peuvent être sans état ou conversationnel (stateless ou stateful)

Exemple de Session bean public class CartBean implements SessionBean { String customerName; Vector contents; public void ejbCreate(String person) throws CreateException { … initialisation du bean } // business method public void addBook(String title) { … // code de la méthode} public void removeBook(String title) throws BookException {… } public Vector getContents() {…} // methodes appelées par le conteneur public void ejbRemove() {} public void ejbActivate() {} public void ejbPassivate() {} public void setSessionContext(SessionContext sc) {}

L’interface L’interface décrit le contrat avec les clients public interface Cart extends EJBObject { public void addBook(String title) throws RemoteException; public void removeBook(String title) throws BookException, RemoteException; public Vector getContents() throws RemoteException; }

La factory Définit les méthodes permettant de créer, trouver et détruire des objets EJB public interface CartHome extends EJBHome { Cart create(String person) throws RemoteException, CreateException; }

Le descripteur de déploiement Fournit les informations nécessaires au déploiement dans le conteneur et pour la configuration des intercepteurs <enterprise-beans> <session> <display-name>CartEJB</display-name> <ejb-name>CartEJB</ejb-name> <home>CartHome</home> <remote>Cart</remote> <ejb-class>CartBean</ejb-class> <session-type>Stateful</session-type> <transaction-type>Container</transaction-type> <security-identity> <description></description> <use-caller-identity></use-caller-identity> </security-identity> </session> </enterprise-beans>

Déploiement (suite) <assembly-descriptor> <method-permission> <role-name>user<role-name/> <method> <ejb-name>CartEJB</ejb-name> <method-intf>Remote</method-intf> <method-name>getContents</method-name> <method-params /> </method> </method-permission> <container-transaction> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar>

Le client public class CartClient { public static void main(String[] args) { Context initial = new InitialContext(); // context JNDI CartHome home = initial.lookup("java:comp/env/ejb/SimpleCart"); // Recherche de l’interface de la factory // Creation de l’objet session Cart shoppingCart = home.create("Duke DeEarl« xs); // appel de quelques business méthodes shoppingCart.addBook("The Martian Chronicles"); Vector bookList = new Vector(); bookList = shoppingCart.getContents(); shoppingCart.removeBook("Alice in Wonderland"); // suppression de l’objet session shoppingCart.remove(); }

Les entity beans Implantation d’objets métiers persistants (client, compte,…) Persistance gérée par Les conteneurs (CMP) Le bean lui-même (BMP) Le conteneur gère également les transactions et la sécurité pour le composant. Utile pour gérer les accès concurrents à des données persistantes.

Exemple d’entity bean (CMP) … // Méthodes requises par le conteneur public void ejbPostCreate(String _author,String _title) { } public void ejbRemove() { } public void ejbLoad() { } public void ejbStore() {} public void setEntityContext(EntityContext context) { this.context = context;} public void unsetEntityContext() { context=null; } public void ejbActivate() { } public void ejbPassivate() { } } public class BookEJB implements javax.ejb.EntityBean { public String author; public String titlel; public int price; private EntityContext context; public String getTitle() {return title;} public String getAuthor() {return author;}; public int getPrice() {return price;} public void setPrice(int _price) {price=_price;} public String ejbCreate (String _author, String _title) throws CreateException { author=_author; title=_title; price=0; return null; } …

Home interface public interface BookHome extends EJBHome { public Book create(String id, String url) throws RemoteException, CreateException; public Book findByPrimaryKey (String id) throws RemoteException, FinderException; public Collection findAll() throws RemoteException, FinderException; Public Collection findByAuthor(String author) throws RemoteException, FinderException; }

Interface de l’Entity Bean public interface Book extends EJBObject { public String getAuthor() throws RemoteException; public String getTitle() throws RemoteException; public int getPrice() throws RemoteException; public void setPrice(int mode) throws RemoteException; }

Le descripteur de l’entity bean <display-name>Book</display-name> <ejb-name>Book</ejb-name> <home>BookHome</home> <remote>Book</remote> <ejb-class>BookEJB</ejb-class> <persistence-type>Container</persistence-type> <prim-key-class>java.lang.String</prim-key-class> <reentrant>False</reentrant> <cmp-field><field-name>title</field-name></cmp-field> <cmp-field><field-name>author</field-name></cmp-field> <cmp-field><field-name>price</field-name></cmp-field> <primkey-field>title</primkey-field> <query> <description></description> <query-method> <method-name>findByAuthor</method-name> <method-params><method-param>java.lang.String</method-param></method-params> </query-method> <ejb-ql>select distinct object(b) from Book b where b.author=?1</ejb-ql> </query> </entity>

Message Driven Bean (ejb2.0) Intégration des EJB et de JMS Interactions asynchrones Utilisé pour réagir à des messages JMS Stateless bean Une seule méthode dans l’interface onMessage()

Exemple de message bean <message-driven> <ejb-name>ValueContainerListener</ejb-name> <ejb-class>hero.container.ValueContainerListener</ejb-class> <message-selector>JMSType='ValueContainer'</message-selector> <transaction-type>Container</transaction-type> <ejb-ref> <description>Value Container Home</description> <ejb-ref-name>ejb/valuecontainer</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <ejb-link>ValueContainer</ejb-link> <home>hero.container.ValueContainerHome</home> <remote>hero.container.ValueContainer</remote> </ejb-ref> <message-driven-destination> <destination-type>javax.jms.Topic</destination-type> <subscription-durability>NonDurable</subscription-durability> </message-driven-destination> </message-driven>

EJB Object EJB Object : object visible sur le réseau. Proxy pour le bean

Paquetage d’application

Déploiement Création d’un paquetage contenant Les classes des beans Le fichier de description Les fichiers de configuration spécifique au serveur D’autres librairies Mise en place dans le serveur (outils spécifique ou déploiement à chaud)

Intérêt des EJB Simplicité de l’écriture des composants Mais le design est plus complexe Portabilité des composants A l’exception des adaptations des serveurs Réutilisation/Composition Il faut quand même programmer Indépendance par rapport aux vendeurs

Bénéfices d’un serveur d’EJB Gestion automatisée des stocks de ressources Gestion automatisée du cycles de vie des composants Gestion de la concurrence Scalabilité Fonctionnalités déclaratives Disponibilité et tolérance aux pannes Modèle d’objet distribué …

Limites actuelles (variables selon les serveurs) Maturité de la spécification, des technologies,… Moins vrai depuis la version 2.0 Performances ? Environnements de développement Complexité du design Expérience des développeurs

Bibliographie et sources des schémas J2EE Specification Java.sun.com/products/j2ee Enterprise Java Beans Specification 1.1 et 2.0 Java.sun.com/products/ejb Mastering Enterprise JavaBeans and the Java 2 Platform Enterprise Edition – Ed Roman – Wiley Computer publishing 1999 www.theserverside.com java.sun.com/j2ee/tutorial www.jboss.org (serveur Open Source) Support de cours de Didier Donsez (université de Valenciennes) J2EE blueprints (java.sun.com) Mastering Enterprise JavaBeans II – Ed Roman -(www.theserverside.com)

Exemple d’application J2EE

Jboss - client sampleApp { // jBoss LoginModule org.jboss.security.LDAPLoginModule required; // Put your login modules that need jBoss here }; Idem que pour une application classique dans un fichier policy

Jboss - serveur <application-policy name = « sampleServerApp"> <!-- --> <authentication> <login-module code = "org.jboss.security.auth.spi.LDAPLoginModule" flag = "required" /> </authentication> </application-policy>

Cas pratique : Utilisation de LDAP pour une authentification/autorisation avec JAAS avec Tomcat

Tomcat : présentation Tomcat et les Servlets

Spécification J2EE Servlet, JSP JAX (JAX-P, JAX-B, JAX-R, JAX-RPC) JNDI, JMS EJB, JTA, JTS JavaMail, JDBC JMX, J2EE Connector, etc.

Application multi-tiers L’application Web est décomposée en plusieurs parties (tiers)

Conteneurs de Servlet Tomcat 4.1 IronFlare Orion 1.5 Jetty 4.1 Caucho Resin 2.1 Sun ONE 7.0 IBM WebSphere 4.0 BEA WebLogic 7.0

Tomcat Tomcat 4.1 (Catalina) Projet Apache (Apache  Apache Httpd) Open source Implantation de référence de la spécification Spécification Servlet 2.3 et JSP 1.2 (bientôt Servlet 2.4 et JSP 2.0)

Le conteneur de servlets associe à des URLs virtuels une servlet Servlet & Conteneur Le conteneur de servlets associe à des URLs virtuels une servlet Browser HTTP Conteneur de Servlets /admin/* /vignette/*.html /examples/*.html servlet 1 servlet 2 Requête Réponse

Organisation des répertoires de Tomcat Répertoire de Tomcat Organisation des répertoires de Tomcat scripts startup & shutdown jar utilisés par Tomcat (Ant, Servlet, etc.) configuration: server.xml, web.xml, users.xml fichiers de logs fichiers jar propres à tomcat fichiers jar communs à toutes les servlets zone de déploiement /bin /common/lib /conf /logs /server/lib /shared/lib /webapps

Configuration Tomcat Le fichier server.xml Server Racine, spécifie le port de shutdown. Service Associe des connecteurs à un engine. Connector Ils correspondent à un point d’accès à un service, soit via un serveur soit en connexion directe. Engine correspond au conteneur de servlet en lui-même. Logger Ils effectuent la journalisation. Host Déclare où sont stockées les servlets pour un nom de machine. Context Chaque Context représente la configuration associée à un chemin dans la hiérarchie

Configuration Tomcat (2) port d’écoute Un Connector point d’accès utilisable par un client : port="8080" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="100"   connectionTimeout="20000" Le conteneur Engine name="Standalone"   defaultHost="localhost" nombre de threads minimum nombre de threads maximum DNS inverse nombre de connections pendantes Nom de l’host si pas HTTP 1.1

Configuration Tomcat (3) Le Logger effectue la journalisation des requêtes prefix="catalina_log. " suffix=".txt" timestamp="true" Le tag Host définit les paramètres pour un host virtuel name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"

Configuration Tomcat (4) Gestion des associations entre un URI et un chemin sur le disque Un Context représente l’association entre un chemin sur le serveur (URI) et un chemin sur le disque path= "/examples" docBase="examples" reloadable="true" URI d’accès Chemin d’accès des fichiers (relatif ou absolu par rapport à webapps) Détection automatique des changements et rechargement si besoin

Architecture d’une appli Web Une application Web possède dans un repertoire lui-même dans webapps une architecture spécifique *.html, *.jsp /WEB-INF/web.xml /WEB-INF/classes/ /WEB-INF/lib/ fichiers HTML fichier de configuration (XML) classes des servlets fichiers jar des servlets L’ensemble des fichiers et répertoire peut être mis dans un war (Web Archive) grâce à la commande jar. Le war est automatiquement dé-jarré s’il est placé dans le répertoire webapps.

Configuration d’une appli Web Le fichier web.xml <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"    "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd"> <web-app> <display-name>Mon application Web</display-name> <servlet> <servlet-name>maServlet</servlet-name> <servlet-class>fr.umlv.myservlet.MaServlet</servlet-class> </servlet> <servlet-mapping> <url-pattern>*.test</url-pattern> </servlet-mapping> <url-pattern>/toto</url-pattern> </web-app> nom de la servlet nom de la servlet nom de la servlet URI d’accès URI d’accès

Configuration d’une appli Web Paramètres d’initialisation d’une servlet association name/value <servlet> <servlet-name>maServlet</servlet-name> <servlet-class>fr.umlv.myservlet.MaServlet</servlet-class> <init-param> <param-name>parametre1</param-name> <param-value>valeur1</param-value> </init-param> <param-name>parametre2</param-name> <param-value>valeur2</param-value> </servlet>

Generic vs HTTP Servlet Il existe deux types de servlets Les GenericServlet qui ne pré-suppose pas d’un protocole Les HttpServlet qui repondent à des clients par le protocole HTTP GenericServlet est une classe du paquetage javax.servlet tandis que HttpServlet est une classe du paquetage javax.servlet.http

Cycle de vie d’une servlet Le cycle de vie d'une servlet : la méthode init() est appelée après le chargement ; une méthode service() est appelée à chaque requête dans une nouvelle thread. la méthode destroy() est appelée pour le déchargement. La synchronisation est gérée par l’objet Response

HelloServlet La méthode service() est appelée avec un objet requête et un objet réponse import java.io.*; import javax.servlet.*; public class HelloServlet extends GenericServlet { public void service(ServletRequest request, ServletResponse response) throws ServletException, IOException { PrintStream out = new PrintStream(response.getOutputStream()); out.println("Hello World!"); } public String getServletInfo() { return "Hello World Servlet"; L’objet réponse permet d’obtenir le flux de sortie en écriture Information textuelle sur la servlet

L’interface Request Description du serveur Description du client L'interface ServletRequest permet de récupérer les paramètres de la requête : public abstract int getContentLength() public abstract String getContentType() public abstract String getProtocol() public abstract String getScheme() public abstract String getServerName() public abstract int getServerPort() public abstract String getRemoteAddr() public abstract String getRemoteHost() public abstract ServletInputStream getInputStream() throws IOException public abstract String getParameter(String name) public abstract String[] getParameterValues(String name) public abstract Enumeration getParameterNames() public abstract Object getAttribute(String name) Description du serveur Description du client Il est possible de rajouter des attributs (non HTTP)

L’interface Response Taille de la réponse (peut être omis) L'interface ServletResponse permet de renvoyer une réponse : public abstract void setContentLength(int length) public abstract void setContentType(String type) public abstract ServletOutputStream getOutputStream() throws IOException Taille de la réponse (peut être omis) Type de contenu au format MIME L’objet réponse permet d’obtenir le flux de sortie en écriture

Fichier de configuration Le fichier web.xml correspondant <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>Appli de Demo</display-name> <description>Ceci est une série de servlets de démo</description> <servlet> <servlet-name>hello</servlet-name> <servlet-class>fr.umlv.servletdemo.HelloServlet</servlet-class> </servlet> <servlet-mapping> <url-pattern>/hello.html</url-pattern> </servlet-mapping> </web-app> Le ‘/’ ici est par rapport à l’application Web

Le conteneur de servlets fait l’association entre l’URL et la servlet Hello World Le conteneur de servlets fait l’association entre l’URL et la servlet

Répertoires sur le serveur Hello World (2) Répertoires sur le serveur

Les servlets HTTP La méthode service de la classe HttpServlet est déjà implantée et redirige les requêtes vers les méthodes do* Les méthodes sont doDelete, doGet, doHead, doOptions, doPost, doPut, doTrace protected void do*(HttpServletRequest req,                       HttpServletResponse resp) throws ServletException, IOException

HelloWorld réécrit avec une servlet HTTP HTTP HelloWorld HelloWorld réécrit avec une servlet HTTP import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloHttpServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out = response.getWriter(); out.println("HTTP Hello World!"); } public String getServletInfo() { return "HTTP Hello World Servlet"; L’objet réponse permet d’obtenir le flux de sortie en écriture

Informations sur la requête protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out= response.getWriter(); out.println("Protocol: " + request.getProtocol()); out.println("Scheme: " + request.getScheme()); out.println("ServerName: " + request.getServerName()); out.println("ServerPort: " + request.getServerPort()); out.println("RemoteAddr: " + request.getRemoteAddr()); out.println("RemoteHost: " + request.getRemoteHost()); out.println("Method: " + request.getMethod()); out.println("requestuestURI: " + request.getRequestURI()); out.println("ServletPath: " + request.getServletPath()); out.println("PathInfo: " + request.getPathInfo()); out.println("PathTranslated: " + request.getPathTranslated()); out.println("QueryString: " + request.getQueryString()); out.println("RemoteUser: " + request.getRemoteUser()); out.println("AuthType: " + request.getAuthType()); } GET, POST, PUT etc. Chemin virtuel complet Chemin de la servlet Chemin de la ressource Chemin sur le serveur

Informations sur la requête (2) Déclaration de la servlet « header » Définition des servlets <servlet> <servlet-name>header</servlet-name> <servlet-class>fr.umlv.servletdemo.HeaderServlet</servlet-class> </servlet> … ... <servlet-mapping> <url-pattern>/header/*</url-pattern> </servlet-mapping> Chemin de la servlet Définition des associations

Informations sur la requête (3) URL complète Informations sur la requête

En-tête = Informations envoyées par le browser Entêtes de la requête En-tête = Informations envoyées par le browser protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out= response.getWriter(); Enumeration e= request.getHeaderNames(); for (; e.hasMoreElements();) { String name= (String) e.nextElement(); out.println(name + ' ' + request.getHeader(name)); } Ensemble des noms des entêtes Valeur d’un entête

En-têtes de la requête Entêtes Informations sur la requête

Réponse HTTP L’objet HttpServletResponse permet en plus de renvoyer des codes d’erreurs public class HttpRedirectServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { if ("/index.html".equals(request.getPathInfo())) response.sendRedirect("/demo/header/index.html"); else response.sendError(HttpServletResponse.SC_NOT_FOUND); } Redirection HTTP SC = Status Code

Paramètres d’initialisation Les paramètres sont déclarés dans le fichier web.xml <servlet> <servlet-name>initParam</servlet-name> <servlet-class>fr.umlv.servletdemo.InitParamServlet</servlet-class> <init-param> <param-name>count</param-name> <param-value>5</param-value> </init-param> <param-name>message</param-name> <param-value>hello config</param-value> </servlet>

Paramètres d’initialisation (2) L’objet ServletConfig permet de récupérer les paramètres public class InitParamServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out= response.getWriter(); for(int i=0;i<count;i++) { out.println(message); } public void init(ServletConfig config) throws ServletException { count = Integer.parseInt(config.getInitParameter("count")); message = config.getInitParameter("message"); private int count; private String message; Demande la valeur du paramètre "count"

Paramètres d’initialisation (3) Le destroy doit libérer les ressources !! protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { … } public void init(ServletConfig config) throws ServletException { super.init(config); count = Integer.parseInt(config.getInitParameter("count")); message = config.getInitParameter("message"); public void destroy() { message=null; private int count; private String message; Stockage des paramètres Libération des paramètres

Gestion uniforme au niveau des servlets Les formulaires Deux méthodes de passage de paramètres : GET (dans l’URL) POST (dans la requête HTTP) Gestion uniforme au niveau des servlets

HTML pour la méthode GET Les formulaires GET HTML pour la méthode GET <form enctype="application/x-www-form-urlencoded" action="subscribe" method=GET> Titre : <select name=title> <option value="Mr">Mr <option value="Ms">Mme </select> Nom : <input type=text size=20 name=username> Prénom : <input type=text size=20 name=firstname> <hr> <input type=submit value="Envoi"> <input type=reset value="Réinitialiser"> </form>

Les formulaires GET (2) Utilisation des méthodes getParameter*() protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out= response.getWriter(); out.println("<html><body bgcolor=\"white\">"); Enumeration e=request.getParameterNames(); for(;e.hasMoreElements();) { String name=(String)e.nextElement(); String value=request.getParameter(name); out.println(name+'='+value+"<br>"); } out.println("</body></html>"); Ensemble des paramètres de la requète Valeurs d’un paramètre de la requète

HTML pour la méthode POST Les formulaires POST HTML pour la méthode POST <form enctype="application/x-www-form-urlencoded" action="subscribe" method=POST> Titre : <select name=title> <option value="Mr">Mr <option value="Ms">Mme </select> Nom : <input type=text size=20 name=username> Prénom : <input type=text size=20 name=firstname> <hr> <input type=submit value="Envoi"> <input type=reset value="Réinitialiser"> </form>

Les formulaires POST (2) Utilisation des méthodes getParameter*() protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out= response.getWriter(); out.println("<html><body bgcolor=\"white\">"); Enumeration e=request.getParameterNames(); for(;e.hasMoreElements();) { String name=(String)e.nextElement(); String value=request.getParameter(name); out.println(name+'='+value+"<br>"); } out.println("</body></html>"); Ensemble des paramètres de la requète Valeurs d’un paramètre de la requète

Inclusion & Redirection L’interface RequestDispatcher : - include(request,response) - forward(request,response) Obtenir un RequestDispatcher : getServletContext().getRequestDispatcher(path) Chemin correspondant soit à une servlet soit à un fichier

Inclusion & Redirection (2) La redirection n’est pas visible au niveau du client protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { getServletContext().getRequestDispatcher("/index.html"). forward(request,response); } fichier L’inclusion permet d’inclure plusieurs fois des ressources protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); getServletContext().getRequestDispatcher("/hello.html"). include(request,response); } servlet

Inclusion & Redirection (3) Plusieurs problèmes : Forward : - ne pas faire de setContentType() avant - ne rien faire après un forward sur le flux de sortie Inclusion : - eviter setContentType() après, - enlever les balises <html> et <body> dans la ressource inclue

Permettre de garder des informations d’une requête à l’autre Session Permettre de garder des informations d’une requête à l’autre Problème : HTTP est un protocole sans état Solutions : Authentification Session (Cookie, URL rewriting)

L’objet HttpSession gère les sessions Créé une session si non existante Création : request.getSession() request.getSession(boolean create) Gestion d’association clé/valeur : session.getAttributeNames() session.getAttribute(String name) session.setAttribute(String name, Object value) session.removeAttribute(String name) Destruction : session. invalidate() session. logout() Invalide toutes les sessions pour un client

Ouverture et fermeture d’une session

Requête GET sur la servlet Session (4) Requête GET sur la servlet protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintStream out = new PrintStream(response.getOutputStream()); out.println("<html><body bgcolor=\"white\">"); HttpSession session=request.getSession(false); if (session!=null) { out.println("<h1>Welcome "+session.getAttribute("username")+ ' '+session.getAttribute("firstname")+"</h1><hr>"); } getServletContext().getRequestDispatcher("/session-part.html"). include(request,response); out.println("</body></html>"); Demande une session sans création automatique

Requête POST sur la servlet Session (5) Requête POST sur la servlet protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { HttpSession session=request.getSession(); if (request.getParameter("logout")==null) { session.setAttribute("username", request.getParameter("username")); session.setAttribute("firstname", request.getParameter("firstname")); } else session.invalidate(); doGet(request,response); Demande une session avec création automatique

Authentification : les rôles login-config: schéma d’authentification security-role: rôles de l’appli Web <login-config> <auth-method>BASIC</auth-method> <realm-name>univ-mlv</realm-name> </login-config> <security-role> <description> Client Rôle </description> <role-name>client</role-name> </security-role>

Authentification : Tomcat Services d’authentification fournis : Fichier XML (tomcat-user.xml) JDBC (base de données) LDAP Définition des rôles Définition des utilisateurs <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="client"/> <role rolename="admin"/> <user username="toto" password="toto" roles="client"/> <user username="admin" password="admin" roles="admin,client"/> </tomcat-users>

Authentification : Servlet L’interface java.security.Principal correspond à l’utilisateur et ses différents rôles public class Authentication2Servlet extends HttpServlet { protected void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); PrintWriter out=response.getWriter(); out.println("RemoteUser "+request.getRemoteUser()); out.println("UserPrincipal "+request.getUserPrincipal()); out.println("is a client ? "+request.isUserInRole("client")); } Nom de l’utilisateur Regroupe un utilisateur et ses rôles L’utilisateur possède-t-il le rôle

Authentification : Servlet (2) Authentification avant l’appel à la servlet

Les filtres Servlet Filtre Hello World Hello World Filtré Requête Réponse Hello World Hello World Filtré

Les filtres Il est possible d’ajouter des filtres qui seront exécutés avant les servlets <filter> <filter-name>footer</filter-name> <filter-class>fr.umlv.servletdemo.FooterFilter</filter-class> </filter> <filter-mapping> <url-pattern>/filter/*</url-pattern> </filter-mapping> <servlet-name>hello</servlet-name > Filtre à partir d’un URL Filtre à partir d’une servlet

Des wrappers permettent d’interagir avec la servlet Les filtres Des wrappers permettent d’interagir avec la servlet public void doFilter(ServletRequest request,ServletResponse response, FilterChain chain) throws IOException, ServletException { response.setContentType("text/html"); PrintWriter out=response.getWriter(); out.println("<html><body bgcolor=\"white\"><h1>"); HttpServletResponseWrapper newResponse=new HttpServletResponseWrapper( (HttpServletResponse)response) { public void setContentType(String contentType) { } }; chain.doFilter(request,newResponse); // context.getRequestDispatcher("/footer.html").include(request,response); out.println("</h1></body></html>"); Exécuté avant Appelle les autres filtres ou la servlet Exécuté après

Administration de Tomcat Tomcat possède un outil d’administration à distance Pour l’activer il est nécessaire de rajouter un utilisateur ayant le rôle admin

Administration de Tomcat Même informations que dans le fichier server.xml

Ajouter un nouveau rôle Créé un nouveau rôle Sur les Rôles Rôle manager créé

Ajouter un rôle à un utilisateur L’utilisateur admin devient un manager de servlets

Reload démandé directement dans l’URL Manager de Servlet Permet de deployer/ démarrer/ arrêter/ recharger des servlets Trois modes d’exécutions : - dans une URL - dans le HTML - avec Ant Reload démandé directement dans l’URL

Manager de Servlet

Tomcat : utilisation de LDAP pour l’authentification et l’autorisation On passe par le JNDIRealm ou le JAASRealm Un realm est une base d’utilisateurs, de droits et de passwords JAASRealm : Fonctionnement différent de la pile JAAS classique : union des droits, pas intersection Dans le server.xml : <Realm className="org.apache.catalina.realm.JNDIRealm" debug="99" connectionURL="ldap://localhost:389" userPattern="uid={0},ou=people,dc=mycompany,dc=com" roleBase="ou=groups,dc=mycompany,dc=com" roleName="cn" roleSearch="(uniqueMember={0})" />

Modèles de déploiement des grilles : le modèle distribué pair-à-pair Exemples: Gnutella, Freenet KaZaA, JXTA OceanStore FreeHaven Essentiellement utilisé dans pour les grilles de stockage Ne pas être vulnérable Pas d’état global Découverte des ressources par diffusion PC Diffusion Table des voisins : @IP 1 @IP 2 @IP x @IP a @IP b @IP z

Modèle client/serveur pour les grilles de stockage : le cas Napster Entre le client/serveur et le P2P Accès à des données via un site unique contenant un index Stockage de données Partage des données Données « inaltérables » Copies multiples sans aucun contrôle Limites de l’approche Plutôt du client/serveur que réellement du P2P Serveur « vulnérable » Par les tribunaux… Ou par d’autres… Serveur Napster Association musique-@IP Utilisateur A Napster (Client + Serveur) Utilisateur B Napster (Client + Serveur)

Modèle par annuaire OceanStore Exemple de Napster Annuaire distribué Un seul serveur central Annuaire NomDeFichier <-> Pair Liens statiques pairs-serveur Annonce de présence Ressources locales Capacités de communication Charge en cours Communication continue Heartbeat Pairs sur Internet Serveur d’annuaire www.napster.com

Recherche d’un fichier Le Pair A veut un fichier Requête au serveur central Une liste complète est aussi disponible « Search *.mp3 » Réponse du serveur Fichiers sur C et D S’assure que les machines sont actives Pair A Requête Réponse Pair C Pair D

Récupération du fichier Connexion directe De A à C « Get *.mp3 » Protocole de download direct Gestion d’erreurs triviale Pas de gestion des reprises Pas de hammering Une seule source Beaucoup mieux aujourd’hui Kazaa, eDonkey2000, WinXP Pair A Demande Download Pair C Pair D

Modèle par inondation C’est un modèle isotropique Les pairs sont libres et égaux en dignité et en droit Chacun dispose de données locales Aucune notion de réplication Chaque recherche repart de zéro Diffusion en vague d’une requête

Gnutella Liste de pairs Sessions permanentes Locale à chacun Quelques centaines Evolutive En fonction d’événements divers Sessions permanentes Sur 5 à 9 pairs Routage des messages Continuel

Gnutella : Les messages Ping Annonce de présence Pong Réponse au ping IP/port du réceptionnaire attachée File padding Query Requête de recherche Vitesse minimum du répondant QueryHits Réponse au message Query Nombre de fichiers en réponse avec leurs index

Gnutella : Query Routage par broadcast contraint Requête en vague (ou inondation) Vers tous les voisins Chacun fait une recherche locale… …et relaie la requête à tous ses voisins Les messages déjà reçus sont ignorés Evite les cycles Chaque message a un Time-To-Live 1 2 3’ 4 3

Gnutella : QueryHit Recherche locale Relais inverse Par chaque pair lors du Query Relais inverse Adresse / Descripteur de fichier Réponses positives seulement Aggrégation des retours Padding ou stuffing L’émetteur original choisit un fichier (et le pair associé) Le download se fait alors en direct 3 Download 2 hit 1

Passage a l’échelle de Gnutella Ca ne marchera jamais ! Au passage des 20 000 utilisateurs, écroulement Observé en été 2000 Why Gnutella Can't Scale. No, Really. [Ritter2000] Les leçons tirées Nécessité de modéliser/simuler/émuler Hubs BearShare SuperPeers permettant d’étendre le système Mais pas en O(log(N)) !

Modèle client/serveur pour les grilles de calcul : l’Internet Computing Principe Des millions de PC en attente… Récupération des cycles processeurs inutilisés (environ 47% en moyenne dans une entreprise*) via un économiseur d’écran) Exemples SETI@home (ce n’est pas du P2P !) Recherche de signaux extra-terrestres 33,79 Teraflop/s (à comparer aux 12,3 Teraflop/s de l’ordinateur le plus puissant au monde au LLNL !) Décrypthon Etablir la carte des 500 000 protéines du vivant RSA-155 Casser des codes cryptographiques * d’après une enquête d’Omni Consulting Group

Modèle client/serveur pour les grilles de calcul : le metacomputing / ASP Principe Acheter du service de calcul sur l’Internet Service = applications pré-installées + calculateurs Exemples Netsolve (Univ. Tennessee) NINF (Univ. Tsukuba) DIET (ENS Lyon/INRIA) Client Requête AGENT(S) S2 ! A, B, C Réponse (C) Op(C, A, B) S1 S2 S3 S4 Serveur Serveur Serveur Serveur

Plan : Architecture des grilles de calcul et de données Définition Vue générale : les principaux composants d’une grille Système d’information Gestion de ressources Sécurité & Organisations virtuelles Environnement d’une application Réseaux

Définition Approche pour la distribution de la puissance électrique = le réseaux électrique et la haute-tension

Approche pour la distribution de la puissance informatique = Définition Approche pour la distribution de la puissance informatique = le réseau Internet et la haute-performance (parallélisme et distribution)

Et ses différentes incarnations… Grid computing P2P WEB Internet computing Metacomputing Web services Global computing

Vue générale : les principaux composants d’une grille Dans tous les systèmes déjà présentés, certains besoins sont apparus : Système d’information : comment savoir quelles ressources sont disponibles ? Gestion des ressources : pourquoi et comment attribuer les ressources aux différentes applications Sécurité : assurer authentification, confidentialité, non-répudiation, autorisation, etc … Environnement d’une application : comment assurer un ensemble de services à des applications ?

Architecture générale : vue logique Sécurité Interface utilisateur Gestion de ressources chargement Allocation Système d'information Publi S.I. Hétérogénéité C.M.P.P. Migration des données Environnements de communication Transfert HD Stockage File System DSM MPI Environnement d’exécution

Architecture générale : Déploiement possible Chargement U.I Machines noyau e-Toile Publi C.M.P.P. Hétérogénéité Machines ressources Allocation

Architecture des grilles de calcul et de données : systèmes d’information

Le besoin d’informations Système d’information  point crucial pour les opérations sur la grille et la construction d’applications Comment une application détermine quelles ressources sont disponibles ? Quel est « l’état » de la grille Besoin d’un système d’information général pour répondre à ces questions

Quelques informations utiles Caractéristiques d’un serveur de calcul Adresse IP, logiciels disponibles, administrateur système, connections aux réseaux, version d’OS, charge Caractéristiques d’un réseau Bande passante et latence, protocoles, topologie logique Caractéristiques de l’infrastructure logicielle gestionnaire de ressources, etc.

Service d’information Fournir un accès à des informations statiques et dynamiques sur les composants Base pour la configuration et l’adaptation de systèmes dynamiques et hétérogènes Besoins et caractéristiques Accès uniforme et flexible à l’information Accès efficace et extensible aux données dynamiques Accès à des sources d’informations multiples Maintenance décentralisée

Approche MDS Basée sur LDAP Schéma spécifique à Globus Application Basée sur LDAP Lightweight Directory Access Protocol v3 (LDAPv3) Modèle de données standard Protocole de requête standard Schéma spécifique à Globus Représentation centrée sur l’hôte Outils spécifiques Globus GRIS, GIIS Découverte, publication de données Middleware API LDAP GRIS … GIIS … SNMP NWS NIS LDAP

Le MDS Metacomputing Directory Service Annuaire de ressource de Globus Contient toutes les informations sur tous les nœuds globus Consultable sur Internet http://www.globus.org/mds Distribué depuis la version 1.1.3 Permet de créer son propre « sous-Globus »

Metacomputing directory service MDS Representation c=US Switch Ethernet o=globus sunny IBM SP WAN LAN o=USC o=ANL nn=WAN hot LAN dark cold … … ou=ISI ou=MCS nn=MCS-lan Carl Steve Ian Gregor Steve Warren cn=Carl nn=SP-switch … USC/ISI ANL/MCS cn=Steve nn=SP-ether cn=Ian cn=Gregor Structure physique cn=Steve cn=Warren hn=sp1.mcs.anl.gov … hn=spN.mcs.anl.gov

Architecture des grilles de calcul et de données : gestion de ressources

Gestion de ressources Un langage de spécification de ressources flexible qui fournit la puissance nécessaire pour exprimer les contraintes requises Des services pour la co-allocation de ressources, l’organisation d’exécutables, l’accès à des données distantes et la gestion des flux d’entrées/sorties Intégration de ces services dans des outils de haut niveau Globus : MPICH-G: un MPI pour la grille globus-job-*: commandes flexible d’exécution à distance

Gestion de ressources Resource Specification Language (RSL) est utilisé pour communiquer les besoins L’API du Globus Resource Allocation Manager (GRAM) permet de lancer les programmes sur des ressources distantes, sans tenir compte de l’hétérogénéité locale Une architecture en couche permet de définir des courtiers de ressources et des co-allocateurs spécifiques aux applications comme étant des services GRAM

Modèle d’ordonnancement GRAM supporte le modèle suivant suspendu actif terminé échec Suspendu : ressources non encore allouées Actif : ressources allouées, exécution en cours Échec : terminaison prématurée (erreur ou arrêt) Terminé : terminaison avec succès

Composants GRAM Client MDS: Grid Index Info Server Appels MDS pour localiser les ressources Client MDS: Grid Index Info Server Appels MDS pour avoir des infos sur les ressources Limite du site Appels GRAM pour requête d’allocation de ressources et création de processus. MDS: Grid Resource Info Server Requête sur l’état de la ressource Mise à jour GRAM Globus Security Infrastructure Local Resource Manager Allocation & création des processus Requête Job Manager Création Gatekeeper Processus Parse Monitoring & contrôle Processus Bibliothèque RSL Processus

Architecture de la gestion de ressources spécialisation RSL Courtier RSL Application Requêtes Service d’Information & Info Ground RSL Co-allocateur Simple ground RSL Gestionnaires de ressources locaux GRAM GRAM GRAM LSF EASY-LL NQE

Langage de spécification de ressource Notation commune pour l’échange d’information entre composants RSL fournit deux types d’informations : Besoins en ressources : type de machine, nombre de nœuds, mémoire, etc. Configuration d’un job : Répertoire, exécutable, arguments, environnement API fournie pour manipuler RSL

Syntaxe RSL Forme élémentaire : clauses parenthésées (attribut op valeur [ valeur … ] ) Opérateurs supportés: <, <=, =, >=, > , != Quelques attributs supportés : exécutable, arguments, environnement, stdin, stdout, stderr, resourceManagerContact, resourceManagerName Les attributs inconnus sont ignorés Peut-être gérés par d’autres outils

Contraintes : “&” Par exemple : & (count>=5) (count<=10) (max_time=240) (memory>=64) (executable=myprog) “Créer entre 5-10 instances de myprog, chacune sur une machine with ayant au moins 64 MB de mémoire et disponible pour moi pendant 4 heures”

Multi-requêtes : “+” Une multi-requête permet de spécifier plusieurs besoins de ressources, par exemple : + (& (count=5)(memory>=64) (executable=p1)) (&(network=atm) (executable=p2)) Exécuter 5 instances de p1 sur une machine ayant au moins 64Mb de mémoire Exécuter p2 sur une machine ayant une connexion ATM Multi-requêtes sont le cœur de la co-allocation

GRAM Globus Resource Allocation Manager Permet à un programme d’être lancé sur des ressources distantes malgré l’hétérogénéité locale Utilise le langage de spécification de ressources (RSL)

DUROC Dynamically Updated Request Online Co-allocator Co-allocation : allocation simultanée d’un ensemble de ressources Basée sur des prédictions concernant les nœuds libres et la taille des files d’attentes

Architecture des grilles de calcul et de données : sécurité

Mécanismes primitifs

Sommaire Introduction Cryptographie Authentification Certification Microsoft .NET Passport Kerberos SSL

Authentification & Application Introduction Apparition des systèmes distribués Réseaux à grande échelle préserver la confidentialité des données préserver l'intégrité des données authentifier le correspondant Assurer la non-répudiation

Sommaire Introduction Cryptographie Authentification Certification Microsoft .NET Passport Kerberos SSL

Cryptographie Définition Bases Science du chiffrement Meilleur moyen de protéger une information = la rendre illisible ou incompréhensible Bases Une clé = chaîne de nombres binaires (0 et 1) Un Algorithme = fonction mathématique qui va combiner la clé et le texte à crypter pour rendre ce texte illisible

Cryptographie Chiffrement Symétrique Une Clé Secrète (Unique) partagée entre les 2 parties qui sert pour le chiffrement et le déchiffrement du message

Cryptographie Chiffrement Symétrique Algorithmes utilisant ce système : DES (Data Encryption Standard, très répandu) : les données sont découpées en blocs de 64 bits et codées grâce à la clé secrète de 56 bits propre à un couple d’utilisateurs IDEA, RC2, RC4 Avantage : Rapide Inconvénients : Il faut autant de paires de clés que de couples de correspondants La non-répudiation n’est pas assurée. Mon correspondant possédant la même clé que moi, il peut fabriquer un message en usurpant mon identité Transmission de clé

Cryptographie Chiffrement Asymétrique Clé publique Sert à chiffrer le message Clé privée Sert à déchiffrer le message

Cryptographie Chiffrement Asymétrique Algorithmes utilisant ce système : RSA (Rivest, Shamir, Adelman) DSA ElGamal Diffie-Helmann Avantage : pas besoin de se transmettre les clés au départ par un autre vecteur de transmission. Inconvénient : Lenteur

Cryptographie Combinaison des 2 Chiffrements Chiffrement symétrique Problèmes d’échanges de clés Chiffrement asymétrique Problème de lenteur  combinaison des 2 = clé de session

Sommaire Introduction Cryptographie Authentification Certification Microsoft .NET Passport Kerberos SSL

Authentification Définition La personne à qui j'envoie un message crypté est-elle bien celle à laquelle je pense ? La personne qui m'envoie un message crypté est-elle bien celle à qui je pense ?

Authentification Technique d’Identification Prouveur Celui qui s’identifie, qui prétend être… Vérifieur Fournisseur du service Challenge Le Vérifieur va lancer un challenge au prouveur que ce dernier doit réaliser

Technique A Clé Publique Principe Algorithme RSA = Réversible ((Mess)CPu)CPr = ((Mess)CPr)CPu Confidentialité Authentification

Technique A Clé Publique Confidentialité Le Texte est totalement confidentiel car le destinataire est le seul a avoir la clé privée

Technique A Clé Publique Authentification On est sûr de l’identité de l’émetteur car il est le seul à pouvoir chiffrer un message avec cette clé privée

Serveur d’authentification – Annuaire (Clé Publiques de F & D…) Technique A Clé Publique Protocole 1) F demande la Clé Publique de D 2) S envoie la Clé Publique de D à F Serveur d’authentification – Annuaire (Clé Publiques de F & D…) 3) F envoie le « challenge » à D: Décrypte mon message M1(If) et renvoie mon If pour me le prouver! 1 4 4) D décrypte M1 et demande à S la Clé Publique de F 5) S envoie la Clé Publique de F à D 2 5 6) A son tour D envoie un « challenge » à F: Décrypte mon message M2(If, Id) et renvoie mon Id ! 3 M1 7) F décrypte M2 et renvoie M3(Id) à D pour lui montrer qu’il y est arrivé F 6 M2 D 7 M3 8) F & D peuvent maintenant par ex s’envoyer des messages en créant une Clé Privée à partir de (If,Id) 8

Serveur d’authentification – Annuaire Technique A Clé Secrète Protocole de Needham – Schroeder 1) F demande une Clé de Session pour pouvoir parler avec D 2) S envoie à F M1 crypté par la Clé Secrète de F: M1 = une Clé de Session CSfd en clair et une cryptée par la Clé Secrète de D (CSfd)CPd Serveur d’authentification – Annuaire (Clés Secrètes de F & D) 1 3) F envoie le « challenge » à D: Décrypte mon message M2((CSfd)CPd) et renvoie un Id crypté par CSfd 2 M1 4) D décrypte M2 et envoie son « challenge » : Décrypte mon message M3((Id)CSfd) et renvoie Id-1 3 M2 F 4 M3 D 5) F décrypte M3 et renvoie M4((Id-1)CSfd) 5 M4 6) F & D peuvent donc s’envoyer des messages avec la Clé de Session (MESSAGE)CSfd 6

Signature électronique (1) Comment savoir que le message n’a pas été altéré ?  fonction de hachage algorithmes de hachage les plus utilisés: MD5 (128 bits) et SHA (160 bits)

Signature électronique (2) Pb du hachage : on est pas sur de l’expéditeur  Scellement des données

Sommaire Introduction Cryptographie Authentification Certification Microsoft .NET Passport Kerberos SSL

Certification Principes Besoins Chiffrement asymétrique = basé sur la distribution de clés publiques (Annuaire) rien ne garantit que la clé est bien celle de l'utilisateur a qui elle est associée…  Certificats Certificats Carte d’identité électronique, composée de la clé publique du porteur et d’informations relatives à ce dernier. Délivré par une autorité appelée tiers de confiance, qui, par sa signature, en garantit l’authenticité.

Certification Certificat X509

Certification Exemple Certificat X509

Certification PKI (Public Key Infrastructure) IGC (Infrastructure de Gestion de Clés) Système permettant la gestion de clés de chiffrement et la délivrance de certificats numériques Repose sur l’utilisation de la cryptographie à clé publique

PKI - Organisation

Sommaire Introduction Cryptographie Authentification Certification Microsoft .NET Passport Kerberos SSL

Microsoft .NET Passport service en ligne gratuit permet de se connecter (en toute sécurité ?) à n'importe quel service ou site Web Passport participant Utilisation d’une adresse de messagerie et d’un mot de passe unique

Microsoft .NET Passport Contenu obligatoire Email (nom d’utilisateur) Mot de passe Contenu optionnel Phrase de rappel Clé de sécurité Numéro de mobile Date de naissance, coordonnées Informations bancaires

Microsoft .NET Passport L’utilisateur contacte un site L’utilisateur est redirige sur le site PassPort L’utilisateur S’authentifie et reçoit un cookie chiffré L’Utilisateur est redirigé vers le premier site qui lit le cookie L’utilisateur reste authentifié pour tout autre site

Sommaire Introduction Cryptographie Authentification Certification PGP Microsoft .NET Passport Kerberos SSL

Kerberos Introduction Conditions de fonctionnement Les serveurs ne font aucune confiance aux clients Les clients n’accordent qu’une confiance limitée aux serveurs Authentification contrôlée par des serveurs spécialisés

Kerberos Service d’Authentification Pré-requis Le serveur Kerberos détient les mots de passe utilisateurs Le serveur détient la clé privée du serveur de tickets Le serveur de tickets détient les clés privés de tous les serveurs

Kerberos Lexique Ticket Caractérise une session entre un client C et un serveur S Tcs={S, C, adr, Td, durée, Kcs}Ks Adr : adresse IP du client Td : heure de début de session Durée : durée max de session Kcs : clé de session partagée par C et S Ks : clé permanente (secrète) de S

Kerberos Lexique Authentifieur caractérise le client à un instant, vis à vis d’un serveur Acs(t)={C, adr, t}Kcs Engendré par le client Permet une authentification permanente par le serveur

Sommaire Introduction Cryptographie Authentification Certification PGP Microsoft .NET Passport Kerberos SSL

SSL (Secure Sockets Layer) Définition « Couche de Sockets Sécurisée » Protocole d’échange de données au dessus de TCP/IP qui assure: Confidentialité des échanges entre 2 applications Authentification des serveurs Indépendant du protocole Utilisé (HTTP, FTP, …)

SSL (Secure Sockets Layer) Principe Utilise RSA (clé publique) pour s’échanger des clés DES (clé Secrète) Protocole de négociation (choix clés) Protocole d’échange (chiffré par DES) Authentifie un navigateur, pas une personne Compatibilité Presque Tous les Navigateurs Affichage du cadenas en bas pour les sites Sécurisés Un serveur sécurisé possède une URL commencant par https://

SSL Phase de Négociation Authentification Utilise des certificats émis par une autorité de certification Authentifier le serveur vis à vis du client (navigateur) Authentifier le navigateur vis à vis du serveur Génération des clés de session Technique à clé publique vue précédemment Création des clés de session Fin de négociation Client & serveur sont authentifiés mutuellement Ils ont leurs clés secrètes pour la phase d’échange

Infrastructure de Gestion des Privilèges mécanismes Infrastructure de Gestion de Clés Infrastructure de Gestion des Privilèges Délégation infrastructure de clé publique (PKI, public key infrastructure): infrastructure pouvant prendre en charge la gestion de clés publiques afin de fournir des services d'authentification, de chiffrement, d'intégrité et de non répudiation. infrastructure de gestion de privilège (PMI, privilege management infrastructure): infrastructure qui peut prendre en charge la gestion des privilèges correspondant à un service complet d'autorisation et en relation avec une infrastructure de clé publique.

Infrastructure de Gestion de Clés (1) Infrastructure de Gestion à clés Publique (PKI) AE : Autorité d’Enregistrement  enregistre et vérifie les informations propres aux utilisateurs AC : Autorité de Certification  délivre les certificats aux utilisateurs Annuaire de publication des certificats  fournit les données de validation des certificats des utilisateurs politiques de certification Utilisation des Certificats X.509 à clés publiques « PKI » (long time certificate) Certificat PKC: utilisé pour mettre en place un service d’identification des utilisateurs Protection des clés privées des utilisateurs (carte à puce, …) validation et révocation des certificats d’authentification (CRLs, ARLs, ..) … Autorité de Certification (CA, Certification Authority): autorité jouissant de la confiance d'un ou de plusieurs utilisateurs pour la création et l'attribution de certificats. L'autorité de certification peut, de manière optionnelle, créer les clés des utilisateurs. Autorité d’Enregistrement(RA, Registration Authority):. liste de Révocation de Certificat (CRL, Certificate Revocation List): liste signée contenant les certificats qui ne sont plus considérés comme valides par leur émetteur. Certains types de listes CRL spécifiques sont définis en plus du type générique de liste CRL, pour couvrir des domaines particuliers. validation de certificat: processus consistant à s'assurer qu'un certificat était valide à un instant donné, impliquant éventuellement la construction et le traitement d'un itinéraire de certification avec la garantie que tous les certificats de l'itinéraire étaient valides (c'est-à-dire, non caducs ou révoqués) à l'instant donné politique de certification : ensemble nommé de règles indiquant la possibilité d'appliquer un certificat pour une communauté particulière et/ou une classe d'applications articulière avec des besoins de sécurité communs. Une politique de certification particulière peut, par exemple, indiquer la possibilité d'application d'un certificat pour des transactions avec échange de données électroniques pour le commerce de biens dans une fourchette de prix donnée.

Authentification forte des utilisateurs (2) Certificat d’authentification  pièce d’identité électronique permettant l’authentification des utilisateurs Certificat d’authentification  contient des informations pérennes (durée de vie 1 à 2 ans) Format du certificat d’authentification RFC 2459, 3280 DN du sujet  Nom distinct de l’utilisateur DN de l’émetteur  Nom distinct de la communauté de l’utilisateur KeyUsage  utilisation de la clé = authentification CertificatePolicies  politique de certification … authentification forte: authentification utilisant des justificatifs obtenus par des moyens de chiffrement.

Certificat d’attributs Il est signé par une autorité d’attributs qui n’est pas nécessairement une autorité de certification Il ne permet pas d’identifier un utilisateur ou un process Il spécifie les attributs d’un utilisateur Rôle (objet (permission)*)* Il est associé à un certificat d’authentification Unification des DN

Infrastructure de gestion des privilèges (1) PMI Composantes Autorité d’Attribut (AA) Source d’Autorité (SOA) Vérificateur de privilèges Déclarant de privilèges Politique de privilèges certificat d'attribut: structure de donnée, portant la signature numérique d'une autorité d'attribut, qui lie certaines valeurs d'attribut à des informations d'identification concernant son détenteur. source d'autorité (SOA, source of authority): autorité d'attribut auquel peut faire confiance un vérificateur de privilège pour une ressource donnée, en tant qu'autorité ultime pour l'attribution d'un ensemble de privilèges autorité d'attribut (AA): autorité qui attribue des privilèges par l'émission de certificats d'attribut. vérificateur de privilège: entité effectuant la vérification de certificats conformément à une politique de privilège. politique de privilège: politique qui définit dans ses grandes lignes les conditions sous lesquelles les vérificateurs de privilège peuvent fournir ou effectuer des services sensibles au profit ou pour le compte de déclarants de privilège qualifiés. La politique de privilège est liée à des attributs associés au service, ainsi qu'à des attributs associés aux déclarants de privilège. déclarant de privilège: détenteur de privilège utilisant son certificat d'attribut pour déclarer un privilège.

Infrastructure de gestion des privilèges (2) Utilisation des certificats d’authentification dans PMI Utilisation de l’Extension SubjectDirectoryAttribute pour définir les attributs des utilisateurs dans leurs certificats d’authentification Durée de validité du certificat = durée de validité des attributs Révocation des attributs  Révocation du certificat l’authentification Autorité d’attribut (AA)= Autorité de gestion des certificats (AC)

Infrastructure de gestion des privilèges (3) Utilisation des certificats d’attributs Définition X509 ISO IEC 9594-8 (cf aussi RFC 3281) les attributs sont des OID (rôle, groupe, ACL) durée de vie du certificat d’attributs est différente du certificat d’authentification Verification le certificat d’attribut est vérifié par un « vérificateur » qui peut un moniteur Droits et privilèges non publiés (à compléter) Remontée d’une chaîne de signature jusqu’au SOA

Délégation Transfert d'un privilège d'une entité détentrice vers une autre entité. Délégation du droit d’authentification d’un utilisateur par la création de certificat proxy attributs associés au certificat proxy sont inclus dans les attributs associés au certificat PKC. associé Att PKC Signé par Att Signé par Proxy proxy Att Att Att

Certificats proxy Le certificat est signé par un certificat utilisateur X.509. Le certificat proxy peut signé par un autre certificat proxy le bi-clé du certificat proxy est différent du bi-clé du certificat utilisateur émetteur le certificat proxy d’authentification trace (mémorise) l’identité de son émetteur le certificat proxy contient une extension spécifique Extension ProxyCertInfo qui le distingue des autres certificats.

Architecture de confiance

Architecture de confiance Architecture PKI Architecture PMI Association PKI et PMI Application Au Grid

Architecture PKI

Architecture PKI (1) Communauté Architecture PKI structure arborescente (1 communauté ) Génération du certificat MTC Root pour toute la communauté Génération d’un certificat « AC déléguée » pour chaque entité de la communauté Génération des certificats des utilisateurs Validation d’un certificat par la validation du chemin de certification menant au MTC user 1 MTC CA 1 CA 2 2 3 4 LAR LCR

Architecture PKI (2) Architecture PKI structure arborescente Communauté Architecture PKI structure arborescente même source de confiance pour tous les utilisateurs une gestion simplifiée une infrastructure simple politique de certification commune user 1 MTC CA 1 CA 2 2 3 4 LAR LCR

Architecture PKI (3) Architecture réseaux de PKI Plusieurs communautés 1 CA 1 CA 2 u2 u3 u4 MTC LAR LCR Cross Certification Architecture réseaux de PKI Plusieurs communautés Plusieurs MTC Cross Certification mutuelle entre les communautés plusieurs politiques de certification Critères de cross certification entre les communauté des équivalences de politiques de certification

Architecture PKI (4) Architecture réseaux de PKI 1 CA 1 CA 2 u2 u3 u4 MTC LAR LCR Cross Certification Architecture réseaux de PKI La complexité de l’architecture augmente avec le nombre des communautés Chaînes de certification complexe (multiples) Gestion de l’infrastructure devient complexe Problèmes d’interopérabilité entre les PKI La validation des certificats devient plus complexe.

Architecture PKI (5) Architecture Bridge CA 1 MTC CA 1 u2 MTC u 1 u2 Architecture Bridge CA Création d’une communauté virtuelle Établir des relations de Cross certification entre la communauté virtuelle et l’ensemble des communautés Simplification des itinéraires de certification Cross Certification Communauté Virtuelle u 1 CA 1 CA 2 u2 u3 u4 MTC LAR LCR MTC u 1 u2 Préciser comment se déclarent et se formalisent les relations de cross certif Comment se passe une vérification sur une communauté A d’un certificat d’une communauté B ?

Architecture PMI

Architecture PMI Principe d’Arborescence PMI une Source d’Autorité de confiance SOA plusieurs Autorités d’Attributs AA Certificats d’Attributs signée par les AA la validation d’un certificat d’attribut par la validation du chemin menant au SOA A 1 SOA AA 1 AA 2 2 3 4

Association PKI et PMI

Association PKI et PMI Architecture avec même source de confiance pour les deux infrastructures PKI et PMI Indépendance des deux infrastructures PKI et PMI

Architecture avec même source de confiance PKI et PMI Origines de confiance des droits d’identification et des privilèges sont confondues : MTC = SOA politiques de certification et politiques de privilège sont sous la responsabilité de la même Autorité Compromission du MTC  Compromission du SOA la validation des droits d’identification et d’attributs peut être effectuée par l’ensemble des composantes de l’infrastructure (visibilité globale) La délégation des droits d’authentification et des privilèges des utilisateurs peut être effectuée dans l’ensemble de l’infrastructure

Architecture avec même source de confiance PKI et PMI MTC SOA Fusion des architectures PKI et PMI l’autorité de certification est l’autorité d’attribut : les administrations des droits d’identification et des attributs sont fusionnés les Certificats PKC et Certificat d’Attributs d’un utilisateurs sont émis par la même Autorité révocation de l’AC  révocation de AA AC 1 AA 1 A1 A2 U 1 U 2 A3 A4 AC 2 AA 2 U 3 U 4 A’1 A’2 A’3

Architecture avec même source de confiance PKI et PMI Séparation de l’administration des droits d’authentification et d’attribut l’autorité de certification et l’autorité d’attribut sont indépendante l’administrateur de certification # administrateur des privilèges révocation de l’AC # révocation de AA AC U1 U2 AA MTC SOA A1 An

Architecture avec même source de confiance PKI et PMI délégation du droit de génération des certificats d’attributs l’autorité de certification et l’autorité d’attribut sont indépendante délégation de l’AA du droit de génération des certificats d’attributs à l’AC MTC SOA Délégation AA AC U 2 U 1 A1 A2

Indépendance des Architectures PKI et PMI Origines de confiance des droits d’identification et des privilèges sont différentes: MTC # SOA Politiques de certification et politiques de privilège sont sous la responsabilité de plusieurs autorités différentes Compromission du MTC n’a aucune conséquence sur le SOA et réciproquement La validation des droits d’identification est globale PKI, la validation des certificats d’attributs est locale PMI La délégation des droits d’authentification peut se faire dans l’ensemble de l’infrastructure PKI La délégation d’attributs ne peut pas être effectuée

Indépendance des Architectures PKI et PMI MTC PKI Origine de confiance des droits d’identification et des privilèges sont séparée les autorités de certification et les autorités d’attributs sont indépendantes les chemins de certification et d’attributs sont indépendants les révocations des droits d’identification est indépendante de la révocation des privilèges AC1 U1 U2 AC2 U3 U4 PMI AA2 SOA1 A3 A4 AA1 A1 A2 AA4 SOA2 A7 A8 AA3 A5 A6 PMI

Grids

Grid : Quelques caractéristiques (1) Composant physique chaque organisation peut être composée de plusieurs entités chaque organisation a un ensemble d’utilisateurs chaque organisation possède le contrôle total sur l’attribution et la révocation des droits d’identification des utilisateurs (administration des droits I&A) chaque entité d’une organisation possède un ensemble de ressources qui lui sont propres chaque entité veut possède un contrôle total sur l’attribution et la révocation des doits d’accès (privilèges) des utilisateurs à ces ressources (administration des des droits d’accès aux ressources) …….

Grid : Quelques caractéristiques (2) utilisateurs un utilisateur appartient à une seule organisation physique un utilisateur peut appartenir à plusieurs entités physiques d’une même organisation physique le droit d’authentification d’un utilisateur lui est délivré par une autorité de certification de son organisation un utilisateur bénéficie de l’ensemble des privilèges qui lui sont nécessaires pour effectuer ces tâches dans son organisation les privilèges d’un utilisateur lui sont délivrés par les administrateurs des droits d’accès aux ressources de chaque entité de son organisation

Grid : Quelques caractéristiques (3) organisation virtuelle une organisation virtuelle regroupe des utilisateurs de plusieurs organisations physiques afin d’effectuer des travaux nécessitant l’accès aux ressources de une ou plusieurs entités ; chaque entité appartient à une organisation physique. L’utilisateur d’une organisation virtuelle doit bénéficier pour effectuer son travail des droits I&A dans plusieurs organisations physiques, et des droits d’accès aux ressources dans plusieurs entités des organisations physiques

Grid : Contraintes fonctionnelles I&A l’I&A d’un utilisateur dans une organisation virtuelle est effectuée grâce au droit d’I&A qui lui ont été attribués par son organisation physique au cours d’une même session un utilisateur d’une organisation virtuelle n’a pas besoin de se re-authentifier à chaque accès à une organisation physique La protection des échanges électroniques entre l’utilisateur et les entités ne nécessite pas la re-utilisation du droit d’I&A de l’utilisateur ……

Grid : définitions Allocateur des ressources : dispositif permettant d’allouer .. Statique dynamique Moniteur : dispositif chargé de contrôler la légitimité des tentatives d'accès des utilisateurs sur les ressources Base d’informations d’attributs Chargeur :

Architecture de sécurité

Définir les objectifs de sécurité I&A : Toutes les actions autorisées sur le Grid ne peuvent être exécutées que par des utilisateurs dûment authentifiés Etc.. Droits d’accès : Les utilisateurs authentifiés peuvent accéder uniquement aux ressources sur lesquelles ils bénéficient d’une autorisation. Communication : L’ensembles des échanges électroniques doivent être protéger en intégrité et confidentialité Etc… Audit

Définitions complémentaires Client proxy utilisateur : dispositif qui utilise un certificat proxy délégué d’un utilisateur pour effectuer des demandes de tâche (ou job) à un allocateur des ressources, ou à un serveur proxy ressource Serveur proxy ressource : serveur proxy permettant d’authentifier les demandes d’accès à des ressources Base d’information d’attributs : base de stockage des informations de validation des certificats d’attributs d’un ensemble d’utilisateur Base d’information de certification : base de stockage des information de validation des certificats à clés publiques des utilisateurs

Architecture de sécurité : délégation (1) User Client Proxy 1 Étape 1 Serveur I&A Étape 2 Moniteur Base d’information des attributs Serveur I&A Allocateur Chargeur réception de la Requête d’exécution du job par l’allocateur Authentification mutuelle entre client proxy 1 et serveur I&A Demande de vérification des attributs du user au moniteur vérification des attributs du user par le moniteur (accès à la base d’information d’attributs) réponse de vérification des attributs du user Demande de chargement des taches au chargeur Authentification du user Génération d’un nouveau bi-clé Génération d’un certificat proxy délégué par le user Lancement d’un client proxy sur le poste du user requête d’exécution d’un job de l’user

Architecture de sécurité : délégation (2) Étape 4 Étape 3 User Client Proxy 1 Serveur I&A Serveur I&A Allocateur Moniteur Base d’information des attributs Chargeur Client Proxy 2 Réception de la demande de certificat délégué Génération d’un certificat proxy délégué 2 par le le client proxy 1 envoie du certificat proxy 2 génération d’un certificat proxy 2 pour le lancement des taches sur les serveurs distants génération d’un nouveau bi-clé demande d’un certificats proxy délégué au client proxy 1 pour effectuée le lancement des taches distantes réception du certificat proxy 2 du client proxy 1 Lancement du client proxy 2

Architecture de sécurité : délégation (3) Étape 6 Étape 5 User Client Proxy 1 Serveur I&A Serveur I&A Allocateur Moniteur Base d’information des Attributs Chargeur Client Proxy 2 Serveur Proxy Ressource Tâche demande de lancement d’une tâche distante réception de la demande de lancement de la tâche authentification mutuelle entre client proxy 2 et serveur proxy ressource lancement de la tache

Architecture de sécurité : délégation (4) Client Proxy 1 Serveur I&A Base d’information des Attributs User Moniteur Serveur I&A Allocateur Tâche Chargeur Serveur Proxy Ressource Client Proxy 2 Canal sécurisé TLS

Architecture de sécurité : délégation (5) Client Proxy 1 Serveur I&A Base d’information des Attributs User Moniteur Tâche Serveur I&A Allocateur Serveur Proxy Ressource Chargeur Client Proxy 2 Client Proxy 3 Itinéraire de délégation des droits d’authentification de longueur 3 Serveur Proxy Ressource Tâche Serveur Proxy Ressource Tâche Liaison TLS

Architecture de sécurité : délégation (6) Organisation 1 Serveur I&A Allocateur Moniteur Base des Attributs Chargeur Client Proxy 2 Tâche Serveur Proxy Tâche Client Proxy 3 Serveur Proxy Serveur I&A Client Proxy 1 User Tâche Client Proxy 3 Serveur Proxy Tâche Serveur Proxy Organisation 2 Serveur I&A Allocateur Moniteur Base des Attributs Chargeur Client Proxy 2 Serveur I&A Allocateur Moniteur Base des Attributs Chargeur Client Proxy 2 Tâche Client Proxy 3 Organisation 3 Serveur Proxy Tâche Serveur Proxy Tâche Serveur Proxy Tâche Serveur Proxy

Dispositifs de sécurité PKI : module CA (génération de certificat PKC, révocation, … ), module RA module de publication PMI : modules AA (génération des certificats d’attributs, révocation, …) Base d’information de certification par exp : Annuaires LDAP Base d’information d’attribut par exp : Annuaires LDAP Moniteurs par exp : un vérificateur des certificats d’attributs

Dispositifs de sécurité Serveurs Proxy ressources : TLS (serveur) Module de lancement des proxy client Proxy client Module de génération des bi-clés TLS délégation protocol client (requête des certificats proxy) Module de génération des certificats proxy (pour d’autres clients proxy) TLS délégation protocol Serveur (réponse des demandes de certificats proxy)

Environnement d’une application

Environnement des communications Problèmes Support des architectures grilles Routage Multiplexage Dynamicité

Réseau haute performance Support grille Exploitation des Grappes de grappes Réseaux intra-grappes rapides Liens inter-grappes rapides Hétérogénéité au niveau réseau Réseau à haut débit Réseau haute performance

Principe Canaux réels Canaux virtuels Liés à un réseau Ne couvrent pas nécessairement tous les noeuds Canaux virtuels Couvrent tous les noeuds Contiennent plusieurs canaux réels Myrinet SCI Virtuel

Infrastructure Processus Gestionnaire de communications

Support d’architectures évolutives Dynamicité Support d’architectures évolutives

Points clés Granularité Niveau processus Niveau grappes La dynamicité a un coût Scrutations supplémentaires Prise en compte du changement de topologie La dynamicité est parfois impossible Interfaces de communication à lanceur propriétaire Interfaces sans primitives/potentiel de connexion dynamique

Changement de topologie Propagation à toute la configuration Serveur de gestion des communications Processus applicatifs Deux conséquences Vraisemblablement une synchronisation globale Impact fort sur l’exécution Prise en charge d’événements asynchrones de la gestion des communications sur les nœuds applicatifs Nécessité d’un thread dédié Verrouillages délicats

Changement de topologie Cas du routage multi-réseau Nécessité d’un recalcul des routes Opération coûteuse Problème pour les blocs de données en transit sur les passerelles Routage dynamique ? Ordre des messages Refaire IP ?

Conclusion – support dynamicité Réalisable pour une dynamicité à gros grain (grappes) pour une faible dynamicité au niveau processus Prohibitif pour une forte dynamicité au niveau processus Impossible Interfaces à lanceurs spécifiques Interfaces sans possibilités de connexions dynamiques MPI, BIP

Plan : Perspectives pour les grilles de calcul et de données Prochain standards Projets en cours Tendances actuelles

MPICH-G - Description & Technologie MPICH est une implémentation libre et disponible du standard MPI qui peut s’exécuter sur un large panel de systèmes. MPICH est dérivé de MPI et de Chameleon; Caméléon parce que MPICH peut s’exécuter sur un large panel d’environnements et aussi parce que l’implémentation initiale de MPICH utilise le Chameleon message-passing portability system.

Perspectives

Prochains standards Une organisation, le Global Grid Forum, a été depuis quelques années et défini les standards de demain, le dernier étant une extension d’OGSA, WSRF (Web Service Resource Framework), basé sur la notion de l’exposition de ressources comme étant des WS à état. La technologie n’est pas encore stable, et il est probable que les standards définis actuellement ne seront pas les derniers.

Projets en cours Plusieurs projets de recherche en France via l’Action Concerté Incitative GRID Globalisation des Ressources Informatiques et des Données et en Europe via la PCRD. Le projet faisant suite à DataGrid, dans l’optique de l’exploitation pour le LHC d’une grille de données, vient de passer sa première revue annuelle. Il compte 72 partenaires répartis en Europe, industriels et scientifiques.

Perspectives Les grilles génériques, dédiées a tout type d’applications, tendent à disparaître pour être remplacés par des projets communautaire, soit par spécialité (physique, biologie) soit par type d’application (stockage de données à grande échelle, calcul matriciel et algèbre linéaire. Les projets de grande ampleur semblent ralentir pour laisser la place aux grilles d’entreprises.

Quelques mots sur ce cours/références Ce cours ayant été préparé en peu de temps, l’essentiel des transparents présenté ici proviennent d’autres sources. Je prie les auteurs de me pardonner cet emprunt. Liste des auteurs/présentations : Architectures de grappes de PC Philippe Augerat ID-IMAG Les architectures parallèles et leur programmation pour le calcul scientifique Yves Denneulin GRAAL Algorithmique pour les plateformes distribuées et hétérogènes LIP ENS Lyon INRIA Rhône-Alpes Madeleine - Marcel Olivier Aumage Raymond Namyst LIP - ENS Lyon Introduction to Grid computing and overview of the EU Data Grid Project The European DataGrid Project Team

Liste des sources/auteurs (suite) Bioinformatique distribuée : application dans le domaine de la parasitologie N. Jacq, E. Cornillot Laboratoire de Biologie des Protistes - CNRS - Clermont-Ferrand DIET Une approche extensible pour les serveurs de calcul E. Fleury, E. Jeannot INRIA Lorraine LORIA Nancy, France E. Caron, F. Desprez, M. Quinson, F. Suter INRIA Rhône-AlpesLIP ENS Lyon, France S. Contassot, F. Lombard, J.-M. Nicod, L. Philippe LIFC Besançon, France Supports d’exécution parallèles et répartis Raymond Namyst LaBRI Université de Bordeaux I Jean-François Méhaut GRIMAAG Université des Antilles-Guyane Le centre de calcul de l'IN2P3 : une architecture pour le calcul intensif et le stockage de masse Pascal Calvat Programmation Répartie Tronc commun – Module réseau Philippe Lalevée IAAI – 2004 Étude de la parallélisation de méthodes heuristiques d’optimisation combinatoire. Application au recalage d’images médicales. LSIIT-ICPS Illkirch, le 11 décembre 2001 Michel Salomon

Liste des sources/auteurs (fin ?) … Et tout ceux que j’ai pu oublier

Pour en savoir plus … Applications scientifiques : http://public.eu-egee.org/ Architectures parallèles : Algorithme et architecture parallèles, Michel Cosnard, InterEdition. LDAP : http://www.openldap.org/ (OpenLDAP) http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx (Active Directory) JBoss: http://www.jboss.org/ Tomcat : http://jakarta.apache.org/tomcat/ JAAS : http://java.sun.com/products/jaas/

Annexe : scénario utilisateur

Un scénario utilisateur : soumission d'application S.I.C. Chargeur G.U.I.D.E. Application utilisateur e-Toile Allocateur S.P.A.M. Globus Gram C.M.P.P.