AUTHENTIFICATION PAR LDAP Et CRYPTAGE DE MOT DE PASSE

Transcription

1 AUTHENTIFICATION PAR LDAP Et CRYPTAGE DE MOT DE PASSE RAPPORT DE STAGE Maître de Stage : Sandrine Locatelli Ingénieur développement Produit 4ème année Réseau Informatique Et Communication Multimédia (RICM4) Année

2 2

3 Remerciements Je tiens tout particulièrement à remercier mon maître de stage Sandrine LOCATELLI et la directrice R&D et Production Bénédicte BOUCHE pour leur accueil chaleureux, ainsi que le directeur de Interview S.A., Alain BOUVERET, pour m avoir accepter en tant que stagiaire. Je remercie également Daniel CHIPAN, Pierre GOIFFON, Guillaume MARY, Xavier FARRET et Mathieu MARTINEZ pour leur sympathie, leur disponibilité et leurs conseils qui m ont aidés à résoudre les problèmes liés à mes missions et ainsi d effectuer sereinement mon stage. D une façon plus générale, je remercie tous les membres de la société Interview pour leur accueil et les moments de détente que nous avons eu ensemble qui m ont permis d apprécier la vie en entreprise. Je remercie de même ma tutrice de stage Nadia BRAUNER VETTIER pour son encadrement pendant la durée de mon stage. 3

4 Table des matières Remerciements 3 Résumé.. 5 Introduction ère Partie : Cadre du stage I. L «Enterprise Feedback Management» (E.F.M.), la nouvelle méthode d enquêtes 1. Présentation 7 2. Une dénomination peu connue mais un concept jugé utile. 8 II. Interview?! S.A., précurseur sur le marché de l EFM 1. La petite histoire 8 2. Interview S.A. aujourd hui 2.1. Organisation sociale de l entreprise Partenaires et clients Solutions EFM proposées Le département produits ème Partie : Les missions et les apports du stage I. Les missions 1. Le protocole DomainKeys Indentified Mail (DKIM) Authentification avec Lightweight Directory Access Protocol (LDAP) Cryptage de mot de passe 20 II. Les apports du stage 1. Compétences Techniques Acquises Problèmes Rencontrés& Solutions Apportées La vie dans la société. 23 Conclusion.. 24 Bibliographie/Webographie. 25 Documents rédigés Table des figures Annexes 27 Tableau des révisions 39 4

5 Résumé Mon stage de dix semaines au sein de la société Interview S.A. a été des plus enrichissants. Bien que ne répondant pas au besoin de la société d améliorer sa délivrabilité, le protocole Domain Keys Identified Mail (DKIM) est un protocole de signature intéressant et comme expliqué dans mon rapport de stage, sa mise en place, très simple, serait une sécurité supplémentaire pour la lutte contre l hameçonnage. L authentification en utilisant un annuaire Lightweight Directory Access Protocol (LDAP) est un moyen pour les clients de Interview de pouvoir avoir accès aux produits qu ils offrent en utilisant le même mot de passe et login que ceux pour s authentifier dans leur entreprise. La mise en place de cette couche LDAP passe par l utilisation de frameworks tels que JAAS et JNDI. Le cryptage des mots de passe en base de données résulte d un besoin pour Interview de ne plus les y avoir en «clair». Le moyen le plus sûr de faire ce cryptage- c est-à-dire sans possibilité de retrouver le mot de passe original-, c est d utiliser les fonctions de hachage. Cependant, pour pouvoir rendre à l utilisateur son mot de passe en cas de perte, le chiffrement à clé publique reste le meilleur choix. My training course of ten weeks within the company Interview Inc. was the most enriching. Although not answering the need of the company to improve its deliverability, the protocol Domain Keys Identified Mail (DKIM) is an interesting signature protocol and, as explained in my report of training course, its implementation, very simple, would be an additional safety for the fight against the fishing. The authentication by using a directory Lightweight Directory Access Protocol (LDAP) is a means for the customers of Interview to be able to have access to the products which they offer by using the same password and login as those to authenticate in their company. The implementation of this layer LDAP passes by the use of frameworks such as JAAS and JNDI. The encoding of the passwords in database results from a need for Interview to have them there not more in "light". The way the safest to make this encoding -that is without possibility find the original password- it is to use the hash functions. However, to be able to return to the user its password in case of loss, the encoding with public key stays the best choice. 5

6 Introduction J ai effectué mon stage au sein de la société Interview S.A. situé au 2 Avenue de l Obiou, La Tronche. Ce rapport présente les différentes missions que j ai effectuées durant ces dix semaines de stage. Et le point commun que l on peut trouver à ces différentes missions, est que d une façon où d une autre, elles traitent de la sécurité. En effet, bien que le but de l étude du protocole Domain Keys Identified Mail(DKIM) était de faire croître la délivrabilité des mails de Interview, il s avère à la fin que c est une méthode de protection contre l usurpation d identité. De même, l authentification par Lightweight Directory Access Protocol (LDAP) et le cryptage de mot de passe en base de données ont pour but de protéger les produits de Interview. Les différents projets effectués se sont avérés très intéressants et très enrichissants du point de vue expérience professionnelle. En effet, grâce à ces différentes missions, j ai pu entrevoir en quoi consiste le métier d ingénieur et surtout de pointer un sujet qui m intéresse vivement : la cryptologie, la sécurité et le codage de l information. Le but de ce rapport n est pas seulement de faire une présentation exhaustive de tous les aspects techniques que j ai pu apprendre ou approfondir au cours de ces semaines de stages, mais aussi de présenter les aspects humains auxquels j ai été confrontée. Alors, dans ce rapport, je donnerais une définition de ce qu est l Entreprise Feedback Management (E.F.M.), le domaine dont Interview est spécialiste. Puis, je présenterais la société elle-même. Et enfin, je parlerais des différentes missions que j ai accomplies, m attardant sur la manière dont elles ont été abordées. 6

7 1 ère Partie : Cadre du stage I. L «Enterprise Feedback Management» (E.F.M.), la nouvelle méthode d enquêtes 1. Présentation Interroger des clients via des enquêtes est une pratique répandue et utilisée depuis longtemps par les entreprises. Que se soient des enquêtes de satisfaction, de qualité ou encore de notoriété, le but de celles-ci est de répondre à une question unique posée par un département spécifique de l entreprise. Mais les résultats de ces enquêtes sont très peu souvent réutilisés ou suivis à la fin de l enquête. Cependant, face à un contexte concurrentiel de plus en plus difficile, les entreprises ont plus que jamais besoin de rester à l écoute de leurs clients et ce de manière constante et régulière. Le but étant de palier rapidement tout signe de mécontentement ou d insatisfaction et ainsi éviter la perte de clientèle au profit de la concurrence. Ce n est pas un besoin ponctuel, pas plus qu il ne doit appartenir à un département dans l entreprise plutôt à un autre. C est un enjeu d entreprise indispensable à leur développement. Pour répondre à cette évolution, les éditeurs d enquêtes ont eu à s approprier les principes bien connus des systèmes décisionnels. Ces derniers permettent de constituer en un lieu unique une base de connaissance d information intégrées et archivées qui sera ensuite mise à disposition d un grand nombre d utilisateurs pour une exploitation adaptée à leur besoin. De plus, ils ont eu à «épouser» les solutions CRM 1 (Custom Relation Management) déjà mises en œuvre chez beaucoup d entreprises et qui permettent la collecte des informations transactionnelles clients et la gestion de la relation avec les clients au quotidien. Ce qui a donné lieu à l émergence d une nouvelle méthode de traitement de l information : l Entreprise Feedback Management ou EFM. 2. Une dénomination peu connue Le concept d EFM n est pas nouveau. Il a été introduit en 2005 par le Gartner. Il désigne une tendance de management où toutes les informations d entreprise sont centralisées au sein d un outil, connecté au reste du système d information et mutualisable entre les différents métiers de l entreprise. En d autres mots, l EFM répond au besoin de collecter,gérer et analyser un maximum d informations venant des sources internes (salarié,filiales) comme externes (clients,partenaires) et de centraliser ces informations dans des outils qui communiquent entre eux pour un traitement fiable et économique. Le but étant d établir des plans d actions efficaces auprès des ces diverses sources. Si plusieurs acteurs proposent aujourd hui ce type de plateforme (WysuForms, Interview?! SA, VDoc Software ou GrimmerSoft, et d autres), peu d entreprises ont 1 Voir Annexe A 7

8 réellement adopté cette nouvelle méthode de traitement de l information. La raison est, d après les résultats du nouveau Baromètre annuel de l EFM, commandité GrimmerSoft, que l EFM est encore mal connu. L étude a porté sur les réponses de vingt deux mille sept cent vingt-huit (22728) professionnels de tous secteurs en France, interrogés par Marketor 1 via un questionnaire en ligne administré entre le 15 mars et le 15 mai Ce baromètre révèle en effet que seulement 5 % des entreprises connaissent la dénomination EFM. 3 mais un concept jugé utile Aujourd hui, les entreprises utilisent une grande variété d outils pour recueillir et traiter les informations. Par ailleurs, elles ont souvent recours à des outils de bureautiques non spécialisés. Le baromètre commandité par GrimmerSoft 2 fait état du fait que si, globalement, les personnes interrogées sont satisfaites de leurs outils de recueil et de traitement de l information, elles estiment qu ils restent source d insatisfaction en matière d intégration avec le reste du système (48% d insatisfaits en moyenne et 43% pour le service de Marketing- Etudes) et de coût d acquisition (40% d insatisfaits en moyenne et 46% pour le service Marketing-Etudes). Mais même si sa notoriété est faible, le concept d EFM est jugé utile par 76% des répondants, et notamment par le service des Ressources humaines (77%). Le service informatique fait également partie des convaincus (68%), tandis que le Marketing est plus sceptiques (seulement 47% des répondants approuve son utilité). Il en ressort que plus de 25% des entreprises seraient prêtes à s équiper de solution EFM à court terme (moins de douze mois). Dans cette éventualité, elles demeureraient attentives particulièrement au coût du projet et à l adéquation de ces solutions aux spécificités des différents métiers de leur organisation. II. Interview?! S.A., précurseur sur le marché de l EFM 1. La petite Histoire Dès 1998, les créateurs d Interview SA ont décidé de concevoir une plate-forme logicielle destinée à organiser et à structurer tous types de remontées d informations. Cette plateforme devait être simple, générique et immédiatement opérationnelle pour ses utilisateurs. En 2000 l idée a pris forme et Interview SA est née. Et la plateforme a été nommée interview?!. En 2002, il est créé au sein de la société un département Etudes chargé de la conception des questionnaires ou quiz, de l accompagnement des clients et de l analyse des résultats de l enquête. Trois ans plus tard, la démarche proposée par Interview SA a trouvé un nom dans les pays anglo-saxons : Enterprise Feedback Management. Cette démarche, fondée sur le besoin de mieux intégrer son environnement dans les prises de décision, détermine un nouveau métier. Ses maîtres mots sont : technologies efficaces et génériques, vision globale et industrialisation des outils. 1 Marketor est une société créée en 2005 et spécialisée dans les études sur le secteur IT. 2 Quelques résultats du baromètre sont donnés en Annexe B 8

9 En 2007, Interview SA assure sa seconde levée de fond. En 2009, un nouveau bureau est créé à Stuttgart (Allemagne). En 2010, Interview dispose de nouveaux supports de recueil : écrans tactiles, USSD 1 (Unstructured Supplementary Service Data) 2. Interview SA aujourd hui 2.1. Organisation sociale Le président et fondateur d Interview SA, Alain BOUVERET, compte au sein de son entreprise trente collaborateurs. Comme le montre l organigramme suivant, l entreprise est subdivisée en trois pôles importants : Figure 1 : Organigramme Interview SA (Juillet 2010) o Le pôle Client & Opération : il regroupe trois départements qui sont le département commercial, le département études et le département projets. Son rôle est de répondre directement aux besoins des clients de la société. 1 Voir Annexe A 9

10 o Le pôle R&D et Production : il est lui aussi constitué de trois départements : le département Dev-Produits, le département Réseau et Infrastructure et le département Qualité et Support. o Le pôle Marketing et Relations Extérieures. Le tout complété par le service administratif (RH, comptabilité et administration générale) Partenaires et clients Aujourd hui, Interview SA compte environ deux cents clients. Parmi eux, on note des grandes entreprises telles que Schneider Electric, Auchan, EDF, France Télécom, Michelin Et pour répondre de façon plus précise aux besoins de ces clients Interview SA a conclu des partenariats avec certaines sociétés. Ces partenaires entrent dans trois profils : les prescripteurs, les revendeurs et les intégrateurs. Parmi eux, on compte : - DIMO Gestion, expert dans l intégration de solutions collaboratives qui propose la solution d Interview SA pour l analyse et la collecte d informations de ses clients ; - Orange (depuis 2002) pour la mise en œuvre de solutions de remontées d informations sur terminaux mobiles ; - Vdoc Software, leader français sur le marché BPM 1 : Interview SA est rentré dans son programme Alliance afin de proposer aux clients une nouvelle offre EFM. - MONGOLFIER Consultants, cabinet de conseil, de formation et de coaching : il collabore avec Interview SA pour la création d une offre autour du développement durable au sens large ; - Zap-Meeting, spécialiste de la communication audiovisuelle dynamique sur écran : avec Interview SA, il propose à leurs clients des solutions de recueil d informations via des écrans tactiles ; L élargissement des usages d interview?! au sein de ces groupes pour la plupart internationaux fait en sorte que les solutions EFM apportées par Interview SA sont mises en œuvre dans près de soixante pays sur tous les continents. Le siège et les équipes de développement sont à Grenoble. Interview SA dispose aussi d implantations sur Paris, Montpellier, Milan et Stuttgart Solutions EFM proposées Interview SA propose à ses clients trois solutions EFM : - interview?! C est le premier produit, développé sous Notes, que Interview SA a mis en place. Les maîtres mots de la plate-forme interview?! sont : o interroger : création d un formulaire personnalisé de type questionnaire, quiz ou sondage ; o collecter : diffusion du formulaire soit par , dépôt sur site intranet/internet ou via mobiles ; puis suivi en temps réel des réponses obtenues ; o analyser : traitement des informations (récupération des données sous format CSV (Excel), préparation des rapports d analyse) Les impacts de cette solution sont : o une capacité d écoute déployée à différents niveaux : détaillée localement et consolidée internationalement, 1 Voir Annexe A 10

11 o des économies de coûts, o un développement de nouvelles compétences internes, o une possibilité de suivi transverse des clients et des collaborateurs (fidélisation, anticipation). Figure 2 1 : la plate-forme EFM interview?! En ce moment, les développeurs d Interview tente de le faire migrer vers JAVA. La raison est que Notes des de moins en moins utilisé chez les clients. - dataview?! : Le but de cette solution EFM, développée en JAVA, est de permettre à une certaine population de pouvoir accéder, via le WEB (authentification login/mot de passe), aux données de résultats d une enquête en pouvant manipuler simplement les variables. Ces données peuvent venir d interview?! ou non. - openview?! : Il est difficile d exploiter les réponses aux questions ouvertes (exemple : Quel est votre opinion sur?) car ces dernières nécessitent un traitement long et coûteux. Le but de openview?! est de o pouvoir mettre en œuvre des outils d études qualitatives en ligne (forum, bulletin board, chat) o puis analyser les données textuelles obtenues. Ces deux derniers produits de Interview sont en cours de réalisation. 3. Le département Produits Au sein de cette société de taille humaine, il est aisé de percevoir les interactions entre les différents pôles et départements cités ci-dessus. Cependant, compte tenu du fait que mon stage a exclusivement été effectué au département Dev-Produits, il sera uniquement développé ici le fonctionnement de ce service. Le département Dev-Produits, dirigé par Bénédicte Bouché, est composé de huit employés, répartis en deux équipes: une équipe Java pour le développement des produits en java (dataview?!, openview?! et migration de interview?! en java) et d une équipe Notes qui 1 Source 11

12 s occupe de interview?! qui est écrit en Notes. Chacune des équipes se trouve dans un bureau. Cette répartition facilite le brainstorming. Par exemple, si un membre de l équipe java bloque sur un concept java, il peut demander de l aide aux autres qui sont dans le même bureau que lui. Chaque membre du département est responsable d un projet. Le lundi, une réunion d équipe est organisée. Le but de cette réunion est de faire part aux autres membres du département de l évolution du projet, des problèmes rencontrés. L avantage de cette réunion qu elle permet de développer des synergies au sein de l équipe et d éviter que chacun se sente isolé. Et dans l optique de créer une bonne entente entre les membres de l équipe, des balades, randonnées ou barbecue sont organisés. Cela leur permet de discuter en dehors du bureau et de sujet différent du travail. 2 ème Partie : Les missions et les apports du stage I. Les missions 1. Le protocole Domain Keys Identified Mail (DKIM) Du fait de ses objectifs, Interview SA est un grand diffuseur de mails de sollicitation d enquête. Cependant, certains des ces mails peuvent être considérés comme des spams 1. Il fallait donc trouver une solution pour améliorer la délivrabilité des mails de diffusion de Interview. L équipe du département Dev-Produits a pensé que la mise en place d un système de signature électronique, le protocole Domain Key Indentified Mail (DKIM), pourrait être cette solution. Ma mission consistait donc dans un premier temps de mener une étude sur ce protocole afin que l équipe soit en mesure d apprécier et de comprendre son fonctionnement. Puis, en fonction de mes résultats, il serait décidé si oui ou non, le protocole serait mis en place. Les étapes de mon étude sont les suivantes : - la compréhension du principe et du fonctionnement général de DKIM, - comment DKIM peut aider Interview SA à être considéré comme non spammeurs? - la rechercher d autres alternatives à DKIM, - la recherche des Fournisseurs d Accès Internet (FAI) et des clients qui utilisent DKIM, - quelles sont les procédures et étapes pour une éventuelle mise en place au sein de Interview? Le protocole DKIM est une norme d authentification fiable du nom de domaine de l expéditeur d un courrier électronique. Il est la résultante d un consortium industriel en Il intègre et améliore DomainKeys, de Yahoo! et Identified Internet Mail, de Cisco Ce protocole donc est lié au courrier électronique. De ce fait, pour pouvoir le comprendre, j ai eu à revenir sur la définition du courrier électronique et surtout sur la description du trajet parcouru par un courrier électronique de son envoi à sa réception. Il en est ressorti que le courrier électronique ou courriel ou mail ou suit un parcours (de l envoi à la réception) qui peut être subdivisé en quatre étapes comme le montre la figure ci-après : 1 Voir Annexe A 12

13 Figure 3 1 : Etapes de l acheminement de courrier électronique Étape 1 : le Mail User Agent (MUA) ou client de messagerie de l expéditeur envoie, utilisant SMTP 2 (Simple Mail Transfert Protocol), le message à un serveur de courriel (celui de son fournisseur d accès généralement) ou MTA (Mail Transfert Agent) ; étape2 : le premier MTA atteint route le message vers le MTA hébergeant le domaine du destinataire. Le MTA final délivre au MDA (Message Delivery Agent) qui est en charge de la gestion des boîtes aux lettres ; étape 3 : le destinataire, par l intermédiaire de son MUA, demande à son serveur de courrier (MDA) les nouveaux messages par l utilisation des protocoles IMAP (Internet Message Access Protocol) ou POP (Post Office Protocol) ; puis le destinataire, par l intermédiaire de son navigateur demande au serveur web de retrouver les nouveaux messages sur le MDA ; étape 4 : le serveur envoie le message au MUA du destinataire. Les notions de MUA, MTA, MDA, ont été importantes pour la compréhension du protocole que je devais étudié car que elles interviennent dans le fonctionnement de la signature DKIM. Pour illustrer, prenons l exemple suivant 3 : 1. L utilisateur compose le message From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: < F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. 1 Source 2 Voir Annexe A. De même pour IMAP et POP 3 Source : Annexe a du RFC

14 2. DKIM (qui peut être installer dans le MUA, mais sera en général dans le MSA (Mail Submission Agent) ajoutera une en-tête DKIM-Signature : DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; i=joe@football.example.com; h=received : From : To : Subject : Date : Message-ID; bh=2jusoh9nhtvgcqwnr9briaprekqjo6sn7xikfjvozv8=; b=auuofefdxtdkhllxszepzj79liceps6eda7w3detvfok4yauoqob 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [ ] by submitserver.example.com with SUBMISSION; Fri, 11 Jul :01: (PDT) From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: < F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. Cet entête est de type SMTP. Elle contient une série de valeurs séparées par des «;». L'une de ces valeurs est obtenue par le chiffrement asymétrique (RSA) de l'empreinte (SHA1 ou SHA256) d'une forme canonique du message et de certains de ses entêtes. Le destinataire du message peut déchiffrer cette empreinte au moyen de la clé publique du domaine signataire et vérifier l'intégrité du message en la recalculant. On observe que la technique utilisée est très similaire à celle utilisée pour la signature S/MIME ou PGP. L'entête «From:» faisant partie des entêtes qui sont toujours signés, sa falsification n'est possible qu'en disposant de la clé privée de signature. L identité est indiquée dans la signature pour éviter de longs débats sur l identité la plus pertinente parmi toutes les identités présentes dans le mail. Le MUA doit donc en tenir compte et afficher l adresse qui est authentifiée, pas seulement celle qui se trouve dans le champ From et qui peut être différente.la signification de chaque champ de cette signature ainsi que les différents algorithmes de chiffrement sont donnée dans l annexe C. 3. Vérification de la signature DKIM Le programme qui veut vérifier la signature (MTA (Mail Tranfert Agent ou Message Transfer Agent) mais cela peut être le MUA) doit récupérer la clé publique de la signature. DKIM récupère la clé via DNS ( Domain Name System), pour ne pas dépendre des lourdes et chères autorités de certification. Pour cela, il utilise le nom de domaine «example.com» extrait du tag «d=», ainsi que le sélecteur «brisbane» extrait du tag «s=» contenu dans l en-tête DKIM-Signature pour former DNS DKIM query suivant : brisbane._domainkey.example.com Puis la vérification de signature physique commence par l en-tête du champ Received, suivi de l en-tête du champ From, et ainsi de suite, suivant l ordre de la liste extraite de l étiquette «h=». La vérification se poursuit jusqu au CRLF (Carriage Return Line Feed : séquence de 14

15 deux octets qui indiquent la fin de la ligne). Le résultat de la requête précédente (DNS DKIM query) et des différentes vérifications est enregistré dans le champ d entête X-Authentication-Results.Ce qui correspond dans notre exemple à : X-Authentication-Results: shopping.example.net header.from=joe@football.example.com; dkim=pass Received: from mout23.football.example.com ( ) by shopping.example.net with SMTP; Fri, 11 Jul :01: (PDT) DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; i=joe@football.example.com; h=received : From : To : Subject : Date : Message-ID; bh=2jusoh9nhtvgcqwnr9briaprekqjo6sn7xikfjvozv8=; b=auuofefdxtdkhllxszepzj79liceps6eda7w3detvfok4yauoqob 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [ ] by submitserver.example.com with SUBMISSION; Fri, 11 Jul :01: (PDT) From: Joe SixPack <joe@football.example.com> To: Suzie Q <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: < F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. Au vu de cet exemple, deux actions importantes dans le processus de signature DKIM ressortent : la signature proprement dite et la vérification de signature. Pour résumé, on peut dire que le principe du protocole DKIM est le suivant : le serveur émetteur doit ajouter à l entête du message, un champ qui contient une signature électronique cryptée. Le serveur de mail qui reçoit le message peut alors interroger le serveur DNS de l expéditeur pour obtenir une clef qui lui permettra d'authentifier, ou non, le message et son expéditeur Cette étude a duré trois semaines. Au bout de la première semaine, une réunion a été organisée avec quatre membres de l équipe (dont mon maître de stage et le chef du département) pour présenter la première partie de l étude. Il ne s agissait pas d une présentation technique mais de donner un aperçu de ce qu était le protocole DKIM, une définition. A la fin de l étude, un document de synthèse a été rédigé puis j ai fait une présentation lors de la réunion d équipe qui a lieu le lundi matin. La conclusion de ma présentation était la suivante : le protocole DKIM, bien empêchant l usurpation de domaine et permettant de définir de manière non descriptive les serveurs pouvant envoyer des mails pour un domaine et de faire la réputation d un domaine, n avait aucun impact quant à la politique des filtres antispams. En d autres termes, DKIM ne permet pas à celui qui l utilise d être considéré comme non spammeurs. Au terme de cette réunion, la décision de ne pas mettre en place le protocole a été prise. Ce qui a donné lieu à un changement de mon sujet de stage. 15

16 2. Authentification avec Lightweight Directory Access Protocol (LDAP) La plupart des clients "grand compte" d'interview disposent d'un annuaire LDAP pour la gestion de leurs collaborateurs. Un besoin récurrent de ces clients est de pouvoir se connecter aux applications Interview?! en utilisant leur login / mot de passe LDAP. Les produits java d Interview dispose d'un service d'authentification (commun à tous les produits), s'appuyant sur la base de données des produits pour la gestion des accès. Les utilisateurs s'authentifient par un login / mot de passe via une requête SQL dans la base de données. Le but de cette partie du travail est d'améliorer ce service d'authentification en lui ajoutant une couche LDAP permettant éventuellement de déporter l'authentification à un annuaire LDAP. Au final, le service d authentification devrait fonctionner comme suit : Figure 4 : Service d authentification auprès des produits Interview (exemple avec dataview?!) (1) : Le client Interview tente de se connecter sur la page web du produit souhaité en donnant son login et mot de passe. (2) : l application de gestion d authentification lance, à partir du login du client, la recherche dans l annuaire LDAP 1.La connexion se fait avec le login/mot de passe de l administrateur de l annuaire LDAP. (3) : le résultat de la recherche est envoyé. 16

17 Si la recherche a été fructueuse (client trouvé), on passe au (4).Sinon, on reprend le (2) et le (3) avec l annuaire suivant. Et ainsi de suite jusqu à ce que soit le client est trouvé, soit il y a plus d annuaire à interroger. (4) : tentative de connexion avec le login/mot de passe du client. (5): résultat de la connexion : - si OK alors on passe au (8), - sinon, reprendre à partir du (2). (6), (7) : si la recherche auprès des annuaires LDAP ne donne rien, alors la gestion de l accès se fait au niveau de la base de données. (8) : accès au produit dataview?!. (9) : la recherche auprès des annuaires LDAP et l authentification avec la base de données n a pas été fructueuse, alors il est renvoyé au client que la connexion est un échec. La notion LDAP était assez vague pour moi. De ma formation, je savais juste que c était un annuaire électronique telle que DNS mais pas plus. Alors pour mener à bien cette mission, j ai prévu une journée pour comprendre le fonctionnement global de l annuaire LDAP (comment il est constitué? comment on y accède?). Le logiciel JXplorer 1 m a été d une grande aide pour voir à quoi ressemblait l architecture d un annuaire LDAP. Les spécifications de ma mission incluaient une étude du framework 2 JAAS (Java Authentification and Authorization Service) pour savoir dans quelle mesure il permettrait de mettre en place cette couche LDAP. Cependant, lors de ma recherche sur le fonctionnement de l annuaire, je me suis rendu compte qu il existait un autre framework qui lui aussi pourrait répondre à ce problème. Il s agit de JNDI (Java Naiming and Directory Interface). JNDI est un standard et une librairie de classes JAVA, élaboré par SUN (maintenant Oracle) afin de normaliser tout type d annuaire et de répertoire de noms. Mon choix s est initialement porté sur cet framework car son fonctionnement est simple et facile de mise en place. Pour définir une connexion, JNDI a besoin de deux éléments : - la fabrique du contexte racine : c est cet objet qui assure le dialogue avec le service utilisé en se basant sur le protocole adéquat ; - l url du service à utiliser (ici LDAP). Le code que j ai écrit n était constitué que d une seule classe, la classe LdapAuthentification.java construite suivant le principe de JNDI se divisant en trois parties : l initialisation, la recherche et la connexion qui sont représentés respectivement par un constructeur et deux méthodes. L initialisation consiste en : - l importation des paquetages requis pour JNDI : i. javax.naming.* qui contient les classes Java et les interfaces pour accéder à des services de noms ; ii. javax.naming.directory.* qui est une extension du paquetage précédent qui offre des services complémentaires dédiés aux annuaires. - La paramétrisation de l environnement nécessaire au contexte de connexion. Cet environnement est une Hashtable. Il est modifiable à tout moment durant l exécution de l application. Les informations qui y sont entrés sont : 1 JXplorer est client LDAP développé en Java sous une licence opensource de type OSI. Il permet de lire ou de modifier la contenu de tout annuaire LDAP (Source : OpenVms) 2 Un framework, en programmation orientée objet, est typiquement composés, de classes mères qui seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui l utilisent (Source : Wikipédia). 17

18 i. le nom de la classe à utiliser comme fournisseur de service d annuaire. Dans notre cas, comme nous voulons LDAP, j ai rentré la classe «com.sun.jndi.ldap.ldapctxfactory» ; ii. l adresse de l annuaire LDAP à laquelle on veut se connecter. J ai utilisé l adresse du LDAP de Interview ; iii. les paramètres d identification. Si ces paramètres ne sont pas spécifiés, on parle d identification anonyme. Dans le code que j ai écrit j ai choisi une identification simple (les valeurs possibles sont none, simple, ou strong), en donnant le Distinguish Name 1 et le mot de passe d un administrateur pour la recherche. Ces informations sont récupérées à partir d un fichier properties que j ai initialement rempli. La partie recherche consiste en la connexion à l annuaire, suivi de l identification et enfin de la recherche proprement dite. Cette dernière consiste en la définition des options de la recherche comme suit : SearchControls ctrl = new SearchControls(); ctrl.setsearchscope(searchcontrols.subtree_scope) La deuxième ligne de code précise que la recherche doit se faire dans les nœuds sous-jacents à l objet de base. Puis, j ai utilisé la méthode search() de la classe DirContext en spécifiant l objet de base de la recherche puis le filtre. Pour ce qui est du filtre, j ai fait en sorte que la recherche se fait soit sur le prénom (SurName(SN)), soit sur le nom (givenname) ou soit sur le nom et prénom(common Name(CN)). A la fin de la méthode de recherche, si elle a été fructueuse, je récupère le DN du client qui a tenté de se connecter pour effectuer la connexion avec son mot de passe. C est la méthode connectuser(string login, String pwd) qui gère cette connexion. Elle ne diffère pas de la partie connexion de la méthode de rechercher. Le seul changement est dans l identification : les DN et mot de passe rentrés ne sont plus ceux de l administrateur de l annuaire, mais ceux du client qui tente de s authentifier. J ai présenté ma solution lors d une réunion avec mon maître de stage. Suite à celle-ci, elle m a demandé de voir dans quelle mesure je pouvais adapter ce que j avais fait avec JNDI à l authentification avec JAAS. Ayant approfondi mes recherches sur JAAS, je me suis rendu compte que cet framework, bien que moins simple que JNDI, avait un niveau de sécurité plus élevé. JAAS a la particularité de séparer la gestion des droits d accès aux composants J2EE du code métier. Le fonctionnement de JAAS se fait en deux temps : authentification c est-à-dire validation de l identité du client, puis autorisation. De plus, grâce à «LoginModule», JAAS implémente plusieurs algorithmes qui réalisent l authentification selon un mécanisme bien choisi tel que JndiLoginModule. Ce dernier réalise l authentification à travers un service d annuaire configuré sous JNDI. Je pouvais donc adapter ce que j avais fait avec JNDI. La mise en œuvre de cette solution a nécessité trois classes : - la classe LdapCallBackHandler qui implémente l interface CallbackHandler. Cette interface gère les callbacks (demande d informations telle que le login et le mot de passe) ; 1 Voir Annexe A. De même que pour SN, givenname et CN. 18

19 - la classe LdapModule qui implémente l interface LoginModule. C est une interface du composant d authentification, implémentée par le fournisseur d authentification ; - et enfin, la classe LdapPrincipal qui implémente l interface Principal. Un principal représente l identité du demandeur de connexion. D autres classes interviennent dans la mise en œuvre de JAAS. Il s agit de : - Subject : représente le demandeur. Il peut avoir plusieurs identités ou principals. - LoginContext : avec méthode «login()», elle exploite les modules décrites dans la configuration de JAAS. - Callback : interface de demande d'information (login, password). JAAS utilise un fichier de configuration «.config» qui a une certaine syntaxe et où sont spécifié toutes les options dont a besoin le LoginModule de se mettre en place. Cette syntaxe est la suivante : Name { }; Name { ModuleClass Flag ModuleClass Flag ModuleClass Flag ModuleClass Flag ModuleClass Flag ModuleOptions; ModuleOptions; ModuleOptions; ModuleOptions; ModuleOptions; }; Le ModuleClass est le nom de la classe qui implémente LoginModule. Les flags permettent de spécifier la façon dont se fera l authentification en cas d échec ou de succès du LoginModule. Ce sont : «required», «requisite», «sufficient» ou «optional». Leur définition est donnée en annexe D. ModuleOptions sont les différentes options de connexion. Dans notre cas il s agit du nom du serveur LDAP, le login/mot de passe de l administrateur pour la recherche, les clés de recherche Le fichier de configuration que j ai utilisé pour la connexion est donné en annexe D. Pour les tests, j ai utilisé l annuaire LDAP de la Interview, ainsi que les différents annuaires publiques que j ai trouvé sur Internet. Les tests devaient portés sur tous les cas possibles. De ce fait, utiliser une méthode «main» pour les tests était inutile. De plus, il me fallait écrire des tests tels que si il y avait une modification de mon code dans le futur, ils attesteraient toujours le bon fonctionnement de l application. Il m a alors été suggérer d utiliser les tests unitaires JUnit 1. Ma classe de test contient quatre tests qui gère la tentative de connexion avec soit le nom, soit le prénom, soit le nom prénom ; un test pour la gestion d un client qui n est dans aucun annuaire LDAP spécifié ; un test avec un mot de passe incorrect. Pour la connexion, je crée un LoginContext ayant pour paramètres le nom du module où il faudra aller chercher les informations de connexion ainsi que les login et mot de passe de l utilisateur. Ces derniers sont les paramètres du LdapCallBackHandler. Puis je lance la méthode login(). Après une mise au point avec mon maître de stage, cette solution a été adoptée puis remontée sur le serveur SVN 2 de la société. Elle sera utilisée plus tard sur les produits Interview. 1 Voir paragraphe sur les compétences acquises. 2 SVN ou Subversion est un logiciel de gestion des versions. Un serveur SVN permet de sauvegarder un code, de récupérer une version ancienne si la nouvelle présente des erreurs et de partager un projet. 19

20 3. Cryptage du mot de passe en base de données Actuellement, les mots de passe de la base de données sont écrits en dur et non cryptés. La mission qui m a été confié alors est de trouver et de mettre en place une méthode de cryptage qui réponde aux spécifications suivantes : - cryptage du mot de passe doit se faire en une fois car il sera mis en dur en base de données ; - si un utilisateur perd son mot de passe et demande à le récupérer, l application doit être capable de renvoyer le mot de passe initiale en décryptant celui qui se trouve dans la base de données. Cette deuxième spécification écarte la méthode de cryptage avec une fonction de hachage (md5, sha) qui, bien que très sécurisant, est à sens unique. La solution est donc d utiliser un crypto système à clé publique. Le fonctionnement global de ce dernier est résumé sur le schéma suivant : Figure 5 1 : Cryptographie à clé publique La méthode de chiffrement à clé publique RSA est la solution qui a été choisie et implémentée. La raison de ce choix est, en plus du fait que c est un crypto système que je connais bien( l ayant étudié en cours), Java possède des paquetages qui facilitent sa mise en place. Il s agit des paquetages java.security et java.security.interfaces. Ces derniers fournissent les classes et interfaces suivants : - KeyPairGenerator qui gère la génération de paire de clé publique et clé privée ; - SecureRandom qui fournit un générateur de nombre aléatoire très fort du point de vue de la cryptographie ; - KeyPair qui est un simple conteneur de paire de clé publique/privée ; - RSAPrivateKey et RSAPublicKey. Le code écrit pour la mise en place de cette solution est constitué des deux méthodes cryptermessage(string message) et decryptermessage(string messcrypte). Leur principe est le suivant : - «Bob veut envoyer à Alice le message M. Il utilise la clé publique représenté par le couple (n, e) pour coder le message. n = p*q, avec p et q deux entiers premiers très grands. e = 1/d mod((p-1)(q-1)) avec d un nombre premier avec (p-1)*(q-1). Bob fait alors le calcul c = M exp(e) mod(n).» 1 Source 20