Vous êtes sur la page 1sur 35
Sécurisation de web service Tuteur : Christophe TURBOUT Auteur : Gaëtan TURCAS Année universitaire :
Sécurisation de web service Tuteur : Christophe TURBOUT Auteur : Gaëtan TURCAS Année universitaire :
Sécurisation de web service Tuteur : Christophe TURBOUT Auteur : Gaëtan TURCAS Année universitaire :
Sécurisation de web service Tuteur : Christophe TURBOUT Auteur : Gaëtan TURCAS Année universitaire :

Sécurisation de web service

Tuteur : Christophe TURBOUT

Sécurisation de web service Tuteur : Christophe TURBOUT Auteur : Gaëtan TURCAS Année universitaire : 2012-2013

Auteur : Gaëtan TURCAS Année universitaire : 2012-2013

Sécurisation de web service

Remerciements

2012/2013

Je tiens à remercier monsieur Christophe TURBOUT de m'avoir accompagné tout au long de ce projet, en effet grâce à lui j'ai pu développer ce projet dans le bon sens, en établissant une liste d’étapes à franchir afin de le mener à bien.

Enfin, je remercie l’équipe des enseignants toujours présente pour répondre à toutes mes questions.

Sécurisation de web service

Sommaire

2012/2013

1.

Web service

5

1.1.

Qu'est-ce qu’un Web service?

5

1.1.1. Fonctionnement

5

1.1.2. Avantages

6

1.1.3. Inconvénients

6

2.

WSO2 Framework for PHP

7

2.1. Fonctionnent

7

2.2. Composition du web service Framework PHP

8

2.3. Utilisations et utilisateurs

10

3. Les objectifs

3.1. Installation

3.1.1. Problèmes rencontrés

3.2. Tests de la plate-forme

13

13

14

15

3.2.1. Mon premier service

16

3.2.2. Tests de sécurité

18

3.2.3. Fonctionnement des certificats

19

3.2.4. Test 1 aucune sécurité

22

3.2.5. Test 2 Authentifications

22

3.2.6. Test 3 Chiffrements

23

3.2.7. Test 4 Signatures avec les certificats

24

3.2.8. Test 5 Temps de validité d'un message

25

3.2.9. Problèmes rencontrés

25

3.3. Mise à jour de sécurité de la plate-forme

27

3.4. Intégrer du CDATA

27

3.5. Conclusion des quatre objectifs

29

4. Déroulement du projet

29

5. Conclusion

31

6. Glossaire

32

7. Bibliographie

33

8. Annexe

34

Sécurisation de web service

Introduction

2012/2013

Aujourd’hui, l’informatique joue un rôle essentiel aussi bien pour les professionnels que pour les particuliers. En effet, les systèmes informatiques sont désormais au cœur de toutes les fonctions de l’entreprise et plus généralement dans la vie quotidienne. Étant ainsi très utilisé, il y la nécessité de les optimiser.

Pour cela, il existe des outils appelés Web Service. Ceux-ci sont très utilisés dans le domaine des entreprises pour garantir un fonctionnement permanent des services.

Ainsi, ce projet portera essentiellement sur l’étude et l’analyse d'une solution de web service "WSO Web Service Framework for PHP". Le projet se situe donc dans une thématique de test et d'amélioration de la sécurité : «Comment installer tester et améliorer la plateforme WSO ? ».

Pour répondre à cette problématique, je vais dans un premier temps vous expliquer ce qu’est un « Web service », comment il fonctionne et opère. Dans un deuxième temps, je montrerai la réalisation des différents objectifs, comprenant l'installation, tests de la sécurité, mise à jour de sécurité puis l'intégration de CDATA. Enfin nous tirerons une conclusion.

Sécurisation de web service

1. Web service

2012/2013

Avec la connexion des ordinateurs en réseau sur internet, il est possible de faire fonctionner des applications sur des serveurs distants. L'intérêt d'une application fonctionnant à distance est de permettre notamment :

De centraliser les données uniquement sur un serveur distant

Le serveur est généralement physiquement plus puissant (puissance de calcul, de stockage) que les ordinateurs des clients.

Le service centralisé peut être utilisé simultanément par un grand nombre d’utilisateurs.

L'application distante peut être utilisée simultanément par un grand nombre d'utilisateurs et sa mise à jour n'intervient qu'à un seul endroit.

Les Web Services sont une solution définissant un standard de communication avec des applications distantes et d'en récupérer les résultats à travers internet.

1.1. Qu'est-ce qu’un Web service?

Un service web, ou web service, est un programme de communication entre applications distantes à travers internet ou intranet. Le concept est indépendant de tout langage de programmation. La notion d’architecture de service a été définie sur le modèle SOA. SOA (Service Oriented Architecture) est un modèle d'architecture permettant l’intégration des divers systèmes d’information de l’entreprise qui considére chaque ressource informatique comme un service.

1.1.1. Fonctionnement

Un ou plusieurs clients d'environnement diffèrents comme client Java, PHP vont envoyer une requête à un ou des services situés dans un autre lieu. Le service va traiter et interpréter la demande et renvoyer une réponse au client. Le service est interconnecté à des basses de données.

Le service est interconnecté à des basses de données. Pour communiquer, il utilise le protocole HTTP

Pour communiquer, il utilise le protocole HTTP comme moyen de transport.

Les requêtes échangées entre clients et services utilisent le protocole SOAP (Simple Object Access Protocol) ou REST (Representational State Transfer). Ces requêtes sont dans un format XML, elles sont envoyées du client au service. Le service interprète les

Sécurisation de web service

2012/2013

balises XML, puis traite et calcul le message du client. Le service finit par envoyer une réponse de type SOAP ou REST au client.

1.1.2. Avantages

L'avantage d'utiliser une architecture web Service est de centraliser la puissance de calculs dans un serveur dédié aux calculs et relié directement à la base de données. Les clients qui peuvent être nombreux sont donc allégés de la puissance de calcul. Cet avantage permet donc de diminuer les couts. Si la puissance de calcul avait été répartie sur tous les clients, le cout aurait été beaucoup plus élevé (multiplication des serveurs physiques puissants, multiplication des bases de données

Un autre avantage est la maintenance informatique, le fait de centraliser les services facilite la gestion base de données services, serveur web.

1.1.3. Inconvénients

Si le web service n'est pas sécurisé, il y a potentiellement une faille de sécurité avec une attaque de type l'homme du milieu "man in the middle " entre client et service, où les échanges de données peuvent être interceptées et modifiées en usurpant l'identité d'un client ou d'un service. Heureusement, il existe des parades pour éviter ce type d'attaque avec des certificats d'authenticités. Nous verrons plus en détails la sécurité du web service.

Sécurisation de web service

2. WSO2 Framework for PHP

2012/2013

WSO2 est une solution de web service open source, disponible en plusieurs langages de programmation par exemple en C, PHP. Il est destiné aux développeurs et aux professionnels.

La solution de web service est un middleware, il se place entre les clients et services. Elle

permet l’interopérabilité des différents langages de programmation (.net, java, PHP

La version étudiée pour le projet annuel est WSO2 Framework for PHP.

Un API est disponible sur le site officiel WSO.com afin de connaître les différentes classes et options qui s’offrent à l'utilisateur. Notamment les paramètres de sécurités, que j'ai utilisé et analysé dans le projet.

WSO2 est disponible sous différents types de format chacun ayant des utilisations différentes.

2.1. Fonctionnent

).

ayant des utilisations différentes. 2.1. Fonctionnent ). Source : http://wso.com Un client ou des clients (partie

Source : http://wso.com

Un client ou des clients (partie de gauche) de différents environnements (java, .net, c++, navigateur internet) veulent accéder à différents serveurs d'applications contenant des services (partie de droite). WSO le serveur de web service qui est un middleware, se situe donc au milieu. Il permet de contrôler les actions et requêtes de clients vers services. Le Framework en PHP permet d'interpréter la configuration dans le code des clients et services afin d'appliquer des actions.

La base de données peut être reliée au web service afin de la rendre accessible depuis

La puissance de calcul nécessaire est centralisée

les clients ou serveurs d'applications.

Sécurisation de web service

2012/2013

au niveau des serveurs d’applications. La puissance physique des clients peut être ainsi réduite, car elle n’effectue pas de calcul.

2.2. Composition du web service Framework PHP

Le Web service défini dans ce projet repose sur plusieurs couches pour fonctionner.

ce projet repose sur plusieurs couches pour fonctionner. Source : http://wso2.com Le cœur du web service

Source : http://wso2.com

Le cœur du web service repose sur le serveur Web Apache avec le module Axis2/c. Le cœur est écrit en C (Web service Framework for C) permettant le fonctionnement et la configuration de la plate-forme. La communication se fait avec le langage XML, et les protocoles SOAP et REST.

XML (Extensible Markup Language) : langage de programmation avec balises extensibles (création de ses propres noms pour les balises).

SOAP (Simple Object Access Protocol) : Transmit ion des messages avec le protocole SOAP en HTTP (Hypertext Transfer Protocol), et HTTPS (Hypertext Transfer Protocol Secure). L'intérêt de SOAP est qu'il permet d'autoriser un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur.

REST (Representational State Transfer) : est un style d’architecture de web service basé sur les URL (Uniform Resource Locator). Il se base sur HTTP pour la

Sécurisation de web service

2012/2013

transmission de messages entre clients et services. Cependant, il ne rajoute pas de nouvelle couche d'abstraction au-dessus du protocole contrairement à SOAP.

Binary Attachments with MTOM (Message Transmission Optimization Mechanism) :

On peut attacher une pièce jointe aux messages échangés par le web service.

Différentes options de web service WS-* sont possible comme WS-Security qui permet de configurer la sécurité, comme la mise en place du chiffrement des données, ou encore l'authentification.

WS-Addressing : Standard permettant de transmettre des messages SOAP.

WS-Security : permet d'appliquer des options de sécurité.

WS-securityPolicy : représente un ensemble d'options qui décrivent les possibilités et les contraintes de sécurité.

WS-ReliableMessaging : Spécifications sur la fiabilité des messages.

Le Framework en PHP est constitué du service API et client API qui permet l’interprétation et le traitement des commandes en langage PHP vers le cœur en C. Le Framework permet de générer et d'interpréter le WSDL (Web Service Description Langages). Celui-ci fournit une description des actions possibles du web service en format XML. En outre, le WSDL décrit le protocole de communication SOAP, le format des messages requis pour communiquer avec le web service, les méthodes que le client peut invoquer.

Enfin, le web service est compatible avec .NTE et Java qui permet l'interopérabilité entre plusieurs langages.

Sécurisation de web service

2.3. Utilisations et utilisateurs

2012/2013

Aujourd'hui, la plate-forme de web service WSO est utilisée au niveau international dans différents domaines. Par exemple, le domaine du commerce en ligne, des transports ou encore de la communication. Des entreprises comme Ebay ou Expedia se servent du web service WSO.

Dans l'image ci-dessous vous pouvez voir différents domaines d'utilisation ainsi qu'un panel de clients qui utilisent le web service WSO.

qu'un panel de clients qui utilisent le web service WSO. Source : http://wso.com Exemple d'utilisation avec

Source : http://wso.com

Exemple d'utilisation avec Expedia

Expédia est une agence de voyages. Lorsqu’un client d'Expédia va sur le site internet :

expedia.com, celui-ci accède à un formulaire de recherche de voyage , cette page internet affichée dans le navigateur web d'un utilisateur est considérée comme client.

Sécurisation de web service

2012/2013

Ci-dessous le site Expedia.fr avec son formulaire de recherche de voyage.

site Expedia.fr avec son formulaire de recherche de voyage. Une fois que l'utilisateur du site a

Une fois que l'utilisateur du site a rempli le formulaire de recherche de vol, celui-ci va cliquer sur rechercher un voyage, « le client web » va envoyer une requête contenant les informations inscrites dans le formulaire au service web. Le service va rechercher dans sa base de données les vols possibles en fonction des contraintes inscrites dans le formulaire, puis va renvoyer une réponse au client web avec les résultats de sa recherche.

Ci-dessous la réponse du site Expedia pour la recherche d’un vol Paris New York.

Gaëtan TURCAS 11
Gaëtan TURCAS
11

Sécurisation de web service

2012/2013

Enfin, la compagnie WSO2 propose plusieurs autres applications, serveurs et modules qui ne seront pas étudiés dans ce projet.

propose plusieurs autres applications, serveurs et modules qui ne seront pas étudiés dans ce projet. Gaëtan

Sécurisation de web service

3. Les objectifs

2012/2013

Cette partie est dédiée à l'explication des différents objectifs du projet, ainsi que la réalisation, solution, et quelques problèmes rencontrés. Les l'objectifs du projet ont été découpés en quatre tâches : Installation, tests de sécurité, mise à jour de sécurité et enfin inclure du CDATA.

3.1. Installation

Le premier objectif du projet consiste à installer la plateforme WSO2 for PHP dans un environnement de test. Pour ce faire, j'ai mis dans un premier temps, un environnement virtuel avec le logiciel VirtualBox. Cette solution de virtualisation me permet de transporter et d'exporter mon travail d'un ordinateur à un autre sans modifier l'environnement du système d'exploitation de la machine mère. Vous trouverez dans l’annexe les détails des commandes pour l’installation.

Ensuite, à partir de VirtualBox, j'ai installé un système UNIX Debian. WSO2 est également compatible pour une installation Windows. Mon choix s'est porté sur le système UNIX qui me permet contrairement à son concurrent Microsoft d'avoir une visibilité supplémentaire sur se qui se passe vraiment.

Avant de mettre en place la plate-forme, WSO2 a besoin pour fonctionner de certains prés requis. Il faut tout d'abord installer :

Le serveur Web Apaches avec quelques modules associés.

PHP5 pour le langage de programmation PHP avec quelques modules associés.

OpenSSL pour la sécurité et la génération de certificats.

Une fois les différents services installés, il faut télécharger WSO2 framework for PHP, le compiler et l'installer. Enfin, il reste à configurer PHP5 avec la plate-forme.

Ci-dessous le schéma d’installation

Enfin, il reste à configurer PHP5 avec la plate-forme. Ci-dessous le s chéma d’installation Gaëtan TURCAS

Sécurisation de web service

2012/2013

3.1.1. Problèmes rencontrés

L’installation de la plate-forme WSO2 a été assez lourde à mettre en place. La documentation fournie par WSO manque d'informations et de détails au niveau des prés

requis d’installation. En effet, il faut notamment activer les services comme PHP dans un certain mode ou version (« dev »). À cause de ce problème de mode, la compilation de WSO échouait. J'ai résolu le problème de chaque module un à un avec l’erreur fournie à

chaque compilation (30 minutes une compilation

Autres problèmes : La prise en charge du mode WSDL ne se faisait pas correctement une fois la plate-forme WSO exécutée. Le problème était dû à la mauvaise configuration de PHP qui chargeait mal l’environnement de WSO. J'ai réussi à le résoudre avec l'aide de mon tuteur de projet en corrigeant un fichier de configuration de PHP.

).

Malgré quelques difficultés d'installation, la plate-forme de web service est finalement opérationnelle pour les tests.

Sécurisation de web service

3.2. Tests de la plate-forme

2012/2013

Dans cette partie, je vais vous présenter le fonctionnement de la plate-forme à partir de la solution installée précédente.

WSO fournit des exemples accessibles via le navigateur web qui permet de valider et de comprendre le fonctionnement des requêtes échangées entre clients et services, la génération de WSDL, différentes options de sécurité.

Dans l'image ci-dessous vous pouvez apercevoir la page d'exemple fourni par WSO

vous pouvez apercevoir la page d'exemple fourni par WSO Dans chaque exemple on, peut afficher le

Dans chaque exemple on, peut afficher le code en PHP de la partie client et du service. Le bouton WSDL permet d'afficher en langage XML la description du service. En enfin, le lien « run client » exécute la page PHP du client.

Ci-dessous un extrait du premier exemple au format WSDL.

Gaëtan TURCAS 15
Gaëtan TURCAS
15

Sécurisation de web service

Ci-dessous le premier exemple exécuté.

2012/2013

service Ci-dessous le premier exemple exécuté. 2012/2013 Ces premiers exemples simples m’ont permis de comprendre

Ces premiers exemples simples m’ont permis de comprendre le fonctionnement de la plate-forme WSO. J'ai ainsi abouti à écrire un code afin de comprendre et vérifier le code côté service et client. J'ai donc suivi un tutoriel recommandé sur le site wso.com pour les débutants, afin de tester le mécanisme de messages envoyés entre client et service.

3.2.1. Mon premier service

Mon premier service va calculer la valeur factorielle d'un nombre. On se place dans l'optique générale que le service est hébergé sur un serveur avec une puissance importante de calcul. Le client peut être une machine lambda avec de faibles performances. Dans notre simulation on s'imagine que le calcul d'une factorielle requière des ressources processeur importantes.

Le client veut connaître la valeur de la factorielle du nombre 10. Il va envoyer une requête HTTP contenant un message SOAP. Dans celui-ci, on trouve en XML la valeur 10. Le service réceptionne la requête et interpréter le message. Il calcule la factorielle du nombre 10, et il renvoie une réponse contenant les résultats de la factorielle 10.

L'image ci-dessous met en évidence les échanges de message entre clients services.

évidence les échanges de message entre clients services. J'ai ainsi créé un fichier client.php contenant le

J'ai ainsi créé un fichier client.php contenant le code client permettant d'envoyer et recevoir des requêtes au service de factorisation service.php. Ce dernier est aussi un fichier à programmer

Le code PHP du client: En vert le code en PHP en rouge la partie requête en XML qui sera envoyée au service, en jaune (optionnel) affiche dans le navigateur web les messages envoyés et reçus

<?php

$requestPayloadString = <<<XML

<getFactorial>

<param>10</param>

</getFactorial>

XML;

Sécurisation de web service

2012/2013

$client = new WSClient(array("to" => "http://localhost/facto/service.php"));

$response = $client->request($requestPayloadString);

$simplexml = new SimpleXMLElement($response->str);

echo "Result = ".$simplexml->result[0]."<br/>";

printf("<br/> Request = %s </br>", htmlspecialchars($client->getLastRequest()));

printf("<br/> Response = %s </br>", htmlspecialchars($client->getLastResponse()));

?>

Pour le service en PHP : En vert le code en PHP, en rouge la réponse en XML qui sera envoyée au client.

<?php

function factorial($number) { if ($number == 0) return 1; return $number * factorial($number - 1);

}

function getFactorial($message) {

$simplexml = new SimpleXMLElement($message->str); $value = $simplexml->param[0];

$result = factorial($value);

$responsePayloadString = <<<XML

<getFactorialResponse>

<result>$result</result>

</getFactorialResponse>

XML;

$outMessage = new WSMessage($responsePayloadString);

return $outMessage;

}

$service = new WSService(array("operations" => array("getFactorial")));

$service->reply();

?>

En exécutant le client dans un navigateur, on obtient le résultat suivant :

Result = 3628800

Request =

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-

envelope"><soapenv:Body><getFactorial> <param>

10

</param>

 

</getFactorial></soapenv:Body></soapenv:Envelope>

 

Sécurisation de web service

2012/2013

Response =

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-

envelope"><soapenv:Body><getFactorialResponse> <result>

3628800

</result>

 

</getFactorialResponse></soapenv:Body></soapenv:Envelope>

 

La réponse du service donne le résultat de la factorielle 10 qui est 3628800.

En jaune, on peut remarquer la requête envoyée du client au service. Le message contient une enveloppe SOAP constituée de balise XML avec la valeur 10.

En rouge, la réponse du service qui utilise également le standard SOAP. On peut voir le résultat dans la réponse reçue par le client.

Concernant la sécurité de cet échange entre client service, rien ne prouve que le service, ou client contacté soit bien le bon. Les messages peuvent être écoutés et lu par une personne extérieure en écoutant le canal de transmission avec un outil comme tel que Wireshark. Enfin, le service ne demande pas d'authentification au client. Il est donc important de sécuriser ses échanges. C'est pour cette raison que le projet porte sur des tests de sécurité

3.2.2. Tests de sécurité

Les

confidentialité.

trois

critères

de

sécurité

reposent

sur

la:

disponibilité,

critères de sécurité reposent sur la: disponibilité, l'intégrité et la Source de l'image Wikipedia.org

l'intégrité

et

la

Source de l'image Wikipedia.org

La disponibilité : Vise à rendre le plus disponible et fonctionnel le système informatique. Il est possible de calculer la disponibilité en pourcentage sur une période définie. Pour assurer la disponibilité, plusieurs moyens peuvent être combinés tels que la sauvegarde, redonder les équipements, et enfin prévoir un plan de reprise d'activité (PRA).

Intégrité : a pour objectifs de garder les données intactes que ce soit dans une transmission, dans un stockage ou encore de leur traitement. L'intégrité vise à s'assurer que les données n’ont pas été altérées (modifiées) par un pirate ou une erreur de traitement. Afin de permettre une intégrité des données pendant les échanges, il faut utiliser une fonction de hachages tels que MD5 (Message Digest 5) et des certificats à clef

Sécurisation de web service

2012/2013

publique et privée. Ces derniers prouvent l'identité des deux correspondants par exemple entre client et service. La fonction de hachage permet de donner une empreinte unique à une donnée, si la donnée a été modifiée l'empreinte changera aussi. On peut ainsi prouver que la donnée n'a pas été corrompue. Cette section de sécurité permet de se prémunir de la célèbre attaque de l'homme du milieu.

La confidentialité : a pour but de rendre accessible l'information uniquement aux personnes autorisées et authentifiées. La confidentialité peut être associée aux données d'un système d'information, et aussi aux messages transmis entre entités. Pour rendre cette confidentialité possible, il faut chiffrer les données et messages avec un algorithme de cryptographie tel que RSA (Rivest Shamir Adleman). Il y a deux possibilités : soit d'utiliser un secret partagé (dit symétrique), ou le système de certificats à clef publique et clef privée (dit asymétrique).

Enfin, sur les données stockées dans le système d'information, il faut utiliser des pare- feu pour bloquer les éventuelles intrusions.

De plus l'authenticité est primordiale dans la sécurité car elle vise à vérifier la bonne identité d'une personne. C'est pour cette raison que j'ai décidé d'utiliser le système de certificat X509 pour les tests du web service. Dans cette étude, le critère de disponibilité ne sera pas utilisé, pour la raison que les options ne dépendent pas directement du web service, mais plutôt du système mit en place autour (tel qu’un serveur de sauvegarde).

3.2.3. Fonctionnement des certificats

Utilité : pour identifier une ressource, chiffrer les données échangées entre deux entités.

Le certificat doit être signé par un tiers de confiance tel que « verising » pour prouver la valeur sûre de l’identité de celui qui possède le certificat. Le tiers de confiance permet de révoquer un certificat si l'utilisateur du certificat est frauduleux, ou encore s’il a été victime d'un piratage. Un certificat révoqué par une autorité, n'est plus validé auprès des navigateurs web, ou autres outils qui vérifient le tiers de confiance. Dans le cas de notre web service, nous allons utiliser des certificats auto-signés pour des raisons de simplicité et de prix.(un certificat signé par un tiers à un coût).

Notre client et service possèdent chacun une paire de clefs publique et privée.

Si le client envoie un message chiffré (avec le couple clef publique du service et clef privée du client) au service, celui-ci est sûr que c'est le client qui a envoyé le message, car le service connaît la clef publique du client et peut déchiffrer le message avec le couple clef publique du client et clef privée du service

Sécurisation de web service

2012/2013

Sécurisation de web service 2012/2013 Dans l’image ci - dessus le client et service s’échange nt

Dans l’image ci-dessus le client et service s’échangent des messages chiffrés avec la clé publique du client et du service (selon le sens des requêtes). Le pirate peut écouter les messages chiffrés échangés. Il connait les clefs publiques du client et service. Seulement pour déchiffrer les messages, il lui faut au moins une clef privée qu’il ne possède pas.

Pour créer les certificats, j'ai utilisé Openssl. Dans un premier temps, on génère un

certificat non signé.csr et une clé privée.pem

permettre d’ « auto-signer » le certificat .crs. Quand celui-ci est signé par le certificat

d’autorité, il obtient comme extension « .crt ».

Puis on crée un certificat ca.crt qui va

L’utilitaire Keytool permet de créer des « keystore ». Un keystore permet de contenir plusieurs certificats et clefs privées. C'est en quelque sorte un coffre contenant des certificats. Le keystore permet une gestion simplifiée des certificats. WSO prend en charge les keystore au format p12. J'ai donc décidé de créer un keystore pour le client et un pour le service.

Sécurisation de web service

2012/2013

Ci-dessous un schéma rassemblant clef privée, certificat (clef publique) et le keystore.

clef privée, certificat (clef publique) et le keystore. Ci-dessous le certificat client.crt généré (clef

Ci-dessous le certificat client.crt généré (clef publique) :

Ci-dessous le certificat client.crt généré (clef publique) : Ci-dessous la clef privée client.key : Gaëtan TURCAS

Ci-dessous la clef privée client.key :

Ci-dessous le certificat client.crt généré (clef publique) : Ci-dessous la clef privée client.key : Gaëtan TURCAS

Sécurisation de web service

2012/2013

Pour chacun des tests suivants, le client va envoyer hello au service, celui-ci doit répondre se qu'il reçoit à laide de la fonction « echo ». Seules les options de sécurité WS-Security changent. Sauf pour le premier test, les réponses affichées ne sont pas complètes à cause de leurs longueurs.

3.2.4. Test 1 aucune sécurité

Le premier test doit permettre de comparer un test sans sécurité et un avec sécurité.

Response =

<ns1:echoString

 

xmlns:ns1="http://wso2.org/wsfphp/samples"><text>Hello</text></ns1:echoString>

Request =

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-

 

envelope"><soapenv:Body>

<ns1:echoString

 

xmlns:ns1="http://wso2.org/wsfphp/samples"><text>Hello</text></ns1:echoString>

</soape

nv:Body></soapenv:Envelope>

 

Response =

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-

 

envelope"><soapenv:Body>

<ns1:echoString

 

xmlns:ns1="http://wso2.org/wsfphp/samples"><text>Hello</text></ns1:echoString>

</soape

nv:Body></soapenv:Envelope>

 

Ici on peut voir que les deux requêtes échangées (rouge requête client ->service et en vert réponse du service ->client) ne possèdent pas de champs d'authentification. Les messages circulent en claire, ce qui induit que n'importe quel client peut communiquer avec le service se faisant passer pour n'importe qui.

3.2.5. Test 2 Authentifications

Authentification par login et mot de passe (mode digest pour le mot de passe c'est-à-dire qu'il doit être chiffré) : Pour des raisons de longueur et pour faciliter la compréhension, Le client et le service utilise les certificats pour s’authentifier en plus du login et mot de passe.

Rappel, à partir de ce test, les requêtes présentées sont des extraits.

Dans la requête envoyée par le client on retrouve le login Gaetan (en vert) et le mot de passe chiffré (en rouge) qui était « secure »:

<wsse:Username>

open.org/wss/2004/01/oasis-200401-wss-username-token-profile-

1.0#PasswordDigest">

></soapenv:Header><soapenv:Body><ns1:echo xmlns:ns1="http://wso2.org/wsfphp/samples

xmlns:ns1="http://wso2.org/wsfphp/samples gaetan</wsse:Username><wsse:Password

gaetan</wsse:Username><wsse:Password Type="http://docs.oasis-

</wsse:Password>

fSAOwuJcTvggljQlZkABnx01dlk=

</wsse:Password> fSAOwuJcTvggljQlZkABnx01dlk=

World!</text></ns1:echo></soapenv:Body></soapenv:Envelope>

"><text>Hello

Sécurisation de web service

2012/2013

Dans la requête et la réponse on peut voir en claire le message hello (en jaune).

3.2.6. Test 3 Chiffrements

Dans ce test, on va chiffrer les données envoyées au service. Mise en place des certificats sur le client et service. Le client connait la clef publique du service, et le service connait la clef publique du client.

Dans le message envoyé au service on ne peut plus voir le texte hello : il y a, à la place la clef du certificat généré avec RSA(en vert) puis suivi du texte chiffré (en rouge) avec l'algorithme AES-256 (Advanced Encryption Standard) :

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><ds:KeyInfo

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><wsse:SecurityTokenReference

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-

1.0.xsd"><ds:X509Data><ds:X509IssuerSerial><ds:X509IssuerName>

C=fr, ST=normandie, L=caen,

O=Internet Widgits Pty

 

Ltd</ds:X509IssuerName><ds:X509SerialNumber>1</ds:X509SerialNumber></ds:X509IssuerSerial></ds:X5

09Data></wsse:SecurityTokenReference></ds:KeyInfo><xenc:CipherData><xenc:CipherValue>NooJg72e1ea

eoiFySOGSdHbhKEcFiaNOXapsrFfpqcTdwyQhBHn9Vx5sB9UBbQsgGUm7my61hWX7RfiaU9Xfbw==

</xe

nc:CipherValue></xenc:CipherData><xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:DataReference URI="#EncDataID-cc4bccae-80fd-

1e21-3173"/></xenc:ReferenceList></xenc:EncryptedKey><xenc:EncryptedData

Type="http://www.w3.org/2001/04/xmlenc#Content" Id="EncDataID-13564786-80fa-1e21-30d6"

xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-

cbc"/><xenc:CipherData><xenc:CipherValue>

C5xe8BqGutF3pAUOjUK3wh0O5MoscJOSIrSadTYlQ1JC+1/z

SNPTUwyfOmWRYcQDwRQqeUtV3TZOdufTxIYGyTRBpE/4G0b1VCB17G0cDVdtadkwc2VbKlgZG69f7

GZOQbTSGmszAnqp54iFroiFBg==

</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData>

Ainsi, on peut dire que le chiffrement est efficace, car le message « HELLO » ne circule plus en claire.

Dans la réponse on peut également remarquer les informations sur le certificat en vert, mais il y a dans la réponse le texte en claire ( en rouge) .

<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/><ds:KeyInfo

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><wsse:SecurityTokenReference><ds:X509Data><ds:X509I

ssuerSerial><ds:X509IssuerName>

C=fr, ST=normandie, L=caen, O=Internet Widgits Pty

 

Ltd</ds:X509IssuerName><ds:X509SerialNumber>1</ds:X509SerialNumber></ds:X509IssuerSerial></ds:X5

09Data></wsse:SecurityTokenReference></ds:KeyInfo><xenc:CipherData><xenc:CipherValue>0aM2VbK2O

OP4D7JFAAEOpFlV/x60P8y76fGtBI4q5vX8pm5DBWHBFn1HruEMjjJSdvBaOU8/HIhvqxvdh+5y+g==

</xe

nc:CipherValue></xenc:CipherData><xenc:ReferenceList><xenc:DataReference URI="EncDataID-cc51dee6-

80fd-1e21-

3121"/></xenc:ReferenceList></xenc:EncryptedKey></wsse:Security></soapenv:Header><soapenv:Body><n

s1:echo xmlns:ns1="http://wso2.org/wsfphp/samples">

<text>Hello

World!</text>

</ns1:echo></soapenv:Body></soapenv:Envelope>

La confidentialité des messages transmis entre client et service est compromise si le message circule en claire dans la réponse.

Sécurisation de web service

2012/2013

J'ai abouti à deux hypothèses sur la question : pourquoi dans la réponse le message n'est pas chiffré ?

1. WSO à un problème de chiffrement dans la réponse du service. Dans le code du service il y a bien le chiffrement d'activé.

2. Le client déchiffre directement le message dés la réception donc le chiffré non visible à cet instant.

Solution possible pour vérifier la deuxième hypothèse : on peut regarder les échanges avec Wireshark qui va capturer toutes les trames IP échangées.

On peut voir sur la capture avec wireshark que la réponse du service capturé est en claire contrairement à la requête du client.

est en claire contrairement à la requête du client. L'hypothèse numéro deux concluante. Il y a

L'hypothèse numéro deux concluante. Il y a donc potentiellement un problème de sécurité au niveau de la plate-forme WSO.

3.2.7. Test 4 Signatures avec les certificats

Rappel : la signature permet de vérifier la bonne identité d'un client ou d'un service.

En jaune la signature créée avec le certificat. De plus, on remarque en rouge que le message est envoyé en claire ce qui est normal, car l'option de chiffrement n'est pas activée.

<ds:Signature Id="SigID-f010797c-8112-1e21-3171"

 

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod

 

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod

 

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#SigID-f00e9102-8112-

 

1e21-3170"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-

 

c14n#"/></ds:Transforms><ds:DigestMethod

 

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>NxMzh4WZhwYyEVTvxGS6eskd

9Bg=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>FRjcLX0z9jKorXzZu4rXw/OL

LFtgiraKH2l22PpCVTGKuqcdUeYnSKUd+5XZHlNccRIayuGWLgeoFGerZXSHR/fEyRX3aAIyK0wLIEyhl

4JeMKzjS3dguzrouY7p9lndtlupZCBoXKEoZOMVlwWJ/IBlBACbBKaJxcDRVgTsXkc=</ds:SignatureValue

> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-

 

1.0#X509v3"/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature>

</wsse:Security></soapenv:He

ader><soapenv:Body wsu:Id="SigID-f00e9102-8112-1e21-3170" xmlns:wsu="http://docs.oasis-

open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><ns1:echo

xmlns:ns1="http://wso2.org/wsfphp/samples">

<text>Hello

World!</text>

</ns1:echo></soapenv:Body></soapenv:Envelope>

La réponse contient également la signature.

Sécurisation de web service

2012/2013

3.2.8. Test 5 Temps de validité d'un message

L'option timestamp permet de définir une heure de validité de la requête envoyée. J'ai programmé une valeur de 60 secondes de validité.

Dans la requête envoyée au service, on peut voir en jaune l'option de date de validité. Ici la requête expire le 2013-02-28 à 13:46:53. En rouge le message est transmis en claire ce qui est normal, car l'option de chiffrement n'est pas activée

<wsu:Timestamp wsu:Id="SigID-2b6e5198-81ad-1e21-3bda" xmlns:wsu="http://docs.oasis-

 

open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsu:Created>2013-02-

28T13:45:53.230Z</wsu:Created><wsu:Expires>2013-02-

 

28T13:46:53.231Z</wsu:Expires></wsu:Timestamp

 

xmlns:ns1="http://php.axis2.org/samples"><

text>Hello

 

World!</text>

</ns1:echo></soapenv:Body></soapenv:Envelope>

></soapenv:Header><soapenv:Body><ns1:echo

Il y a la même option dans la réponse du serveur.

Cette option de sécurité permet d'éviter qu'un pirate puisse rejouer des messages envoyés au service ou au client.

3.2.9. Problèmes rencontrés

Au début des tests je devais tester la plate-forme avec un logiciel open source SoapUI. Celui-ci permet de tester les web service. Malheureusement, il semble que la version de java utilisée par SoapUi pour la gestion des keystores soit incompatible avec la version des keystores créés pour WSO. J'ai passé beaucoup de temps à corriger ce problème, mais sans succès. Cependant, j'ai testé le logiciel SoapUI sur un autre web service mit a disposition par le tutoriel du logiciel.

Pour utiliser un service avec SoapUI, il suffit d'utiliser le format WSDL généré par un service avec une URL de ce type : http://monwebservice.com/service.php?WSDL

URL de ce type : http://monwebservice.com/service.php?WSDL Une fois le service chargé on peut configurer les options

Une fois le service chargé on peut configurer les options de sécurité associées aux requêtes envoyées au service. Une fois correctement configuré, on peut notamment faire des tests de sécurité poussés comme un test de charge de requête d'authentification.

Sécurisation de web service

2012/2013

Vous pouvez voir dans l'image ci-dessous l’interface graphique de SoapUI

3 4 2 1
3
4
2
1

1 la gestion des différents projets en arborescence

2 La requête envoyée au service

3 L'URL du service

4 La réponse du service ici on peut voir une erreur de signature.

C'est pourquoi à cause de ces incompatibilités, et en accord avec mon tuteur, j'ai fait les tests de sécurité (montrés précédemment) en me basant sur les requêtes échangées visibles dans le navigateur web, et dans Wireshark.

Sécurisation de web service

2012/2013

3.3. Mise à jour de sécurité de la plate-forme

Le but est de mettre à jour les bibliothèques de sécurité WS-security. WSO utilise OpeSSL pour gérer la sécurité.

Au moment de la compilation du web service, celui-ci va chercher les modules et bibliothèques nécessaires. Notamment les bibliothèques Openssl. La solution sur un système déjà installé, est de mettre a jour Openssl, puis de recompiler le web service avec les nouveautés de OpenSSL.

traitée assez

Cette partie, validée par mon tuteur Christophe Turbout, a donc été rapidement.

3.4. Intégrer du CDATA

Le CDATA (Caratere DATA) permet de définir une chaîne de caractère dans du XML qui sera interprétée uniquement comme du texte. Le CDATA commence une balise (en vert dans l'exemple ci-dessous). À l’intérieur on retrouve du texte pouvant contenir des symboles tels que « < > & ». En XML ces symboles ont une signification bien particulière comme une balise « <ma balise> », si celle-ci n'est pas fermée on a une erreur dans le code XML. Le CDATA ne doit pas interpréter les balises et symboles comme du XML (en jaune).

<body> Dans le body

 

<![CDATA[

Du texte dans le Cdata avec une fausse balise <fausse balise non fermée> & encore du texte

]]>

 

</body>

 

Par défaut, WSO ne gère pas correctement le CDATA. En effet, certain caractères comme « < ,>, & » sont quand même interprétés et peuvent provoquer des erreurs. WSO utilise une mauvaise bibliothèque XML qui pose problème avec le CDATA. La solution consiste à compiler le web service avec une option prenant en compte la dernière version

libxml2.

Test sur la plate-forme à partir de l’exemple de la factorielle. On va inclure du CDATA dans le XML et vérifier le comportement. Dans le CDATA nous allons mettre une balise non fermée, ainsi le CDATA est malgré tout interprété, mais nous allons avoir une erreur.

Le client envoie le XML

Le service envoie du XML

 

<getFactorial>

<getFactorialResponse> <![CDATA[le CDATA envoye par le

<param>10</param>

<![CDATA[le CDATA envoye par le client avec

service avec

<balise non fermee>

suivis du

Sécurisation de web service

2012/2013

<balise non fermee>

suivis du symbole & un

symbole & un chiffre 3 ]]> <result>$result</result>

chiffre 3 ]]> </getFactorial>

</getFactorialResponse>

En jaune ci-dessus la balise qui devrait provoquer une erreur XML si le CDATA n'est pas pris en compte.

On exécute le client et on obtient le résultat ci-dessous :

Result = 3628800

Request = <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap- envelope"><soapenv:Body><getFactorial> <param>10</param> le CDATA envoye par le

client avec

</getFactorial></soapenv:Body></soapenv:Envelope>

&lt;
&lt;

balise non fermee

&gt;
&gt;

suivis du symbole

&amp;
&amp;

un chiffre 3

Response = <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap- envelope"><soapenv:Body><getFactorialResponse> le CDATA envoye par le service avec

&lt;
&lt;

balise non fermee

&gt;
&gt;

suivis du symbole

&amp;
&amp;

un chiffre 3 <result>3628800</result>

</getFactorialResponse></soapenv:Body></soapenv:Envelope>

On remarque donc dans un premier temps qu'il n'y a pas d'erreur. En regardant plus en détails les messages échangés, on peut voir que les caractères spéciaux <, > et & ont été remplacés automatiquement par des codes (en jaune) pour ne pas être interprétés.

Maintenant, si on remplace le XML du client en enlevant l’entête <![CDATA[

<getFactorial>

<param>10</param>

Le CDATA envoye par le client avec </getFactorial>

<balise non fermee>

suivis du symbole & un chiffre 3

En exécutant dans un navigateur, on obtient une page vide.

Dans les logs du web service on peut voir l'erreur qu'il n'arrive pas à lire le XML, car le XML a une balise non fermée.

Extrait d'un fichier de log du web service.

[Thu Feb 28 11:32:29 2013] [error] libxml2_reader_wrapper.c(954) Specification mandate value for attribute non -- SEVERITY_ERROR [Thu Feb 28 11:32:29 2013] [error] libxml2_reader_wrapper.c(954) attributes construct error -- SEVERITY_ERROR [Thu Feb 28 11:32:29 2013] [error] libxml2_reader_wrapper.c(954) Couldn't find end of Start Tag balise -- SEVERITY_ERROR

Gaëtan TURCAS 28
Gaëtan TURCAS
28

Sécurisation de web service

2012/2013

[Thu Feb 28 11:32:29 2013] [error] libxml2_reader_wrapper.c(443) error occurred in reading xml stream

Le CDATA a bien rempli sa fonction de ne pas interpréter le contenue du CDATA.

L’objectif du projet d'intégrer du CDATA est donc réussi et fonctionnel grâce aux options de compilation du web service.

3.5. Conclusion des quatre objectifs

L'installation de la plate-forme est assez lourde à mettre en place, notamment à cause de ses pré-requis pour la compilation et une documentation pas assez détaillée. Cependant, une fois correctement configurée, la plate-forme est opérationnelle.

Le deuxième objectif était le plus long à réaliser. Les tests de sécurités ont été réalisés un à un permettant de vérifier chaque option de sécurité. J'ai cependant relevé un problème qui demande un approfondissement sur le chiffrement du message contenu dans la réponse du service.

Les mises à jour de sécurité des bibliothèques ws-security repose sur OpenSSL. La solution trouvée est très simple : il suffit de compiler de nouveau le web service avec les dernières mises à jour d’OpenSSL.

Enfin, le dernier objectif, d'intégrer du CDATA a été réussi en important la bibliothèque libxml2 à l'installation de la plate-forme.

4. Déroulement du projet

Le projet a été réalisé sur la période universitaire de fin octobre 2012 à début mars 2013 soit 18 semaines afin de répondre aux quatre objectifs. Sur cette durée il y a eu 3 soutenances : une en anglais pour présenter le projet, une à mi parcours et enfin, une soutenance finale.

Dans la page suivante, un diagramme de Gant sur le découpage et répartitions des différentes tâches en fonction du temps.

Sécurisation de web service

2012/2013

Sécurisation de web service 2012/2013 Gaëtan TURCAS 30

Sécurisation de web service

5. Conclusion

2012/2013

WSO2 Framework for PHP est une solution de web service permettant d'améliorer les performances des serveurs web. Dans ce projet universitaire de 18 semaines, j'ai dû réaliser quatre objectifs : installer la plate-forme WSO2 Framework for PHP, la tester, mettre à jour les bibliothèques de sécurité et enfin intégrer du CDATA.

Je peux dire que ce projet de sécurisation de web service a été très enrichissant. En effet, grâce à celui-ci, j'ai pu maîtriser de nombreuses technologies utilisées dans le domaine de la sécurité et des web service très utilisées dans le monde professionnel.

De plus, le projet m'a permit d’acquérir de nombreuses connaissances en matière de programmation informatique. En effet, venant d’un cursus orienté Système et réseaux, j'avais quelques lacunes en programmation. Cependant, J'ai su les surmonter et développer au maximum mes connaissances afin de mener à bien ce projet. Le web service installé est fonctionnel, et amélioré.

Enfin, il reste un point de sécurité à approfondir, afin de déterminer pourquoi la réponse du service n'est pas chiffrée. Néanmoins, ce projet, m'a permis de comprendre l’intérêt des technologies autour des web service et d’assimiler son importance au sein du monde professionnel.

Sécurisation de web service

6. Glossaire

2012/2013

HTTP (Hypertext Transfer Protocol) : est un protocole de navigation internet.

HTTPS (Hypertext Transfer Protocol secure) : est un protocole de navigation internet sécurisée.

SOA (Service Oriented Architecture) : L’architecture orientée service représente un moyen technique d’intégration des divers systèmes d’information de l’entreprise considérant chaque ressource informatique comme un service.

SOAP (Simple Object Access Protocol) : Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur.

WSDL (Web Services Description Language) : décrit une Interface publique d'accès à un Service Web.

XML (Extensible Markup Language) : est un langage informatique de balisage.

Open SSL (Secure Layer Security): Est un module utilisé pour la création de certificat. Il permet de générer des clés de chiffrements

VirtualBox : Est un logiciel qui permet de lancer sur un système d’exploitation d’autres systèmes.

URL (Uniform Ressource Locator): Est une adresse internet de type http://google.com qui pointe vers une page web.

Pare-feu: Celui-ci permet d’appliquer des règles de filtrage sur le trafic entrant et sortant d’un réseau.

WS-* : reposent tous sur un ensemble de protocoles et de standards de base utilisées pour l'échange de données entre applications dans des environnements divers. C’est une liste de spécification liée au web service.

Certificat X509 : il est comme une carte d'identité numérique. Il est utilisé principalement pour identifier une ressource, mais aussi pour chiffrer des échanges.

Sécurisation de web service

2012/2013

Apache : Serveur Web le plus utilisé actuellement.

PHP (Hypertext Preprocessor) : est un langage programmation principalement utilisé pour produire des pages Web dynamiques via un serveur http.

CDATA (Caratere DATA) : permet d'indiquer à l'analyseur de ne pas interpréter les caractères contenu dans la section CDATA.

7. Bibliographie

Sites consultés :

Sécurisation de web service

8. Annexe

2012/2013

Installation de la plateforme WSO

1. Installation de la distribution linux Debian avec interface graphique.

2. Ajout des sources liste:

On ajoute les sources listes suivantes dans le fichier /etc/apt/sources.liste :

deb http://ftp.fr.debian.org/debian stable main contrib non-free deb-src http://ftp.fr.debian.org/debian stable main contrib non-free

deb http://ftp.debian.org/debian/ squeeze-updates main contrib non-free deb-src http://ftp.debian.org/debian/ squeeze-updates main contrib non-free

deb http://security.debian.org/ squeeze/updates main contrib non-free deb-src http://security.debian.org/ squeeze/updates main contrib non-free

3. Installation des modules nécessaires:

Module build-essential:

apt-get install build-essential

Serveur Web apache:

apt-get install apache2

Le module PHP5 et PHP en mode dev et xsl:

apt-get install php5 php5-dev php5-xsl

Des bibliothèques, et le mode axis2c pour apache :

apt-get install libaxis2c-dev libaxis2c-doc librampart-dev libaxis2c-bin libapache2-mod- axis2c libxml2-dev

4. Téléchargement de la plate-forme WSO2 framework for php depuis le site officiel.

5. Compilation WSO

Dans le dossier source de wso2for php téléchargé précédemment :

./configure ( ajouter les options si erreur) make make install

Sécurisation de web service

6. Configuration de PHP

2012/2013

Dans le fichier /etc/php/conf/php.ini il faut ajouter les lignes suivantes afin d’intégrer le web service :

[wsf] extension=wsf.so extension=xsl.so

extension_dir="/usr/lib/php5/20090626+lfs/"

include_path = ".:/home/wso2-wsf-php-src-2.1.0/scripts/"

wsf.home="/usr/lib/php5/20090626+lfs/wsf_c/"

wsf.log_level=5

7. Test PHP

Pour vérifier si les modules installés sont bien activés on peut créer dans le serveur web (/var/www/) un fichier test.php qui contient :

<?php

phpinfo();

?>

En accedant à la page dans un navigateur web, on a des informations sur les modules PHP modules activés.

8. Exemples fournis par WSO

Pour accéder aux exemples fournis par WSO il faut créer un Lien symbolique :

ln -s /home/wso2-wsf-php-src-2.1.0/samples /var/www/samples

A partir de maintenant la plate-forme est opérationnelle.

9. Fichiers de logs

Il est possible de consulter les logs du web service :

/tmp/wsf_php_server.log pour la partie serveur et /tmp/wsf_php_client.log pour la partie client.