Sec Des Services Web

Projet de semestre – Sécurité des services web Jonathan Rod
Rapport
Projet de semestre de Jonathan Rod, EIT6
Ecole d’ingénieurs du Canton de Vaud - 2003
Mandaté par : e-Xpert Solutions SA

Contact : Sylvain Marret
Professeur responsable : Stefano Ventura

Chargé de cours responsable : Christian Buchs
Page 1 / 52 10/07/2003
Table des matières :

1 INTRODUCTION ............................................................................................................................................ 5
2 MOTIVATIONS............................................................................................................................................... 5
3 DÉFINITIONS.................................................................................................................................................. 5
3.1 SÉCURITÉ .................................................................................................................................................... 5
3.2 SÉCURITÉ INFORMATIQUE ........................................................................................................................... 5
3.3 SERVICES WEB............................................................................................................................................. 5
4 SIMPLE OBJECT ACCESS PROTOCOL (SOAP).................................................................................... 6
4.1 AUTHENTIFICATION DU MESSAGE ............................................................................................................... 6
4.2 SIGNATURE DU MESSAGE ............................................................................................................................ 7
4.3 ENCRYPTION DU MESSAGE .......................................................................................................................... 7
4.4 APPLICATION............................................................................................................................................... 7
5 SERVICE WEB SOAP .................................................................................................................................... 8
5.1 SITUATION ................................................................................................................................................... 8
5.2 INFRASTRUCTURE ..................................................................................................................................... 11
5.3 SÉCURISATION .......................................................................................................................................... 11
5.3.1 « All-in-One »................................................................................................................................... 11
5.3.2 « Classique » .................................................................................................................................... 12
5.3.3 Election............................................................................................................................................. 13
6 PLATEFORMES............................................................................................................................................ 13
6.1 IPCOP ........................................................................................................................................................ 13
6.1.1 Introduction ...................................................................................................................................... 13
6.1.2 Motivation ........................................................................................................................................ 14
6.1.3 Installation........................................................................................................................................ 14
6.1.4 Configuration ................................................................................................................................... 14
6.1.5 Tests .................................................................................................................................................. 14
6.1.6 Vulnérabilité..................................................................................................................................... 14
6.1.7 Conclusion........................................................................................................................................ 14
6.2 APACHE ..................................................................................................................................................... 14
6.2.1 Introduction ...................................................................................................................................... 14
6.2.2 Motivation ........................................................................................................................................ 15
6.2.3 Installation........................................................................................................................................ 15
6.2.4 Configuration ................................................................................................................................... 15
6.2.5 Tests .................................................................................................................................................. 15
6.2.6 Conclusion........................................................................................................................................ 15
7 WEB SERVICE SECURITY ........................................................................................................................ 15
8 DESCRIPTION DU FIREWALL SOAP .................................................................................................... 16

8.1 MOTIVATIONS ........................................................................................................................................... 16
8.2 BUTS.......................................................................................................................................................... 16
8.3 FONCTIONNALITÉS .................................................................................................................................... 16
8.4 IMPLÉMENTATION ..................................................................................................................................... 16
8.5 COMPORTEMENT ....................................................................................................................................... 16
8.6 SPÉCIFICATIONS ........................................................................................................................................ 18
8.7 POLITIQUE DE SÉCURITÉ............................................................................................................................ 18
8.8 CYCLE DE VIE ............................................................................................................................................ 18
8.9 CONCLUSION ............................................................................................................................................. 18
9 CONCLUSION ............................................................................................................................................... 19
10 BILAN.......................................................................................................................................................... 19
Page 2 / 52 10/07/2003
11 RÉFÉRENCES ........................................................................................................................................... 20
12 ANNEXE 1 : SIMPLE OBJECT ACCESS PROTOCOL..................................................................... 21

12.1 DÉFINITION ............................................................................................................................................... 21
12.1.1 Services web ..................................................................................................................................... 21
12.1.2 Appel à distance de procédure......................................................................................................... 21
12.1.3 SOAP (Simple Object Access Protocol) .......................................................................................... 21
12.2 INTRODUCTION À SOAP ........................................................................................................................... 21
12.2.1 SOAP & XML ................................................................................................................................... 22
12.2.2 Messages SOAP................................................................................................................................ 22
12.2.3 Fautes SOAP .................................................................................................................................... 24
12.2.4 Modèle d’échange de message......................................................................................................... 24
12.2.5 Réaliser un service web « RPC »..................................................................................................... 25
12.2.6 Encodage des données - Terminologie ............................................................................................ 26
12.2.7 Types de donnée ............................................................................................................................... 28
12.2.8 Transport des messages SOAP ........................................................................................................ 28
12.3 CONCLUSION ............................................................................................................................................. 29
12.4 RÉFÉRENCE ............................................................................................................................................... 29
13 ANNEXE 2 : WS-SECURITY .................................................................................................................. 30
13.1 MOTIVATION ............................................................................................................................................. 30
13.2 INTRODUCTION .......................................................................................................................................... 30
13.3 APPLICATION DE WS-SECURITY ............................................................................................................... 30
13.4 ENTÊTE SOAP VERSION WS-SECURITY ................................................................................................... 31
13.5 PARAMÈTRES SUPPLÉMENTAIRES ............................................................................................................. 31
13.6 AUTHENTIFICATION .................................................................................................................................. 32
13.6.1 Username / password....................................................................................................................... 32
13.6.2 X.509 Certificats............................................................................................................................... 33
13.6.3 Kerberos ........................................................................................................................................... 33
13.7 SIGNATURE................................................................................................................................................ 33
13.8 ENCRYPTION ............................................................................................................................................. 34
13.9 CONCLUSION ............................................................................................................................................. 36
13.10 RÉFÉRENCE ........................................................................................................................................... 36
14 TUTORIAL : MISE EN PLACE D’UN SERVICE WEB SOAP ......................................................... 37
14.1 BUT ........................................................................................................................................................... 37
14.2 INTRODUCTION .......................................................................................................................................... 37
14.3 DEPLOIEMENT DE APACHE SOAP SUR UN SYSTEME WINDOWS XP ........................................................ 37
14.3.1 Serveur d’application : Tomcat ....................................................................................................... 37
14.3.2 Application web: SOAP ................................................................................................................... 39
14.3.3 Déploiement d’un service de démo.................................................................................................. 40
14.3.4 Ecoute du dialogue SOAP................................................................................................................ 42
14.4 MISE EN PLACE DU CLIENT ........................................................................................................................ 45
14.5 CONCLUSION ............................................................................................................................................. 45
14.6 RÉFÉRENCE ............................................................................................................................................... 45
15 PLANNING ET OBJECTIFS PROJET DE SEMESTRE & OBJECTIFS TRAVAIL DE
DIPLÔME ............................................................................................................................................................... 46
15.1 PLANNING DU PROJET DE SEMESTRE ......................................................................................................... 46
15.2 OBJECTIFS DU PROJET DE SEMESTRE ......................................................................................................... 47
15.3 OBJECTIFS DU TRAVAIL DE DIPLÔME ........................................................................................................ 48
16 ANNEXE 3 : SÉCURITÉ DES APPLICATIONS WEB (AVORTÉ).................................................. 49
16.1 INTRODUCTION .......................................................................................................................................... 49
16.2 CAHIER DES CHARGES ............................................................................................................................... 49
16.3 ANALYSE DES MENACES SPECIFIQUES AUX APPLICATIONS WEB .............................................................. 49
16.3.1 Unvalidated Parameters (paramètres invalides) ............................................................................ 49
16.3.2 Broken Access Control (perte du contrôle d’accès)........................................................................ 50
Page 3 / 52 10/07/2003
16.3.3 Broken Account And Session Management (perte de contrôle de la gestion des acomptes et des
sessions) 50
16.3.4 Cross-Site Scripting (XSS) Flaws .................................................................................................... 50
16.3.5 Buffer Overflows (surcharge d’un tampon)..................................................................................... 51
16.3.6 Command Injection Flaws (Faille d’injection de commande)........................................................ 51
16.3.7 Error Handling Problems (problèmes de gestion d’erreur) ........................................................... 51
16.3.8 Insecure Use Of Cryptogrsphy (utilisation non-sécurisé de la cryptographie) ............................. 52
16.3.9 Remote Administration Flaws (contrôle à distance des outils d’administration) .......................... 52
16.3.10 Web And Application Server Misconfiguration (incohérence entre les configurations de
l’application et du serveur) .............................................................................................................................. 52
Page 4 / 52 10/07/2003
1 Introduction
Le but de ce rapport est de fournir les prérequis pour permettre l’implémentation d’un firewall applicatif SOAP
pour le protocole http durant un travail de diplôme.
Les grandes étapes de cette préparation sont :

- l’étude du Simple Object Access Protocol (SOAP)
- la mise en place d’un service web SOAP (client, serveur)
- la recherche de la plateforme pouvant accueillir le firewall
- l’étude de Web Service Security
Des résumés portant sur SOAP et WS-Security ainsi qu’un tutorial sur la mise en place d’un service SOAP ont
été rédigé. Ils sont fournis en annexe de ce rapport.
2 Motivations
Les services web prennent aujourd’hui une grande place dans le monde d’Internet. On pourrait dire qu’il s’agit
d’une nouvelle mode en quelque sorte. Ils donnent la possibilité de relier un environnement informatique
distribué, en assurant une communication totalement neutre entre les différentes entités du système. Leur premier
but est donc d’introduire l’homogénéité entre applications.
L’échange d’information de manière transparente et l’invocation de procédures distantes sont permis grâce à
l’utilisation des services web. Dans ces deux cas, des données sensibles peuvent être transmises sur un réseau
non sûr. Il est donc nécessaire d’introduire une politique de sécurité propre aux services web, afin de permettre
leurs utilisations dans n’importent quel condition.
Ce rapport porte donc sur l’établissement de la sécurité dans le monde des services web. En passant par la prise
en main et la compréhension des différents protocoles et plateformes utilisés.
3 Définitions
3.1 Sécurité
« Tranquillité d’esprit de celui qui pense qu’aucun danger n’est à craindre » (réf. Dictionnaire Hachette
Encyclopédique, 1998)
3.2 Sécurité informatique

Ensemble de mesures visant à assurer la sécurité des utilisateurs de matériel informatique. Les concepts de base
dans ce domaine sont l’authentification, l’intégrité et la confidentialité.
3.3 Services web

Un service web est une interface réseau permettant l’accès aux fonctionnalités d’une application via des
technologies Internet. Autrement dit: si une application est accessible via un réseau utilisant des protocoles
comme http, XML, SMTP, etc., il s’agit en fait d’un service web.
Ces services web sont accessibles via des applications de service qui permettent de publier, gérer, et rechercher
des informations. Ces mécanismes sont accessibles au travers de protocoles et de format de données standardisés
comme http et html. La majorité des services web sont actuellement déployés sous la forme de site web html sur
Internet.
Le client du service web sera un simple utilisateur d’un navigateur qui reconnaisse les standards utilisés par le
service.
IBM et Microsoft ont déjà adopté le concept des services web. IBM intègre des supports de services web dans
WebSphere, Tivoli, DB2, et Lotus. Alors que la nouvelle plateforme de développement .NET de Microsoft est
basée sur les services web.
Page 5 / 52 10/07/2003
4 Simple Object Access Protocol (SOAP)
Le standard des services web qui concerne l’échange de message passe par le métalangage XML. Ce dernier a
été formalisé et standardisé pour donner naissante au Simple Object Access Protocol (SOAP). Ce protocole a été
définit pour permettre l’échange de documents et les appels de procédures distantes. Il utilise des protocoles de
transport comme http, https, smtp, ftp, etc.
Les messages SOAP sont construits de manière rigide. Les données à transmettre sont contenues dans le corps
du message, alors que l’entête de ce dernier définira la manière dont le message doit être traité: transfert,
encryptage, signature, etc.
Voir résumé en annexe portant sur SOAP
On voit tout de suite que SOAP peut nous permettre une grande rigueur dans l’application de la sécurité. Il est
simple de fixer un gabarit de message « sécurisé » et de l’appliquer à toutes les communications faites par le
service web et ses clients.
Dans ce gabarit de message, on peut décider d’assurer :

L’authentification et/ou l’intégrité et/ou la confidentialité
4.1 Authentification du message

La façon la plus simple d’authentifier un message est d’ajouter à son entête un bloque contenant un nom
d’utilisateur et un mot de passe (username + password). Il sera alors facile au récepteur de comparer ces
informations avec celles contenues dans une base de données par exemple.
Il est clair que cette solution est incomplète, puisque le mot de passe circule en clair sur le réseau. Il est donc
relativement facile pour un hacker de se le procurer. Afin de résoudre ce problème, on peut faire transiter un
hash du mot de passe.
Le déroulement de cette opération sera le suivant :

- l’envoyeur du message génère un hash de son mot de passe à l’aide d’une fonction de hachage
- l’envoyeur met dans un bloque de l’entête de son message son nom d’utilisateur et le hash de son mot
de passe
- le message est envoyé
- le récepteur recherche le mot de passe grâce au nom d’utilisateur reçu
- le récepteur génère le hash du mot de passe trouvé
- le récepteur compare les deux hashs
Si le récepteur ne reconnaît pas le nom d’utilisateur ou si les hashs sont différents, alors le message est ignoré.
Envoyeur Récepteur
Fonction de hachage Fonction de hachage
XY XY
Msg SOAP
Entête password
password - login trouvé
- hash
hash (ex. 128bits)
hash (ex. 128bits)
Corps
Si 0
XOR msg ok
Figure 0 : authentification du message SOAP
Page 6 / 52 10/07/2003
Les conditions pour effectuer ce type d’authentification sont:

- la même fonction de hachage doit être utilisée par l’envoyeur et le récepteur
- la communication du mot de passe au récepteur doit être faite de manière sécurisée
Cette solution pour l’authentification sera implémentée dans le firewall
4.2 Signature du message

La même méthode que celle vue pour l’authentification peut être utilisée pour signer le message et ainsi garantir
son intégrité.
Dans ce cas, on hash le corps du message et on ajoute le résultat dans un bloque de l’entête du message.
Le récepteur doit à nouveau générer un hash et le comparer à celui reçu.
4.3 Encryption du message

Pour garantir la confidentialité du message, l’encryptage doit être utilisé. Pour faciliter cette étape, une solution
d’encryptage symétrique paraît être la meilleure solution.
Au lieu de transmettre les données en clair dans le message, on encrypte le corps du message. Le récepteur devra
utiliser une clé secrète pour décrypter le message et ainsi avoir accès à son contenu.
Comme pour l’authentification, une condition pour utiliser ce type d’encryptage (symétrique) est que la clé soit
transmise au récepteur de manière sécurisée.
Cette solution pour la confidentialité sera implémentée dans le firewall
4.4 Application
La mise en place d’un service web utilisant SOAP paraît être la meilleure façon d’appliquer le protocole.
L’infrastructure nécessaire est constituée d’un client et d’un serveur. Il est possible d’implanter les deux sur une
même machine, toutefois l’utilisation de deux ordinateurs est nécessaire si l’on veut par la suite placer un
firewall au milieu.
Voir tutorial en annexe portant sur la mise en place d’un service web SOAP
L’utilisation de ApacheSOAP et du serveur d’application Tomcat permet de gagner du temps pour la mise en
place d’un service. De plus ApacheSOAP fournit des exemples de service qui permettent de tester facilement le
fonctionnement du système complet.
Il existe également un tunnel servant à visualiser les messages SOAP.
Pour illustrer et vérifier le fonctionnement du firewall par la suite, il sera nécessaire de créer un service web qui
utilise les solutions adoptées ci-dessus. Toutefois cette opération s’annonce longue et compliquée.
Page 7 / 52 10/07/2003
5 Service web SOAP

Ce chapitre présente les différents aspects d’un service web SOAP
5.1 Situation
Diagramme représentant une problématique typique des services web
Utilisateur
Client utilisant Compagnie
un navigateur aérienne
Commande : (Swiss)
Commande Genève – Service web
transport : New York SOAP
Yverdon –
New York
Transport
Commande transport : Ferroviaire
Agence de voyage Yverdon - Genève (CFF)
Site web proposant des offres de Service web
voyage. SOAP
Client de différents services web
Figure 1 : problématique grossière
L’agence de voyage propose au client des offres de transport entre différentes villes. Elle dispose bien sûr d’une
base de données contenant les conditions et tarifs de ces différentes offres, mais elle a également besoin
d’accéder aux informations des compagnies avec lesquels elle travaille pour valider ces offres.
Page 8 / 52 10/07/2003
Voici le diagramme détaillé d’une partie de la figure 1:
Utilisateur
Session SGBD
(Oracle)
Commande
Client
Produit
SOAP
Internet
Agence de voyage
Compagnie aérienne
SGBD
Serveur (Oracle)
SOAP
Note :
La partie interface entre l’utilisateur et l’agence de
Gestion des vols
voyage n’est pas détaillée.
Figure 2 : problématique plus détaillée

Dans ce diagramme, on voit avec plus de précision dans quels mesures et conditions le service web SOAP va être mis à contribution.
Page 9 / 52 10/07/2003
Voici maintenant le même diagramme avec l’incorporation d’un firewall SOAP :
Utilisateur
Session SGBD
(Oracle)
Commande
Client
Produit
SOAP
Internet
Agence de voyage
Compagnie aérienne
FW SGBD
SOAP Serveur Oracle
SOAP
Note :
La partie interface entre l’utilisateur et l’agence de
Gestion des vols
voyage n’est pas détaillée.
Figure 2 : problématique plus détaillée

Cette incorporation d’un firewall est préliminaire à cette étape de l’établissement, mais elle permet une prévisualisation de la solution bientôt abordée.
Page 10 / 52 10/07/2003
5.2 Infrastructure
Exemple d’infrastructure (coté serveur) :
(correspondant à l’infrastructure qui peut être mise en place en suivant le tutorial sur la mise en place d’un
service web SOAP en annexe)
Serveur d’application : Tomcat (en standalone)
API Java de parsing XML : Xerces
API SOAP d’Apache : ApacheSOAP
Tomcat
Serveur Serveur d’application

web
Client http RPCRouterSrvlet
Services :
XML parser
Figure 3 : diagramme de l’infrastructure SOAP
Déroulement d’une invocation (hypothèse : le service demandé est déjà déployé):

- le client construit une requête SOAP
- le client envoi la requête SOAP en utilisant le protocole de transport http
- le serveur web reçoit la requête SOAP, l’identifie comme tel, et le transmet au RPCRouterServlet
- le RPCRouterServlet doit identifier le service invoquer par la requête SOAP, pour se faire il fait appel
au XML parser
- le RPCRouterServlet invoque le service demandé
- le RPCRouterServlet génère la réponse SOAP à l’aide des informations fournies par le service
- le RPCRouterServlet transmet la réponse SOAP au serveur web
- le serveur web envoi la réponse SOAP au client en utilisant le protocole de transport http
- le client reçoit la réponse SOAP, l’identifie comme tel
5.3 Sécurisation
Dans la section « Situation » (figure 2), on a vu une notion de firewall apparaître. Ce firewall, dont les
spécifications seront traitées plus loin, est là pour répondre aux motivations du chapitre 2. C'est-à-dire pour
permettre aux services web d’échanger n’importe quelles données sans avoir à se soucier des problèmes de
sécurité.
Deux principales infrastructures sont à envisager pour mettre en place une notion de sécurisation du service web.
La première est une solution à priori facile à mettre en place et économique. La deuxième est deux fois plus
lourde en terme de matériel, mais est sans doute plus fiable.
5.3.1 « All-in-One »
5.3.1.1 Description de l’infrastructure coté serveur :

Serveur web : Apache
Serveur d’application : Tomcat
Page 11 / 52 10/07/2003
Serveur Tomcat
web
http Apache RPCRouterSrvlet
Client
+
Services :
Module
Firewall
SOAP
XML parser
Figure 4 : diagramme de l’infrastructure « All-in-One »
5.3.1.2 Avantages
- pas besoin de machine supplémentaire
- économie de temps (pas besoin de configurer la machine supplémentaire)
5.3.1.3 Inconvénients
- besoin d’une machine puissante (faire tourner : un serveur web, un serveur d’application avec plusieurs
services activés, un module firewall. Les deux derniers ayant besoin de faire du parsing)
- firewall et serveurs dans la même machine, si l’un tombe l’autre tombe aussi mauvais en terme de
sécurité!
5.3.2 « Classique »
5.3.2.1 Description de l’infrastructure coté serveur :

Serveur d’application : Tomcat (en standalone)
Plus une deuxième machine avec, comme proposition de plateforme :
- un module firewall SOAP tournant sous un serveur web Apache
OU
- une fonctionnalité supplémentaire de firewall SOAP tournant sous un système complet dédié à la
sécurité comme IpCop
Page 12 / 52 10/07/2003
Serveur Tomcat
web
http Apache RPCRouterSrvlet
Client +
Module
Firewall Services :
SOAP
OU
IpCop XML parser
Figure 5 : diagramme de l’infrastructure « Classique »
5.3.2.2 Avantages
- pas besoin de machine puissante
- chaque machine est indépendante meilleure sécurité
5.3.2.3 Inconvénients
- besoin d’une machine supplémentaire
- configuration complète d’une nouvelle machine nécessaire
5.3.3 Election
L’aspect « si l’un tombe l’autre tombe aussi » de la première solution suffit à l’éliminer d’office. La deuxième
infrastructure sera donc choisie pour l’implémentation du firewall.
6 Plateformes
L’implémentation du firewall devra se faire sur une plateforme existante. Le choix de cette dernière se fera selon
les critères suivants :
- possibilité d’extension de la plateforme
- documentation sur le plateforme
- utilisation de la plateforme sur le marché actuel
6.1 IpCop
6.1.1 Introduction
« IPCop met en oeuvre des techniques existantes, des pratiques de programmation sûres et les concepts
émergents pour en faire ‘la’ distribution Linux apte à protéger le simple ordinateur personnel jusqu'aux grands
réseaux d'entreprises contre les intrusions et les attaques. Que ce soit pour votre habitation ou bien votre SOHO
(Small Office/Home Office), IPCop s'adapte à vos besoins. » (réf. www.ipcop.org)
Page 13 / 52 10/07/2003
6.1.2 Motivation
Le choix de cette plateforme vient du fait que :
• Le support (hardware) qu’elle demande est très léger
• C’est un produit Open Source (basé sur Linux)
• La documentation est disponible en quantité sur le site officiel d’IpCop
• La plateforme propose déjà une palette de fonctionnalités typiques de firewall
6.1.3 Installation
La dernière version disponible est la 1.3.0 avec deux correctifs à télécharger en plus. Cette version a pu être
installée sur une machine de test (P166 CPU, 128M RAM, 2GB HDD), mais n’était hélas pas fonctionnelle
(impossible de lancer le système). La version 1.2.0 (avec cinq correctifs) n’a posé aucun problème.
6.1.4 Configuration
La configuration du firewall (et des autres fonctionnalités) se fait grâce à une interface html au travers de
n’importe quel navigateur. Le protocole de transport utilisé est sécurisé, il s’agit de https.
6.1.5 Tests
Toutes les fonctionnalités (NAT, ouverture / redirection de port, serveur DHCP, serveur SSH, proxy, etc.) ont été
testées avec succès.
La sécurité du système (firewall, IDS, etc.) est confirmée par différents tests disponibles via Internet, comme par
exemple « Symantec Security Check » du logiciel Norton SystemWorks.
6.1.6 Vulnérabilité
A priori (test à réaliser) une vulnérabilité pourrait venir de la génération des logs. IpCop garde tous les logs et ne
les compresse qu’une fois par semaine. Il serait donc possible de littéralement remplir la partition du disque dur
réservée aux logs pour faire tomber la machine entière.
6.1.7 Conclusion
IpCop est une excellente solution pour les gens disposant d’un SOHO à protéger. Il offre une gamme de
fonctionnalités réellement intéressante et ne demande qu’un ordinateur dédié.
Toutefois, il serait beaucoup trop compliqué d’ajouter une fonctionnalité dans ce système. En plus de la rigueur
de sa programmation, l’aspect interface de configuration le rend inabordable.
6.2 Apache
6.2.1 Introduction
Apache est le serveur web le plus répandu sur Internet (plus de 50% du marché). Ses concurrents directs sont:
Microsoft IIS, Microsoft PWS, Xitami, etc.. Fonctionnant à la base sur des systèmes Unix, il est aujourd’hui
(depuis 1998) disponible sur une multitude de plateforme dont celles de Microsoft.
Apache (prononcé à l’anglophone : « Apatchy ») a été mis au point sur la base d’une multitude de correctifs
logiciels, afin d’en faire une solution très sûre. Le résultat est une application ayant très peu de failles connues,
puisque dès qu’une faille ou d’un bug est décélé, celui-ci est rapidement corrigé par l’arrivée d’une nouvelle
version.
Page 14 / 52 10/07/2003
6.2.2 Motivation
Le choix de cette plateforme vient du fait que :
• Le support (hardware) qu’elle demande est très léger.
• C’est un produit Open Source.
• La documentation est disponible en quantité sur le site officiel de l’Apache Software Foundation.
• L’application Apache est réputée très sûre
• L’ajout de module est courant et bien documenté
• L’écriture de ces modules est documentée
6.2.3 Installation
Les versions 1.3.27 et 2.0.46 s’installent sans problème sur une machine sous Windows 2000. Le lancement du
serveur se fait simplement grâce à un script créé lors de l’installation.
6.2.4 Configuration
6.2.4.1 Version 2.0.46

Cette version, pourtant réputée pour être la « ninth public release of Apache 2.0 », se révèle totalement
inutilisable dès lors que l’on veut mettre en place des nouveaux modules (existants, mais pas activés). Après de
nombreux essais et des recherches sur la résolution de ce problème, cette version a dû être abandonnée.
6.2.4.2 Version 1.3.27

Cette version, évidemment plus ancienne, a été sortie principalement pour corriger les bugs et les failles de
sécurité
Un module proxy a pu être mis en fonction sans aucune difficulté.
6.2.5 Tests
Les tests réalisés sont quasiment nuls. On peut simplement dire que le serveur web fonctionne et le proxy aussi.
6.2.6 Conclusion
Apache paraît être une meilleure solution. Il s’agit ici d’une simple application et non plus d’un système complet
comme IpCop. De plus l’aspect modulaire pour l’ajout d’une fonction supplémentaire annonce des possibilités
de « débuggage » facilités.
L’argument ultime en sa faveur est tout simplement sa popularité. Puisque le nombre de personne susceptible de
connaître et résoudre un éventuel problème est énorme.
7 Web Service Security

La spécification WS-Security porte sur l’ensemble (ou presque) des assertions de sécurité qu’il est possible de
faire avec SOAP, tout en utilisant les dernières technologies et standards du monde de la sécurité informatique.
Cette spécification permet d’atteindre un niveau de sécurisation très élevé si elle est suivie dans son intégralité.
Toutefois la lourdeur du système obtenu le rendrait sans doute inutilisable!
Voir résumé en annexe portant sur WS-Security
Il est très important de se souvenir que par la nature même de SOAP et des services web, WS-Security définit
une sécurité « end-to-end ». Soit une sécurité d’utilisateur à utilisateur.
Les solutions adoptées plus loin font toutes parties du WS-Security.
Page 15 / 52 10/07/2003
8 Description du firewall SOAP
L’infrastructure choisie pour l’implantation du firewall est celle de la figure 5. Une machine dédiée sur laquelle
tournera un système d’exploitation (encore à définir: Windows 2000 ou Linux) et un serveur web Apache.
8.1 Motivations
Une question :
Pourquoi un firewall pour contrôler une sécurité « end-to-end » ???
Première raison :
La sécurité « end-to-end » n’est plus une sécurité qui dépend d’une infrastructure figée mise à disposition. Elle
dépend de chaque utilisateur ou client de cette infrastructure. Un portable ajouté à cette dernière, mais qui ne
serait pas configuré selon les normes de sécurité en vigueur représenterait une menace (cas plutôt évident coté
client). Pour éviter ce cas de figure, on empêche tout simplement les informations non conformes d’arriver
jusqu’aux clients. Grâce par exemple à un « filtrage » effectué sur un firewall.
protection du réseau contre ses propres utilisateurs (et leurs naïvetés)
prévention
Deuxième raison :
La sécurité « end-to-end » peut se révéler lourde à gérer par un client. Dans ce cas, un firewall pourrait effectuer
une partie du travail pour soulager le client. Ou simplement éviter que le client effectue un travail pour rien en
faisant un contrôle préventif.
soulagement du travail du client (serveur)
Troisième raison :
Il est plus simple de centraliser les correctifs et autres modifications de sécurité à une seule place au lieu de les
appliquer à plusieurs endroits. Par exemple dans le cas où plusieurs serveurs seraient derrière un seul firewall.
efficacité
rapidité de mise en place d’une protection (sous la forme d’un update ou d’une règle supplémentaire)
8.2 Buts
Assurer l’authenticité, l’intégrité et la confidentialité des messages SOAP
Empêcher les attaques (flooding, pillage de données, etc.)
8.3 Fonctionnalités
- inspecter chaque requête pour sécuriser les transactions
- vérifier la conformité des messages par rapport à un schéma XML (gabarit)
- utiliser des informations (locales ou distantes) pour authentifier l’appelant, vérifier son authenticité et
l’intégrité du message
- détecter les schémas d’attaque (flooding, pillage de données, etc.)
- blocage d’IP
Note : dans le blocage d’IP, on peut soit bloquer des adresses identifiées comme dangereuses (réaction), soit
autoriser uniquement les adresses connues (prévention).
8.4 Implémentation
L’implémentation se fera sous la forme d’un module Apache. Ecrit en langage « C », ce module travaillera en
« standalone » (pas d’accès distant à une base de données, etc.) et contiendra donc toutes les informations
d’authentification, etc. dont il a besoin.
8.5 Comportement
Le firewall devra accepter uniquement:
- les requêtes jugées conformes
- les messages correspondant au schéma XML fixé
- les messages dont l’authentification ET l’intégrité ET la confidentialité seront confirmés
- les messages dont le contenu sera jugé conforme
Seuls les messages répondant à ces quatre critères seront transmis au service concerné, les autres seront rejetés
(dénie par défaut).
Page 16 / 52 10/07/2003
Voici le diagramme qui illustre le comportement du firewall SOAP lors de la réception d’une requête:
Firewall SOAP
Requête
« POST /soap/servlet/rpcrouter HTTP/1.0 »
Contrôle de la requête
Enveloppe SOAP POST, Host, etc.
Entête du message SOAP
Identité Contrôle du schéma XML du message
Username + hash (password)
Authenfication (basée sur username ):
Rechercher username dans BD locale
Signature Rechercher password dans BD locale
hash (message) Générer le hash du password trouvé
si (hash reçu XOR hash généré) =0 alors
Authenfitication OK
Encryption message
- type d’encryption
Intégrité :
Générer le hash du message reçu
si (hash reçu XOR hash généré) =0 alors
Corps du message SOAP Intégrité du message OK
Confidentialité :
Contrôler que le message a été encrypté
Contrôle du contenu :
Après décryptage (clé dans BD locale)
Figure 6 : comportement lors de la réception d’une requête
Page 17 / 52 10/07/2003
8.6 Spécifications
En plus des sections sur le comportement, les fonctionnalités et l’implémentation ci-dessus, on peut ajouter
qu’un firewall SOAP doit pouvoir monter rapidement en charge et y rester (plusieurs milliers de messages gérés
par seconde).
Ce ne sera bien sûr pas le cas du firewall qui va être implémenté par la suite (matériel peu performant,
algorithmes non optimisés, etc.).
On peut ajouter que la fonctionnalité de blocage d’IP sera sans doute implémentée en appliquant également une
politique de dénie par défaut. Donc en autorisant dans un premier temps uniquement les adresses « reconnues » à
accéder aux services.
8.7 Politique de sécurité

Un service web met à disposition de l’information pure, contrairement à un site web qui lui la mélange avec de la
présentation. Cette différence fait d’un service web une cible beaucoup plus intéressante pour un hacker. Lors de
l’établissement de la politique de sécurité, on doit donc tenir compte de cette différence.
D’ailleurs à ce stade, l’analyse de risque a déjà dû démontrer que les conséquences de l’intrusion d’un service
web sont plus grandes que celles du serveur web en terme de confidentialité en tout cas.
8.8 Cycle de vie

Comme tout composant dans le domaine de la sécurité de l’information, on ne peut pas l’installer et le laisser
tourner sans s’en occuper. Une réévaluation de ses fonctionnalités et de sa capacité est nécessaire pour garantir
une sécurité durable. Voici le cycle correspondant aux besoins du firewall :
Planifier Réaliser Contrôler Agir
Figure 7 : cycle de vie du firewall SOAP
Toutefois, cette possibilité de mise à jour du firewall ne sera pas implémentée dans un premier temps pour des
raisons de temps à disposition.
8.9 Conclusion
L’implémentation de ce firewall et son incorporation dans un réseau sécurisé permettra effectivement
d’augmenter le niveau de sécurité globale. En empêchant par exemple qu’un ordinateur n’échappe aux solutions
de sécurité adoptée pour les services web SOAP.
La charge de travail du serveur (client) se situant derrière le firewall ne sera pas diminuée, mais le risque de
gaspillage de temps dû aux traitements de messages non autorisés disparaît.
Hélas, la possibilité de mettre à jour le firewall rapidement grâce à l’installation d’update ou de patch ne sera pas
mise en place. Car beaucoup trop lourd.
Les buts du point de vue de la sécurité sont tous atteints, puisque :

- l’authentification
- l’intégrité
- la confidentialité
sont assurés par le firewall.
L’aspect « identification » d’attaques et réaction se limitera dans un premier temps aux contrôles des requêtes et
du contenu. Le message identifié comme « attaque » ne sera pas accepté.
Page 18 / 52 10/07/2003
9 Conclusion
Les services web sont une solution réelle et abordable pour résoudre les problèmes des systèmes distribués sur
Internet. Le protocole SOAP permet de briser les limites fixées par les environnements en s’appuyant sur des
standards fonctionnels et existants.
La mise en place d’un service web SOAP complet est envisageable par une majorité d’informaticien. Puisque le
langage clé, XML, fait déjà partie du bagage d’une majorité de gens dans cette profession. On peut donc déjà
parier sur un développement considérable dans ce domaine.
De plus le protocole SOAP permet une grande rigueur dans la conception des messages. On a donc à disposition
un protocole permettant l’application « simplifiée » de la sécurité dans un domaine nouveau et voué à un avenir
prometteur.
Le firewall SOAP est une première solution pour fournir un niveau de sécurité élevé dans le domaine des
services web. Son utilisation conjointe à celle d’une sécurité « end-to-end » donne un résultat très sécurisant.
Les spécifications fixées par une note comme WS-Security sont lourdes et complexes à mettre en place. Les
solutions adoptées dans ce rapport sont bien plus abordables, et de ce fait, envisageables pour la suite de ce
projet. De plus le choix d’une application existante et vivante comme Apache pour la base d’implémentation
rend ce projet raisonnable.
10 Bilan
Ce projet de semestre m’a permis d’assimiler un grand nombre de concept clé de la télécommunication et de la
sécurité des systèmes d’information.
Concernant le travail fourni, je ne m’attendais pas à devoir passer autant de temps dans mon cours « Réseaux et
télécommunications ». J’ai maintenant atteint un niveau suffisant pour assimiler certains concepts que j’avais dû
prendre comme acquis lorsque j’ai commencé ce projet.
Le cahier des charges fixé lors de la dernière rencontre avec Messieurs Buchs, Marret et Ventura sera respecté
(reste la partie présentation à mettre en place).
Travail manquant pour le travail de diplôme :

- création d’un service web qui applique le schéma de message SOAP vu à la figure 6
- recherche des algorithmes de hachage et d’encryption qui vont être utilisé par le service web (et donc
par le firewall)
La recherche d’information sur Internet concernant la sécurité des services web donne un grand nombre de
réponses. Toutefois, pour la suite de mon travail il serait sans doute préférable d’acheter un livre sur le sujet. Je
propose :
- « Web services security » de Mark O’Neil publié par McGraw-Hill Osborne Media en janvier 2003
(ISBN 0072224711)
- « Professionnal Web Services Security » de Trivedi, Whitney, Galbraith, Janakinaman, etc. publié par
Wrox Press inc en décembre 2002 (ISBN 1861007655)
Concrètement, je crois être arrivé au bout de la problématique, en ciblant extrêmement mon travail sur SOAP. Et
en restant très abstrait sur certains sujets qui m’auraient pourtant passionnés (XML Encryption, les fonctions de
hachage, etc.).
Vous trouverez le planning de ce projet et ces objectifs, ainsi que les objectifs du travail de diplôme en annexe de
ce rapport. Vous y trouverez également un document portant sur la « Sécurité des applications web » que j’ai
rédigé avant la répartition du travail sur ce projet, j’ai abandonné sa rédaction.
Page 19 / 52 10/07/2003
11 Références
Voir références des annexes
http://www.builder.fr/
http://soapclient.com/
http://jakarta.apache.org/
http://www.commentcamarche.com/
Yverdon-les-bains, le 10 juillet 2003
Jonathan Rod, EIT6
Page 20 / 52 10/07/2003
12 Annexe 1 : Simple Object Access Protocol

12.1 Définition
Ce chapitre donne les différentes définitions pré requises pour aborder la suite de ce document.
12.1.1 Services web

Un service web est une interface réseau permettant l’accès aux fonctionnalités d’une application via des
technologies Internet. Autrement dit: si une application est accessible via un réseau utilisant des protocoles
comme http, XML, SMTP, etc., il s’agit en fait d’un service web.
Ces services web sont accessibles via des applications de service qui permettent de publier, gérer, et rechercher
des informations. Ces mécanismes sont accessibles au travers de protocoles et de format de données standardisés
comme http et html. La majorité des services web sont actuellement déployés sous la forme de site web html sur
Internet.
Le client du service web sera un simple utilisateur d’un navigateur qui reconnaisse les standards utilisés par le
service.
IBM et Microsoft ont déjà adopté le concept des services web. IBM intègre des supports de services web dans
WebSphere, Tivoli, DB2, et Lotus. Alors que la nouvelle plateforme de développement .NET de Microsoft est
basée sur les services web.
12.1.2 Appel à distance de procédure

Il existe deux types de middleware pour les appels à distance de procédure: ORB & RPC. Ces deux systèmes de
transmission de messages inter-programmes ont des spécificités bien différentes.
- ORB (Object Request Broker): ce middleware, orienté objet, permet au client de faire appel à des
méthodes mises à disposition par le serveur. Le problème de ce type d’implémentation est que le client
attend durant le traitement de la méthode par le serveur.
- RPC (Remote Procedure Call): un processus client envoie un message au serveur. L’application client
continue à tourner, mais suspend le processus appelant. Une fois le traitement terminé, le serveur envoie
un message au client pour réveiller le processus suspendu. SOAP est un middleware de ce type.
12.1.3 SOAP (Simple Object Access Protocol)

SOAP est un middleware qui permet l’invocation d’application sur des réseaux distribués et décentralisés. C’est
un protocole d’échange sur lequel Microsoft a basé son architecture .NET. A la base SOAP est une note du
consortium W3.
Le but de SOAP est de permettre l’appel à distance de procédure (Remote Procedure Call), et donc de définir
via des réseaux des services web.
Les protocoles utilisés par SOAP sont http, SMTP ou encore POP3. Ils lui permettent d’effectuer une paire de
message requête – réponse via un réseau.
Les messages SOAP se base sur un langage de description des données qui n’est autre que XML.
La spécification SOAP décrit une balise <envelope>

Message SOAP = combinaison des balises dans un document
12.2 Introduction à SOAP

Les spécifications de SOAP se limitent à définir une enveloppe (basée sur XML) pour les informations à
transférer entre applications, ainsi qu’une série de règles qui permettent de traduire des données propres à une
plateforme ou une application en XML.
Nous allons maintenant voir ce que fait SOAP, et comment il le fait.
Page 21 / 52 10/07/2003
12.2.1 SOAP & XML
Du code SOAP est du code XML, autrement dit SOAP est une simple application des spécifications XML. Les
définitions et les fonctions de SOAP sont basées sur des standards de XML comme « XML Schema » et « XML
Namespaces » (cf. http://www.w3c.org).
12.2.1.1 Messages XML

Les messages XML sont la base même de SOAP. Ils permettent la communication entre 2 applications en
utilisant des documents XML.
Ses messages peuvent contenir des informations de toutes sortes: les résultats d’une recherche, une réservation
d’hôtel, un ordre de paiement, etc.
XML n’est pas propre à une application, un système d’application ou à un langage de programmation. Il peut
donc être utilisé dans tous les environnements. On peut par exemple imaginer la création d’un document XML
dans un programme basé autour d’une plateforme Unix. Puis sa récupération sous Windows pour utilisé les
paramètres transmis.
On peut utiliser les messages XML (SOAP) pour deux applications différentes:
- RPC (Remote Procedure Call) pour transmettre des paramètres et des valeurs de retour de fonction.
- EDI (Electronic Document Interchange) pour transmettre des ordres de paiement, etc.
12.2.1.2 Standard de représentation

XML permet une infinité de représentation pour chaque information (adresse, numéro de téléphone, nom, etc.).
Deux applications voulant se communiquer des informations doivent donc définir un standard de représentation
qui devra définir:
- le type des informations échangées
- comment elles seront exprimées en XML
- comment envoyer cette information
Ce standard de représentation permettra à deux applications de se comprendre. SOAP définit ce standard.
12.2.2 Messages SOAP

Les messages SOAP sont constitués de deux parties:
- l’en-tête du message (SOAP header) elle contient des bloques (header block) qui définissent: le routage
du message et des conditions de livraison, des assertions
d'authentification ou d'autorisation, et des contextes de transaction.
- le corps du message (SOAP body) il contient le message qui devra être effectivement délivré.
SOAP envelope
SOAP header
Header block
Header block
SOAP body
Message body
Le standard pour la syntaxe des messages est décrit dans la note du W3C http://www.w3.org/2001/06/soap-
envelope.
Page 22 / 52 10/07/2003
Ci-dessous, un exemple d’ordre de paiement correspond au style d’un document SOAP.
<s:Envelope
xmlns:s="http://www.w3.org/2001/06/soap-envelope">
<s:Header>
<m:transaction xmlns:m="soap-transaction"
s:mustUnderstand="true">
<transactionID>1234</transactionID>
</m:transaction>
</s:Header>
<s:Body>
<n:purchaseOrder xmlns:n="urn:OrderService">
<from><person>Christopher Robin</person>
<dept>Accounting</dept></from>
<to><person>Pooh Bear</person>
<dept>Honey</dept></to>
<order><quantity>1</quantity>
<item>Pooh Stick</item></order>
</n:purchaseOrder>
</s:Body>
</s:Envelope>
Cet exemple montre les différents composants de l’enveloppe SOAP.
12.2.2.1 Enveloppes SOAP

Une enveloppe SOAP ne peut contenir qu’un seul corps!
L’entête n’est pas obligatoire et on ne peut en mettre qu’une par enveloppe.
12.2.2.2 Messages RPC

Les messages RPC (Remote Procedure Call) vont par pair. Le client produit les messages de type «Request » et
le serveur les « Response ».
Client SOAP Request Server SOAP
Response
Figure 3 : échange de message RPC
Voici l’exemple d’un message qui fait appel à un service déployé sur le serveur :
POST /soap/servlet/rpcrouter HTTP/1.0

Host: bathory.mine.nu:6666
Content-Type: text/xml; charset=utf-8
Content-Length: 492
SOAPAction: ""
<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getAddressFromName xmlns:ns1="urn:AddressFetcher" SOAP-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<nameToLookup xsi:type="xsd:string">John B. Good</nameToLookup>
</ns1:getAddressFromName>
</SOAP-ENV:Body> Figure 4 : message RPC envoyé du client (request)
</SOAP-ENV:Envelope>
Page 23 / 52 10/07/2003
Et la réponse ci-dessous du serveur à la requête ci-dessus :
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=A45B8472165F47F39651C4F67E401D4F; Path=/soap
Content-Length: 946
Date: Thu, 01 May 2003 10:48:01 GMT
Server: Apache Coyote/1.0
Connection: close

<SOAP-ENV:Body>
<ns1:getAddressFromNameResponse xmlns:ns1="urn:AddressFetcher" SOAP-
<return xmlns:ns2="urn:xml-soap-address-demo" xsi:type="ns2:address">
<city xsi:type="xsd:string">Anytown</city>
<phoneNumber xsi:type="ns2:phone">
<areaCode xsi:type="xsd:int">123</areaCode>
<exchange xsi:type="xsd:string">456</exchange>
<number xsi:type="xsd:string">7890</number>
</phoneNumber>
<state xsi:type="xsd:string">NY</state>
<streetName xsi:type="xsd:string">Main Street</streetName>
<streetNum xsi:type="xsd:int">123</streetNum>
<zip xsi:type="xsd:int">12345</zip>
</return>
</ns1:getAddressFromNameResponse>
</SOAP-ENV:Body>
Figure 5 : message RPC envoyé du serveur (response)
Ces messages ont été obtenus grâce à l’utilisation d’un tunnel fourni par ApacheSOAP.
12.2.3 Fautes SOAP

SOAP définit des types de messages qui n’ont pour but que de transmettre des informations concernant les
erreurs. Ces messages contiennent :
- Le code de la faute : identifie le type d’erreur. Attention, cette valeur n’aura de sens que dans le
contexte d’un XML-NameSpace particulier.
- La description de la faute : une explication de la faute
- L’acteur : l’identifiant de la partie du message qui a créé la faute
- Les détails : décrit la faute spécifique de l’application lorsque la faute vient du corps du message
12.2.3.1 Définition des fautes

Un service web peut définir ses propres fautes. Elles seront donc totalement inconnues du protocole SOAP.
A n’utiliser que dans un cas où la précision des fautes prédéfinis est trop faible. Si un service ne comprend pas
ces fautes, il agira de manière imprévisible et donc dangereuse.
12.2.4 Modèle d’échange de message

SOAP ne fait que définir une enveloppe pour le transport d’informations. Une fois les données réceptionnées et
l’enveloppe enlevée, le modèle d’échange donne un gabarit qui nous permet de les gérer.
Page 24 / 52 10/07/2003
12.2.4.1 Routes et acteurs des messages
On peut voir une enveloppe SOAP comme un moyen de transport unidirectionnel entre un envoyeur et un
receveur. Cette enveloppe peut passer au travers de différentes « escales » intermédiaires. La liste de ces escales
nous donne la route du message. Chacune de ces escales est considérée comme un acteur.
La construction de cette route n’est pas propre au protocole SOAP, mais elle dépend de chaque message. Pour
« corriger » ce manque, Microsoft a écrit le SOAP Routing Protocol (WS-Routing).
Prenons, un exemple. Si une revendeur reçoit une demande pour des marchandises dont le prix attend $1000.-,
sous la forme d’un message SOAP sur son service web. Pour vérifier l’authentification et l’intégrité du message,
il peut spécifier une route particulière pour ce type de message qui passe par un organe de contrôle externe. Cet
organe devra vérifier le message et ajouter à son tour un certificat au message pour spécifier au revendeur que le
message est intègre et authentique.
Service web Client :

du revendeur 1) envoit de l’ordre de commande (avec sa signature digitale) acheteur
Service web
2. demande validation de validation
des signatures
digitales
3. passer commande
Figure 6 : exemple de route d’un message SOAP
Il est important de comprendre que SOAP ne définit comment le message doit passer par un acteur (service
intermédiaire), il dit juste qu’il doit le faire. Microsoft a donc définit une entête standard dans son WS-Routing
pour expliciter les informations sur la route.
12.2.5 Réaliser un service web « RPC »

Cette section montre comment les appels de procédures distantes sont codés et implantés dans le corps des
messages SOAP.
12.2.5.1 Invocation
Il existe deux règles pour pouvoir implanter des requêtes RPC dans une enveloppe SOAP :
- L’appel de la méthode distante doit être représenté en une simple structure. Avec les paramètres
d’entrée ou d’entrée/sortie comme champs de cette structure
- L’ordre et les noms des paramètres dans la requête doivent correspondre à l’ordre et aux noms des
paramètres de la méthodes invoquée
Exemple: invocation d’une méthode Java

Signature de la méthode Java :
String test (String code, String nbID);
Arguments de l’invocation:
result = test (‘myCode’, ‘myID’);
Page 25 / 52 10/07/2003
Enveloppe SOAP correspondante à l’invocation:
<s:Envelope xmlns:s="...">
<s:Body>
<test xmlns="..."
s:encodingStyle="http://www.w3.org/2001/06/soap-encoding">
<orderCode xsi:type="string">myCode</orderCode>
<customerID xsi:type="string">
myID
</customerID>
</test>
</s:Body>
</s:Envelope>
Figure 7 : enveloppe SOAP avec RPC à une méthode Java : invocation
12.2.5.2 Réponse
Les mêmes règles que pour l’invocation sont valables pour les réponses (structure simple contenant paramètres
& même ordre et noms).
Suite de l’exemple donné plus haut

Enveloppe SOAP correspondante à la réponse:
<s:Envelope xmlns:s="...">
<s:Body>
<testResponse
s:encodingStyle="http://www.w3.org/2001/06/soap-encoding">
<return xsi:type="xsd:string">myTest</return>
</testResponse>
</SOAP:Body>
</SOAP:Envelope>
Figure 8 : enveloppe SOAP avec RPC à une méthode Java : invocation
Le nom « testResponse » n’est pas une obligation. Toutefois la convention veut qu’on utilise le nom de la
méthode suivi de « Response ».
12.2.5.3 Rapport d’erreur

La convention SOAP veut qu’on retourne des fautes SOAP au client RPC en cas d’erreur. La partie détail du
message d’erreur peut fournir les informations nécessaires à la compréhension de l’erreur. Dans des rares cas
particuliers, le service web définira des erreurs propriétaires.
12.2.6 Encodage des données - Terminologie

Cette partie explique comment les données sont mappées et encodées dans un format XML lors de leurs
insertions dans une enveloppe SOAP.
L’encodage des données est complètement optionnel, heureusement vu la lourdeur qu’une telle manœuvre
représente. Les enveloppes SOAP peuvent accueillir n’importe quel document XML, peut importe la tête du
corps que l’on veut y placer. Toutefois un standard est définit par SOAP pour permettre à deux entités
d’échanger des informations sans devoir en premier lieu s’entendre sur un standard propriétaire. On puit donc
soit mettre n’importe quoi dans l’enveloppe, soit suivre les spécifications existantes.
Deux termes doivent être définit avant d’aborder la suite de l’encodage :

- value (valeur)
- accessor (accesseur)
Value
Définition : représente soit une unité de données, soit plusieurs unités de données.
Exemple : nom d’une personne, température ambiante (en ce moment 30° au labo…)
Page 26 / 52 10/07/2003
Accessor
Définition : représente un élément qui contient ou donne accès à une value
Exemple : nom, prénom, température
Compound Value : représente plusieurs value accessible depuis le même accessor. Il existe deux types de
Compound Value (struct : accessor différents / array : accessor pareils)
Exemples (value & compound value):

<prenom> Jonathan </prenom>
Figure 9 : value = Jonathan / accessor = prenom
<personne>
<prenom> Jonathan </prenom>
<nom> Rod </nom>
</personne>
Figure 9bis : compound value : struct (accessor = nom)
<personnes>
<nom> Jean </nom>
<nom> Rod </nom>
</personnes>
Figure 9bis : compound value : array (accessor = nom)
SOAP définit qu’un accessor peut être « single-referenced » ou « multi-referenced ». Respectivement : soit un
accessor sert à référencer, soit il sert à donner une valeur.
Exemples (accessor « single-referenced » ou « multi-referenced »):

<peuple>
<personne nom='Jonathan Rod'>
<addresse>
<rue>36 Rumine</street>
<ville>Lausanne</city>
</addresse>
</personne>
</peuple>
Figure 10 : accessor single-referenced (ici adresse)
<peuple>
<personne nom='Jonathan Rod'>
<addresse href='#address-1'
</personne>
<personne nom='Jean Reymond'>
<addresse href='#address-1'
</personne>
</peuple>
<addresse id='address-1'>
<street>36 Rumine</street>
<city>Lausanne</city>
</addresse>
Figure 10bis : accessor multi-referenced (ici adresse)
Page 27 / 52 10/07/2003
SOAP donne également d’utiliser un accessor externe
Exemples (accessor externe):

<nom = ‘Jonathan Rod’>
<adresse href = ’http://exemple.ch/donnee.xml#jonathan_rod’ />
</nom>
Figure 10 : accessor externe
12.2.7 Types de donnée

Les types de données supportés par SOAP sont ceux définis par les « XML Schema data types » spécifications.
Tous les types utilisés dans l’encodage SOAP doivent être tirés de ces spécifications ou directement dérivées de
celles là.
Il existe deux syntaxes pour exprimer un type de données dans une enveloppe SOAP :
<SOAP-ENC:int>77</ SOAP-ENC:int>
<value xsi:type=”xsd:int”>77</value>
Figure 11 : syntaxes de déclaration de la valeur 77 de type entier
La première méthode, la plus répandue, se nomme « anonymous accessor » puisque le nom de l’accessor est le
nom du type. La deuxième méthode vient de l’attribut « xsi:type » trouvés dans les spécifications de XML
Schemas, je n’en parlerai pas ici.
12.2.7.1 Types composés: structuré, tableau, etc.

Nous avons déjà vu la différence entre type structuré et tableau.
Les tableaux normaux sont indiqués comme étant des accessors du type « SOAP-ENC:Array » ou de type dérivé.
Le type des éléments qui peuvent être contenu par le tableau est définit grâce à l’attribut « arraytype ».
<some_array xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="se:string[2]">
<se:string>Jonathan</se:string>
<se:string>Jean</se:string>
</some_array>
Figure 12 : attribut « arrayType »
On remarquera la valeur entre crochets [] qui indique la taille du tableau. Ces crochets peuvent également être
utilisés pour créer un offset dans le tableau afin de n’en transmettre qu’une partie.
Des tableaux à plusieurs dimensions peuvent également être déclarés.
12.2.8 Transport des messages SOAP

SOAP se place au-dessus des protocoles de transport et de réseaux afin d’utiliser les standards déjà présents. Il
permet de complètement faire abstraction des protocoles de transport et ainsi est extrêmement portable. Pour
illustrer cette portabilité, on peut citer le service web de Pavel Kulchenko qui transmet les messages SOAP au
travers des protocoles: http, ftp, raw TCP, SMTP, POP3, MQSeries et Jabber.
12.2.8.1 SOAP sur http

Le protocole http est extrêmement répandu sur Internet, et ça fait de lui le protocole le plus pratique pour
l’échange des messages SOAP. Les deux protocoles correspondent naturellement puisqu’ils sont les deux basés
sur un système de requête / réponse.
La requête SOAP est « postée » au serveur grâce à la requête http, et la réponse SOAP est retournée par le
serveur grâce à la réponse http.
Page 28 / 52 10/07/2003
Client http Server http

http « POST » SOAP request
http response SOAP response
Figure 13 : Utilisation du protocole http par SOAP
Ci-dessous, le code des requêtes / réponse http correspondantes
POST /StockQuote HTTP/1.1

Content-Type: text/xml
Content-Length: nnnn
SOAPAction: "urn:StockQuote#GetQuote"
<s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope">
...
</s:Envelope>
Figure 14 : requête http contenant l’enveloppe SOAP
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
<s:Envelope xmlns:s="http://www.w3.org/2001/06/soap-envelope">
...
</s:Envelope>
Figure 14bis : réponse http contenant l’enveloppe SOAP
Une entête http nommée « SOAPAction » est définit par le protocole SOAP pour indiquer au serveur http
l’intention de la requête. Sa valeur est arbitraire, mais elle doit annoncer au serveur le but de la requête SOAP
avant que ce dernier décode le XML de l’enveloppe SOAP.
Il faut tout de même noter que http n’est pas fait pour transporter du XML, et dans certaines situations http et
SOAP ne se supportent pas mutuellement. Pour corriger cela, la nouvelle plateforme .Net de Microsoft utilise
son protocole « Instant Messaging » pour faire transiter les messages SOAP.
12.3 Conclusion
L’étape suivante serait l’écriture d’un service web SOAP. Le temps manque hélas pour sa réalisation. Les
chapitres « Writing SOAP Web Services » et suivants du livre de référence utilisé vous fournirons si besoin les
détails utiles pour cette réalisation.
Les différents langages proposés pour l’écriture d’un service web sont :
- Perl
- Visual Basic
- Java
- .Net
12.4 Référence
O’Reilly, « Programming Web Service with SOAP », First Edition 2001
Page 29 / 52 10/07/2003
13 Annexe 2 : WS-Security
13.1 Motivation
Avant d’expliquer ce qu’est WS-Security, il est important de comprendre pourquoi il existe.
SOAP est un moyen d’échanger des messages par exemple en utilisant le protocole http. Mais ce dernier ne
propose pas des solutions satisfaisantes au niveau de la sécurité (authentification, intégrité, confidentialité). Il
se limite à compter sur la sécurité « poin-to-point » (par exemple firewall à firewall) existante. Alors que WS-
Security fixe une politique de sécurité « end-to-end » (utilisateur à utilisateur).
13.2 Introduction
WS-Security est une spécification développée et promue par Microsoft, IBM et VeriSign.
WS-Security définit un gabarit pour incorporer des standards déjà existants aux messages SOAP. L’utilisation
des standards suivants est facultative. X.509 est utilisé pour l’authentification et utilise PKI pour la gestion des
clés. « XML Encryption » et « XML Signature » sont utilisés pour encrypter et signer le contenu du message
XML. Des mécanismes plus simples peuvent également être mis en place (authentification par mot de passe par
exemple).
Pour précisément, WS-Security définit l’entête du message SOAP (SOAP Header). Elle peut par exemple
contenir une description de la manière avec laquelle le message a été signé grâce à « XML Signature ».
WS-Security propose une solution de sécurité « end-to-end » en gardant toutes les informations de sécurité dans
le message SOAP lui-même. Toutefois, un contrôle préalable des messages peut être effectué par un organisme
(par exemple un firewall) afin d’assurer que ces derniers répondent bien aux exigences de sécurité mise en place.
Les différents aspects de la sécurité abordés plus tard sont:

o Authentification
o Signature
o Intégrité
Attention: WS-Security définit une palette de possibilités pour assurer la sécurité des messages SOAP.
Toutefois, rien n’est obligatoire!
13.3 Application de WS-Security

Le message SOAP doit pouvoir nous permettre d’utiliser différentes informations. Dans l’ordre ces informations
sont:
o Identifier l’auteur du message
o Prouver que l’auteur fait partie d’un groupe connu
o Prouver que l’auteur a les bons droits
o Prouver que le message reçu et le même que celui envoyé
Toutes ces informations sont contenues dans un jeu d’entêtes SOAP attaché au message. WS-Security définit en
premier lieu un « UsernameToken » dont le rôle sera de transmettre le login et le password (si le service web
demande une authentification).
Un « Security Token Service » pourra être utilisé pour l’obtention et la validation du Token. Ce dernier pourra
être : un service Kerberos ou PKI, ou une simple base de données contrôlant un login et password.
Lorsque le client a obtenu le Token, il doit l’incorporer à son message. Si le client utilise un UsernameToken
pour l’authentification, il devra envoyer un hash de son password et signé le message avec son password. Le
serveur peut alors contrôler la validité du message en comparant la signature qu’il génère avec celle contenu
dans le message.
Page 30 / 52 10/07/2003
On peut également utiliser des certificats X.509 pour signer le message. Dans ce cas, le message sera signer à
l’aide de la clé privée. Et le certificat X.509 sera ajouté au message. Toutes entités possédant la clé publique sera
donc en mesure de contrôler la signature du message.
1.Envoit de la requête pour l’obtention d’un Token Security Service Token

Web
2.Reception du Token pour l’ajouter au message
Service
Client
4.Validation Token
3.Envoit du message signé (avec le Token) Web Service
5.Réception de la réponse
Figure1 – Déroulement typique d’une transaction
Le diagramme ci-dessus illustre le déroulement d’une transaction avec l’utilisation des concepts explicités ci-
dessus.
Est-ce suffisant d’obtenir l’identité de l’auteur du message avec certitude?

Non, puisqu’un pirate pourrait remplacer le corps d’un message (dont il sait que l’entête est valide) par un corps
malveillant.
13.4 Entête SOAP version WS-Security

Les entêtes SOAP sont basées autour des types suivants. Ces derniers sont nécessaires pour permettre à l’entête
d’accueillir plusieurs « Token ».
Namespace Description Namespace URI

Xs XML Schema http://www.w3.org/2001/XMLSchema
Wsse WS-Security http://schemas.xmlsoap.org/ws/2002/07/secext
Wsu Utility elements http://schemas.xmlsoap.org/ws/2002/07/utility
Soap SOAP elements http://schemas.xmlsoap.org/soap/envelope/
Tableau 1 – XML Namespaces utilisés dans les entêtes SOAP
Un message SOAP peut contenir plusieurs bloques d’entête. Chaque bloque WS-Security est identifiée par un
seul acteur. Cela pour rendre plus simple l’identification de quel bloque fait quoi. Chaque acteur est identifié de
manière unique par un URI. C’est cet URI qui permettra d’identifier et de traiter le bloque WS-Security comme
il se doit. Le service web doit définir le traitement pour chaque acteur.
13.5 Paramètres supplémentaires

Certains paramètres fixés par WS-Security paraissent à priori hors de propos quand il s’agit du sujet de la
sécurité. Toutefois, deux de ces paramètres attirent l’attention.
wsu:ID
Cet attribut a été ajouté pour faciliter au maximum le travail des « relais » des messages. La valeur de cet attribut
peut être dupliquée n’importe où dans le document. Elle permet une identification claire des différents éléments
ainsi nommés.
wsu:Timestamp
Cet attribut permet de connaître les dates importantes du message (la date de sa création, de son expiration et de
sa réception). Chacune de ces dates est identifiée de manière unique grâce à un wsu:ID.
Page 31 / 52 10/07/2003
En cas d’arrivée de deux messages identiques, leur « Timestamp » respectif peuvent permettre de choisir le bon
message. La date d’expiration permet également de déterminer si un message est encore valable ou pas.
13.6 Authentification
WS-Security propose de nombreuses méthodes pour permettre la validation d’un utilisateur. J’aborde ici trois de
ces méthodes.
13.6.1 Username / password

Sans doute la manière d’authentification la plus répandue. Pour transmettre ces informations, WS-Security a
définit le UsernameToken.
Voici le schéma d’un UsernameToken:
<xs:element name="UsernameToken">
<xs:complexType>
<xs:sequence>
<xs:element ref="Username"/>
<xs:element ref="Password" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Id" type="xs:ID"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
</xs:element>
Figure 2 – schéma UsernameToken
Ci-dessous, on découvre deux nouveaux types: username & password. En particulier, on remarque l’attribut
« Type » de password qui permet de définir la façon dont il est codé (plain text, digest format, etc.). Ici, le
password passe en clair (plain text).
<wsse:UsernameToken>
<wsse:Username>scott</wsse:Username>
<wsse:Password Type="wsse:PasswordText">password</wsse:Password>
</wsse:UsernameToken>
Figure 3 – UsernameToken dans un message SOAP (code XML) password en clair
Même UsernameToken, mais cette fois le password est hashé.

<wsse:UsernameToken>
<wsse:Username>scott</wsse:Username>
<wsse:Password Type="wsse:PasswordDigest">
KE6QugOpkPyT3Eo0SEgT30W4Keg=</wsse:Password>
<wsse:Nonce>5uW4ABku/m6/S5rnE+L7vg==</wsse:Nonce>
<wsu:Created xmlns:wsu=
"http://schemas.xmlsoap.org/ws/2002/07/utility">
2002-08-19T00:44:02Z
</wsu:Created>
</wsse:UsernameToken>
Figure 4 – UsernameToken dans un message SOAP (code XML) password hashé (algorithme SH1)
Dans le cas d’un passage du password hashé, le récepteur devra vérifier les données en récréant le hash à partir
du password (qu’il doit évidemment connaître) et en le comparant au hash reçu.
Page 32 / 52 10/07/2003
13.6.2 X.509 Certificats

Lors de l’authenfication avec X.509, le certificat public est transmis sous la forme du schéma ci-dessous: un
BinarySecurityToken:
<xs:element name="BinarySecurityToken">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Id" type="xs:ID" />
<xs:attribute name="ValueType" type="xs:QName" />
<xs:attribute name="EncodingType" type="xs:QName" />
<xs:anyAttribute namespace="##other"
processContents="strict" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Figure 5 – schéma BinarySecurityToken
Ce schéma contient:
o Une chaîne de caractère
o Un identifiant unique
o Des informations sur le type des éléments contenus et comment ils sont encodés
13.6.3 Kerberos
Un utilisateur peut, s’il détient toutes les pièces (conditions) demandées, obtenir un TGT (ticket granting ticket).
Ce TGT est une obscure partie de donnée que l’utilisateur ne peut pas lire (exploiter). Par contre l’utilisateur
pourra utiliser ton TGT pour obtenir un ST (service ticket) et ainsi accéder aux services.
Déroulement du système:
o Un client s’authentifie auprès d’un distributeur de clés (KDC: Key Distribution Center) et obtient un
TGT
o Le client utilise son TGT pour accéder à un TGS (Ticket Granting Service)
o Le client demande un ST pour une ressource réseau particulière.
o Le TGS délivre le ST au client
o Le client accède à la ressource réseau spécifiée avec les droits spécifiés en présentant son ST.
13.7 Signature
La signature d’un message ne protège en aucun cas son contenu de la visualisation d’autrui, par contre elle
permet d’assurer que le contenu reçu et bien celui envoyé. Intégrité: oui, confidentialité: non!
Les trois méthodes d’authentification vues ci-dessus peuvent être utilisées pour signer le message et ainsi
garantir son intégrité.
o X.509 demande à l’envoyeur de signer son message avec sa clé privée.
o Kerberos demande une « clé de session » que l’envoyeur crée et transmet avec son ticket. Et seul le
destinateur de ce message peut lire le ticket, et ainsi retrouver la clé de session. Et vérifier l’authenticité
de la signature.
o UsernameToken demande que le message soit signé avec le password.
La signature est générée en utilisant « XML Signature ». Il est important de comprendre que même pour signer
un message « Hello World », il est nécessaire de signer chaque élément individuellement.
Page 33 / 52 10/07/2003
13.8 Encryption
L’intégrité est importante, mais la confidentialité l’est également. C’est pourquoi WS-Security met en place des
systèmes d’encryption.
Deux grandes familles peuvent être utilisées pour l’encryptage de données: l’encryption symétrique ou
asymétrique. L’encryption symétrique demande que le secret (la clé de décryptage) soit connu par l’envoyeur et
le destinataire. Puisque la clé sert à la fois à encrypter et à décrypter les données.
Intuitivement, on peut dire que l’utilisation de l’encryption symétrique est réservée aux cas où :
- on contrôle le système entier (end-to-end)
- l’application et/ou le client utilisant la clé sont connus (et dignes de confiance)
Le problème de l’encryption symétrique est le passage de la clé entre les futurs utilisateurs. On ne peut pas
imaginer envoyer la clé « en clair » dans un mail avant de l’utiliser pour encrypter les transmissions suivantes.
Les solutions envisagées sont très diverses, allant du colis postal contenant un disc sur lequel le mot de passe est
enregistré à la correspondance téléphonique.
L’encryption asymétrique ne pose pas ces problèmes, puisque la clé publique (servant à l’encryption) peut être
diffusée à n’importe qui. Cela est envisageable, puisqu’un message ne pourra être décrypté que grâce à la clé
privée. L’utilisateur voulant recevoir des données encryptées n’aura donc qu’à garder sa clé privée secrète pour
garantir la confidentialité.
Page 34 / 52 10/07/2003
Voici un exemple de message encrypté avec un algorithme symétrique. Il contient les informations sur les
données contenues dans le message, ainsi que sur la manière dont le message a été encrypté.
<?xml version="1.0" encoding="utf-8" ?>

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<soap:Header
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"
xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
<wsu:Timestamp>
<wsu:Created
wsu:Id="Id-3beeb885-16a4-4b65-b14c-0cfe6ad26800"
>2002-08-22T00:26:15Z</wsu:Created>
<wsu:Expires
wsu:Id="Id-10c46143-cb53-4a8e-9e83-ef374e40aa54"
>2002-08-22T00:31:15Z</wsu:Expires>
</wsu:Timestamp>
<wsse:Security soap:mustUnderstand="1" >
<xenc:ReferenceList>
<xenc:DataReference
URI="#EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51" />
</xenc:ReferenceList>
<xenc:ReferenceList>
<xenc:DataReference
URI="#EncryptedContent-666b184a-a388-46cc-a9e3-06583b9d43b6" />
</xenc:ReferenceList>
</wsse:Security>
</soap:Header>
<soap:Body>
<xenc:EncryptedData
Id="EncryptedContent-f6f50b24-3458-41d3-aac4-390f476f2e51"
Type="http://www.w3.org/2001/04/xmlenc#Content">
<xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Symmetric Key</KeyName>
</KeyInfo>
<xenc:CipherData>
<xenc:CipherValue
>InmSSXQcBV5UiT... Y7RVZQqnPpZYMg==</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soap:Body>
</soap:Envelope>
Figure 6 – message SOAP avec encryption symétrique réalisée
Page 35 / 52 10/07/2003
13.9 Conclusion
WS-Security nous offre les moyens de :
- identifier l’envoyeur du message Authentification
- signer le message Intégrité
- encrypter les données contenues dans le message Confidentialité
dans les échanges SOAP.
WS-Security met bien en place une solution de sécurité « end-to-end ». Dans ce cas l’application de cette
solution dépend donc des clients (utilisateurs ou applications) et non plus de l’infrastructure réseau elle-même.
On pourrait par exemple imaginer que des messages SOAP non conformes seraient reçus par une personne
utilisant un portable au saint d’une entreprise qui applique WS-Security. Les conséquences pourraient être
l’affaiblissement de la sécurité de l’entreprise.
Pour garantir l’application de WS-Security, il est donc nécessaire que la sécurité « point-to-point » soit mise à
contribution. Typiquement en faisant contrôler par un firewall le contenu de l’entête des messages SOAP dès
leurs arrivées dans le réseau d’entreprise (SOHO). Le firewall pourra ainsi laisser passer, par exemple,
uniquement les messages dont l’entête signalera qu’ils sont signés et encryptés. Le firewall pourrait même
participer à l’authentification de l’envoyeur du message au travers d’une base de données locale ou distante.
On constate que l’application de WS-Security est nécessaire afin que le protocole SOAP soit sécurisé, et ainsi
utilisable pour des échanges d’informations sensibles. Dans des entreprises telles que: banques, assurances,
ventes par correspondance par carte de crédit, etc.
13.10Référence
http://msdn.microsoft.com/
Page 36 / 52 10/07/2003
14 Tutorial : mise en place d’un service web SOAP

14.1 But
Construire et fournir des services web sur la base de Apache SOAP
14.2 Introduction
Apache SOAP
Apache SOAP se compose d’un servlet qui écoute les requêtes SOAP, de classes Java
correspondantes pour la traduction des requêtes en code Java, et de classes Java pour la
génération de la réponse SOAP. Il tourne sur des serveurs d’application, comme par exemple:
Tomcat, IBM Websphere, BCA Weblogic, Allaire JRun, etc.
Tomcat
Tomcat est un serveur d’application qui peut soit tourner sous un serveur web comme par
exemple Apache, soit tourner indépendamment.
En utilisant Apache SOAP, nous allons mettre en place un service web SOAP. D’abord le
fournisseur de service web (serveur) au chapitre 3 puis le consommateur (client) au chapitre 4.
Attention! Ce tutorial aboutit à la mise en place d’un service web fonctionnel. Toutefois cette
fonctionnalité n’a été testée qu’avec une version de chaque composant.
14.3 Déploiement de Apache SOAP sur un système Windows XP
14.3.1 Serveur d’application : Tomcat
14.3.1.1 Java
14.3.1.1.1 Télécharger Java

http://java.sun.com/j2se/downloads.html
Version: 1.4.1_02
Note: ne pas prendre de version antérieure à 1.3
14.3.1.1.2 Installer Java

Exécuter le fichier d’installation et suivre les instructions
Répertoire par défaut: C:\j2sdk1.4.1_02
14.3.1.1.3 Editer la variable d’environnement JAVA_HOME

Note: pour éviter de refaire manuellement chaque étape par la suite, créer un script
Page 37 / 52 10/07/2003
startTC.bat
set JAVA_HOME=C:\j2sdk1.4.1_02
Figure 1 : code du script startTC.bat
14.3.1.2 Tomcat
14.3.1.2.1 Télécharger Tomcat

http://jakarta.apache.org/site/binindex.cgi
Version: 4.1.24
Note: prendre une version sous « Release Builds », et télécharger le .zip correspondant
14.3.1.2.2 Extraire Tomcat

A l’aide d’un utilitaire de décompression (Winzip, etc.)
C:\soap\jakarta_tomcat_4.1
Note: ne pas mettre d’espace dans le nom du répertoire
14.3.1.2.3 Editer la variable d’environnement CATALINA_HOME

Modifier le script
startTC.bat
set CATALINA_HOME=C:\soap\jakarta_tomcat_4.1
%CATALINA_HOME%\bin\startup.bat
14.3.1.2.4 Lancer Tomcat

Exécuter le script « startTC.bat »
14.3.1.2.5 Test du serveur

Pour vérifier le fonctionnement du serveur, taper http://localhost:8080 dans la barre d’adresse
de votre navigateur. La page d’accueil de Tomcat doit apparaître.
La page d’accueil de Tomcat vous propose différents tests à effectuer pour vérifier le
fonctionnement des SSPs et des servlets.
Lancer un exemple SSP (SSP Examples)
Lancer une servlet (Servlet Examples)
Si les tests ci-dessus réussissent, votre serveur d’application est installé et fonctionnel! Sinon
recommencez en contrôlant que vous suivez bien les rubriques « Note » de chaque étape.
Page 38 / 52 10/07/2003
14.3.2 Application web: SOAP
14.3.2.1 Apache SOAP
14.3.2.1.1 Télécharger Apache SOAP

http://xml.apache.org/dist/soap/
Version: 2.3.1
Note: télécharger le .zip correspondant
14.3.2.1.2 Extraire Apache SOAP

A l’aide d’un utilitaire de décompression (Winzip, etc.)
C:\soap\soap-2_3_1
Note: ne pas mettre d’espace dans le nom du répertoire
14.3.2.2 Bibliothèques
Apache SOAP pour Java nécessite l'API JavaMail qui dépend elle-même du Framework Java
Activation (JAF). Apache SOAP a également besoin du package Xerces (parser XML), donc
nous devons le télécharger et l'installer.
14.3.2.2.1 Javamail
Télécharger Javamail http://java.sun.com/products/javamail/
Version: 1.2
Note: section « JavaMail API »
Extraire dans C:\soap\javamail-1.2
14.3.2.2.2 Javabeans
Télécharger Javabeans http://java.sun.com/products/javabeans/glasgow/jaf.html
Version: 1.2
Extraire dans C:\soap\jaf-1.0.2
14.3.2.2.3 Xerces
Télécharger Xerces http://xml.apache.org/dist/xerces-j/old_xerces1/
Version: 1.2
Extraire dans C:\soap\xerces-1_2_3
14.3.2.3 SOAP vers Tomcat
14.3.2.3.1 Copie des modules SOAP pour Tomcat

C:\soap\soap-2_3_1\webapps\soap.war C:\soap\jakarta_tomcat_4.1\webapps\soap.war
Page 39 / 52 10/07/2003
14.3.2.3.2 Accès aux fichiers .jar SOAP pour Tomcat

Modifier le script :
startTC.bat
set CLASSPATH=C:\soap\soap-2_3_1\lib\soap.jar
set CLASSPATH=%CLASSPATH%;C:\soap\javamail-1.2\mail.jar
set CLASSPATH=%CLASSPATH%;C:\soap\jaf-1.0.2\activation.jar
set CLASSPATH=%CLASSPATH%;C:\soap\xerces-1_2_3\xerces.jar
14.3.2.4 Test de Apache SOAP

Pour vérifier le fonctionnement du serveur, taper http://localhost:8080/soap/servlet/rpcrouter
dans la barre d’adresse de votre navigateur. Le message suivant doit apparaître :
1 SOAP RPC Router

Sorry, I don't speak via HTTP GET- you have to use HTTP POST to talk to me.
Figure 4 : résultat attendu
Si le test ci-dessus réussit, votre application SOAP est installée et fonctionnelle! Sinon
recommencez en contrôlant que vous suivez bien les rubriques « Note » de chaque étape.
14.3.3 Déploiement d’un service de démo
Un utilitaire java (java org.apache.soap.server.ServiceManagerClient) est fourni par Apache

SOAP pour nous permettre de faire appelle à un script de déploiement.
Les paramètres de ce script sont :
- L’URL du servlet SOAP
- Un fichier XML décrivant le service (descripteur de déploiement)
Apache SOAP fournis des services de démo dans le répertoire: C:\soap\soap-2_3_1\samples
Page 40 / 52 10/07/2003
14.3.3.1 Création du script de déploiement

deployerTC.bat
java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter deploy %1
pause
Figure 5 : code du script deployerTC.bat
14.3.3.2 Modification du script de démarrage de Tomcat

startTC.bat
set CLASSPATH=%CLASSPATH%;C:\soap\soap-2_3_1
Note: il faut arrêter puis redémarrer Tomcat pour que le nouveau CLASS_PATH soit pris en
compte.
14.3.3.3 Déploiement du service de démo

>deployerTC.bat C:\soap\soap-2_3_1\samples\addressbook\DeploymentDescriptor.xml
14.3.3.4 Contrôle du déploiement du service

Pour contrôler le déploiement du service, taper http://localhost:8080/soap/admin/index.html
dans la barre d’adresse de votre navigateur. Sous la rubrique List vous trouverez la ligne
« urn:AddressFetcher » correspondant à votre service.
14.3.3.5 Contrôle du fonctionnement du service

Puisque le client SOAP n’existe pas encore, nous allons utiliser le client fournit par Apache
SOAP. Il se contentera d’appeler la méthode getAddressFormName du service.
Page 41 / 52 10/07/2003
Création du script client :
getAddressFormName.bat
set CLASSPATH=%CLASSPATH%;C:\soap\soap-2_3_1\
java samples.addressbook.GetAddress http://localhost:8080/soap/servlet/rpcrouter "John B. Good"
pause
Figure 7 : code du script getAddressFormName.bat
Pour vérifier le fonctionnement du service,exécuter le script. Le message suivant doit

apparaître :
123 Main Street
Anytown, NY 12345
(123) 456-7890
14.3.4 Ecoute du dialogue SOAP

Un tunnel (TcpTunnelGui inclus dans le package soap.jar) est fourni par Apache SOAP pour
nous permettre de regarder le dialogue SOAP entre le client et le serveur.
14.3.4.1 Principe de TcpTunnelGui

Le tunnel écoute les requêtes TCP/IP sur un certain port, les affichent à l’écran, puis les
réexpédient vers le port qui traite les requêtes. Même démarche pour les réponses.
14.3.4.2 Création du script de démarrage du tunnel

tunnelSOAP.bat
java org.apache.soap.util.net.TcpTunnelGui 6666 localhost 8080
Figure 9 : code du script tunnelSOAP.bat
Page 42 / 52 10/07/2003
14.3.4.3 Modification du script du client

java samples.addressbook.GetAddress http://localhost:6666/soap/servlet/rpcrouter "John B. Good"
pause
Figure 10 : modification du script getAddressFormName.bat
14.3.4.4 Affichage du dialogue SOAP

Après avoir lancé le tunnel en exécutant le script tunnelSOAP.bat, lancer le client en
exécutant le script getAddressFormName.bat.
L’interface graphique vous montre le dialogue SOAP client-serveur.
Figure 11 : interface utilisateur du tunnel SOAP
Page 43 / 52 10/07/2003
Détail des messages :
Du client :
POST /soap/servlet/rpcrouter HTTP/1.0
Host: localhost:6666
Content-Length: 492
SOAPAction: ""

<SOAP-ENV:Body>
<ns1:getAddressFromName xmlns:ns1="urn:AddressFetcher" SOAP-
<nameToLookup xsi:type="xsd:string">John B. Good</nameToLookup>
</ns1:getAddressFromName>
</SOAP-ENV:Body>
Figure 12 : code du message SOAP envoyé par le client : requête
Du serveur :
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=A45B8472165F47F39651C4F67E401D4F; Path=/soap
Content-Length: 946
Date: Thu, 01 May 2003 10:48:01 GMT
Server: Apache Coyote/1.0
Connection: close

<SOAP-ENV:Body>
<ns1:getAddressFromNameResponse xmlns:ns1="urn:AddressFetcher" SOAP-
<return xmlns:ns2="urn:xml-soap-address-demo" xsi:type="ns2:address">
<city xsi:type="xsd:string">Anytown</city>
<phoneNumber xsi:type="ns2:phone">
<areaCode xsi:type="xsd:int">123</areaCode>
<exchange xsi:type="xsd:string">456</exchange>
<number xsi:type="xsd:string">7890</number>
</phoneNumber>
<state xsi:type="xsd:string">NY</state>
<streetName xsi:type="xsd:string">Main Street</streetName>
<streetNum xsi:type="xsd:int">123</streetNum>
<zip xsi:type="xsd:int">12345</zip>
</return>
</ns1:getAddressFromNameResponse>
</SOAP-ENV:Body>
Figure 13 : code du message SOAP envoyé par le serveur : réponse
Page 44 / 52 10/07/2003
14.4 Mise en place du client

A ce stade là, la manière la plus simple et rapide de créer un client distant et de :
• installer Java sur la machine client (voir section 3.1)
• faire une copie du répertoire c:\soap du serveur dans un répertoire équivalent sur le
client
• récupérer le script créé pour le test du serveur (getAddressFormName.bat) et faire la
modification indiquée ci-dessous.
java samples.addressbook.GetAddress http://serveurName:8080/soap/servlet/rpcrouter "John B. Good"
pause
Figure 14 : code du script getAddressFormName.bat coté client
Pour vérifier le fonctionnement du client, exécuter le script. Le message suivant doit

apparaître :
123 Main Street
Anytown, NY 12345
(123) 456-7890
14.5 Conclusion
Si vous avez suivi les indications ci-dessus, vous disposez maintenant d’un service web
SOAP fonctionnel composé d’un client et d’un serveur.
Il existe de nombreux exemples de services web disponibles sur Internet, par exemple sur le
site de référence nommé ci-dessous.
14.6 Référence
http://www.soapuser.com/
Page 45 / 52 10/07/2003
15 Planning et objectifs projet de semestre & objectifs

travail de diplôme
15.1 Planning du projet de semestre
13 mars 2003
Apprentissage de XML : recherche de documentation sur Internet et à la bibliothèque
20 mars 2003
Analyse des menaces spécifiques aux applications Web. Edition d’un résumé sur la base du
document The Ten Most Critical Web Application Security Vulnerabilities publié par
OWASP.
27 mars 2003
Discussion avec Messieurs Maret et Buchs pour la mise au point du cahier des charges.
Edition du planning du projet.
Apprentissage de XML : lecture de différents cours sur le sujet, dont celui de M. Jaton
3 avril 2003
Apprentissage de XML : pratique (parsing, etc.).
10 et 17 avril 2003
Etude et édition d’un résumé portant sur SOAP.
1, 8 et 22 mai 2003
Recherche des outils et des APIs (par exemple pour Java).
Recherche des outils pour la mise en place du FW.
Edition d’un tutorial sur la mise en place d’un banc de test pour l’étude des communications
SOAP.
Mise en place d’un banc de test pour l’étude des communications XML / SOAP.
Utilisation de ApacheSOAP, d’un tunnel pour la visualisation des messages SOAP.
12 juin 2003
Réception de l’infrastructure mise à disposition par l’Eivd.
Réunion et présentation du bilan intermédiaire.
Etude des communications (requêtes, réponses, etc.).
19 juin 2003
Mise en place d’un serveur Apache sous Windows 2000.
Configuration d’un module proxy sous Apache.
26 juin 2003
Test de l’infrastructure complète (client, serveur, serveur Apache) à l’aide d’un service web.
3 et 10 juillet 2003
Etude et édition d’un résumé sur WS-Security.
Etude sur les menaces spécifiques aux services Web SOAP.
Rendre le dossier contenant le rapport du projet ainsi que les annexes.
Page 46 / 52 10/07/2003
17 juillet 2003
Présentation du projet.
Modification du cahier des charges pour le travail de diplôme si besoin.
15.2 Objectifs du projet de semestre
Rendre mon rapport sur les services web
Rendre comme annexe de mon dossier:

Le résumé sur SOAP
Le tutorial sur la mise en place d’un service web
Le résumé sur WS-Security
Le résumé sur la sécurité des applications web (avorté)
Avoir à disposition une infrastructure complète présentant un service web, contenant:

Le serveur
Le client
La plateforme pouvant accueillir le FW
Présenter le fonctionnement du service web:

La partie Client
La partie Serveur
Le FW
Page 47 / 52 10/07/2003
15.3 Objectifs du travail de diplôme

(avec planning en pourcentage des 60 jours à disposition 1.66% = 1 jour )
Installation d’Apache sous Linux

Recherche d’informations sur le sujet
Installation de Linux
Installation et configuration d’Apache
Note: je pense qu’il est plus simple d’utiliser une plate-forme Linux pour les tests et la mise
en place d’un module sous Apache. C’est pourquoi je me tourne ici vers Linux.
5%
Module Apache
Apprentissage des modules Apache au travers de l’étude d’un module déjà existant
Révision du langage C
Ecriture d’un module basique (typiquement un exemple)
10%
Module Firewall SOAP

Réalisation d’un firewall applicatif SOAP pour le protocole http sous la forme d’un module
spécifique pour Apache.
Les fonctionnalités du firewall se limiteront dans un premier temps à un contrôle des en-têtes
des enveloppes SOAP et à un contrôle de leurs contenus (corps de l’enveloppe).
50%
Test de l’infrastructure complète

Fonctionnalité
Résistance aux attaques
Evolution possible du module suite aux résultats des tests
35%
Page 48 / 52 10/07/2003
16 Annexe 3 : sécurité des applications web (avorté)

16.1 Introduction
Etudier la problématique de sécurité des applications Web dans le cadre d’un travail de
semestre.
16.2 Cahier des charges

(défini par Sylvain Marret)
Dans un premier temps, cette étude comportera l'analyse des menaces spécifiques aux
applications Web et plus spécifiquement les échanges Soap transitant par http ou https. Cette
étude analysera les mécanismes actuels d'authentification, d'intégrité des échanges, de la
confidentialité et enfin de la signature des transactions.
· XML
· XML-Signature
· XML-Encryption
· SOAP
· SAML
· WS-Security
· PKI- X509
Puis dans une deuxième phase, cette étude se focalisera sur les outils à mettre en œuvre pour
la protection des services Web et plus spécifiquement la sécurisation des messages Soap à
l'aide de firewall.
Pour mettre en pratique cette problématique, cette étude devra mettre en œuvre un service
web utilisant des échanges de messages Soap à travers le protocole http. L'étape suivante sera
de réaliser un firewall applicatif Soap pour le protocole http. L'idée étant d'utiliser le server
Apache comme base de travail et d'implémenter le firewall Soap en tant que module Apache.
16.3 Analyse des menaces spécifiques aux applications Web
Cette étude se base dans un premier temps sur un article publié par l’organisation OWASP
(Open Web Application Security Project) pour approcher la problématique des menaces
spécifiques aux services Web d’une manière générale.
Vous trouverez ci-dessous une liste des menaces les plus répandues dans les applications
Web.
16.3.1 Unvalidated Parameters (paramètres invalides)
Des informations sont transmisses depuis le Web jusqu’aux applications Web. Si la validité
de ces dernières n’est pas contrôlée avant la transmission, cela créer une vulnérabilité. Un
Hacker peut attaquer les composants de l’application via cette faille.
Page 49 / 52 10/07/2003
Chaque partie de la requête HTTP doit être contrôlée avant la validation de cette dernière. La
modification de l’URL, de l’en-tête de la requête, etc. pourrait suffire au Hacker pour
outrepasser le mécanisme de sécurité.
Protection : tous les paramètres doivent être validés selon un typage stricte (type de donnée,
longueur des données, paramètre null accepté, paramètres dupliqués, etc.) fixé par exemple
par une librairie centrale.
16.3.2 Broken Access Control (perte du contrôle d’accès)
La définition des restrictions propres à un utilisateur authentifié par un système n’est pas
correctement spécifiée. Un Hacker peut accéder à des acomptes, des fichiers ou des
fonctionnalités grâce à ce manque de rigidité.
Une mauvaise mise en place des droits (ou des restrictions) impartis à un utilisateur peut créer
un flou dans la vision globale de la problématique. Ceci rend pratiquement impossible toute
mise à jour propre et contrôlée des restrictions. Un Hacker peut trouver une incohérence dans
cette politique et ainsi accéder à des niveaux de privilège dangereux pour le système.
Protection : établir une politique globale de sécurité. Puis tirer toutes les mesures de sécurité
de cette dernière afin de garder en tout temps une vision intégrale de la problématique. Note :
sans documentation sur la politique de sécurité globale, les mesures indépendantes à chaque
application sont inefficaces.
16.3.3 Broken Account And Session Management (perte de contrôle

de la gestion des acomptes et des sessions)
La protection des acomptes et des sessions n’est pas correctement assurée. Un Hacker peut
accéder aux passeports, aux cookies, aux clés, etc. des autres utilisateurs, et ainsi prendre leurs
identités.
Si par exemple une application doit garder une trace de toutes les requêtes d’un même
utilisateur, elle sera alors obligée de créer elle-même un moyen d’authentification de chaque
utilisateur. Pour se faire, l’application crée des "jetons" propres à un utilisateur pour marquer
une session en cours. Ce jeton permet à l’application d’authentifier ce dernier. Si un Hacker
récupère ce jeton, il peut alors se faire passer pour un utilisateur authentifié aux yeux de
l’application. Il peut également essayer de décrypter le contenu du jeton pour en créer des
nouveaux.
Protection : les passeports doivent être changés régulièrement par tous les utilisateurs. Un
nombre minimum de caractères doit être défini pour la taille de ces derniers. Toujours
encrypter les données de "login" avant de les transmettre.
16.3.4 Cross-Site Scripting (XSS) Flaws
Page 50 / 52 10/07/2003
Cette vulnérabilité vise directement la machine de l’utilisateur final. Le Hacker se sert de
l’application Web pour transporter son mécanisme d’attaque (par exemple : JavaScript).
Certaines applications font transiter des informations sans les filtrer. Par exemple une entrée
directement redirigée sur une sortie. Puisque le récepteur reçoit l’information d’une
application (typiquement un serveur) il considère cette dernière comme sans danger. Un
Hacker peut donc profiter de cette "non-méfiance" pour attaquer une machine finale du
réseau.
Protection : certains caractères (<, >, (, ), #, &) transitant par l’application doivent être
modifiés pour améliorer la sécurité.
16.3.5 Buffer Overflows (surcharge d’un tampon)
Une application Web peut être écrite dans un langage qui ne gère pas la validité des
paramètres d’entrées, typiquement leurs longueurs (Le problème peut aussi venir de la
manière de coder du programmeur de l’application). Un Hacker peut soit rentrer un
paramètre très long pour faire planter l’application, soit chercher la taille limite du tampon
afin de découvrir le contenu adjacent au tampon en mémoire centrale.
L’écriture d’un tampon disproportionné par rapport à la taille mémoire allouée à ce dernier,
permet au Hacker d’écraser une partie adjacente de la mémoire par son propre code. Et ainsi
de faire exécuter son code.
Protection : analyser chaque partie de code qui accepte des entrée venant qu’une requête
HTTP et vérifier si les limitations sont bien respectées. Il existe également des scanners qui
recherche cette faille sur un site Web complet.
16.3.6 Command Injection Flaws (Faille d’injection de commande)
Les applications Web passent des paramètres lors d’accès soit à un système externe, soit au
système d’exploitation. Un Hacker peut modifier ces paramètres et ainsi faire exécuter ces
commandes en lieu et place de celles de l’application Web.
Même des appels systèmes peuvent être remplacés lors d’une "injection". Des scripts écrits en
Python, Perl, etc. sont généralement utilisés pour réaliser cette attaque.
Protection : interdire tous les appels systèmes qui ne sont pas nécessaires à notre application.
Pour les autres, mettre en place un système de validation pour éviter l’exécution d’un code
interdit.
16.3.7 Error Handling Problems (problèmes de gestion d’erreur)
Les exceptions levées durant l’exécution normale d’une application Web peuvent être mal
gérées. Un Hacker peut trouver la marche à suivre pour générer ces exceptions. En observant
Page 51 / 52 10/07/2003
le comportement de l’application, il peut en déduire des informations sur le système. Ou
simplement faire planter l’application.
16.3.8 Insecure Use Of Cryptogrsphy (utilisation non-sécurisé de la

cryptographie)
Les applications Web utilisent la cryptographie pour protéger la confidentialité des

informations. Mais les fonctions de cryptage ont souvent des failles connues qui corrompent
la sécurité de la confidentialité.
16.3.9 Remote Administration Flaws (contrôle à distance des outils

d’administration)
Les applications Web offrent souvent la possibilité de se faire gérer via le Web. Un Hacker
qui accède à la configuration de l’application peut ainsi s’attribuer un accès complet à la
configuration du site.
16.3.10 Web And Application Server Misconfiguration (incohérence

entre les configurations de l’application et du serveur)
Une configuration trop lourde du serveur est critique pour la sécurité de l’application Web.
Travail avorté après réunion avec M. Maret, Buchs et Ventura
Page 52 / 52 10/07/2003

Sec Des Services Web

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sec Des Services Web

Transféré par

Droits d'auteur :

Formats disponibles

Projet de semestre – Sécurité des services web Jonathan Rod

Mandaté par : e-Xpert Solutions SA

Professeur responsable : Stefano Ventura

Table des matières :

8 DESCRIPTION DU FIREWALL SOAP .................................................................................................... 16

12 ANNEXE 1 : SIMPLE OBJECT ACCESS PROTOCOL..................................................................... 21

Les grandes étapes de cette préparation sont :

3.2 Sécurité informatique

3.3 Services web

Voir résumé en annexe portant sur SOAP

Dans ce gabarit de message, on peut décider d’assurer :

4.1 Authentification du message

Le déroulement de cette opération sera le suivant :

Figure 0 : authentification du message SOAP

Les conditions pour effectuer ce type d’authentification sont:

Cette solution pour l’authentification sera implémentée dans le firewall

4.2 Signature du message

4.3 Encryption du message

Il existe également un tunnel servant à visualiser les messages SOAP.

5 Service web SOAP

Figure 1 : problématique grossière

Figure 2 : problématique plus détaillée

Figure 2 : problématique plus détaillée

Serveur Serveur d’application

Figure 3 : diagramme de l’infrastructure SOAP

Déroulement d’une invocation (hypothèse : le service demandé est déjà déployé):

5.3.1.1 Description de l’infrastructure coté serveur :

Figure 4 : diagramme de l’infrastructure « All-in-One »

5.3.2.1 Description de l’infrastructure coté serveur :

Figure 5 : diagramme de l’infrastructure « Classique »

6.2.4.1 Version 2.0.46

6.2.4.2 Version 1.3.27

7 Web Service Security

Voir résumé en annexe portant sur WS-Security

Les solutions adoptées plus loin font toutes parties du WS-Security.

Figure 6 : comportement lors de la réception d’une requête

8.7 Politique de sécurité

8.8 Cycle de vie

Planifier Réaliser Contrôler Agir

Figure 7 : cycle de vie du firewall SOAP

Les buts du point de vue de la sécurité sont tous atteints, puisque :

Travail manquant pour le travail de diplôme :

Yverdon-les-bains, le 10 juillet 2003

Jonathan Rod, EIT6

12 Annexe 1 : Simple Object Access Protocol

12.1.1 Services web

12.1.2 Appel à distance de procédure

12.1.3 SOAP (Simple Object Access Protocol)

La spécification SOAP décrit une balise <envelope>

12.2 Introduction à SOAP

Nous allons maintenant voir ce que fait SOAP, et comment il le fait.

12.2.1.1 Messages XML

12.2.1.2 Standard de représentation

12.2.2 Messages SOAP

Cet exemple montre les différents composants de l’enveloppe SOAP.

12.2.2.1 Enveloppes SOAP

L’entête n’est pas obligatoire et on ne peut en mettre qu’une par enveloppe.

12.2.2.2 Messages RPC

Client SOAP Request Server SOAP

Figure 3 : échange de message RPC

POST /soap/servlet/rpcrouter HTTP/1.0

<?xml version='1.0' encoding='UTF-8'?>

<?xml version='1.0' encoding='UTF-8'?>

Figure 5 : message RPC envoyé du serveur (response)