Web Services : Beyond the peer-to-peer architecture

Web Services :

Beyond the peer-to-peer architecture

Jérémy De Roey

Mémoire présenté sous la direction du Professeur Esteban Zimányi et de Ir. François Deliège en vue de l’obtention du grade de Licencié en Informatique

Année académique 2006–2007

Remerciements

Je tiens `a adresser mes remerciements `a toutes les personnes qui ont contribu´e `a la bonne r´ealisation de ce m´emoire :

le Professeur Esteban Zim´anyi, mon directeur de m´emoire, pour ses encouragements, ses nombreux conseils ainsi que ses relectures qui ont permis de mener `a bien ce m´emoire,

mon co-directeur de m´emoire, Ir. Fran¸cois Deli`ege, pour ses nombreux conseils et orien- tations lors de mon Erasmus au Danemark,

les membres du jury qui prendront le temps de lire mon travail et de l’´evaluer,

toutes les personnes de l’Universit´e Libre de Bruxelles et de l’Universit´e d’Aalborg qui ont permis la r´ealisation ainsi que l’organisation de mon Erasmus au Danemark,

ma famille, ma compagne Sylvie et mes amis pour leur soutien et leurs encouragements, ainsi que ma “future belle-m`ere” pour ses relectures et corrections.

1 Introduction 1

1.1 Motivation . . . 1

1.2 Structure du document . . . 2

2 Services web 4 2.1 Introduction . . . 4

2.2 D´efinition . . . 5

2.3 La composition de services web . . . 7

2.4 Avantages et inconv´enients . . . 8

2.5 Les services web dans l’industrie . . . 9

2.6 Aspects techniques . . . 11

2.6.1 Sc´enario g´en´eral de fonctionnement . . . 12

2.6.2 XML . . . 13

2.6.3 SOAP . . . 15

2.6.4 WSDL . . . 19

2.6.5 UDDI . . . 20

2.6.6 WS-BPEL . . . 23

2.7 S´ecurit´e . . . 23

2.7.1 S´ecurisation de la connexion . . . 24

2.7.2 XML Signature . . . 25

2.7.3 XML Encryption . . . 26

2.7.4 XKMS . . . 27

2.7.6 XACML . . . 29

2.7.7 WS-Security . . . 30

2.7.8 Autres sp´ecifications bas´ees sur WS-Security . . . 31

3 R´eseaux peer-to-peer 33 3.1 Introduction . . . 33

3.2 Historique . . . 34

3.3 D´efinition, caract´eristiques et objectifs . . . 35

3.4 Les diff´erentes topologies . . . 37

3.4.1 Architecture centralis´ee. . . 37

3.4.2 Architecture d´ecentralis´ee hybride . . . 38

3.4.3 Architecture d´ecentralis´ee P2P pure . . . 38

3.5 Couche de routage . . . 40

3.5.1 Protocoles de routage au sein de r´eseaux structur´es . . . 41

4 Communication de groupe 48 4.1 Introduction . . . 48

4.2 IP-Multicast . . . 50

4.3 Multicast applicatif sur une infrastructure P2P. . . 51

4.3.1 Scribe . . . 51

5 Architecture P2P sur une couche de transport service web 56 5.1 Pr´esentation g´en´erale . . . 56

5.2 Combinaison de services web et P2P . . . 57

5.2.1 Les avantages . . . 58

5.2.2 Les inconv´enients . . . 59

5.3 Choix des protocoles . . . 60

5.3.1 Choix du protocole de routage P2P . . . 60

5.3.2 Choix du protocole Multicast . . . 61

5.4 Aspects techniques . . . 61

5.4.1 Couche services web . . . 61

5.4.2 Couche de routage P2P. . . 67

5.4.3 Couche de communication de groupe . . . 70

5.5 Exp´erience et r´esultats . . . 71

5.5.1 L’interface . . . 71

5.5.2 L’impl´ementation . . . 73

5.5.3 Exemple d’ex´ecution . . . 75

6 Conclusions 78 A Annexes 80 A.1 WSRemoteNodeI.java. . . 80

A.2 Mapping type Java - XML sch´ema . . . 81

A.3 Publication de services web . . . 83

Bibliographie 84

Table des figures

2.1 Composition de services web . . . 7

2.2 Exemple d’utilisation du service web Google Maps . . . 10

2.3 Couches des services web . . . 11

2.4 Mod`ele d’interaction des services web . . . 12

2.5 Format d’un message SOAP sans pi`ece jointe. . . 17

2.6 Structure d’un document WSDL. . . 19

2.7 Entr´ee d’un annuaire UDDI . . . 22

2.8 SAML : Authentification unique . . . 30

2.9 S´ecurit´e : Standards bas´es sur WS-Security . . . 32

3.1 Napster : fonctionnement . . . 34

3.2 Architecture centralis´ee . . . 38

3.3 Architecture d´ecentralis´ee hybride . . . 39

3.4 Architecture centralis´ee P2P pure . . . 39

3.5 CAN . . . 42

3.6 Chord . . . 43

3.7 Pastry : Routage par pr´efixe . . . 44

3.8 Pastry : Table de routage. . . 46

4.1 Envoi multiple via unicast . . . 49

4.2 Scribe : inscription `a un groupe . . . 53

5.1 D´ecoupage en couches de la solution . . . 57

5.2 Parties d’une peer de l’application . . . 64

5.3 WS : Instances et points d’entr´ees . . . 65 5.4 Application : Fenˆetre de connexion . . . 72 5.5 Application : Fenˆetre principale . . . 73

Chapitre 1 Introduction

1.1 Motivation

Associ´es g´en´eralement `a la piraterie, les r´eseaux peer-to-peer constituent un moyen ais´e et performant pour le partage de ressources `a grande ´echelle. Malheureusement, la plus grande utilisation faite de ce genre de r´eseaux est la distribution de logiciels, de fichiers musicaux... majoritairement ill´egaux menant ainsi les fournisseurs d’acc`es `a Internet `a s’armer contre cette utilisation frauduleuse en pla¸cant, notamment, des filtres sur leurs serveurs.

N´eanmoins, le th`eme des r´eseaux peer-to-peer ouvre ses portes `a d’autres types d’usages comme l’a bien fait remarquer la recherche dans ce domaine. En effet, de par ses diverses caract´eristiques comme par exemple le fait d’ˆetre d´ecentralis´e, auto-adaptatif et extensible, le concept de r´eseaux peer-to-peer semble ˆetre une base int´eressante pour de futures ap- plications, d´esireuses d’´eviter le mod`ele tant utilis´e sur Internet mais limit´e en puissance,

`

a savoir le mod`ele client/serveur.

Dans un autre domaine, les services web forment une solution aux diff´erentes interac- tions dynamiques entre des entit´es h´et´erog`enes de par leur architecture, leur langage de pro- grammation ou encore de par leur architecture. Cette technologie permet ainsi de construire des architectures orient´ees services dans lesquelles chaque entit´e peut, sans connaissance pr´ealable d’un service, consommer ce dernier apr`es avoir effectu´e une recherche dans un annuaire et r´ecup´er´e une description de celui-ci. De plus, les services web mettent en avant des atouts int´eressants dont il serait utile de profiter dans un type d’interaction autre que

celui du mod`ele client/serveur : le mod`ele d´ecentralis´e.

C’est la raison pour laquelle ce document se focalise, apr`es une description de ces tech- nologies, sur la combinaison de celles-ci dans un syst`eme ayant pour application la gestion de groupes et l’envoi de messages en mode multicast/anycast `a ces derniers.

Ainsi, ce m´emoire a pour objectifs de pr´esenter ces diverses technologies et surtout de cr´eer une application permettant la communication de groupes, reposant sur une ar- chitecture peer-to-peer, le tout utilisant les services web comme moyen de transport de messages.

1.2 Structure du document

Pour ce faire, ce document se divise en quatre parties caract´eris´ees chacune par un chapitre.

Le chapitre2pr´esente la technologie des services web en commen¸cant par d´efinir celle-ci de mani`ere rigoureuse. Ensuite, ce chapitre d´ecrit l’utilisation des services web dans l’indus- trie ainsi que les diff´erents avantages et inconv´enients pouvant mener au d´eveloppement d’une application l’exploitant. Ceci ´etant fait, le chapitre pr´esente les diff´erents aspects techniques impliqu´es dans cette technologie. Finalement, diff´erentes facettes concernant la s´ecurit´e des services web seront explicit´ees.

Le chapitre 3 expose le sujet des r´eseaux peer-to-peer en commen¸cant par un bref historique suivi d’une d´efinition ainsi que d’un ´enonc´e des diff´erentes caract´eristiques et objectifs de ceux-ci. Ensuite, apr`es avoir pr´esent´e les diff´erentes topologies possibles des r´eseaux peer-to-peer, le chapitre s’attardera sur diff´erents algorithmes de routage au sein de ces r´eseaux dans le cas structur´e.

Le chapitre 4 effectue quant `a lui une pr´esentation g´en´erale de la communication en comparant la communication de groupe au niveau applicatif avec celle effectu´ee par IP- multicast. Ensuite, ce chapitre d´ecrira une technique de multicast applicatif reposant sur une architecture peer-to-peer.

Finalement, le chapitre 5, pierre angulaire de ce document, fournit une pr´esentation globale de l’application permettant la communication de groupe sur une architecture peer- to-peer en utilisant les services web comme couche de transport. Ensuite, apr`es ´evocation des diff´erents avantages et inconv´enients `a combiner les technologies des services web avec une architecture peer-to-peer, une pr´esentation sera faite des aspects techniques des diff´erentes technologies utilis´ees lors de l’impl´ementation de l’application. Enfin, ce cha- pitre sera clˆotur´e par l’expos´e de l’application r´esultante ainsi qu’un exemple d’ex´ecution ayant pour but d’illustrer les diff´erents concepts abord´es.

Services web

2.1 Introduction

Depuis la cr´eation d’Internet, l’utilisation de ce r´eseau s’est diversifi´ee. En effet, tout commen¸ca durant les ann´ees 1950, lors de la guerre froide, lorsque le minist`ere am´ericain de la D´efense souhaitait disposer d’un r´eseau capable de r´esister aux attaques de l’ennemi ; tel n’´etait guerre le cas car ce dernier utilisait le r´eseau t´el´ephonique public consid´er´e comme vuln´erable<sup>1</sup>. Viendra quelques ann´ees plus tard la cr´eation d’une unit´e de recherche pour la D´efense, l’ARPA<sup>2</sup> qui donnera par la suite naissance au r´eseau ARPAnet. Initialement, ce r´eseau reliait seulement quelques universit´es qui l’utilisaient `a des fins de calculs distribu´es.

Dˆu `a son succ`es et `a l’apparition du protocole TCP/IP³, bon nombre d’unit´es de recherche, de r´eseaux et de machines vont s’y rattacher, faisant ainsi augmenter de fa¸con significative la taille de ce r´eseau. L’utilisation d’Internet jusqu’aux ann´ees 90 aura donc concern´e les chercheurs d’universit´e, le gouvernement et les industries.

Par la suite, une nouvelle application va r´evolutionner l’utilisation d’Internet et d`es lors attirer des millions de nouveaux utilisateurs : le WWW<sup>4</sup>. Ce dernier ne se d´efinit plus comme un ´enorme entrepˆot de textes, de fichiers et d’images car il a ´evolu´e vers une architecture orient´ee services (SOA<sup>5</sup>) ; ce qui ajoute ainsi la notion de services `a notre approche. Ainsi, en plus des interactions homme - machine, on va prendre en consid´eration

1En effet, il suffisait de d´etruire quelques-uns des points de commutation afin de fragmenter le r´eseau.

2Advanced Research Projects Agency.

3Il a ´et´e reconnu officiellement en 1983 comme ´etant le seul protocole.

4World Wide Web.

5Service Oriented Architecture.

les interactions machine - machine.

Depuis quelques ann´ees, un engouement particulier vers les SOA (et les services web par la mˆeme occasion) s’est fait ressentir. En effet, une preuve de ceci a ´et´e apport´ee par l’enquˆete men´ee par Evans Data Corporation [13] datant de 2006, dans laquelle le constat suivant a ´et´e fait : le pourcentage d’architectures orient´ees services en ´etat de fonc- tionnement aurait doubl´e par rapport `a l’ann´ee pr´ec´edente. De plus, 24% de l’´echantillon interrog´e se disent impl´ementer des SOA, ce qui correspond `a une augmentation de 85%

par rapport `a l’ann´ee pr´ec´edente et 30% se disent prˆets `a utiliser plus de 20 services pour l’ann´ee suivante, ce qui correspond `a une augmentation de 58% par rapport `a l’ann´ee pr´ec´edente. N´eanmoins, 25% de cet ´echantillon pensent ´egalement que le frein principal de cet augmentation est le manque de standards. En effet, l’un des probl`emes pos´es par les services web concerne les standards, sujet sur lequel nous reviendrons ult´erieurement dans ce chapitre.

Apr`es avoir d´efini de mani`ere rigoureuse les services web, d´ecrit leurs avantages et inconv´enients et donn´e une vision globale sur le sujet, ce chapitre⁶ s’attardera sur les diff´erentes technologies dont ils font usage. De plus, ce chapitre pr´esentera diverses m´ethodes permettant de s´ecuriser ces derniers ainsi que les technologies qui y sont associ´ees.

2.2 D´ efinition

Comme pour tout concept important, il est fondamental de d´efinir de mani`ere rigou- reuse la notion de services web. En effet, nombreuses sont les personnes qui galvaudent ces termes ; la partie web est associ´ee aux sites web et par cons´equent le couple “services web” est associ´e aux services disponibles pour le public via un site web. De plus, la multi- tude de d´efinitions variant avec le temps, l’entit´e la d´efinissant et le manque de standards encouragent cette mauvaise compr´ehension. Afin de rem´edier `a ce probl`eme, l’analyse et l’explication de plusieurs d´efinitions semblent ˆetre un passage n´ecessaire.

Tout d’abord, examinons une d´efinition comportant quelques lacunes provenant de [7] :

“A web service is any service that is available over the Internet, uses a stan- dardized XML messaging system, and is not tied to any one operating system

6Afin d’´elaborer ce chapitre, les r´ef´erences suivantes ont ´et´e utilis´ees : [2,9,10,12,29,36,43,45,53]

or programming language.”

Cette derni`ere consid`ere un service web comme ´etant un service disponible via Internet, utilisant XML⁷ pour l’encodage des messages et ind´ependant du syst`eme d’exploitation, ainsi que du langage de programmation. Cette d´efinition est incompl`ete dans le sens o`u celle-ci ne sp´ecifie pas le fait que l’interaction se produit entre programmes. De plus, les aspects de description du service ainsi que de d´ecouverte de ce dernier sont manquants, la notion de service ´etant laiss´ee dans le vague.

Une d´efinition plus compl`ete nous est fournie par le W3C⁸ :

“A Web service is a software system identified by a URI, whose public inter- faces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.” [54]

Cette d´efinition met en avant le fonctionnement mˆeme des services web. Ainsi, celle-ci pr´ecise qu’un service web doit pouvoir ˆetre d´efini, d´ecrit et d´ecouvert par d’autres applica- tions, m´ecanisme qui est `a la base d’une architecture orient´ee service. Aussi, un prestataire de services voulant mettre un service `a disposition de clients doit, apr`es avoir d´efini et d´ecrit son service, rendre ce dernier disponible⁹ en le publiant par exemple dans un annuaire. Les clients int´eress´es pourront ensuite consulter cet annuaire et faire appel aux services dont ils ont besoin.

D’autres aspects importants de cette d´efinition r´esident dans l’identification d’un ser- vice web via un URI¹⁰ ainsi que l’utilisation de XML pour l’´echange de messages, sujets sur lesquels nous reviendront plus tard dans ce chapitre.

En r´esum´e, un service web est une application qui :

7Extensible Markup Language.

8World Wide Web Consortium abr´eg´e W3C.

9D´ecouvrable.

10Uniform Resource Identifier : Il s’agit d’un identifiant unique pour une ressource web respectant une

• fonctionne ind´ependamment du syst`eme d’exploitation ou du langage de program- mation,

• est identifi´ee par un URI,

• est accessible via un r´eseau,

• communique avec d’autres applications grˆace `a un langage commun de repr´esentation de donn´ees,

• a une interface publique qui sera utilis´ee par les autres applications,

• est inscrite dans un annuaire.

2.3 La composition de services web

Ce type d’architecture consiste en la r´ealisation d’un service qui, pour atteindre son objectif, va utiliser d’autres services. Afin d’´eclaircir cela, il convient de regarder de plus pr`es la figure2.1 illustrant un service web fourni par une agence de voyage.

Client Service d’une

agence de voyage

Réservation de tickets d’avion

Compagnie A

Réservation de tickets d’avion

Compagnie B

Réservation de voiture

Réservation d’hôtel A

Réservation d’hôtel B

Fig. 2.1 – Composition de services web

Dans ce cas-ci, une agence de voyage met `a la disposition du client un service permettant la r´eservation d’un voyage. Ce service aura pour tˆache d’effectuer les r´eservations n´ecessaires

selon les crit`eres donn´es par le client. Il est important de remarquer le fait que l’agence de voyage joue un double rˆole : celui de prestataire de service envers le client et celui d’utilisateur des services de r´eservations divers. Ce type d’architecture est transparent pour le client qui n’utilisera que le service mis `a sa disposition par l’agence de voyage.

2.4 Avantages et inconv´ enients

Le succ`es des services web dans l’industrie n’est pas un hasard. En effet, les services web pr´esentent bon nombre d’avantages :

Un d´eploiement facile et rapide : une entreprise utilisant des services web peut mettre

`

a disposition des nouveaux services tout en limitant les coˆuts ainsi que le temps n´ecessaire `a leur d´eploiement. Ainsi, une entreprise peut tr`es ais´ement cr´eer un nou- veau service en combinant d’autres services d´ej`a existants.

L’interop´erabilit´e : les services web peuvent ˆetre utilis´es par d’autres applications ind´ependamment du syst`eme d’exploitation ou des langages de programmation dans lesquels ces der-

niers sont impl´ement´es.

Protocoles et standards ouverts : les services web utilisent des protocoles et des stan- dards qui sont ouverts. Les donn´ees ainsi que les protocoles ´etant au format texte, ils sont plus facilement compr´ehensibles et lisibles par les d´eveloppeurs.

L’utilisation du protocole HTTP : les services web utilisant le protocole HTTP¹¹ b´en´eficient d’un avantage non n´egligeable, `a savoir leur fonctionnement `a travers de nombreux firewalls sans avoir `a modifier les r`egles de filtrage.

Les services web ne faisant pas partie d’un monde parfait, ceux-ci pr´esentent ´egalement quelques d´efauts :

Faibles performances : comme nous pouvons le voir en r´ef´erence [14], les services web ne constituent pas une grande avanc´ee au niveau des performances quand ils sont compar´es `a CORBA<sup>12</sup> et `a Java-RMI¹³. Ce d´efaut de performance est une des cons´equences directes de l’utilisation de XML.

Probl`eme de s´ecurit´e : bien que l’utilisation du protocole HTTP constitue un avan- tage, ce dernier peut ´egalement ˆetre consid´er´e comme un inconv´enient. En effet,

11Hypertext Transfer Protocol.

puisque cette technologie permet de passer `a travers les firewalls, elle permet par cons´equent de passer au travers des r`egles de s´ecurit´e de ces derniers.

Normes peu d´evelopp´ees : certaines normes telles que la s´ecurit´e ou encore les tran- sactions sont encore au stade de pr´emices.

2.5 Les services web dans l’industrie

L’int´egration et l’interop´erabilit´e ´etant les objectifs premiers des services web et re- cherch´es par l’industrie, il n’est pas ´etonnant de les retrouver dans des applications de nombreuses grandes entreprises telles que Ebay, Amazon, Google, Yahoo Paypal, ViaMi- chelin, etc.

Voici quelques exemples¹⁴de services web mis `a la disposition des d´eveloppeurs par des entreprises tr`es pr´esentes sur Internet :

• Google¹⁵ :

L’entreprise Google, notamment r´eput´ee pour son moteur de recherches, met `a dis- position des d´eveloppeurs des services web permettant d’effectuer, `a partir de pro- grammes d´evelopp´es par ces derniers, des recherches parmi les pages r´ef´erenc´ees et de r´ecup´erer les r´esultats de mani`ere structur´ee. Nous retrouvons ´egalement une API<sup>16</sup> mettant `a disposition des fonctions du c´el`ebre Google Earth<sup>17</sup>, une API permettant la gestion d’un calendrier, une autre permettant la v´erification d’orthographe, etc. Sur la figure 2.2, une agence immobili`ere a utilis´e l’API Google Maps afin de permettre une meilleure visualisation de la localisation des biens.

• Yahoo¹⁸ :

La soci´et´e Yahoo met `a disposition des services web permettant de consulter un compte mail `a partir d’une application. Tout comme Google, Yahoo offre des ser- vices de localisation ainsi que de recherche mais permet ´egalement la cr´eation de galeries de photos ainsi que la cr´eation d’une boutique en ligne.

14Liste non exhaustive.

15http://code.google.com/

16Application Programming Interface.

17http://earth.google.fr/

18http://developer.yahoo.com/

Fig. 2.2 – Exemple d’utilisation du service web Google Maps

• Ebay¹⁹ :

Ebay, la tr`es c´el`ebre soci´et´e d’ench`eres en ligne, permet aux utilisateurs d’interagir avec sa base de donn´ees via ses services web. Par l’interm´ediaire de ceux-ci, on pourra notamment afficher les ench`eres, ench´erir, laisser des ´evaluations, consulter les profils des vendeurs, etc.

• Amazon²⁰ :

La soci´et´e Amazon met `a la disposition des d´eveloppeurs des services web permettant

`

a ces derniers d’int´egrer des donn´ees d’Amazon directement dans leurs applications.

• PayPal²¹ :

PayPal, solution de paiement sur Internet, permet aux d´eveloppeurs d’effectuer dans leurs applications des transactions bancaires, d’obtenir des d´etails sur une transac- tion, etc.

19http://developer.ebay.com/

20http://aws.amazon.com/

21https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/devcentral landing-outside

Ces derni`eres ann´ees, nous avons assist´e `a une augmentation du nombre de services web disponibles. Ainsi, une foule de services “gadget” ont vu le jour dans le but d’attirer le grand public `a la recherche d’originalit´es pour leurs sites web.

2.6 Aspects techniques

Comme illustr´e `a la figure2.3, la technologie des services web se d´ecompose en plusieurs couches, chacune ayant un rˆole bien particulier et reposant sur les fonctionnalit´es fournies par la couche inf´erieure. Nous pouvons d’ores et d´ej`a remarquer que le langage XML est utilis´e comme standard pour ces diff´erentes couches, permettant ainsi l’interop´erabilit´e, but premier des services web. De plus, il apparaˆıt ´egalement sur cette figure que la couche de communication n’est pas restreinte `a un seul protocole ouvrant ainsi ses portes aux protocoles HTTP, SMTP²², FTP²³, etc. permettant de ce fait aux d´eveloppeurs de d´eployer des services web ´egalement sur un intranet. La description de cette couche n’´etant pas le sujet principal de ce document, nous ne nous y attarderons pas.

Couche de communication HTTP, SMTP, FTP,...

Description des services web WSDL

Publication et découverte des services web UDDI

Orchestration WS‐BPEL

Extensions de SOAP Fiabilité, transactions, routage,...

SOAP Messages Basés sur XML

Sécurité

Fig. 2.3 – Couches des services web

22Simple Mail Transfer Protocol.

23File Transfer protocol.

Cette section²⁴ a pour but de d´ecrire les diff´erentes couches ainsi que les interactions entre ces derni`eres en illustrant chacun des concepts grˆaces `a des exemples concrets. Faisant suite `a une pr´esentation des diff´erents acteurs intervenant dans le sc´enario g´en´eral de fonctionnement des services web, les diff´erentes technologies y sont d´etaill´ees.

2.6.1 Sc´ enario g´ en´ eral de fonctionnement

Un fournisseur de services ayant impl´ement´e ces derniers souhaite les rendre accessibles via le r´eseau. Pour ce faire, il va d’abord devoir d´ecrire ces services de fa¸con `a ce que l’utilisateur potentiel de ces derniers ait toutes les informations dont il aura besoin pour une bonne utilisation de ceux-ci. Ceci sera accompli grˆace `a la technologie WSDL²⁵; sujet qui sera d´evelopp´e plus loin dans cette section. Une fois la description r´ealis´ee, il va devoir la publier dans un annuaire de services de fa¸con `a ce que les clients puissent d´ecouvrir le service associ´e. Ces derniers pourront donc effectuer des op´erations de recherche sur cet annuaire pour trouver la description du service dont ils ont besoin. Ceci ´etant fait, le client du service va pouvoir se connecter au fournisseur de services et invoquer le service web souhait´e. Ce sc´enario est illustr´e `a la figure 2.4.

Services web Document

WSDL

Fournisseur de services web Annuaire

Utilisateur UDDI de services web

Applications

SOAP SOAP

SOAP

Publication de services Découverte

de services

Utilisation des services

web

Fig. 2.4 – Mod`ele d’interaction des services web

Les diff´erentes ´etapes n´ecessaires `a l’acc`es et `a l’utilisation d’un service web sont donc

24Afin d’´elaborer cette section, les r´ef´erences suivantes ont ´et´e utilis´ees : [17,22,23,15]

les suivantes :

1. D´ecouvrir le service : le client lance une recherche sur un annuaire UDDI en sp´ecifiant les crit`eres.

2. R´ecup´erer la description du service: le client re¸coit en r´eponse `a sa requˆete un document WSDL d´ecrivant le service dont il a besoin.

3. Utilisation du service web : la communication entre le client et le service web se fait via le protocole SOAP. Le client appelle le service web en pr´ecisant les param`etres divers de ce dernier.

4. R´ecup´erer la r´eponse

Toutefois, il est important de remarquer que ce sc´enario peut ´egalement s’´etendre de mani`ere r´ecursive. En effet, comme nous l’avons vu dans la section2.3, un service web peut ˆ

etre compos´e d’autres services de fonctionnalit´es diverses pouvant ˆetre localis´es `a l’autre bout de la terre.

2.6.2 XML

XML [55] est un langage permettant la repr´esentation de donn´ees ainsi que de do- cuments structur´es sans l’utilisation de balises pr´ed´efinies. Ainsi, ce langage peut ˆetre

´

etendu de fa¸con `a y ajouter des balises sp´ecialis´ees afin de d´ecrire au mieux chaque type de donn´ees. Cette flexibilit´e conf`ere `a XML la popularit´e dont il jouit. Historiquement, XML a ´et´e d´evelopp´e par le W3C en 1996, a profit´e des meilleurs aspects de SGML²⁶ et est, depuis 1998, une recommandation du W3C.

XML d´ecrit un ensemble de r`egles syntaxiques, de fa¸con `a placer de mani`ere coh´erente et correcte les balises `a l’int´erieur d’un tel document. Un document XML qui respecte toutes ces r`egles impos´ees est dit bien form´e. L’avantage de toutes ces r`egles est de per- mettre la cr´eation de parsers²⁷ XML qui seront utilis´es afin de lire et d’extraire les donn´ees d’un document XML. Un exemple de document XML est donn´e ci-dessous :

Dans le code source 2.1, les balises en orange sont appel´ees des ´el´ements. Chaque entit´e peut avoir un ou plusieurs attributs²⁸ (en rouge) permettant d’ajouter de l’information

26Standard Generalized Markup Language.http://www.w3.org/MarkUp/SGML/

27Analyseur syntaxique en fran¸cais.

28La valeur de ceux-ci doit ˆetre encadr´ee par des quotes.

Code source 2.1Exemple de document XML bien form´e

<collection nom=”Ma collection”>

<livre id=”1”>

<titre>Marketing management</titre>

<auteurs>

<auteur>Kotler</auteur>

<auteur>Dubois</auteur>

</auteurs>

<sujet>Marketing</sujet>

</livre>

</collection>

suppl´ementaire aux ´el´ements.

Les namespaces XML

Les namespaces, ou espaces de noms XML, permettent de classer les ´el´ements ainsi que les attributs en une collection, de fa¸con `a ´eviter les ambigu¨ıt´es de nommage telles que les collisions de noms d’´el´ements ou d’attributs. Chaque namespace est identifi´e par un URI et est d´eclar´e en utilisant le mot r´eserv´exmlnstout en respectant la syntaxexmlns: pre- fix = ”URI”dans le cas d’une utilisation avec pr´efixe ou bienxmlns=”URI”. Les deux solutions sont ´equivalentes, si ce n’est que la premi`ere d´efinit en plus un pr´efixe qui devra ˆetre utilis´e avant chaque ´el´ement ou attribut du namespace. Le code 2.2 utilise un namespace avec pr´efixe.

Code source 2.2Exemple de namespace XML (pr´efix´e)

<ns1 :livrexmlns :ns1 = ”http ://www.mylibrary.com”>

<ns1 :titre>Marketing management</ns1 :titre>

<ns1 :auteurs>

<ns1 :auteur>Kotler</ns1 :auteur>

<ns1 :auteur>Dubois</ns1 :auteur>

</ns1 :auteurs>

</ns1 :livre>

Les sch´emas XML

Un sch´ema XML est un document XML permettant la d´efinition d’une structure pos- sible d’un document XML. Ce sch´ema permettra la validation dudit document en d´ecrivant l’ensemble des ´el´ements ainsi que des attributs pouvant apparaˆıtre dans ce dernier, l’ordre des ´el´ements fils ainsi que leur contenu, les types de donn´ees des ´el´ements et des attributs ainsi que leur valeur par d´efaut. Le sch´ema XML2.3 correspond `a celui du document XML 2.1.

2.6.3 SOAP

SOAP²⁹, ou encore Simple Object Access Protocol³⁰, est un standard du Consortium W3C d´efinissant un protocole RPC³¹, tout comme RMI et CORBA, mais utilisant XML pour structurer les messages. Il permet donc l’´echange de messages entre entit´es SOAP d’un

´

emetteur `a un r´ecepteur pouvant passer par des interm´ediaires. Un des grands avantages de ce protocole est qu’il n’est pas limit´e `a un seul protocole de transport, contrairement `a son ancˆetre XML-RPC³²qui, lui, est bas´e sur HTTP. En effet, alors que la grande tendance est

`

a HTTP, on pourrait parfaitement utiliser SMTP, FTP ou tout autre technologie future pour l’impl´ementation de cette couche.

Le protocole SOAP pr´ecise les aspects suivants :

• la mani`ere avec laquelle XML sera utilis´e pour repr´esenter le contenu des messages,

• comment une paire de messages peut ˆetre utilis´ee pour former un ´echange du type Request-Reply,

• des r`egles d´efinissant par exemple comment le r´ecepteur d’un message doit traiter les diff´erents ´el´ements XML qu’il contient.

29Afin de r´ealiser cette section, les r´ef´erences suivantes ont ´et´e utilis´ees : [27,44, 52]

30Cet acronyme n’est valable que jusqu’`a la version 1.1 car la version 1.2 ne le sp´ecifie plus. SOAP devient alors un nom propre n’ayant plus aucune relation avec l’acronyme.

31Remote Procedure Call : m´ecanisme permettant d’appeler des proc´edures situ´ees sur un ordinateur distant.

32http://www.xmlrpc.com/

Code source 2.3Exemple de sch´ema XML

<xs :schema xmlns :xs=”http ://www.w3.org/2001/XMLSchema”

elementFormDefault=”qualified”>

<xs :element name=”collection”>

<xs :complexType>

<xs :sequence>

<xs :element maxOccurs=”unbounded” ref=”livre”/>

</xs :sequence>

<xs :attribute name=”nom”use=”required”/>

</xs :complexType>

</xs :element>

<xs :element name=”livre”>

<xs :complexType>

<xs :sequence>

<xs :element ref=”titre”/>

<xs :element ref=”auteurs”/>

<xs :element ref=”sujet”/>

</xs :sequence>

<xs :attribute name=”id”use=”required”type=”xs :integer”/>

</xs :complexType>

</xs :element>

<xs :element name=”titre”type=”xs :string”/>

<xs :element name=”auteurs”>

<xs :complexType>

<xs :sequence>

<xs :element maxOccurs=”unbounded”ref=”auteur”/>

</xs :sequence>

</xs :complexType>

</xs :element>

<xs :element name=”auteur”type=”xs :NCName”/>

<xs :element name=”sujet”type=”xs :NCName”/>

</xs :schema>

Les messages SOAP

Deux formats de messages SOAP sont possibles, d´ependant de l’utilisation ou non de pi`eces jointes. Comme illustr´e dans la figure 2.5, un message sans pi`ece jointe se compose de trois parties :

• une enveloppe(Envelop)qui estobligatoire et qui contient le nom du message ainsi que les namespaces XML-SOAP utilis´es,

• un entˆete (Header) qui est optionnel et utilis´e pour sp´ecifier les comportements que doivent adopter les diff´erents interm´ediaires se situant entre l’exp´editeur et le r´ecepteur du message,

• un corps(Body)qui estobligatoireet qui contient les noms des diff´erentes m´ethodes qui seront ex´ecut´ees par le destinataire, ainsi que les param`etres associ´es, ou la r´eponse `a une requˆete ou encore un message d’erreur.

Enveloppe SOAP Entête SOAP

Entrée de l’entête Entrée de l’entête

Corps SOAP

Entrée du corps Entrée du corps

Fig. 2.5 – Format d’un message SOAP sans pi`ece jointe

La version avec pi`ece jointe s’obtient ais´ement en ajoutant au format de base, `a l’ext´erieur de l’enveloppe, des blocs de pi`eces jointes qui sont compos´es d’un entˆete MIME<sup>33</sup>ainsi que du contenu. Il est `a noter que dans les deux formats possibles, le message sera encapsul´e par la couche de communication utilis´ee.

Afin d’illustrer un ´echange Request-Reply³⁴utilisant SOAP, les codes2.4et2.5montrent respectivement un message SOAP faisant appel `a la m´ethode SayHello avec le param`etre

“Bob”, ainsi que le message de r´eponse associ´e contenant la r´eponse “Hello Bob”.

Code source 2.4Message de requˆete SOAP

<soapenv :Envelope xmlns :soapenv=”http ://schemas.xmlsoap.org/soap/envelope/”

xmlns :xsd=”http ://www.w3.org/2001/XMLSchema”

xmlns :ns1=”http ://test/”>

<soapenv :Body>

<ns1 :SayHello>

<name>Bob</name>

</ns1 :SayHello>

</soapenv :Body>

</soapenv :Envelope>

Code source 2.5Message de r´eponse SOAP

<soapenv :Envelope xmlns :soapenv=”http ://schemas.xmlsoap.org/soap/envelope/”

xmlns :xsd=”http ://www.w3.org/2001/XMLSchema”

xmlns :ns1=”http ://test/”>

<soapenv :Body>

<ns1 :SayHelloResponse>

<return>hello Bob</return>

</ns1 :SayHelloResponse>

</soapenv :Body>

</soapenv :Envelope>

Finalement, il est `a noter que des extensions peuvent ˆetre ajout´ees au protocole SOAP de fa¸con `a assurer par exemple la s´ecurit´e, la fiabilit´e de transmission, le routage asyn- chrone, etc.

33Multipurpose Internet Mail Extensions.

34Une communication unidirectionnelle est aussi possible.

2.6.4 WSDL

A ce stade, dans la pile des couches des services web, une probl´ematique naˆıt d’un point de vue de la description des services puisque le protocole SOAP ne s’occupe que de l’´echange de messages. En effet, dans l’exemple d’´echange Request-reply (2.4), comment l’utilisateur du service connaˆıt-il les param`etres, les noms de m´ethodes de services distants et le type de r´eponse ? La solution `a cette probl´ematique a ´et´e apport´ee par les soci´et´es Ariba, IBM et Microsoft, qui ont propos´e la sp´ecification WSDL³⁵ permettant la description de services web et en particulier de leur interface au moyen de documents WSDL. Il est `a noter que Microsoft et IBM sont ´egalement `a l’origine de SOAP. Ainsi, chaque prestataire de services va d´efinir dans un document WSDL les diff´erents types de messages qu’il peut recevoir et

´

eventuellement ceux qu’il peut envoyer en guise de r´eponse. En plus de d´efinir ces derniers, WSDL d´efinit ´egalement la localisation des services ainsi que les diff´erents m´ecanismes pour acc´eder `a ceux-ci puisque ces derniers sont accessibles via plusieurs protocoles diff´erents.

Structure d’un document WSDL

<definitions>

<types>

</types>

</definitions>

<message>

</message>

<portType>

</portType>

<binding>

</binding>

Fig. 2.6 – Structure d’un document WSDL

35Web Services Description Language. [48]

Un document WSDL est un document XML qui est constitu´e des ´el´ements suivants :

• D´efinition: elle contient le nom du service qui est d´ecrit dans le document ainsi que les namespaces utilis´es. Il s’agit de l’´el´ement Root du document.

• Types : il s’agit de la d´efinition des types de donn´ees qui seront utilis´es dans les messages. On y trouvera donc par exemple des sch´emas XML.

• Messages: il s’agit d’une description de la structure des messages qui seront ´echang´es.

On y retrouve deux types de messages : les messages entrants et les messages sor- tants. Chaque message peut ˆetre compos´e de plusieurs parties d´ecrivant les diff´erents param`etres de ces derniers.

• PortTypes : il s’agit d’un ensemble d’op´erations, chacune se r´ef´erant `a un message entrant et sortant.

• Bindings : ils sp´ecifient quels protocoles seront utilis´es.

• Service : il s’agit des informations permettant la localisation du service.

La structure d’un tel document est illustr´ee `a la figure 2.6.

Ainsi, lorsqu’un client veut acc´eder `a un service web, il va tout d’abord devoir se procurer la description WSDL de ce dernier. A l’aide de celle-ci, il aura toutes les informa- tions n´ecessaires pour cr´eer les messages SOAP afin d’effectuer l’invocation et r´ecup´erer la r´eponse.

En pratique, la majorit´e des d´eveloppeurs de services web n’a pas besoin de comprendre les d´etails SOAP et WSDL puisque ceux-ci sont g´er´es par les toolkits utilis´es.

2.6.5 UDDI

UDDI [26], ou Universal Description Discovery and Integration, est la sp´ecification d’un framework³⁶ permettant le stockage de descriptions de services web ainsi que la d´ecouverte de ces derniers. Ce projet, lanc´e par les soci´et´es Microsoft, IBM et Ariba et soutenu initia-

lement par plus d’une trentaine d’entreprises, est la r´eponse `a la probl´ematique du B2B<sup>37</sup> sur Internet ainsi qu’au succ`es du commerce ´electronique.

L’API UDDI est en fait un service web qui est d´ecrit via la technologie WSDL et qui permet d’acc´eder `a un annuaire de services web (annuaire UDDI) via le protocole SOAP.

Une analogie peut ˆetre faite entre un annuaire UDDI et un annuaire t´el´ephonique : un annuaire UDDI va organiser l’information sur les services web en trois cat´egories :

• Les pages blanches : celles-ci sont constitu´ees des informations de description des entreprises fournissant les diff´erents services web. Une entr´ee de ces pages sera donc form´ee du nom de l’entreprise, de son adresse, des informations de contact ainsi que d’une description de celle-ci.

• Les pages jaunes : il s’agit de la classification des services web selon des taxono- mies standards comme par exemple les sortes de produits, les entreprises ou encore la localisation g´eographique.

• Les pages vertes : il s’agit des informations techniques concernant les diff´erents services web. Ceci se fera par l’interm´ediaire de documents WSDL.

Pour ce faire, la sp´ecification UDDI d´efinit un mod`ele de donn´ees constitu´e des quatre entit´es principales suivantes :

• l’entit´e Business (BusinessEntity) : contient les informations concernant l’entre- prise incluant son nom, sa description, son adresse ainsi que les informations de contact ; il s’agit donc de l’´equivalent des pages blanches.

• l’entit´e Service (BusinessService) : cet ´el´ement d´ecrit les services web associ´es `a l’entit´e business correspondante ; il contient le nom, la description ainsi qu’une liste (optionnelle) de BindingTemplates ; il s’agit donc de l’´equivalent des pages jaunes.

• l’entit´e mod`ele de liaison(BindingTemplate): il d´ecrit les informations techniques permettant de savoir o`u et comment acc´eder au service web ; il est donc ici question des pages vertes.

37Business-to-Business.

BusinessEntity

BusinessService(1..n)

BindingTemplate(1..n)

tModel Name

Contacts Description Business services Identifier Categories

Name Contacts Description Binding template Categories

Description Address Detailed info References to tModels

Name Contacts Description OverviewDoc Identifiers Categories

WSDL document

Fig. 2.7 – Entr´ee d’un annuaire UDDI

• l’entit´e mod`ele technique (tModel) : il d´ecrit les sp´ecifications d’un service web.

Il contiendra donc une r´ef´erence vers un fichier de description, g´en´eralement un do- cument WSDL.

Afin de publier un ou plusieurs services web dans un annuaire UDDI, il faut d’abord d´efinir les tModels qui vont d´ecrire les caract´eristiques des services web, comme l’inter- face du service en WSDL. Il est `a noter qu’un tModel peut d´ej`a exister pour un ser- vice impl´ementant une interface standardis´ee qui a d´ej`a ´et´e publi´ee par le consortium de standardisation correspondant. Ensuite, il convient de publier les informations concernant l’entreprise (dans une BusinessEntity), celles concernant les services web (dans une Busi- nessService) et finalement les informations techniques(contenant notamment une r´ef´erence vers un tModel) pour les diff´erents services. La figure 2.7 illustre une entr´ee dans un an- nuaire UDDI ainsi que les relations entre les diff´erentes entit´es.

2.6.6 WS-BPEL

Jusqu’`a pr´esent, les diff´erents standards d´ecrits ne permettent qu’une interaction simple (qu’elle soit bidirectionnelle ou non) entre deux applications. Malheureusement, l’int´egration de syst`emes demande plus que ces simples interactions ; elle requiert un mod`ele standard d’int´egration entre les diff´erentes applications : elle n´ecessite donc le recours `a un outil pour d´ecrire de mani`ere pr´ecise les diff´erentes interactions possibles entre les acteurs concern´es.

Ceci est rendu possible grˆace `a WS-BPEL<sup>38</sup>qui tire ses origines de WSFL<sup>39</sup>et XLANG<sup>40</sup>. Il s’agit d’un langage d’orchestration bas´e XML permettant de d´ecrire un processus de haut niveau via la description des interactions entre diff´erents services web. La distinction entre le mod`ele d’orchestration et celui de chor´egraphie est importante. En effet, l’orchestration se place au niveau d’un participant (et va donc d´ecrire comment celui-ci va interagir avec les autres) tandis que la chor´egraphie donne une vue globale du processus en reprenant tous les participants ainsi que leurs interactions entre ceux-ci.

2.7 S´ ecurit´ e

Alors que les services web permettent l’´echange de donn´ees passant par un r´eseau pou- vant ˆetre vuln´erable (comme Internet), il convient de s´ecuriser ces derni`eres. Plusieurs points doivent ˆetre adress´es de fa¸con `a garantir la s´ecurit´e des ´echanges d’informations :

• L’authentification : permet de v´erifier que l’acc`es `a une application ou `a une res- source distante ne se fait que par des entit´es ayant prouv´e leur identit´e.

• L’identification : garantit que l’entit´e acc´edant `a une ressource distante ait bien acc`es `a celle-ci.

• L’int´egrit´e : permet de v´erifier que le message re¸cu par le destinataire n’a pas

´et´e modifi´e durant sa transmission et donc qu’il s’agit bien du message envoy´e par l’´emetteur.

• La confidentialit´e : permet de v´erifier que les messages transmis ne peuvent ˆetre

38Web Service Business Process Execution Language [25].

39Web Services Flow Language.

40XML Business Process Language.

lus par des entit´es autres que le r´ecepteur et l’´emetteur du message.

• La non-r´epudiation: garantit au destinataire d’un message que l’´emetteur de celui- ci est bien celui qu’il dit ˆetre.

Par d´efaut, les services web n’impl´ementent pas ces crit`eres de s´ecurit´e. Aussi, il convient de mettre en place certains dispositifs de fa¸con `a renforcer la s´ecurit´e du syst`eme.

2.7.1 S´ ecurisation de la connexion

Un premi`ere approche pour s´ecuriser les services web est la s´ecurisation de la connexion entre le fournisseur de service et l’utilisateur afin de la rendre fiable. A ce stade, plusieurs possibilit´es peuvent ˆetre mises en oeuvre, selon le r´eseau et la fr´equence des interactions.

Firewall

Une premi`ere possibilit´e est la configuration des r`egles de firewall, en limitant l’acc`es aux adresses IP<sup>41</sup> connues. Cette m´ethode est pratique si l’on veut restreindre l’acc`es au sein d’un r´eseau priv´e LAN ou WAN. N´eanmoins, cette m´ethode n’offre aucun cryptage et par cons´equent, n’est applicable que si le contenu des messages n’est pas secret.

SSL

Une seconde m´ethode permettant l’´echange s´ecuris´e de messages crypt´es est l’utilisation du protocole SSL⁴²/TLS⁴³, offrant les fonctionnalit´es suivantes :

• L’authentification du serveur qui va donc permettre au client de s’assurer de l’identit´e du serveur. Pour ce faire, le client va utiliser des techniques de cryptogra- phie `a cl´e publique afin de v´erifier la validit´e du certificat ainsi que de l’ID publique du serveur.

• L’authentification du client qui fonctionne de la mˆeme mani`ere que l’authentifi- cation du serveur.

41Internet Protocol.

42

• Une connexion chiffr´ee permettant ainsi la confidentialit´e et l’int´egrit´e.

Cette m´ethode est efficace pour une communication client/serveur. Malheureusement, ce protocole perd ses avantages lorsqu’il existe des interm´ediaires dans la communication.

En effet, un sc´enario possible serait un client qui se connecte `a un interm´ediaireA par SSL qui, lui, va se connecter `a un interm´ediaire B via un protocole diff´erent ne garantissant pas l’int´egrit´e et ce dernier est connect´e au serveur.

2.7.2 XML Signature

XML Signature [51] est une recommandation du W3C assurant l’authentification, l’int´egrit´e ainsi que la non-r´epudiation de donn´ees. Pour ce faire, les signatures XML permettent de signer partiellement ou enti`erement de mani`ere digitale n’importe quel document de fa¸con

`

a ce que les parties non sign´ees de ce dernier puissent ˆetre modifi´ees par des interm´ediaires.

On retrouve trois types de signature selon l’emplacement de celle-ci dans le document :

• la signature “envelopp´ee” (enveloped signature) qui s’applique aux donn´ees en- tourant celle-ci dans un document,

• la signature “enveloppante” (enveloping signature) qui s’applique aux donn´ees sign´ees qu’elle contient,

• la signature “d´etach´ee” (detached signature) qui s’applique `a des ressources qui sont ext´erieures au document la contenant.

Un des avantages d’une signature XML est que celle-ci est transform´ee en forme r´egularis´ee ou canonique. En effet, cette transformation permet d’´eviter les probl`emes de jeu de ca- ract`eres ou d’espaces. La structure d’une signature XML est illustr´ee par le code source 2.6 et est compos´ee des ´el´ements XML suivants :

– SignedInfo : il s’agit d’un ´el´ement XML obligatoire qui contient les donn´ees qui seront r´eellement sign´ees. Cet ´el´ement contient le nom de l’algorithme utilis´e pour la r´egularisation (ou la canonisation qui se produit avant la signature), celui utilis´e pour la signature (retournant la valeur de l’´el´ement SignatureValue) ainsi que des

´el´ements Reference contenant chacun une r´ef´erence vers un objet `a signer, les trans- formations `a lui appliquer, du nom de l’algorithme (DigestMethod) utilis´e pour sa

signature (Digest), ainsi que la valeur de cette signature repr´esent´ee par l’´el´ement DigestValue.

– SignatureValue : il s’agit ´egalement d’un ´el´ement obligatoire qui va contenir le r´esultat de la signature obtenu en utilisant l’algorithme pr´ecis´e dans l’´el´ement Signe- dInfo.

– KeyInfo: ´el´ement indiquant la cl´e qui devra ˆetre utilis´ee pour valider la signature.

Cet ´el´ement est optionnel car le signataire peut souhaiter ne pas rendre publique les informations de cl´e aux diff´erents interm´ediaires. De plus, cette donn´ee peut ˆetre connue dans le contexte de l’application et ne doit donc pas ˆetre repr´esent´ee.

– Object : ´el´ement optionnel permettant d’inclure des donn´ees `a la signature comme par exemples un nom, une date, etc.

Code source 2.6Structure d’une signature XML

<Signature ID ?>

<SignedInfo>

<CanonicalizationMethod/>

<SignatureMethod/>

(<Reference URI ? >

(<Transforms>) ?

<DigestMethod>

<DigestValue>

</Reference>)+

</SignedInfo>

<SignatureValue>

(<KeyInfo>) ? (<ObjectID ?>)*

</Signature>

“ ?” repr´esente z´ero ou une occurrence, “+” repr´esente une ou plusieurs occurrences et “*”

z´ero ou plusieurs occurrences

2.7.3 XML Encryption

L’encryptage XML [50] est, tout comme les signatures XML, une recommandation du

term´ediaires. Pour ce faire, l’encryptage avec XML permet de crypter certaines parties d’un document XML, laissant ainsi d’autres parties lisibles par des interm´ediaires. Aussi, cela permettra `a diff´erents destinataires de lire un document de mani`eres diff´erentes ; cha- cun pouvant lire certaines parties de celui-ci sans avoir acc`es `a la totalit´e des donn´ees du document.

Le r´esultat du chiffrement d’une partie d’un document XML (ou du document dans son enti`eret´e) est un ´el´ement XMLEncryptedDataqui remplacera l’´el´ement ou le contenu dans la version crypt´ee du document. Dans le cas du cryptage du document dans son enti`eret´e, l’´el´ement EncryptedData deviendra l’´el´ement ROOT du nouveau document XML. La structure de cet ´el´ement est illustr´ee par le code source 2.7 et est compos´ee des ´el´ements XML suivants :

– EncryptionMethod: ´el´ement XML optionnel d´ecrivant l’algorithme de chiffrement utilis´e.

– ds :KeyInfo : il s’agit d’un ´el´ement XML contenant les informations utiles dans le but de d´ecrypter le contenu de l’´el´ement CipherData.

– CipherData : il s’agit d’un ´el´ement obligatoire qui contient soit le contenu chiffr´e, soit une r´ef´erence vers le contenu chiffr´e.

– EncryptionProperties: ´el´ement XML renfermant des informations suppl´ementaires sur le contenu chiffr´e.

Ce mode de cryptage sera tr`es utile avec les services web dans le cryptage de parties d’un message SOAP.

2.7.4 XKMS

XKMS [49, 46], ou XML Key Management Specification, est une sp´ecification pro- pos´ee notamment par Microsoft, Verisign et webMethods au W3C. Elle permet d’int´egrer PKI⁴⁴ ainsi que les certificats num´eriques dans les transactions sur Internet, dans le but de s´ecuriser ces derni`eres. Ainsi, cette sp´ecification va permettre la distribution ainsi que

44Public Key Infrastructure : il s’agit d’une infrastructure `a cl´es publiques permettant notamment l’enre- gistrement d’utilisateurs, la g´en´eration/renouvellement/r´evocation/publication de certificats, identification et authentification des utilisateurs, etc.

Code source 2.7Structure de l’´el´ement EncryptedData

<EncryptedDataId ? Type ? MimeType ? Encoding ?>

<EncryptionMethod/>?

<ds :KeyInfo>

<EncryptedKey>?

<AgreementMethod>?

<ds :KeyName>?

<ds :RetrievalMethod>?

<ds :*>?

</ds :KeyInfo>?

<CipherData>

<CipherValue>?

<CipherReference URI ?>?

</CipherData>

<EncryptionProperties>?

</EncryptedData>

“ ?” repr´esente z´ero ou une occurrence

l’enregistrement de cl´es publiques qui seront notamment utilis´ees avec XML Signature (2.7.2) et XML Encryption (2.7.3). Un autre objectif de cette sp´ecification est de simplifier l’application voulant int´egrer la s´ecurit´e. En effet, l’application n’a plus besoin de g´erer la syntaxe ni la s´emantique des PKI, puisqu’il lui suffit d’utiliser un protocole XML plus simple pour obtenir les informations requises sur une cl´e aupr`es d’un service XKMS distant.

Comme pr´ecis´e par Kareen Renaudin (responsable apr`es-vente de webMethods) dans [1], XKMS est destin´ee `a ˆetre impl´ement´ee en tant que service web, permettant ainsi `a un client d’acc´eder aux diff´erents services PKI. La sp´ecification XKMS est constitu´ee de deux parties :

• X-KISS(XML Key Information Service Specification) : est un protocole permettant la localisation sans validation oblig´ee, puisque ce service peut ˆetre un relais vers un autre service et par cons´equent n’est pas oblig´e de se prononcer sur la validit´e ou la validation de l’information associ´ee `a une cl´e publique en utilisant alors des donn´ees locales.

• X-KRSS (XML Key Registration Service Specification) : est un protocole permet-

tant l’enregistrement d’une paire de cl´es par son propri´etaire de fa¸con `a la rendre utilisable par le protocole X-KISS.

2.7.5 SAML

SAML, ou Security Assertion Markup Language, est un langage d´evelopp´e par OASIS permettant l’´echange d’informations de s´ecurit´e aussi appel´ees assertions. Pour ce faire, celui-ci va d´efinir la syntaxe ainsi que la s´emantique des messages d’affirmation encod´es en XML, d´efinir un protocole de requˆete et de r´eponse entre diff´erentes parties ´echangeant ces informations de s´ecurit´e et d´efinir des r`egles, ces derni`eres afin d’utiliser les affirma- tions sur divers standards de transport (par exemple comment une affirmation SAML est transport´ee en utilisant SOAP).

La cr´eation de SAML n’est pas un hasard. En effet, ce standard tente de r´esoudre un probl`eme tr`es important : l’authentification unique ou SSO⁴⁵. L’authentification unique permet `a une entit´e (pouvant ˆetre un individu ou une machine) de n’effectuer qu’une seule fois une proc´edure d’authentification et d’´etendre cette authentification `a plusieurs applications, chacune n´ecessitant une authentification, sans r´eit´erer la proc´edure `a chaque application. Ceci est illustr´e `a la figure 2.8.

2.7.6 XACML

XACML, ou Extensible Access Control Markup Language, est un langage bas´e XML standardis´e par OASIS permettant la description de strat´egies de contrˆoles d’acc`es `a cer- taines ressources. Pour ce faire, ce langage inclut des types de donn´ees, des fonctions ainsi que de la logique.

Afin d’effectuer une action sur une ressource, un demandeur va envoyer une requˆete aupr`es de l’entit´e prot´egeant la ressource (comme par exemple un serveur web), aussi appel´eePolicy Enforcement Point (PEP). Ce dernier va construire une requˆete en fonction des diff´erents attributs du demandeur, de l’action demand´ee, de la ressource concern´ee et de toute autre information pertinente. Une fois ceci fait, il va l’envoyer `a un tiers de d´ecision appel´ePolicy Decision Point(PDP) qui va v´erifier s’il existe bel et bien une r`egle accordant l’acc`es `a cette ressource pour cette action `a cet utilisateur et renvoyer une r´eponse au PEP

45Single Sign-On.

Fig. 2.8 – Authentification unique

qui va accorder ou non en cons´equence l’acc`es au demandeur. Il est important de remarquer que le PEP et le PDP peuvent se retrouver dans une mˆeme application ou distribu´es sur plusieurs serveurs.

2.7.7 WS-Security

WS-Security, ou WSS, est une sp´ecification qui a d’abord ´et´e d´evelopp´ee par IBM, Mi- crosoft et Verisign, pour l’ˆetre ensuite par le consortium OASIS permettant d’inclure dans un message SOAP (2.6.3) des m´ecanismes de s´ecurit´e tels que la signature num´erique (XML Signature), l’encryptage (XML Encryption) et des jetons de s´ecurit´e. Cette sp´ecification permettra par cons´equent d’assurer l’int´egrit´e et la non-r´epudiation via la signature num´erique et la confidentialit´e⁴⁶ des donn´ees transmises via l’encryptage de celles-ci. De plus, une confidentialit´e “totale” peut ˆetre obtenue en utilisant un protocole de communication ad´equat tel que HTTPS⁴⁷. Les jetons de s´ecurit´e pourront quant `a eux ˆetre utilis´es dans des m´ethodes d’authentification telles que Kerberos [20] ou encore avec la recommandation

46Celle-ci peut ˆetre partielle par rapport `a la totalit´e des donn´ees.

X.509 [16].

Il est important de faire une distinction entre la s´ecurit´e apport´ee par un protocole de communication particulier et celle du message en tant que tel. En effet, nombreuses sont les diff´erences entre ces deux types de s´ecurit´e pouvant mener, lors de l’impl´ementation d’une infrastructure services web, `a un choix `a effectuer en fonction des avantages et inconv´enients de ces derniers. Une comparaison [33] de ces deux types de s´ecurit´e est r´esum´ee ci-dessous.

Alors qu’une s´ecurit´e au niveau transport cr´ee un tunnel de s´ecurit´e de point `a point sur un chemin, la s´ecurit´e au niveau du message s’applique entre deux extr´emit´es (endpoint).

De plus, la s´ecurit´e au niveau du message apporte une plus grande flexibilit´e dans le sens o`u XML Encryption permet de ne crypter qu’une certaine partie du message, rendant ainsi le contenu non crypt´e accessible et modifiable par les interm´ediaires. Un autre avantage d’une s´ecurit´e au niveau du message est que celle-ci peut utiliser une strat´egie diff´erente pour plusieurs messages. En effet, on pourrait parfaitement crypter une requˆete mais rendre la r´eponse `a cette derni`ere lisible par tous. De plus, la s´ecurit´e au niveau du message ne d´epend pas directement du protocole de transport utilis´e. Malheureusement, ces avantages ont un prix : celui de la complexit´e, qui est une cons´equence directe de l’usage des diff´erents standards pouvant ˆetre fait de diverses mani`eres⁴⁸. N´eanmoins, il est tout `a fait possible de combiner les deux solutions de fa¸con `a utiliser par exemple des jetons de s´ecurit´e, apparaissant normalement en clair, qui sont prot´eg´es via une s´ecurit´e de transport.

2.7.8 Autres sp´ ecifications bas´ ees sur WS-Security

Alors que WS-Security constitue la couche de base du mod`ele de s´ecurit´e des services web, une myriade de sp´ecifications vient s’y superposer de fa¸con `a rajouter des fonctionna- lit´es `a celle-ci. Ceci est illustr´e `a la figure2.9; la couche constitu´ee de WS-Policy, WS-Trust et WS-Privacy formant `a son tour une base pour les sp´ecifications de plus haut niveau : WS-SecureConversation, WS-Federation et WS-Authorization.

L’avantage de ce mod`ele est clair : permettre une grande modularit´e. En effet, selon les besoins, on pourra choisir les sp´ecifications qui nous int´eressent. Ainsi, nous pouvons disposer, en plus de WS-Security, des sp´ecifications suivantes :

48Faut-il une signature num´erique, une authentification, un cryptage ? Quel algorithme de cryptage utiliser ? O`u le client va-t-il trouver une cl´e publique pour encoder les donn´ees ? etc.

Fig. 2.9 – Standards bas´es sur WS-Security

– WS-Policy : permet de d´ecrire en terme de s´ecurit´e les exigences du destinataire ainsi que les capacit´es de s´ecurit´e de l’´emetteur d’un message.

– WS-Trust : d´ecrit un mod`ele permettant d’´etablir des relations de confiance pou- vant se baser sur un syst`eme de jetons de s´ecurit´e.

– WS-Privacy : d´ecrit les r`egles de discr´etion et de confidentialit´e.

– WS-SecureConversation : d´ecrit comment deux entit´es peuvent communiquer en s’authentifiant mutuellement et en formant un contexte de s´ecurit´e.

– WS-Federation: permet de construire des espaces de confiance globaux permettant ainsi d’effectuer des authentifications entre entit´es utilisant des m´ethodes d’authen- tification diff´erentes.

– WS-Authorization : d´ecrit comment g´erer et cr´eer des r`egles d’autorisation, cer- tifier des autorisations via des jetons, ´echanger ces jetons et interpr´eter ceux-ci de mani`ere `a contrˆoler correctement les acc`es aux services.

Chapitre 3

R´ eseaux peer-to-peer

3.1 Introduction

L’apparition des r´eseaux peer-to-peer est une cons´equence logique du d´esir de r´esoudre diff´erents probl`emes li´es `a l’augmentation de la demande de services sur Internet. En effet, le but premier de ce type de r´eseau est de permettre le partage de ressources et de donn´ees

`

a grande ´echelle tout en ´evitant le mod`ele centralis´e utilisant des serveurs pour lesquels l’administration peut ˆetre une tˆache complexe et coˆuteuse, surtout si ceux-ci sont soumis

`

a de grands trafics. Cette d´ecentralisation va permettre d’effectuer non plus une relation de client `a serveur dans laquelle chaque entit´e joue un rˆole bien distinct, mais une relation de pair-`a-pair¹ dans laquelle le rˆole de chaque entit´e est ´equivalent. En effet, chaque entit´e occupera la fonction de client mais ´egalement celle de serveur. Toutefois, diff´erentes topo- logies de r´eseaux peer-to-peer existent, modifiant ainsi le rˆole de chaque entit´e au sein de ces derniers.

Ce chapitre² a pour but de donner une vue d’ensemble du sujet tout en soulignant l’un des probl`emes principaux de ce m´emoire : les algorithmes de routage au sein d’un r´eseau peer-to-peer. Pour ce faire, ce chapitre donnera une d´efinition ainsi que les caract´eristiques et objectifs d’un r´eseau peer-to-peer. Ensuite, celui-ci d´ecrira les diff´erentes topologies existantes de tels r´eseaux et d´etaillera diff´erents protocoles de routage au sein de r´eseaux peer-to-peer structur´es.

1Peer-to-peer en Anglais et est abr´eg´e P2P.

2Afin de r´ealiser ce chapitre, les r´ef´erences suivantes ont ´et´e utilis´ees : [8, 40]