Rapport du projet de fin d'études ASR Application pour Firefox OS de gestion d'amis - Sujet
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Rapport du projet de fin d’études ASR
Sujet :
Application pour Firefox OS de gestion d’amis
WebID
Réalisé par :
Ghada Mhiri
Amna Bouzakoura
Encadrant :
M.Olivier Berger
Année universitaire : 2013/2014
Rapport du projet de fin d’études ASR
Avant Propos
Le présent travail a été élaboré dans le cadre de notre projet de
troisième année d'Ingénieur le long de la voie d’approfondissement
Architecture de Services informatiques en Réseaux (ASR) à Télécom
SudParis (membre du Groupe Institut Mines-TELECOM).
Ce projet consiste à développer une application pour Firefox OS
pour se lier à des contacts WebID durant la période allant du 04
octobre 2013 au 28 janvier 2014.
page 2
Rapport du projet de fin d’études ASR
Remerciements
Nous tenons à adresser nos vifs remerciements à notre encadrant
Mr Olivier Berger, ingénieur chercheur à Télécom SudParis, pour son
suivi, ses précieuses directives et sa disponibilité tout au long de la
réalisation de ce projet.
Nous souhaitons transmettre également l’expression de notre
reconnaissance à Mr Andrei Vlad Sambra, actuellement architecte de
Web Sémantique au sein de MIT, pour son aide et ses valeureux
conseils.
Nous tenons également à exprimer toute notre gratitude à tous
ceux qui ont contribué de près ou de loin pour accomplir ce projet dans
les meilleures conditions spécialement nos amis Mohamed Amine
Bouassida, et Dorra Ben Jemâa.
Nous voudrons finalement remercier tous les membres du jury qui
ont bien voulu accepter d’évaluer ce modeste travail.
page 3
Rapport du projet de fin d’études ASR
Table des matières :
Liste des figures ........................................................................................................................ 5
Introduction générale ............................................................................................................... 6
Chapitre 1 : Etat de l’art ......................................................................................................... 7
I.1.Web Identity and Discovery (WebID): ............................................................................. 7
I.2 .Protocole SSL/TLS : ........................................................................................................ 8
I.3.WebID -TLS : ................................................................................................................... 9
I.4. WebID-TLS : Authentification déléguée : ..................................................................... 13
I .5 . Firefox OS :.................................................................................................................. 14
I .6. Resource Description Framework (RDF): .................................................................... 16
I .7. L’ontologie FOAF : ...................................................................................................... 17
I .8.Web Social Distribué: .................................................................................................... 17
Chapitre 2: Etude et Réalisation du Projet .......................................................................... 18
II.1.Etude théorique du Projet : ............................................................................................ 18
II.1.1. Présentation du projet : .......................................................................................... 18
II.1.2. Les étapes de réalisation du projet : ....................................................................... 19
II.1.3. Les outils utilisés : ................................................................................................. 20
II.2.Etude pratique du Projet : .............................................................................................. 21
II.2.1. Etude de faisabilité : .............................................................................................. 21
II.2.2. Préparation de l’environnement du travail : .......................................................... 22
II.2.2.1 Installation des composants requis: ................................................................. 22
II.2.2.2 Problèmes rencontrés lors de la préparation de l’environnement:................... 23
II.2.3. Travail réalisé et problèmes rencontrés: ................................................................ 24
II.2.4.Perspectives futures: ............................................................................................... 27
Conclusion générale.............................................................................................................................. 30
Références ............................................................................................................................................. 31
page 4
Rapport du projet de fin d’études ASR
Liste des figures
Figure 1:Exemple de WebID et relation entre WebID et document Profile .............................. 8
Figure 2 : Exemple de certificat sous format x509 .................................................................. 10
Figure 3 : Diagramme de séquence illustrant le principe WebID-TLS ................................... 11
Figure 4 : Exemple d'authentification déléguée ....................................................................... 13
Figure 5 : Exemple de Smartphone Firefox OS ....................................................................... 15
Figure 7:Exemple de RDF/TURTLE ....................................................................................... 16
Figure 6 : Exemple de graphe RDF .......................................................................................... 16
Figure 8 : Exemple de la partie utilisant l’ontologie foaf dans un profil WebID écrit en Turtle..
.................................................................................................................................................. 17
Figure 9 : Le problème d'interopérabilité entre les différents réseaux sociaux ........................ 18
Figure 10 : Diagramme de séquence illustrant les étapes de l'application ............................... 20
Figure 11: Diagramme de séquence de l'authentification avec le serveur local....................... 24
Figure 12: Diagramme de séquence de l'authentification déléguée ......................................... 25
Figure 13: Représentation graphique de la structure de la base de donnée « WebID-friend » 26
Figure 14:Diagramme de séquence du mécanisme d'ajout d'ami ............................................. 26
Figure 15: Simulation de l'application avec JQuery Mobile .................................................... 28
Figure 16: Diagramme de séquence du scénario futur de l'application.................................... 29
page 5
Rapport du projet de fin d’études ASR
Introduction générale
Ces dernières années ont été sans doute marquées par une omniprésence des
applications web mobiles dont le nombre ne cesse de s’accroître à haute cadence dans le
monde, et surtout celles dites « applications web social ». Cette augmentation est fortement
liée, en général, au nombre de Smartphones en cours d'utilisation dans le monde qui a dépassé
un milliard [1], et en particulier, à la volonté des utilisateurs de se rattacher aux réseaux
sociaux.
Certes, le web social offre aux utilisateurs l’opportunité de créer leurs profils
personnels où ils peuvent gérer des listes d’amis, poster des photos, des statuts, etc.
Mais, la pratique commune de la majorité des sites web ou applications qui offrent de tels
services est la centralisation des ressources des utilisateurs. Et par ce fait, la vie privée de ces
derniers s’échappe totalement de leur contrôle.
En outre, ce type de services offert ne permet pas en général l’interopérabilité entre les
différents réseaux sociaux. Autrement dit, les membres de deux réseaux sociaux distincts ne
peuvent ni communiquer ni partager des données entre eux.
Dans ce contexte, développer une application web social décentralisée s’avère utile voire
même indispensable pour remédier aux problèmes mentionnés ci-dessus permettant ainsi aux
utilisateurs de choisir où stocker leurs données et avec qui les communiquer et partager.
C’est dans ce cadre que se déroule notre projet intitulé « Application Firefox OS pour
se lier à des contacts WebID » qui fera l’objet du présent rapport composé principalement de
deux chapitres : Le premier sera dédié à un « Etat de l’art » dans lequel nous avons résumé
toutes nos recherches bibliographiques, quant au second chapitre, il sera entièrement réservé
au travail effectué et aux obstacles rencontrés lors de la réalisation de ce projet.
page 6
Rapport du projet de fin d’études ASR
Chapitre 1 : Etat de l’art
Dans ce premier chapitre, nous allons définir les concepts de base de notre projet ainsi que leurs états
d’évolution à l’instant de rédaction de ce rapport.
I.1.Web Identity and Discovery (WebID):
Le WebID est une URI qui fait référence à un agent (Personne, Organisation, Groupe,
périphérique, etc.). Le terme WebID a été inventé par Dan Brickley et Tim Berners-Lee en
2000 [2] et a été standardisé dans sa version 1.0 par le World Wide Web Consortium (W3C)
en décembre 2011[3].
Mis à part le WebID en tant que URI, ce dernier fait référence à un protocole qui permet une
authentification de son possesseur sans avoir recours à un login et mot de passe grâce à un
certificat géré par le protocole de sécurité SSL/TLS, et l’accès aux informations de
l’utilisateur avec l’ontologie FOAF (Friend Of A Friend).
Par ce fait, utiliser un WebID contribue à la constitution d’un « web de confiance » où chaque
utilisateur est libre de choisir à qui donner accès pour voir ses propres ressources
(publications, photos ou autres).
Un WebID est toujours associé à un profil de « réseau social » appelé « document profile »
dans lequel on trouve l’identité Web d’un acteur, la liste d’amis avec un contrôle d’accès, le
certificat d’authentification,…
Ce document est, donc, une ressource web qui doit être écrite en format text/turtle , même si
dans certains cas , elle peut être écrite sous un autre format comme le RDFA-CORE ce qui
n’affecte pas l’affichage du profil.
page 7
Rapport du projet de fin d’études ASR
Figure 1:Exemple de WebID et relation entre WebID et document Profile
Source : W3C Editor'sDraft 21 January 2014
Cette figure contient un exemple de WebID qui est « http://www.w3.org/People/Berners-
Lee/card#i » (contenant #i hash tag) qui réfère à Tim Berners Lee, l’inventeur du World Wide
Web et le directeur du World Web Consortium (W3C). [4]
Quant au document profile, son URI correspondante est "http://www.w3.org/People/Berners-
Lee/card" (sans #i hash tag) qui pointe sur le profil de la personne ou en général de l’agent
possesseur du WebID.
I.2 .Protocole SSL/TLS :
On vient de voir dans la définition du WebID ci dessus que celui-ci utilise le protocole
SSL/TLS pour assurer l’authentification des utilisateurs.
En effet, TLS est l’acronyme de Transport Layer Security et son prédécesseur est Secure
Sockets Layer (SSL) qui sont des protocoles de sécurisation des échanges sur Internet,
développés à l'origine par Netscape (SSL version 2 et SSL version 3) [5].
Ce protocole fonctionne suivant un mode client-serveur. Il fournit les objectifs de sécurité
suivants :
• Authentification - Le client doit pouvoir identifier le serveur. A partir de la version 3.0
du protocole SSL, le serveur peut aussi demander au client de s'authentifier. C’est ce
qu’on appelle « l’authentification mutuelle ». Cette fonctionnalité est assurée par
l'emploi de certificats.
page 8
Rapport du projet de fin d’études ASR
• Confidentialité - Le client et le serveur doivent s’assurer que leur conversation ne
pourra pas être écoutée par un tiers. Cette fonctionnalité est gérée par un algorithme de
chiffrement.
• Identification et intégrité - Le client et le serveur doivent pouvoir s'assurer que les
messages transmis ne sont ni tronqués ni modifiés, qu'ils proviennent bien de
l'expéditeur attendu. Ces fonctionnalités sont assurées par la signature des données.
Il est à savoir qu’à chaque protocole exploitant SSL ou TLS est associé un port TCP donné
tels que les protocole HTTPS, TELNETS et FTPS qui utilisent respectivement les ports TCP
443,992 et 990. [6]
I.3.WebID -TLS :
Le protocole WebID-TLS assure une authentification sécurisée et efficace des utilisateurs du
Web et ce en combinant les avantages du WebID et ceux de TLS. [7]
Il permet aux internautes de s’authentifier en choisissant un certificat client proposé par leurs
navigateurs. Ceci a pour but de prouver que ces utilisateurs possèdent bien la clé privée
associée à la clé publique stockée dans ce même certificat ainsi que dans leurs profils
WebIDs.
Ces certificats peuvent êtres générés par un simple click dans n’importe quel générateur de
WebID notamment My-profile [8] qui a été élaboré par Andrei Sambra lors de sa thèse à
Télécom SudParis.
Voici ci dessous un exemple de certificat client contenant une clé publique, un WebID présent
dans le champ « Subject Alternative Name » et d’autres informations supplémentaires.
page 9
Rapport du projet de fin d’études ASR
Figure 2 : Exemple de certificat sous format x509
Source : W3C Editor'sDraft 12 December 2011
Pour mieux illustrer le principe de l’authentification WebID-TLS, nous donnons le scénario
d’interaction entre un client et un serveur présenté dans la figure 3: le client étant BOB qui
initie une connexion avec le serveur d’Alice afin d’accéder à l’une de ses ressources privées.
page 10Rapport du projet de fin d’études ASR
Figure 3 : Diagramme de séquence illustrant le principe WebID-TLS
Source : W3C Editor'sDraft 21 January 2014
1. Initialisation de la connexion TLS :
o Le client BOB initie une connexion TLS avec le serveur d’Alice pour pouvoir
l’identifier moyennant les mécanismes TLS. Ceci constitue la première étape de la
connexion HTTPS.
2. Connexion au niveau applicatif :
o Un agent, généralement se trouvant dans le serveur, appelé « the Guard » est
toujours en attente des requêtes de la part des clients de type demande d’accès
page 11Rapport du projet de fin d’études ASR
à des ressources protégées ou demande d’ajout à la liste d’amis. Ensuite, le
« Guard » décide si ce client nécessite une authentification ou pas.
3. Demande de certificat client :
o Le « Guard » demande à l’agent TLS d’envoyer une requête au client pour
récupérer son certificat.
o Le client demande à BOB de choisir un certificat parmi ceux stockés dans son
navigateur.
o L’agent TLS vérifie si le client possède vraiment la clé privée associée au
certificat choisi.
o Ensuite, l’agent TLS passe le certificat au « Guard ».
4. Vérification du WebID :
o Le « Guard » demande au « WebIDVerifier » de poursuivre la partie
authentification relative au WebID vu que toutes les étapes précédentes étaient
assurées par le protocole TLS.
5. Extraction de la clé publique de BOB :
o Le « WebIDVerifier » extrait la clé publique de BOB et toutes les URIs ou
WebIDs contenus dans le champ du certificat dit « Subject Alternative
Name ».
o Le « WebIDVerifier » télécharge le document ou le profil de BOB sur lequel
pointe le WebID.
o Le « WebIDVerifier » compare la clé publique de BOB se trouvant dans le
profil téléchargé précédemment avec la clé publique se trouvant dans le
certificat. Si c’est la même clé, alors le client est bien identifié.
6. Vérification des règles de contrôle d’accès :
o Cette étape est dédiée à la détermination des agents qui ont le droit de voir les
ressources d’Alice.
7. Accès à la ressource protégée.
Il est à noter que la majorité des étapes sont assurées par le protocole de sécurité TLS et
c’est seulement les deux étapes 5 et 6 qui sont spécifiques au protocole WebID.
page 12Rapport du projet de fin d’études ASR
Il est aussi important de savoir que dans le « draft » de W3C qui a été publié le 22 janvier
2014 [9], ils ont mis comme note le fait que l’étape 3 de l’authentification peut ne pas se
passer systématiquement, c’est à dire, le « Guard » peut ne pas demander le certificat client de
façon automatique vu que certaines ressources auxquelles le client veut accéder peuvent être
publiques et ne requièrent ainsi pas d’authentification.
Ceci peut être assuré par ce qu’on appelle « la renégociation TLS » qui a été découverte
en 2009.
I.4. WebID-TLS : Authentification déléguée :
Certaines applications Web ou certains services qui sont soit incapables de gérer tous
seuls la procédure d’authentification TLS, soit ne voulant pas prendre en charge cette
étape, décident de la déléguer à une entité tierce. Cette dernière s’intercale ainsi dans
le processus d’authentification.
Le plus important dans ce type d’authentification est la confiance entre celui qui offre
le service voulant authentifier ses clients et la partie tierce.
Voici ci dessous une figure qui résume le principe d’authentification déléguée :
Figure 4 : Exemple d'authentification déléguée
Source : [7]
page 13Rapport du projet de fin d’études ASR
Les étapes schématisées sur la figure peuvent être résumées comme suit :
1. Contrairement à l’authentification classique et standard WebID-TLS ,expliquée dans
la section précédente, le client est tout d’abord redirigé à l’entité tierce ou l’entité de
confiance désignée dans la figure par RP signifiant « Relying Party » .
2. Dans cette entité tierce, il y a un agent responsable de la vérification du WebID qui va
extraire le WebID du client depuis le champ du certificat « Subject Alternative
Name » ainsi que la clé publique.
3. Ensuite, à partir du webID, la partie tierce télécharge le document de profil du client
depuis IdP : « Identity Provider» .
4. L’entité tierce vérifie si la clé publique se trouvant dans le certificat est la même que
celle trouvée dans le document de profil du client. Si c’est le cas, le client s’est bien
authentifié.
5. L’entité tierce redirige le client à celui qui offre le service et qui veut authentifier ses
clients en ajoutant des informations supplémentaires telles qu’une signature pour
prouver que le résultat d’authentification provienne bien de la partie tierce et non pas
d’un autre agent qui s’est passé pour elle .
6. A ce moment, l’offreur de service vérifie la signature et permet au client,qui à priori
s’est ben authentifié, d’accéder au service demandé.
Il est à noter ici que l’ authentification déléguée peut être assurée par le serveur qui a été
développé lors de la thèse de Doctorat de Andrei Sambra [7] et qui jouera le rôle du tiers de
confiance disponible sur https://auth.my-‐profile.eu/.
I .5 . Firefox OS :
C’est un système d'exploitation mobile libre proposé et développé par la Mozilla Corporation.
Sa première apparition était en Février 2012 et sa première commercialisation était le 2 juillet
2013 avec Telefónica [10].
Auparavant, il était connu sous le nom de Boot to Gecko ou B2G.
Il est conçu pour s’adapter aux Smartphones existants. En effet, à l’encontre des autres
systèmes d’exploitation mobiles qui utilisent des technologies dédiées, Firefox OS utilise des
standards libres. Par ce fait, il s’avère facile de porter une application d’un système à un autre.
page 14Rapport du projet de fin d’études ASR
En d’autres termes, Firefox OS introduit plus d’ouverture dans le monde des applications
mobiles.
Figure 5 : Exemple de Smartphone Firefox OS
Source : The Mozilla Magazine publiée le 18 juillet 2013
En 9 décembre 2013 [11], la dernière version de Firefox OS 1.2 est devenue disponible.
Quant au simulateur Firefox OS, il a atteint sa version 4.0. Il permet de tester les applications
dans un environnement très semblable à celui de Firefox OS et ce en l’ajoutant en tant que
extension du navigateur Firefox par un simple téléchargement.
Cependant, selon Mozilla Developer Network [12], le simulateur de Firefox OS manque
encore de performance. En effet, il y a certaines « Web activities » qui ne fonctionnent pas
telles que l’accès à la caméra du simulateur mais aussi celle de l’émulateur dans sa dernière
version.
On distingue 3 types d’applications sur Firefox OS :
o Application certifiée : Elle a été conçue pour assurer une fonctionnalité
critique du système. Pour cette raison, elle doit être approuvée par le fabricant
ou l'opérateur téléphonique de l'appareil qui l'utilise.
o Application privilégiée : Elle doit être approuvée par une boutique
d'applications telle que le Firefox Marketplace.
o Application Web : Elle est qualifiée de « normale » qui ne nécessite pas une
autorisation pour la tester.
page 15Rapport du projet de fin d’études ASR
Cependant, il y a des APIs qui sont, jusqu’au moment de la rédaction du présent rapport,
valables uniquement pour les applications privilégiées ou certifiées notamment TCP socket
API [13].
I .6. Resource Description Framework (RDF):
Resource Description Framework est un modèle de graphe destiné à décrire de façon formelle
les ressources Web et leurs métadonnées. Il a été développé et standardisé par le W3C en 10
Février 2004 pour être ensuite le langage de base du Web sémantique.
Figure 6 : Exemple de graphe RDF
Source : RDF Primer, W3C Tutorial
Donc, comme on voit dans la figure, le RDF sert à décrire un agent ou une personne :
Comment s’appelle –il ? Qui connait-il ? Quel est son métier, ses préférences,…?
Il s’avère évident que le document décrivant le profil WebID d’un utilisateur est modélisé par
ce type de graphe.
RDF possède plusieurs syntaxes telles que RDF/XML ou encore RDF/TURTLE qui est
beaucoup plus compréhensible.
Figure 7:Exemple de RDF/TURTLE
Source : RDF Primer, W3C tutorial
page 16Rapport du projet de fin d’études ASR
I .7. L’ontologie FOAF :
FOAF est l‘acronyme de « Friend of a Friend » qui est une ontologie lisible par une machine
basée sur le Resource Description Framework (RDF). Elle permet de désigner les personnes,
leurs activités et leurs relations avec d'autres personnes et objets et tout ça sans la nécessité
d’avoir recours à une base de données centralisée. En effet, toutes les relations entre les
personnes sont décrites dans des fichiers FOAF sous le contrôle des utilisateurs.
Figure 8 : Exemple de la partie utilisant l’ontologie foaf dans un profil WebID écrit en Turtle
Source : [7]
I .8.Web Social Distribué:
Ce type de réseau permet d’héberger des informations chez chaque utilisateur et non pas dans
un serveur central comme le cas des majorités des réseaux sociaux existants notamment
Facebook, Twitter, Linked in,… Il fonctionne sur le principe du pair à pair (ou peer to peer)
où tous les ordinateurs récupèrent de l’information et resservent l’information obtenue.
Un tel réseau social a été élaboré par Andrei Sambra lors de sa thèse de Doctorat [7] appelé
My-profile disponible sur https://my-profile.eu/. Il s’agit d’une plateforme décentralisée
lancée en Avril 2011 qui permet à ses utilisateurs premièrement d’avoir leurs propres WebIDs
et par la suite leurs propres profils,de garantir que les données de ces utilisateurs soient sous
leur contrôle et non pas centralisées dans des « silos » comme le cas de la majorité des
réseaux existants. Quant aux applications mobiles, il existe aujourd’hui une seule application
de web social distribué développée avec Android basée sur l’ajout d’amis avec leurs WebIDs.
Elle est encore sous sa version beta 0.9.6
page 17Rapport du projet de fin d’études ASR
Chapitre 2: Etude et Réalisation du Projet
Dans ce chapitre, nous allons commencer par présenter les différents aspects théoriques de notre
projet ainsi que les étapes de son déroulement pour entamer ensuite la partie pratique qui portera sur
les détails techniques du projet.
II.1.Etude théorique du Projet :
II.1.1. Présentation du projet :
Notre projet consiste à développer une application pour Firefox OS qui permet à l’utilisateur
de gérer ses contacts dans un réseau social distribué, basé sur le standard WebID.
L ‘objectif majeur de notre projet est le fait de garantir l’interopérabilité entre les différents
réseaux sociaux tout en assurant que chaque utilisateur ait un contrôle total sur ses données
privées qui seront stockées chez lui et non pas dans un « silo » central.
D’ailleurs qui d’entre nous, les internautes en général et les utilisateurs des réseaux sociaux en
particulier, ne s’est pas senti un jour « prisonnier » au sein de son réseau social, incapable
d’échanger des données avec des amis n’appartenant pas au même réseau social ?
La figure ci dessous illustre bien ce problème d’interopérabilité :
Figure 9 : Le problème d'interopérabilité entre les différents réseaux sociaux
Source : Illustration par David Simonds pour article de The Economist Everywhere and nowhere du
19 mai 2008
page 18Rapport du projet de fin d’études ASR
Une solution de ce problème peut être la décentralisation puisque les internautes sont libres de
choisir où stocker leurs données. Cette solution inclut aussi le contrôle de la vie privée vu
qu’en permettant à chaque utilisateur de stocker chez lui ses propres ressources, il n’y aura
plus le souci de s’interroger ni par rapport à l’emplacement de ses données ni par rapport à la
façon avec laquelle sont utilisés ces données.
II.1.2. Les étapes de réalisation du projet :
Pour réaliser ses objectifs, l’application doit comporter les étapes suivantes :
1. Echange du WebID entre deux personnes voulant devenir « amis » :
On suppose que l’échange se fait lors d’une rencontre professionnelle où à la place
d’échanger des cartes visites, ils échangent leurs WebIDs qui pointe sur leurs profils
contenant toutes leurs informations. De plus, l’échange peut se faire avec un scan de QR code
ou un autre mécanisme d’échange tel que NFC. (figure 10, étape 1,2,3,4)
2. Vérifier que le WebID appartient bien au contact, autrement dit, vérifier si le fournisseur
de l’URI (WebID) est bien celui qu’il prétend être :
C’est l’étape la plus importante de l’application vu qu’elle affecte la sécurité des ressources
privées de l’utilisateur car s’il s’avère que celui qui a fourni son WebID n’est pas son vrai
possesseur , il peut ainsi accéder au profil de l’autre personne et ainsi à toutes ses ressources.
D’où l’importance de l’authentification dans notre application. Ceci peut être assuré par les
protocoles WebID et TLS décrite dans le chapitre 1, section I.3. (figure 10, étape 5--->10)
3. Si l’authentification est réussie, alors les deux personnes deviennent « amis »:
A ce moment, se fait la mise à jour du profil WebID écrit en RDF, c’est à dire, il y aura
modification du schéma RDF de façon à indiquer que ces deux personnes se connaissent en
se basant sur l’ontologie FOAF : (foaf :knows). (figure 10, étape 11)
Voici ci dessous le diagramme de séquence qui illustre les étapes décrites précédemment :
page 19Rapport du projet de fin d’études ASR
Figure 10 : Diagramme de séquence illustrant les étapes de l'application
II.1.3. Les outils utilisés :
Nous avons choisi d’héberger toutes les ressources liées au projet ainsi que tous les comptes
rendus de nos réunions sur la plate-forme fusionforge.int-evry.fr exploitée par le département
informatique de Télécom SudParis. Notre projet contient notamment un dépôt Git qui nous a
permis d’archiver et synchroniser le code source et tous les documents qu’on a jugés utiles.
Quant au développement de notre application, on a utilisé la plate-forme de développement
web « WampServer » dans sa version 2.1 contenant le serveur Apache dans sa version 2.2.17,
le langage de scripts PHP dans sa version 5.3.5 ainsi que la base de données MySQL dans sa
version 5.5.8.
Pour la simulation de notre application et la conception de son interface graphique, nous nous
sommes servies du « Framework » JQuery Mobile dans sa dernière version 1.4.0 vu qu’il est
riche en fonctionnalités intégrant une compatibilité avec les différentes plateformes actuelles.
page 20Rapport du projet de fin d’études ASR
II.2.Etude pratique du Projet :
II.2.1. Etude de faisabilité :
Vu que notre projet consiste à développer une application pour Firefox OS et que ce dernier
est encore récent par rapport à d’autres OS mobiles, nous avons décidé de commencer par
faire une étude de faisabilité de ce projet.
Nous avons commencé notre étude par analyser les besoins du projet dans chaque étape de sa
réalisation (les étapes ont été décrites dans la section précédente de ce chapitre), autrement
dit, dans chaque étape requise, nous avons accompli des recherches approfondies pour
identifier ses besoins et sa faisabilité.
Pour la première étape qui présente l’échange de WebID entre 2 utilisateurs, nous avons
trouvé qu’il existe déjà une application sur Firefox OS capable de scanner un QR code
disponible dans le dépôt github accessible par cette URI : https://github.com/ppapadeas/fxos-
qreader . Donc, nous avons jugé utile de l’adopter et l’intégrer dans notre application.
Nous avons aussi pensé à une autre alternative d’échange de WebID, c’est l’utilisation de
la technique NFC de communication en champ proche (en anglais Near Field
Communication).
Cependant, après avoir creusé là dessus, il s’est avéré impossible d’utiliser cette technique vu
que les Smartphones Firefox OS ne supportent pas le NFC jusqu’à la version actuelle 1.2.
Quant à la deuxième étape de notre projet, elle constitue sans doute la phase la plus
importante et la plus délicate par rapport aux autres étapes car, comme c’est expliqué dans la
section II.1.2, elle touche à la sécurité de la vie privée de l’utilisateur et donc à l’objectif
majeur de notre application. Pour cette raison, nous avons consacré plus de temps à faire des
recherches approfondies là dessus et les couronner ensuite par des confirmations de la part des
développeurs de Mozilla que ce soit lors des visites effectuées à leur local à Paris ou en posant
des questions sur Mozilla Developer Network.
Premièrement, nous avons commencé par vérifier si Firefox OS dans sa version actuelle, est
capable de gérer l’authentification WebId-TLS (expliquée dans le 1er chapitre) sans
l’intervention d’aucune entité tierce. Mais, il s’est révélé que actuellement, Firefox OS ne
supporte pas les certificats clients [13] .Il est aussi incapable de gérer une paire de clés (clé
privée + clé publique) côté client et les transporter à une machine distante.
page 21Rapport du projet de fin d’études ASR
Après l’obtention de ce résultat, l’intégration d’un serveur tiers, à priori Apache, devient
indispensable et ce pour que celui-ci s’occupe de la phase de demande de certificat client et
toutes les autres étapes nécessaires à l’authentification notamment l’extraction de la clé
publique,… et renvoie le résultat de cette authentification au mobile.
Il est évident donc dans ce scénario que le mobile doit communiquer avec le serveur tiers à
travers le réseau pour échanger le certificat du client avec le serveur web, si on suppose que
ce certificat a été stockée dans le mobile. Ainsi, nous avons besoin d’établir une connexion
TCP/IP moyennant une socket TCP. Et là, s’impose un autre problème ; c’est que Firefox
OS dans sa version actuelle, ne permet pas aux applications Web d’utiliser l’API « TCP
socket » ; c’est seulement les applications certifiées et privilégiées qui peuvent utiliser cette
API [14] .
Pour toutes ces raisons, il s’avère difficile de développer cette application sur Firefox OS dans
sa version actuelle voire même impossible. Par conséquent, nous avons choisi de la simuler
sur des ordinateurs et non pas sur des mobiles. Les détails de cette simulation font l’objet de
la section suivante.
Quant à la troisième étape qui consiste à faire la mise à jour du profil WebId après avoir
validé la phase d’authentification, nous n’avons pas pu effectué assez de recherches là dessus
car nous nous sommes concentrées plutôt sur l’authentification sur laquelle notre application
est entièrement basée.
II.2.2. Préparation de l’environnement du travail :
Pour pouvoir simuler notre application basée sur des fonctionnalités liées à la cryptographie et
nécessitant l’utilisation d’un serveur, nous devons impérativement installer quelques
logiciels.
II.2.2.1 Installation des composants requis:
Vous trouverez ci-dessous la liste des outils que nous nous sommes procurée avant de
commencer notre travail :
ü OpenSSL: qui est une implémentation open-source des protocoles SSL et TLS. Il
représente une boîte à outils de chiffrement qui comporte deux bibliothèques et
implémente les fonctions cryptographiques de base.
page 22Rapport du projet de fin d’études ASR
Dans notre cas et afin d’effectuer certaines opérations telles que la création d'une clef
privée du serveur et la génération d'un « Certificate Signing Request » (CSR) pour le
serveur on a eu besoin d’installer la version 0.9.8k de OpenSSL.
Il suffit de consulter ce lien pour avoir tous les détails de la configuration :
http://fash7y.wordpress.com/2011/12/03/solved-how-to-set-up-https-with-openssl-in-
wamp/
ü WAMP Server: est une plate-forme de développement Web sous Windows pour des
applications Web dynamiques qui regroupe un serveur Apache2, le langage de scripts
PHP et une base de données MySQL. Aussi il donne accès à PHPMyAdmin pour gérer
plus facilement les bases de données utilisées. [15]
Puisque notre application utilisera un code PHP assurant l’authentification et aura besoin
d’une base de données notamment MySQL pour gérer la liste d’amis, nous avons choisi de
travailler avec WAMP Server qui offre toutes ces fonctionnalités. Nous avons opté pour la
version 2.1 contenant le serveur Apache dans sa version 2.2.17, le langage de scripts PHP
dans sa version 5.3.5 ainsi que la base de données MySQL dans sa version 5.5.8.
Le choix de la version a été le résultat d’expérimentation de plusieurs versions car nous avons
rencontré des problèmes que nous allons citer dans le paragraphe suivant.
II.2.2.2 Problèmes rencontrés lors de la préparation de l’environnement:
Au début, nous avons choisi de travailler avec la dernière version de WAMP disponible qui
est la version 2.4 contenant le serveur Apache 2.4.4, MySQL 5.6.12 et PHP 5.4.16.
Ensuite, nous avons intégré un code Open Source qui répond à nos besoins d’authentification
réalisé par Andrei Vlad Sambra disponible sur son Github accessible via cette URI :
https://github.com/WebIDauth/WebIDauth .
Cependant, lors du test de ce code et après avoir réussi la configuration SSL/TLS du WAMP,
nous avons eu des contraintes techniques tout d’abord liées à la version de PHP utilisée.
C’est pour cette raison que nous avons décidé de modifier la version de WAMP contenant la
version de PHP adéquate qui doit être une version inférieure à 5.4.
Après avoir réglé ça, nous avons trouvé quelques problèmes techniques avec le code qu’on
détaillera dans la partie suivante.
page 23Rapport du projet de fin d’études ASR
Il est à savoir qu’il a fallu configurer Apache de telle sorte qu’il écoute sur le port 443 et
active le module SSL/TLS.
II.2.3. Travail réalisé et problèmes rencontrés:
Comme expliqué dans l’étude de faisabilité de ce projet, nous allons procéder par une
simulation de notre application de gestion de contacts WebID sur des ordinateurs et non pas
sur des mobiles. Pour cela, nous avons utilisé dans un premier temps le serveur Apache en
tant que serveur local qui va se charger d’assurer l’authentification du fournisseur du WebID
en exécutant toutes les étapes requises expliquées dans la partie I. 3.
D’ailleurs la figure 11 décrit bien le scénario d’authentification mutuelle en local puisque
dans cet exemple non seulement ALICE va pouvoir se connecter et identifier le serveur en
toute sécurité mais aussi le serveur va pouvoir l’authentifier. Ceci est réalisé avec succès après
avoir configuré ce dernier de sorte qu’il écoute sur le port 443, qu’il utilise le module
SSL/TLS et qu’il demande le certificat client. Les détails de la configuration sont disponibles
sur ce lien : http://fash7y.wordpress.com/2011/12/03/solved-how-to-set-up-https-with-
openssl-in-wamp/
De plus, il a fallu intégrer le code de my-profile [8] écrit en PHP pour assurer
l’authentification après l’avoir modifié afin qu’il s’adapte à nos besoins.
Figure 11: Diagramme de séquence de l'authentification avec le serveur local
page 24Rapport du projet de fin d’études ASR
Cependant, bien que nous ayons réglé tous les problèmes de version et de syntaxe PHP, le
code donne tantôt un résultat correct de l’authentification tantôt un résultat erroné. Ce qui
nous a obligé d’abandonner l’authentification en local avec notre propre serveur configuré
comme décrit précédemment et opter pour une authentification déléguée à un tiers de
confiance. Cette alternative a été expliquée plus en détails dans la section I.4 et illustrée dans
la figure 12 ci dessous :
Figure 12: Diagramme de séquence de l'authentification déléguée
Ensuite, pour gérer le mécanisme d’ajout d’amis et permettre à Bob par exemple d’envoyer
une invitation d’ajout d’ami à Alice à travers notre application, il a fallu créer une base de
donnée que nous avons nommée « WebID-friend » contenant une table nommée
« t_notification » servant à stocker les WebIDs de l’expéditeur de l’invitation et de son
destinataire ainsi que le statut de l’invitation (Status= 0 si l’invitation n’a pas encore été
acceptée et Status passe à 1 dans le cas contraire ). (Voir figure 13)
page 25Rapport du projet de fin d’études ASR
Figure 13: Représentation graphique de la structure de la base de donnée « WebID-friend »
Finalement, nous avons programmé en PHP les scripts nécessaires pour gérer la base de
donnée et permettre l’ajout d’ami et la notification de l’émetteur de l’invitation dès que le
destinataire réussit son authentification. Ce scénario est présenté dans la figure 14 :
Figure 14:Diagramme de séquence du mécanisme d'ajout d'ami
page 26Rapport du projet de fin d’études ASR
Pour mieux expliquer les détails de ce qui ce passe au niveau du serveur voici l’enchainement
détaillé du scénario de la figure 14 :
- Dans ce scénario on suppose que BOB s’est déjà bien identifié auprès de son serveur local et
il va maintenant envoyer une invitation d’ajout à Alice et ceci en introduisant son WebID
dans son interface client. (étape 1 fig.14)
- A ce moment là, le serveur va procéder à quelques tests ,tout d’abord pour voir si le WebID
introduit est un WebID différent de celui de BOB puis pour tester si BOB n’a pas déjà envoyé
cette invitation auparavant à Alice ou s’ils sont déjà amis.
Une fois que ces tests sont réussis, une ligne s’ajoute à la base de donnée en mettant dans le
« SenderID » le WebID de BOB et dans « RecieverID » celui d’Alice et dans « Status » la
valeur 0 (étape 2 fig.14).
- Et dès que Alice s’authentifie (étape 3 et 4 fig.14), elle saura qu’elle vient d’accepter Bob en
tant qu’ami et le « Status » dans la base de donnée sera mis à 1 pour pouvoir ensuite notifier
BOB (étape 5 fig.14).
Finalement, pour s’approcher de l’aspect mobile de l’application nous avons choisi d’utiliser
le « Framework » JQuery Mobile dans sa dernière version 1.4.0 dans le but de concevoir
l’interface graphique de l’application.
Notre choix a porté sur « JQuery Mobile » car celui-ci permet de créer facilement des
applications Web qui ont un « look and feel » mobile. En d’autres termes, il permet à
l’application de s’adapter toute seule à la taille du navigateur.
Mais, qui dit Framework, dit fichiers supplémentaires à charger. Dans notre cas, nous avons
intégré à notre travail les librairies JQuery et JQuery Mobile.
Il est à savoir que JQuery Mobile est compatible multiplateforme : iOs, Android, Windows
Mobile, BlackBerry, mais également navigateurs desktop et Phonegap. Puisqu’une
application JQuery Mobile est en fait une application HTML5, il est possible de la lancer dans
n’importe quel navigateur de n’importe quel appareil qui supporte le balisage HTML5
notamment les appareils Firefox OS.[16]
La figure 15 montre à quoi ressemble notre application après l’avoir conçue à l’aide des
composants du JQuery Mobile.
page 27Rapport du projet de fin d’études ASR
Figure 15: Simulation de l'application avec JQuery Mobile
II.2.4.Perspectives futures:
Pour mettre l’accent sur l’authentification, nous avons réussi dans tout ce que nous avons fait
précédemment de faire fonctionner celle-ci dans un environnement centralisé puisque dans
l’exemple de BOB et Alice, les deux se connectent sur le même serveur local Apache.
Cependant, dans une étape plus avancée de la simulation, nous proposons d’assurer l’étape
d’authentification d’une façon décentralisée et passer ensuite à l’étape de modification du
fichier RDF du « document profile » et mettre à jour la relation foaf : knows. (Voir figure 15)
Une fois que ceci serait fait, il ne reste plus qu’à simuler toutes les étapes décrites
précédemment sur Firefox OS dans ses versions futures.
page 28Rapport du projet de fin d’études ASR
Figure 16: Diagramme de séquence du scénario futur de l'application
page 29Rapport du projet de fin d’études ASR
Conclusion générale
Avec l’expansion du marché du mobile de ces dernières années, les applications web
s’imposent de plus en plus en ciblant tous les profils de clients et en touchant tous les
domaines surtout celui du web social.
Mais mettre en place un web social distribué qui garantit la vie privée de ses
utilisateurs tout en permettant une interopérabilité entre eux demeure actuellement un sujet de
débat.
C’est dans ce cadre, donc, que s’est déroulé notre projet qui consiste de développer
une application pour Firefox OS permettant de se relier à des contacts WebID.
Au bout de plus de trois mois d’études et de recherches approfondies sur la faisabilité
de ce projet, nous avons réussi à simuler la partie métier de notre application web social sur
des ordinateurs et non pas sur des mobiles Firefox OS. Lors de ce projet, nous nous sommes
concentrées sur l’authentification des utilisateurs, assurée par une combinaison des protocoles
WebID et TLS qui constitue l’objectif majeur de notre application.
Bien que nous ayons rencontré plusieurs contraintes techniques lors de la réalisation
pratique de notre application que nous avons expliquées dans le chapitre précédent du présent
manuscrit, ce travail nous a apporté tant d’avantages sur le plan professionnel. En effet, il
nous a présenté non seulement une opportunité de faire connaissance et communiquer avec les
développeurs de la communauté ouverte de Mozilla, mais aussi un excellent défi pour
apprendre à programmer sur des logiciels et avec des langages qui nous ne sont pas familiers
tel que HTML5 et PHP.
De plus, grâce à ce projet nous avons pu gérer et maîtriser maints aspects de sécurité et
différentes notions cryptographiques puisque nous avons manipulé des certificats
électroniques et des clés de chiffrements lors de l’utilisation du protocole SSL/TLS.
En prenant du recul vis-à-vis de ce travail, nous réalisons que l’utilisation du protocole
WebID-TLS pourrait sembler relativement compliquée pour les gens non familiers avec les
notions de certificat électronique et les différents protocoles de sécurité.
page 30Rapport du projet de fin d’études ASR
Références
[1] : Rapport du cabinet d'étude de marché « StrategyAnalytics » rendu public le 17/10/2012,
consulté le 29/12/2013. Disponible : http://french.peopledaily.com.cn/Sci-Edu/7981963.html
[2]: “WebIDs and the WebID Protocol”, Dernière mise à jour: 15 janvier 2014.
Disponible: http://www.w3.org/wiki/WebID
[3]: “Web Identification and Discovery” publiée dans “W3C Editor'sDraft 12 December
2011” Disponible: http://www.w3.org/2005/Incubator/webid/spec/
[4]: “W3C Editor'sDraft 21 January2014”, Disponible: https://dvcs.w3.org/hg/WebID/raw-
file/tip/spec/identity-respec.html
[5]: T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol, Version 1.2, Août
2008, Disponible: http://www.ietf.org/rfc/rfc5246.txt
[6] : Vincent LIMORTE, François VERRY et Sébastien FONTAINE, Le site de la Sécurité
Réseau des Entreprises, publié le 23 décembre 2006, consulté le:18/11/2013, Disponible:
http://www.authsecu.com/ssl-tls/ssl-tls.php#Présentation_de_SSL_et_TLS
[7] : Andrei VladSambra, « La propriété des données et l'interopérabilité pour un Web
sémantique social décentralisé », Thèse de Doctorat 2013 conjoint Télécom SudParis et
l’université PIERRE ET MARIE CURIE.
[8] : Andrei VladSambra, plateforme web social décentralisé, Disponible: https://my-
profile.eu/
[9]: W3C Editor'sDraft 22 January2014, Disponible: https://dvcs.w3.org/hg/WebID/raw-
file/tip/spec/tls-respec.html
[10] : « Firefox OS », Wikipédia, Dernière mise à jour : 21 janvier 2014, consulté le: 22
janvier 2014. Disponible: http://en.wikipedia.org/wiki/Firefox_OS
[11] : « Firefox OS 1.2 Notes», Mozilla Developer Network, Disponible :
page 31Rapport du projet de fin d’études ASR
http://www.mozilla.org/en-US/firefox/os/notes/1.2/
[12]: “Firefox OS Simulator”, Mozilla Developer Network, dernière mise à jour: 16 janvier
2014, consulté le: 23 décembre 2013, Disponible:
https://developer.mozilla.org/en/docs/Tools/Firefox_OS_Simulator
[13]: “SSL/TLS Mutual authentication in Firefox-OS”, Mozilla Developer Network,
Disponible: http://stackoverflow.com/questions/21009047/ssl-tls-mutual-authentication-in-
firefox-os
[14]:“TCP Socket”, Mozilla Developer Network, dernière mise à jour: 29 septembre 2013,
consulté le 20 novembre 2013, Disponible: https://developer.mozilla.org/en-
US/docs/Web/API/TCPSocket
[15]: « plate-forme de développement Web sous Windows », Disponible:
http://www.wampserver.com/
[16]: “JQUERY MOBILE: Une introduction au Framework et principes de base”, Publié le:
11 janvier 2013 , Disponible:
http://wdfriday.com/blog/2013/01/jquery-mobile-une-introduction-au-framework-et-
principes-de-base/
page 32Vous pouvez aussi lire
