WEB SERVICES E Bdeptinfo.unice.fr › ~baude › WS › WebServices-2008.pdf• La sécurité des...

WEB

SERVICES

WEB

SERVICES

1FABRICE CLARI - [email protected] CLARI - [email protected]

WEBSERVICES

XMLSOAP, WSDLRPC avec SOAPAXISSOA…

WEBSERVICES

XMLSOAP, WSDLRPC avec SOAPAXISSOA…

WEB

SERVICES

WEB

SERVICES

2

• Pré-requiso XMLo Espaces de noms (namespaces)o XML Schema

• Services Web : définition• SOAP• Les protocoles de communication• RPC avec SOAP • WSDL • UDDI • Un scénario• Les éditeurs• La sécurité des services web• AXIS • SOA

Sommaire

WEB

SERVICES

WEB

SERVICES

3

Introduction à XML (1/4)

Afin de bien comprendre le fonctionnement des services web, il est important d’avoir quelques connaissances sur le langage XML et XML Schema.

• XML est un langage balisé qui est rapidement devenu le standard pour l’échange de données ;

• Les données sont identifiées grâce à des tags (tout tag ouvert doit impérativement être fermé) ;

• A la différence de HTML, les tags XML identifient des données et non un affichage.

Exemple : <?xml version="1.0" encoding="ISO-8859-1" ?>

<album><artiste> Jean-Jacques Goldman </artiste><titre> Chansons pour les pieds </titre><date_de_parution> 2001 </date_de_parution>

<chansons><titre piste='1'> Ensemble </titre><titre piste='2'> Et l'on y peut rien </titre><titre piste='3'> Une poussière </titre>

</chansons><prix euros='20' />

</album>

WEB

SERVICES

WEB

SERVICES

4


• Entre deux tags XML ouvert/fermé, se trouve un élément ;

• Un tag XML peut contenir d’autres tags, ce qui permet une représentation hiérarchique des données ;

• Un tag peut contenir un (voire plusieurs) attribut(s) (piste dans le tag titrede l’exemple précédent) ;

• Tous les tags ouverts doivent être fermés ;

• Un tag vide est valide (<prix euros='20' /> par exemple) ;

• Exemple de commentaires en XML :  ;

• Un document XML commence par un prologue : <?xml version="1.0" encoding="ISO-8859-1" ?>

• Différents types de parseur XML existent : DOM (Document Object Model), qui construit un arbre en mémoire du document, et SAX (Simple API to XML) qui associe un évènement à chaque balise lue.

Astuce : pour vérifier la validité d’un document XML, vous pouvez l’ouvrir avec Internet Explorer (version supérieure ou égale à la 5.5) qui dispose d’un parseur XML. Il affichera une erreur si le document est syntaxiquement faux.

WEB

SERVICES

WEB

SERVICES

5

<?xml version="1.0" encoding="ISO-8859-1" ?>

<albums><album>

<artiste> Jean-Jacques Goldman </artiste><titre> Chansons pour les pieds </titre><date_de_parution> 2001 </date_de_parution>

<chansons><piste n='1'> Ensemble </piste><piste n='2'> Et l'on y peut rien </piste><piste n='3'> Une poussière </piste>

</chansons><prix euros='20' />

</album></albums>


La notion d’espace de noms (namespace) est très utilisée dans les services web. Les namespaces permettent :

• de qualifier de manière unique des éléments et des attributs ; • la définition de balises modulaires.

Exemple

Un magasin de disques et de livres peut caractériser son stock par deux documents XML :

Un décrivant ses disques Un décrivant ses livres


<livres><livre>

<auteur> Jean-Marie Chauvet </auteur><titre> Services Web avec SOAP, WSDL, … </titre><date_de_parution> 2002 </date_de_parution><editeur>eyrolles</editeur><prix euros=‘39' />

</livre></livres>

Problème : la balise <titre> contient deux types d’informations.

WEB

SERVICES

WEB

SERVICES

6


<magasinxmlns:magasin="http://magasin.org"xmlns:album="http://album.org"xmlns:livre= "http://livre.org ">

<magasin:albums><magasin:album>

<album:artiste> Jean-Jacques Goldman </album:artiste><album:titre> Chansons pour les pieds </album:titre><album:date_de_parution> 2001 </album:date_de_parution>

<album:chansons><album:piste piste='1'> Ensemble </album:piste><album:piste piste='2'> Et l'on y peut rien </album:piste><album:piste piste='3'> Une poussière </album:piste>

</album:chansons><album:prix euros='20' />

</magasin:album></magasin:albums><magasin:livres>

<magasin:livre><livre:auteur> Jean-Marie Chauvet </livre:auteur><livre:titre> Services Web avec SOAP, WSDL, … </livre:titre><livre:date_de_parution> 2002 </livre:date_de_parution><livre:editeur> eyrolles </livre:editeur><livre:prix euros='39' />

</magasin:livre></magasin:livres>

</magasin>


L’espace de nom (xmlns) permet de créer un nom unique pour chacune des balises <titre>, en associant un identifiant unique (URI, Uniform Ressource Indentifier) à un nom.

Ces URI ne sont pas vérifiées. En général, elles pointent sur la grammaire de l’espace de noms.

WEB

SERVICES

WEB

SERVICES

7

Introduction à XML Schema

XML Schema précise comment représenter en XML une structure de données. A la différence des DTD, qui ne définissent que les imbrications des éléments entre eux, XML Schema définit les imbrications ainsi que les types des données (éléments et attributs).

Ainsi, le XML Schema définissant l’exemple <livre> (simplifié) est :

<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XML Schema"><xsd:element name="livre">

<xsd:complexType><xsd:sequence>

<xsd:element name=" auteur" type="xsd:string" minoccurs="1" maxoccurs="1"/>

<xsd:element name="titre" type="xsd:string"/><xsd:element name="date_de_parution" type="xsd:strin g"/><xsd:element name="editeur" type="xsd:string"/><xsd:element name="prix">

<xsd:complexType><xsd:attribute name="euros"

type="xsd:int"</xsd:complexType>

</xsd:element></xsd:sequence>

</xsd:complexType></xsd:element>

</xsd:schema>

WEB

SERVICES

WEB

SERVICES

8

De multiples définitions de la notion de Web Services existent, mais sont généralement trop vagues ou trop précises.

Un groupe de travail du W3C (Web Services Architecture group, composé de multiples membres de l’industrie) en donne une définition exacte :

« A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts, and supports direct interactions with other software applications using XML-based messages via Internet-based protocols ».

(source : http://www.w3c.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html#webservice)

• Cette définition met l’accent sur l’utilisation du langage XML, utilisé pour décrire la structure des messages échangés entre clients et serveurs de Services Web ;

• Elle ne précise pas quel protocole de transport doit être utilisé. Cependant, il doit s’agir d’un protocole utilisé sur Internet.

Web Services : une définition

WEB

SERVICES

WEB

SERVICES

9

Les composants d’un service web

Afin de mettre en œuvre un service web, trois composants sont nécessaires :

• un protocole pour décrire le service : il permet –entre autres- d’énumérer les méthodes disponibles, ainsi que leurs signatures (nous étudierons plus tard WSDL) ;

• un protocole pour écrire les messages ;

• un protocole de transport, afin de faire circuler les informations sur Internet.

http://www-106.ibm.com/developerworks/webservices/library/ws-best1/?dwzone=webservices#figure1

WEB

SERVICES

WEB

SERVICES

10

Le protocole SOAP (1/5)

Le protocole SOAP (Simple Object Access Protocol) est devenu le standard pour décrire les messages en XML entre services web. Ce dernier peut être utilisésur différents protocoles de transports. Les deux principaux protocoles utilisés étant HTTP et SMTP.

De par sa nature, SOAP permet l’inter-opérabilité entre différents systèmes d’exploitation et différentes plate-formes (J2EE, .NET, …).

SOAP permet de créer des applications de type distribuées, en suivant le modèle RPC (Remote Procedure Call).

La grande majorité des services web utilise le protocole SOAP.

Un message SOAP est un document XMLcomposé d’une enveloppe qui contientune entête et le corps du message.

Enveloppe SOAP

En-tête SOAP(header)

Corps du message SOAP(body)

WEB

SERVICES

WEB

SERVICES

11

<Envelope > <Header >

<Transaction>3<Transaction></ Header ><Body>

<echoString> <arg0>Hello!</arg0>

</echoString> </ Body>

</ Envelope >

L’enveloppe contient tout le message


Prenons l’exemple d’un message SOAP appelant une méthode echoString(string), qui prend en paramètre une chaîne de caractères.

Le corps (body) du message contient toutes les informations destinées au récepteur (les paramètres par exemple) ou l’élément fault si une erreur s’est produite.

L’entête (header) contient des informations non-liées à la méthode, comme par exemple l’ID de la transaction ou des informations pour la sécurité (infos du header = gestion du contexte).L’entête est facultative et les éléments qu’elle contient peuvent avoir l’attribut mustUnderstand, qui précise si le serveur est obligéde connaître et traiter l’élément.

WEB

SERVICES

WEB

SERVICES

12

<Envelope > <Header >

<Transaction>3<Transaction></ Header ><Body>

<echoStringResponse> <return>Hello!</return>

</echoStringResponse> </ Body>

</ Envelope >


Lorsque le serveur répond à la méthode echoString(string), il ajoute Response à la suite du tag <echoString> (d’une manière générale, il rajoute Response à la suite du tag contenant le nom de la requête.

Si une erreur se produit, la réponse contient l’élément Fault (dans le corps du message).

WEB

SERVICES

WEB

SERVICES

13


Une des forces de SOAP est de permettre l’inter-opérabilité entre différentes plate-formes. Il est donc important d’avoir des règles de codage des types de données, afin que ces dernières puissent être encodées/décodées sans difficultés.

On distingue deux types de données :

• Les données de types simples (une chaîne de caractère par exemple) ;

• Les types composés : structures ou tableaux.

Dans le cas où des données binaires devraient transiter (comme une image par exemple), il est également possible d’envoyer un message SOAP avec attachement et ce grâce à un message MIME (Multimedia Internet Mail Extension).

Pour pouvoir référencer une pièce jointe depuis le corps du message SOAP, une URI est utilisée, faisant référence à la pièce jointe.

WEB

SERVICES

WEB

SERVICES

14


<soapenv:Envelope xmlns:soapenv=" http://schemas.xmlsoap.org/soap/envelope/ "xmlns:xsd=" http://www.w3.org/2001/XMLSchema " xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance ">

<soapenv:Body>

<ns1:echoStringResponse soapenv:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding/ "

xmlns:ns1=" http://soapinterop.org/ "><return xsi:type=" xsd:string "> Hello! </return>

</ns1:echoStringResponse>

</soapenv:Body>

</soapenv:Envelope>

Les messages précédents présentaient SOAP sans l’utilisation des espaces de noms, obligatoires d’après les spécifications du protocole.

• xsi correspond au namespace des types de données connus ;• xsd correspond au namespace du schema du document ;• soapenv correspond au namespace de l’enveloppe (utilisé pour la gestion de la version SOAP).

WEB

SERVICES

WEB

SERVICES

15

La couche de transport (1/6)

Comme nous l’avons vu précédemment, la définition ne définit pas une couche de transport particulière. Le protocole SOAP quant à lui n’est pas dépendant d’un transport particulier (dans sa version 1.0 il ne pouvait circuler que sur HTTP ; cela a été corrigé dans la version 1.1).

Actuellement, deux couches de transport sont fréquemment utilisées (HTTP étant le plus courant) :

• HTTP, lors d’appels synchrones ;• SMTP, lors d’appels asynchrones.

Les spécifications de SOAP ne précisant pas de protocole particulier, on peut très bien imaginer invoquer des services web grâce au protocole FTP par exemple…

Le protocole HTTP (HyperText Transfert Protocol) est l’un des protocoles les plus utilisés sur Internet. La plupart des clients web (IE, …) l’utilisent pour communiquer avec un serveur.

Ce protocole définit le format des requêtes qu’un client peut envoyer ainsi que les résultats qu’il peut attendre. Chaque requête contient une URL qui contient l’identifiant d’un objet demandé par le client (ex.: pages HTML, images, …).

Ce protocole est défini par le W3C et est présenté dans une RFC (Request for Comment) : ftp://ftp.isi.edu/in-notes/rfc2616.txt.

WEB

SERVICES

WEB

SERVICES

16

La couche de transport (2/6) : HTTP

Exemple : un navigateur web souhaite obtenir la page par défaut du site www.google.fr

Client HTTP (Internet Explorer)

Serveur Web(Apache)

Ouverture d’une socket sur le port 80 (port par défaut)

GET / HTTP/1.0

HTTP/1.0 200 OKContent-Length: 3403Server: GWS/2.0Date: Mon, 14 Oct 2002 06:31:35 GMTContent-Type: text/html

<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Google</title><style>……

Dans le cas où toutes les requêtes HTTP doivent transiter par un serveur de cache (proxy HTTP), il faut ouvrir les connexions sur ce proxy (et non sur le serveur ciblé) puis demander l’URL entière.

Ex. : si un client, souhaite obtenir la page www.google.fr en passant par proxy.monintranet

1. Ouverture de la socket (en TCP) sur le port 3128 (port par défaut) de proxy.monintranet ;2. Envoi de la requête : GET http://www.google.fr HTTP/1.03. Le proxy se connecte à son tour à google.fr ;4. Une fois que le proxy a obtenu le résultat, il répond au client.

WEB

SERVICES

WEB

SERVICES

17

• Quand un client envoie une requête, il l’envoie grâce à une méthode (GET, POST ou HEAD), suivie d’une URI (Uniform Ressource Identifier) qui identifie la ressource demandée. Après cette URI se trouve la version du protocole HTTP (1.0 ou 1.1) ;

• Dans les lignes suivantes se trouvent les entêtes qui précisent par exemple quels sont les documents acceptés par client, de quel type de client il s’agit, …

• Après les entêtes se trouve le corps de la requête, rempli seulement lorsque la méthode POST est utilisée.

Permet de supprimer une ressource. DELETE

Permet d’ajouter une ressource.PUT

Permet au client d’envoyer des données dans le corps de la requête.

Utile pour envoyer des formulaires, des documents, poster des messages dans les newsgroups… Cette méthode est celle qui convient le mieux à SOAP

POST

Comme GET, mais aucune information ne se trouve dans le corps du résultat.

Notamment utilisé pour voir si un document a été mis à jour.

HEAD

Utilisé pour demander un document : GET index.html

Le corps d’une telle requête est toujours vide.

Permet également de passer des paramètres au serveur, en les collant à l’URL :

GET index.jsp?userLogin=toto&userPasswd=kkju

Comme résultat, GET renvoie d’abord les entêtes, puis le contenu du document

GET

Les méthodes

• D’autre méthodes existent : LINK, UNLINK, OPTIONS, TRACE mais sont rarement utilisées ;

• La réponse du serveur contient le statut de la réponse, les entêtes puis le corps de la réponse (par exemple le contenu d’un document HTML ;

• Différents statuts existent. Les principaux sont : 200 (ok), 400 (mauvaise requête), 403 (client non autorisé), 404 (document inexistant), 500 (erreur d’exécution –sur le serveur).


Utilisées dans les architectures REST

WEB

SERVICES

WEB

SERVICES

18

Résumé:

• Format d’une requête HTTP:

CommandeEn-têtes[Ligne vide ]Corps


http://fr.wikipedia.org/wiki/HTTP

Codes de retour: http://fr.wikipedia.org/wiki/Liste_des_codes_HTTP

Version actuelle: 1.1

• Format d’une réponse HTTP:

StatusEn-têtes de réponse[Ligne vide ]Corps de réponse

WEB

SERVICES

WEB

SERVICES

19

La couche de transport (5/6) : SMTP

SMTP (Simple Mail Transfer Protocol) est le principal protocole utilisé sur Internet pour faire transiter les emails entre deux hôtes (une passerelle peut également être utilisée).

SMTP utilise TCP comme couche de transport et le port 25 par défaut.

Exemple de l’utilisation du protocole SMTP pour l’envoi d’un mail sur wanadoo.fr : - La première étape est l’ouverture d’une connexion (socket) sur le port 25 de smtp.wanadoo.fr.

WEB

SERVICES

WEB

SERVICES

20

Exemple d’envoi d’un message SOAP au dessus de HTTP

Le message ne contient aucune information le liant à la couche de transport. Concernant le protocole HTTP, l’ajout d’un attribut SOAPAction:uneURI permet au destinataire (le serveur HTTP) de savoir qu’il reçoit une requête SOAP. La valeur est une uri qui n’est pas vérifiée.

Pour un envoi via HTTP:

• ouverture d’une socket sur le port du serveur (80 par défaut) ;• puis :

POST /axis/services/echo HTTP/1.0Content-Type: text/xml; charset=utf-8User-Agent: Axis/1.0Host: 192.168.0.1:8080Cache-Control: no-cachePragma: no-cacheSOAPAction: http://tempuri.org/echoContent-Length: 453

• puis est envoyée la requête.

La couche de transport (6/6)

Obligatoire pour requêteSOAP sur HTTP

WEB

SERVICES

WEB

SERVICES

21

RPC (1/2)

Un RPC (Remote Procedure Call), est un mécanisme permettant l’appel local d’une méthode distante : un client possède une copie (un stub) d’un objet distant sur lequel il appelle des méthodes. Côté serveur, le skeleton est un objet s’interfaçant avec le vrai objet appelé.

• Un stub est un proxy coté client.

Différents langages de RPC existent, dont :

• Corba ;• DCOM ;• RMI ;• SunRPC;• DCE (Distributed Computing Environment).

Un système distribué permet de répartir des sous-ensembles d’une architecture dans différents serveurs.

L’avantage d’un RPC est qu’il n’y a (presque!) pas de différence entre un appel local et un appel distant. Il n’y a donc plus à se soucier de la couche réseau, qui est gérée par le RPC.

WEB

SERVICES

WEB

SERVICES

22

Code de l’appelant STUB RéseauRéseau

Protocole réseau

Client Serveur

Protocole réseau SKELETON

Code du serveur

Service RPC Service RPC

RPC (2/2)

Une architecture distribuée

Chaque RPC a son protocole de communication:• IIOP pour Corba ;• ORPC pour DCOM ;• JRMP pour RMI ;• et HTTP, SMTP, … pour SOAP !

On constate des différences entre SOAP et les autres protocoles :

• SOAP est le seul protocole qui ne fait pas circuler de données binaires. En plus d’être lisible, cela permet le débugage ;• SOAP peut circuler sur HTTP, ce qui lui permet de passer les firewalls dans leurs configurations standards. C’est là un de ses grands avantages.

WEB

SERVICES

WEB

SERVICES

23

A ses débuts, SOAP était destiné à être un protocole fournissant un mécanisme de RPC, inter-opérable, car utilisant XML & HTTP (il est maintenant –entre autre–un protocole de communication entre services web par échanges de messages XML).

Lors d’un appel RPC, un message SOAP doit contenir :

• l’adresse du destinataire du message ;

• le nom de la méthode à exécuter ;

• les paramètres à passer à la méthode.

En devenant un RPC, les services web en SOAP peuvent être vus comme un point d’entrée dans les applications « lourdes » : par exemple, un service web peut permettre une connexion entre un client sur Internet et une application à base d’EJB.

De nombreuses API (Application Programmer Interface) permettent de créer des stubs de méthodes exposées dans des services web. Nous étudierons en TP l’API Axis d’Apache (« un SOAP engine »).

RPC avec SOAP

WEB

SERVICES

WEB

SERVICES

24

WSDL (1/3)

WSDL (Web Service Description Langage), est un langage de description de services web en XML.

Il décrit :

• Les informations sur les fonctions publiques du service web ;

• Les types de données utilisés durant l’échange de messages ;

• Les différents protocoles aux travers desquels le service est accessible ; et comment y accéder ;

• Une adresse permettant de localiser le service web.

A noter : WSDL pourrait décrire n’importe quel protocole de messagerie basé sur XML.

A noter (2) : les documents WSDL ne sont jamais générés par des développeurs, mais le sont grâce à des outils qui automatisent la tâche (par exemple, il existe des outils qui prennent une classe Java et qui créent le WSDL correspondant).

WEB

SERVICES

WEB

SERVICES

25

WSDL (2/3)Ci-dessous le document WSDL décrivant un WS proposant une méthode d’addition.

Décrit les messagesqui circulent

Définit comment est disponible(SOAP) la méthode et à quelle adresse

Abstraction décrivant une opération

Protocole d’accès et format des messages

<wsdl:definitions targetNamespace="http://192.168.0. 12:8080/axis/SimpleWS.jws"/><wsdl:message name="addRequest">

<wsdl:part name="i1" type="xsd:int"/><wsdl:part name="i2" type="xsd:int"/>

</wsdl:message><wsdl:message name="addResponse">

<wsdl:part name="addReturn" type="xsd:int"/></wsdl:message><wsdl:portType name="SimpleWS">

<wsdl:operation name="add" parameterOrder="i1 i2"><wsdl:input message="impl:addRequest" name="addReque st"/><wsdl:output message="impl:addResponse" name="addRes ponse"/>

</wsdl:operation></wsdl:portType><wsdl:binding name="SimpleWSSoapBinding" type="impl: SimpleWS">

<wsdlsoap:binding style="rpc" transport="http://sche mas.xmlsoap.org/soap/http"/><wsdl:operation name="add">

<wsdlsoap:operation soapAction=""/><wsdl:input name="addRequest">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap .org/soap/encoding/" namespace="http://192.168.0.12:8080/axis/SimpleWS.j ws" use="encoded"/>

</wsdl:input><wsdl:output name="addResponse">

<wsdlsoap:body encodingStyle="http://schemas.xmlsoap .org/soap/encoding/" namespace="http://192.168.0.12:8080/axis/SimpleWS.j ws" use="encoded"/>

</wsdl:output></wsdl:operation>

</wsdl:binding><wsdl:service name="SimpleWSService">

<wsdl:port binding="impl:SimpleWSSoapBinding" name=" SimpleWS"><wsdlsoap:address location="http://192.168.0.12:8080 /axis/SimpleWS.jws"/>

</wsdl:port></wsdl:service>

</wsdl:definitions>

WEB

SERVICES

WEB

SERVICES

26

WSDL (3/4)

• Sur le slide précédent, quelques éléments n’ont pas été présentés. Reprenons l’élément <port> : il définit un point de terminaison (adresse internet plus liaison).

<wsdl:service name="SimpleWSService"><wsdl:port binding="impl:SimpleWSSoapBinding" name="SimpleWS">

<wsdlsoap:address location="http://192.168.0.12:8080 /axis/SimpleWS.jws"/></ wsdl:port >

</wsdl:service>

• Il est à noter que l’élément <portType> peut contenir plusieurs opérations.

• A l’exemple précédent manque l’élément <type> qui permet de définir des types complexes (dans l’exemple ci-dessous, la valeur renvoyée est une chaîne de caractères).

Remarque : dans la définition des messages, nous n’avons aucune information sur le protocole de transport. Cela reste dans la logique des web services.

• Le logiciel XMLSpy donne une bonne vue (graphique) d’un document WSDL (ici celui du slide précédent).Une version complète d’évaluation (30 jours) est disponible sur http://www.altova.com.

WEB

SERVICES

WEB

SERVICES

27

WSDL (4/4)

WSDL : résumé des éléments d’un document

• Operation : une action particulière supportée par le service web décrit. En faisant l’analogie avec Java, on peut comparer une Operation à une (méthode d’une) Interface ;

• Message : définition des types de données utilisées lors de l’invocation (et de la réponse) d’une opération ;

• PortType : un ensemble (1..n) d’opérations ;

• Binding : lien entre un PortType et un protocole d’accès ;

• Port : définit un point d’accès (cad une URL par exemple) pour un binding ;

• Service : contient une collection de ports.

WEB

SERVICES

WEB

SERVICES

28

UDDI (1/2)

UDDI (Universal Description, Discovery and Integration) est un standard ayant pour but la création d’un annuaire distribué de services web.

Cet annuaire contient :

• les pages blanches : informations générales sur une société (nom, description, adresse) ;

• les pages jaunes : classement des types de services ;

• les pages vertes ou roses : informations sur les modes d’exploitation du service.

L’UDDI Business Registry est une implémentation complète des spécifications UDDI. Lancée en mai 2001 par Microsoft et IBM, elle permet maintenant àquiconque d’y chercher des informations et aux sociétés de s’enregistrer.

UDDI repose sur une architecture distribuée comparable à celle des serveurs DNS.

En guise d’exemple :

• http://uddi.microsoft.com ;• http://www.ibm.com/services/uddi.

WEB

SERVICES

WEB

SERVICES

29

UDDI (2/2)

L’API UDDI propose deux fonctionnalités principales :

• la recherche de services (envoi de requêtes).

• la publication de services dans un annuaire UDDI ;

Les clients UDDI interrogent les serveurs (les sites opérateurs) UDDI en envoyant des requêtes formatées en SOAP (sur HTTP avec la méthode POST).

______________

Le slide suivant présente un scénario complet. Les étapes sont :

1. Publication d’un service web par une société ;2. Recherche d’un service web ;3. Découverte d’un service web ;4. Consommation d’un service web.

WEB

SERVICES

WEB

SERVICES

30

UDDI + WSDL + SOAP : vue d’ensemble

ServeurUDDI

EntrepriseA

WS

L’entreprise A développe et déploie un service web (WS)

1

L’entreprise A publie WS

2

Le serveur UDDI renvoie l’adresse de WS (plus d’autres info comme la description du service. cf plus loin)

4

EntrepriseBL’entreprise B, à la recherche d’un service

du type WS, envoie une demande de recherche au serveur UDDI

3

L’entreprise B invoque WS

5

L’entreprise A répond à B

6

WEB

SERVICES

WEB

SERVICES

31

Conclusions de la première partie

• Trop souvent on lit « web services = SOAP ». C’est faux !

Web service = XML + (HTTP|SMTP|FTP|…)

• Les services web permettent de mettre en place des services faiblement couplés (loosely coupled), rendant la communication entre deux plate-formes incompatibles possible.

•SOAP est indépendant de la couche de transport ;

•Cependant, SOAP est devenu de facto le standard des services web ;

• SOAP peut faire des RPC, mais pas que des RPC ;

• WSDL sert à décrire des services web ;

• UDDI est un annuaire qui répertorie les sociétés et les services web qu’elles proposent ; UDDI est basé sur une architecture distribuée.

WEB

SERVICES

WEB

SERVICES

32

Les offres du marché

Le marché des services web est très fourni : la plupart des éditeurs proposent des kits de développement.

Le premier à proposer les services web au cœur de son architecture a étéMicrosoft, avec la plate-forme .NET.

Le monde Java a bien réagi bien que les spécifications J2EE de l’époque (version 1.3) ne parlaient aucunement de services web. Ils y ont été introduits dans la version 1.4.

Tous les éditeurs du monde Java proposent leur kit pour les services web :

• Oracle pour 10gAS ;• BEA pour WebLogic ;• IBM pour WebSphere;• Sun pour Sun Java System Application Server ;• …

De nombreux projets Open Source existent également, comme par exemple l’API Axis utilisée en TP. Les IDE open source intègrent eux aussi ces technologies : Eclipse, NetBeans...

WEB

SERVICES

WEB

SERVICES

33

La sécurité des services web (1/4)

A la vue du contenu des messages issus des services web, il est important de disposer de mécanisme de sécurité assurant l’authentification, l’intégrité et l’authenticité des données.

La sécurité d’un service web peut se faire à deux niveaux :

• « applicatif » : sur la couche SOAP par exemple ;

• au niveau réseau.

L’avantage de pouvoir passer les firewalls donnent aux hackers de nouveaux points d’entrée dans le système d’information de l’entreprise ; ce qui peut leur permettre par exemple de lancer une attaque de déni de service sur le serveur.

De plus, les messages étant codés en XML, les méthodes et procédures proposées par une entreprise transitent « en clair » sur le réseau, ce qui constitue une indication pour les pirates.

A la vue de l’architecture des services web, il apparaît que la problématique de sécurisation est la même que celle d’un site web car les données transitent (dans la plupart des cas) sur HTTP.

On peut donc dans un premier temps mettre les mêmes solutions de sécuritéque celles utilisées pour les sites web, à savoir le protocole SSL.

WEB

SERVICES

WEB

SERVICES

34

Seuls le client et

le serveur peuvent

déchiffrer ces messages


Le protocole SSL a été développé par Netscape. Permettant le cryptage des données, il est très utilisé sur Internet pour faire transiter des informations sensibles (par exemple un numéro de carte de crédit).

Il est à noter que l’organisme de normalisation IETF l’a renommé TLS.

Le protocole HTTP s’utilisant avec le protocole SSL devient HTTPS. Le port par défaut n’est plus 80 mais 443.

SSL est basé sur la cryptographie. Il fonctionne grâce à un système de clés publiques et de clés privées.

1 - Le client initialise une connexion (non cryptée, port 443 par défaut)

2- Le serveur renvoie une clé de cryptage (sa clé publique). Cette requête n’est pas cryptée.

3 – Le client génère une chaîne de 46 octets et la crypte avec la clépublique du serveur. Seul le serveur (possédant la clé privée) peut

décrypter ce message.

4 - Le serveur décrypte la chaîne de 46 octets qui est utilisée pour créer des clés de cryptage utilisées pour le reste de la session

5 - Les données transitant sont cryptées

WEB

SERVICES

WEB

SERVICES

35


SSL permet grâce aux clés publiques et privées d’encoder les messages, mais ne permet pas d’identifier le serveur.

En effet, au moment de l’initialisation du protocole SSL (étape 2) sur le slideprécédent, n’importe qu’elle serveur pirate peut se faire passer pour le serveur interrogé par le client et renvoyer une clé publique.

Pour palier ce problème, les certificats ont été mis en place.

Un certificat est un objet verrouillé qui contient l’identité d’un serveur ainsi que sa clé publique. Il est encrypté avec la clé privée de l’organisme qui le délivre (comme Verisign par exemple).

Quand un client se connecte à un site, il demande à l’organisme des certificats de vérifier l’identité du serveur (grâce au certificat envoyé par le serveur).

Cela permet d’avoir avec HTTPS l’authentification ainsi que le cryptage des données.

WEB

SERVICES

WEB

SERVICES

36


La sécurité des services web peut également se faire sur des couches plus basses (couches réseaux). Grâce à des règles définies sur des firewalls, on peut par exemple autoriser l’accès à un service web seulement à des clients ayant des adresses IP connues.

Certains constructeurs/éditeurs de firewalls ajoutent des règles de filtrage de messages SOAP, qui peuvent grâce à des entêtes SOAP vérifier qu’un consommateur d’un service est autorisé à y accéder.

Des protocoles spécifiques sont en cours d’élaboration. Microsoft a proposé au W3C le protocole WS-Security qui permet l’identification des utilisateurs, l’intégrité des messages SOAP ainsi que le chiffrement des données. WS-Security est basé sur XML Signature (authenticité de l’utilisateur) et de XML Encryption (encodage des données).

Un exemple avec le protocole WS-Security (source : http://msdn.microsoft.com)

WEB

SERVICES

WEB

SERVICES

37

AXIS

• Axis est une API Java (Open Source) servant à créer et à consommer des services web;

• AXIS = Apache eXtensible Interaction System

• Site web : http://ws.apache.org/axis ;

• Supporte SOAP 1.1 et 1.2 partiellement ;

• Pas de support d’UDDI ;

• S’utilise avec n’importe quel serveur d’application J2EE (propose même un serveur HTTP pour fonctionner en mode stand-alone) ;

• Propose deux outils WSDL2Java et Java2WSDL permettant le mapping entre des services web et des classes Java, et vice-versa ;

• Dispose d’un outil de monitoring de requêtes ;

• Propose un méchanisme ultra-simple de création de services web ;

• AXIS est l’API que nous allons utiliser pendant les TPs.

WEB

SERVICES

WEB

SERVICES

38

AXIS : invocation dynamique d’un service web

• AXIS implémente la spécification JAX-RPC

WEB

SERVICES

WEB

SERVICES

39

AXIS : utilisation de WSDL2Java

WSDL2Java permet de représenter un service côté client. A la différence de l’invocation dynamique, cela permet de :

• passer les arguments à la place de tableaux d’objets (cf exemple précédent) ;• avoir en retour l’objet attendu et non un objet « Object » à caster…

WSDL2Java génère :

port-nameService.java<service>

nom-portBindingStub.java<binding>

nom-port.java<porttype>

nom-type.java<type>

Classe généréeNom de la balise XML dans le document WSDL

WEB

SERVICES

WEB

SERVICES

40

AXIS : utilisation de WSDL2Java

Relations entre les fichiers générés par WSDL2Java et séquence d’utilisation :

source : http://www.ociweb.com/javasig/knowledgebase/2002Sep/Axis.pdf

WEB

SERVICES

WEB

SERVICES

41

Un peu de sécurité dans la pratique (1/2)

Quelles sont les attaques auxquelles un service web est exposé :

• Déni de service ;• Interception et manipulation des messages ;• Requête du client falsifiée ;• Réponse du serveur falsifiée ;• Tentative de lectures/écritures sur le système de fichiers du serveur.

-> Ces attaques ne sont pas spécifiques aux services web mais aux serveurs web !

A ces attaques, se rajoutent les attaques propres aux données XML :

• Envois de très gros documents XML (assimilée à un déni de service) ;• Déclarations d’entités récursives dans les headers XML ;• Déclarations d’entités pointant sur un fichier local.

source : documentation d’Axis

WEB

SERVICES

WEB

SERVICES

42

Un peu de sécurité dans la pratique (2/2)

Quelques options pour sécuriser un service web :

• Authentifier les clients (avec HTTPS par exemple) ;

• Ecrire du code sûr ;

• Recompiler Axis avec le strict nécessaire à l’exécution du service ;

• Renommer les outils exposés afin que personne ne sache que vous utilisez Axis (ou une autre API) ;

• Désactiver la génération automatique des fichiers WSDL ;

• Filtrer les accès via les adresses IP ;

• Logger les accès ;

• Lancer le serveur web et Axis avec des droits réduits ;

• ...

WEB

SERVICES

WEB

SERVICES

43

La mobilité et les services web (1/2)

De nombreuses solutions permettent d’invoquer des services web depuis des clients mobiles (PDA PocketPC/Linux, téléphones J2ME).

Avec un OS Microsoft :

• .NET CF : la version pour terminaux mobiles de l’environnement d’exécution (runtime) de .NET intègre les API pour invoquer des services web ;

• PocketSOAP : client open source SOAP, disponible sous la forme d’un objet COM (également disponible pour win32) ;

En faisant du Java :

• J2ME Web Service API (JSR 172) : http://developers.sun.com/techtopics/mobility/apis/articles/wsa ;

• Oracle J2ME Web Service : cf slide suivant.

PS : ce n’est pas une liste exhaustive !

WEB

SERVICES

WEB

SERVICES

44

La mobilité et les services web (2/2)

Service webService webProxyProxy

L’approche d’Oracle pour la consommation de services web depuis des applications J2ME :

exemple d’appel d’un service web « Addition »

SOAP/HTTP

add 3 4

7

� Un proxy se charge de la communication avec le service web afin d’en cacher la complexité au client J2ME. Ce proxy doit être généré pendant le développement de l’application (depuis JDeveloper, IDE d’Oracle) ;

� Le terminal mobile n’envoie donc que la chaîne de caractères « add 3 4 », ce qui lui évite de faire du traitement XML (coûteux).

WEB

SERVICES

WEB

SERVICES

45

Architectures Orientées Services (1/4)

SOA = Services Oriented Architecture

Source : http://fr.wikipedia.org/wiki/Service_Oriented_Architecture

L’architecture orientée service est un modèle d’interaction applicative qui met enœuvre des services (composants logiciels) :

• avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent XML)

• et des couplages externes « lâches » (par l'utilisation de couche d'interface intéropérable, le plus souvent un Web services).

� SOA est un concept, les services web en sont une utilisation.

Description d’une architecture SOA :

• Annuaire de services : référence l’ensemble des services disponibles au sein du système d’information ;

• Bus de services : le bus a un rôle de médiateur (middleware) entre le consommateur

et le producteur du service, il permet ainsi de réaliser le couplage lâche ;

• Service : cf. slide suivant.

-> SOA définit comment allier développement orienté objet et programmation distribuée.

WEB

SERVICES

WEB

SERVICES

46


SOA, définitions :

• Fournisseur de services (service provider) : entité qui fournit et exécute le service (cad le serveur) ;

• Consommateur de services (service consumer) : entité qui consomme le service (cad le client) ;

• Message (message): entrées et sorties du service (dans les services web: SOAP) ;

• Contrat de service (service contract) : document qui définit comment le fournisseur et le consommateur inter-agissent (dans les services web: WSDL) ;

• Annuaire (service registry) : un annuaire dans lequel se trouvent les services (dans les services web: UDDI).

WEB

SERVICES

WEB

SERVICES

47



Le service est un composant clef de l’Architecture Orientée Services. Il consiste en une fonction ou fonctionnalité bien définie.

Une architecture orientée services consiste essentiellement en une collection de services qui interagissent et communiquent entre eux. Cette communication peut consister en un simple retour de données ou en une activité (coordination de plusieurs services).

Un service est une entité de traitements qui respecte les caractéristiques suivantes :

• Grande maille (coarse grained) : les opérations proposées par un service encapsulent plusieurs fonctions et opèrent sur un périmètre de données large au contraire de la notion de composant technique ;

• Interface : un service peut implémenter plusieurs interfaces et aussi plusieurs services peuvent implémenter une interface commune ;

• Localisable : avant d’appeler (bind, invoke) un service, il faudra le rechercher (find).

• Instance unique : à la différence des composants qui sont instanciés à la demande et peuvent avoir plusieurs instances en même temps ; un service est unique. Il correspond au design pattern Singleton ;

• Faible couplage (loosely-coupled) : les services sont connectés aux clients et autres services via des standards. Ces standards assurent la réduction de dépendance et du découplage . Ces standards sont des documents XML comme dans les web services ;

• Synchrone ou Asynchrone.

WEB

SERVICES

WEB

SERVICES

48



Parmi les différentes couches de normes et protocoles qui permettent de bâtir des architectures orientées services, on relève :

• la gestion d'un annuaire de services (quels sont les services mis à disposition et par qui) avec : UDDI (Universal Description Discovery and Integration) normalisé par l'OASIS ;

• la description des interfaces des services (quelles sont les données nécessaires àl'exécution du service, que fournit-il en retour, ...) avec : WSDL (Web Services Description Language) recommandé par le W3C ;

• l'invocation (ou l'appel) du service (la requête transmise au service) avec : SOAP (Simple Object Access Protocol) recommandé par le W3C ;

• le format des données échangées avec : XML (eXtensible Markup Language) recommandépar le W3C ;

• le transport des données avec les protocoles internet : HTTP et TCP/IP qui sont des normes RFC ;

• la gestion de la sécurité avec : SSL (Secure Sockets Layer), XML Signature, XML Encryption, SAML (Security Assertion Markup Language) ou encore XKMS (XML Key Management Specification, qui gère les infrastructures à clé publique ou PKI) ;

• l'orchestration (on parle également de chorégraphie) des services pour constituer des processus métier avec : BPEL4WS (Business Process Execution Language For Web Services) qui regroupe WSFL (Web Services Flow Language) d'IBM et XLang de Microsoft, ou encore WSCI(Web Services Choregraphy Interface) ;

• la gestion transactionnelle : WS-Transaction d'IBM, XAML (Transaction Authority MarkupLanguage) ou encore BTP (Business Transaction Protocol).

WEB SERVICES E Bdeptinfo.unice.fr › ~baude › WS › WebServices-2008.pdf• La sécurité des...

Documents

Transcript of WEB SERVICES E Bdeptinfo.unice.fr › ~baude › WS › WebServices-2008.pdf• La sécurité des...