Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc i
Epigraphe LIRT 2011-2012
Epigraphe
«...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc ii
Dédicaces LIRT 2011-2012
Dédicaces
...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc iii
Remerciements LIRT 2011-2012
Remer...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc iv
Liste des abréviations LIRT 2011-20...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc v
Liste des figures LIRT 2011-2012
Lis...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc vi
Avant-propos LIRT 2011-2012
Avant-p...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc vii
Avant-propos LIRT 2011-2012
 Géni...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc viii
Résumé LIRT 2011-2012
Résumé
La m...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc ix
Abstract LIRT 2011-2012
Abstract
Th...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc x
Sommaire LIRT 2011-2012
Sommaire
Epi...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc xi
Sommaire LIRT 2011-2012
2.2.1 Le me...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 1
Cahier des charges LIRT 2011-2012
Ca...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 2
Cahier des charges LIRT 2011-2012
Tr...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 3
Introduction générale LIRT 2011-2012...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 4
Chap. 1 : Généralité sur l’authentif...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 5
Chap. 1 : Généralité sur l’authentif...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 6
Chap. 1 : Généralité sur l’authentif...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 7
Chap. 1 : Généralité sur l’authentif...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 8
Chap. 1 : Généralité sur l’authentif...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 9
Chap. 1 : Généralité sur l’authentif...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 10
Chap. 1 : Généralité sur l’authenti...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 11
Chap. 1 : Généralité sur l’authenti...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 12
Chap. 1 : Généralité sur l’authenti...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 13
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 14
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 15
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 16
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 17
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 18
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 19
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 20
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 21
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 22
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 23
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 24
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 25
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 26
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 27
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 28
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 29
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 30
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 31
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 32
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 33
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 34
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 35
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 36
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 37
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 38
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 39
Chap. 2 : choix de la solution, con...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 40
Chap. 3 : résultats obtenus et pers...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 41
Chap. 3 : résultats obtenus et pers...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 42
Chap. 3 : résultats obtenus et pers...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 43
Chap. 3 : résultats obtenus et pers...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 44
Chap. 3 : résultats obtenus et pers...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 45
Chap. 3 : résultats obtenus et pers...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 46
Conclusion générale LIRT 2011-2012
...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 47
Bibliographie LIRT 2011-2012
Biblio...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 48
Annexes LIRT 2011-2012
Annexes
Anne...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 49
Annexes LIRT 2011-2012
Annexe 2 : f...
Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 50
Annexes LIRT 2011-2012
Annexe 3 : f...
Upcoming SlideShare
Loading in...5
×

Rapport projet3

1,599

Published on

Système d'authentification centralisé SSO avec fournisseur d'identités

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,599
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
87
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Rapport projet3"

  1. 1. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc i Epigraphe LIRT 2011-2012 Epigraphe « Je n’ai pas peur des ordinateurs. Mais j’ai peur qu’ils viennent à nous manquer » Isaac ASIMOV
  2. 2. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc ii Dédicaces LIRT 2011-2012 Dédicaces A nos parents
  3. 3. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc iii Remerciements LIRT 2011-2012 Remerciements Nous ne saurons amorcer la rédaction de ce mémoire sans penser à tous ceux qui directement ou indirectement ont contribué à sa réalisation. Nous tenons donc à les remercier du plus profond de notre cœur. Nous exprimons notre gratitude :  Au Dieu tout puissant pour nous avoir donné tout le nécessaire durant la réalisation de ce travail.  A tout le corps administratif et enseignant de l’IUT Fotso Victor de Bandjoun pour tout leur effort mené au quotidien pour notre formation.  A notre encadreur M. LIENOU pour son soutien professionnel, sa disponibilité et ses encouragements qui ont été indispensables à la réalisation de ce travail.  A la famille KAPDJOU, notamment mon père M. KAPDJOU Mathias et ma mère Mme WETTE Rachel pour leur soutient inestimable.  A la famille MODO, particulièrement à Mme. NGA MODO Germaine, Mme ESSO Odile, Mme. NGO EOCK Nicole, M. ADETONAH Ricardo pour leur assistance et soutient sans pareil.  A M. PENTANE K. Yaya chef section réseau à CAMTEL Douala pour sa contribution précieuse à la réalisation de ce projet.  A mon oncle M. TCHEPKEU Etienne pour son aide social et ses nombreux conseils.  A toute la famille GTR de Bandjoun particulièrement LIRT 2011-2012 pour la solidarité menée durant cette année académique.  A nos camarades notamment FANDOM Martial, DJIKI Armand, CHATUE Herman et CHUMCHOUA Malcom.  A tous ceux qui, de prés ou de loin, ont participé à la réalisation de ce travail.
  4. 4. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc iv Liste des abréviations LIRT 2011-2012 Liste des abréviations ADN : Acide Désoxyribonucléique BD : Base de Données CAS : Central Authentication Service CNIL : Commission Nationale Informatique et Liberté CRU : Commission Réseau des Universités DNS : Domain Name System HTTP : HyperTest Transport Protocol IBM : Industry Business Machine IdP : Identity Provider IETF : Internet Engineering Task Force IMAP : Internet Message Access Protocol IP : Internet Protocol JAAS : Java Authentication and Authorization Service JDBC : Java DataBase Connectivity JRE : Java Runtime Environnement JDK : Java Development Kit LDAP : Lightweight Directory Access Protocol OASIS : Advanced Open Standard for the Information Society OTP : One Time Password PC : Personal Computer PKI : Public Key Infrastructure PME : Petite et Moyenne Entreprise SGBD : Système de Gestion de Base de Données SMS : Short Message Service SP : Service Provider SSO : Single Sign-On SSL : Secure Socket Layer SAML : Security Assertion Markup Language TCP : Transport Control Protocol TGC : Ticket Granting Cookie TPE : Très Petite Entreprise UDP : User Datagram Protocol URL : Uniform Resource Locator VLDAP : Virginia tech LDAP module VPN : Virtual Private Network WAYF : Where Are You From WWW : World Wide Web XML : eXtended Markup Language
  5. 5. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc v Liste des figures LIRT 2011-2012 Liste des figures Figure 1: problème de l’utilisateur .......................................................................................................... 8 Figure 2 : problème de l’administrateur .................................................................................................. 9 Figure 3 : problème générale................................................................................................................... 9 Figure 4 : centralisation de l'authentification ........................................................................................ 10 Figure 5 : authentification centralisée à l'annuaire LDAP..................................................................... 10 Figure 6 : principe d'authentification unique......................................................................................... 11 Figure 7 : principe de la fédération d'identités ...................................................................................... 12 Figure 8 : architecture du serveur CAS................................................................................................. 17 Figure 9 : fonctionnement de base de CAS........................................................................................... 18 Figure 10 : redirection transparente vers le serveur CAS...................................................................... 18 Figure 11 : validation pour l'accès à une ressource ............................................................................... 19 Figure 12 : accès à l'application sans authentification........................................................................... 20 Figure 13 : validation du PT pour l'accès à une ressource..................................................................... 20 Figure 14 : CAS dans l'architecture n-tiers............................................................................................ 21 Figure 15 : fonctionnement du WAYF.................................................................................................. 22 Figure 16 : requête du navigateur vers le fournisseur de service .......................................................... 23 Figure 17 : redirection de l'IdP vers le SP............................................................................................. 23 Figure 18 : le SP demande les attributs de l’utilisateur......................................................................... 24 Figure 19 : réponse du SP au navigateur............................................................................................... 24 Figure 20 : fonctionnement de Shibboleth sans CAS............................................................................ 25 Figure 21 : redirection du navigateur vers le serveur de SSO............................................................... 26 Figure 22 : fonctionnement de Shibboleth avec SSO............................................................................ 27 Figure 23 : requete suivant le meme SP ................................................................................................ 27 Figure 24 : délégation d'authentification vers un autre SP.................................................................... 28 Figure 25 : redirection transparente vers le WAYF .............................................................................. 28 Figure 26 : redirection du WAYF vers le serveur de SSO.................................................................... 29 Figure 27 : réponse du SP après authentification du serveur SSO ........................................................ 29 Figure 28 : réponse du SP sans authentification.................................................................................... 30 Figure 29 : le WAYF en action dans une fédération............................................................................. 30 Figure 30 : architecture du système....................................................................................................... 32 Figure 31 : principe de l'OTP ................................................................................................................ 44
  6. 6. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc vi Avant-propos LIRT 2011-2012 Avant-propos L’institut universitaire de technologie FOTSO Victor de BANDJOUN (IUT-FV) a été construit en 1987, par le fondateur donateur FOTSO Victor dont l’établissement porte le nom sous l’appellation initiale de « collège privé laïc polyvalent FOTSO Victor ». La structure a été cédée à l’Etat camerounais le 12/08/1993. Elle devient plus tard Institut Universitaire de Technologie FOTSO Victor de BANDJOUN suite à la réforme universitaire de janvier 1993. Cet institut fait partie aujourd’hui des établissements de l’université de DSCHANG. Il forme des techniciens et des ingénieurs de travaux dans quatre (04) cycles: DUT (Diplôme Universitaire de Technologie) où l’admission se fait uniquement sur concours avec pour diplôme de base : Bac C, D, E, F. Pour une durée de 2ans, Ses filières sont :  Génie Informatique (GI)  Génie Electrique (GE) : (02) options  Electronique (EN)  Electrotechnique (EL)  Génie des Télécommunications et Réseaux (GTR)  Génie Mécanique et Productique avec pour option Maintenance Industrielle et Productique (MIP)  Génie Civil (GC) BTS (Brevet de Technicien Supérieur) où l’entrée se fait sur étude de dossier et entretien. Pour 2 ans également, les filières sont :  Comptabilité et Gestion des Entreprises (CGE)  Banque et finance (BF)  Secrétariat de Direction (SD)  Action Commerciale (AC)  Génie Civil (GC)  Génie Electrique (GEL) : (02) options  Electronique (EN)  Electrotechnique (EL) LICENCE TECHNOLOGIQUE dans les spécialités :  Concepteur et Développeur Réseaux Internet
  7. 7. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc vii Avant-propos LIRT 2011-2012  Génie Electrique  Ingénierie des Réseaux et Télécommunications  Maintenance Industrielle et Productique  Génie Géomatique  Génie Thermique, Energétique et Environnement LICENCE PROFESSIONNELLE dans les spécialités :  Gestion Administrative et Management des Organisations (GAMO)  Gestion Comptable et Financière (GCF)  Commerce-Marketing (CM) : (02) options  Marketing Manager Opérationnel (MMO)  Banque et Gestion de la Clientèle (BGC) L’IUT dispose en plus d’une formation CISCO dont la durée dépend de l’option choisie à savoir:  CITE 1 & 2  CCNA 1 & 2 En somme, l’IUT FOTSO Victor de Bandjoun avec son administration entreprenante, des enseignants dotés d’une conscience professionnelle et ses étudiants bénéficiant de son lotissement très propice à l’enseignement, a un avenir promoteur. Tout étudiant en fin de formation de licence de technologie doit faire un projet en vue de s’imprégner des réalités du monde professionnel. Au terme de ce projet, l’étudiant devra rédiger un rapport, qui sera exposé devant un jury, d’où la raison d’être du document porté sur « la mise en œuvre d’un système d’authentification centralisé (SSO) avec fournisseur d’identités dans un intranet ».
  8. 8. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc viii Résumé LIRT 2011-2012 Résumé La mémorisation de multiples mots de passe est devenue un problème pour les utilisateurs. Pendant qu’un système SSO1 mémorise les mots de passe pour chaque application à la place des utilisateurs, le fournisseur d’identité permettra d’étendre le champ d’action de ces utilisateurs hors de l’entreprise. L'intranet est aujourd'hui une ressource informatique indispensable à une organisation et destiné essentiellement à mettre en place les services avec conditions d'utilisation. Ainsi, la centralisation d’authentifications est un élément important dans un intranet. Aussi, La mise en place d’un système Single Sign-On avec fournisseur d’identité va épargner la tête des utilisateurs en ne leur faisant mémoriser qu’un seul mot de passe et leur doigts ne seront plus sollicités car ils ne s’authentifieront qu’une seule fois pour accéder à un nombre important d’applications. Ce projet de fin d’études implémenté est une association de plusieurs serveurs. En effet, la configuration des serveurs CAS2 et Shibboleth3 est un exercice professionnel qui demande beaucoup de compréhension en ce qui concerne le principe de fonctionnement. C’est la raison pour laquelle notre encadreur a attiré notre attention sur tous les éléments qui entrent en jeux et à beaucoup insisté sur la sécurité pour l’accès au système. Cela nous a permis de mieux cerner les notions sur l’authentification forte et les difficultés rencontrées nous ont ainsi ouvert l’esprit en ce qui concerne le milieu professionnel en évaluant l’importance de la formation reçue à l’IUT-FV. 1 Single sign-on : une seule authentification pour plusieurs applications 2 Serveur de SSO 3 Fournisseur d’identités
  9. 9. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc ix Abstract LIRT 2011-2012 Abstract The memorizing of multiple passwords became a problem for the users. While a system SSO memorizes the passwords for each application to the place of the users, the supplier of identity will allow to extend the sphere of activity of these users out of the company. The Intranet is today a data-processing resource essential to an organization and primarily intended to set up the services with conditions of use.Thus, the centralization of authentifications is a significant element in an Intranet.Also, the installation of a system Single Sign it with supplier of identity will save the head of the users by making them memorize that only one password and their fingers will not be requested any more because they will authenticate only once to reach a significant number of applications. This project of end of studies implemented is an association of several waiters. Indeed, the configuration of the waiters CASE and Shibboleth are a professional exercise which requires much comprehension with regard to the principle of operation.This is why our encadror drew our attention to all the elements which enter in plays and to insisted much on safety for the access to the system.That enabled us to better determine the concepts on the strong authentification and the encountered difficulties thus opened us the spirit with regard to the professional environment by evaluating the importance of the formation received in Iut-fv.
  10. 10. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc x Sommaire LIRT 2011-2012 Sommaire Epigraphe ................................................................................................................................................. i Dédicaces ................................................................................................................................................ ii Remerciements.......................................................................................................................................iii Liste des abréviations............................................................................................................................. iv Liste des figures....................................................................................................................................... v Avant-propos.......................................................................................................................................... vi Resumé.................................................................................................................................................viii Abstract .................................................................................................................................................. ix Sommaire ................................................................................................................................................ x Cahier des charges................................................................................................................................... 1 Introduction générale............................................................................................................................... 3 Chapitre 1 : Géneralites sur l’authentification..................................................................................... 4 1.1 Les acteurs et services d’authentification.................................................................................. 4 1.1.1 Pourquoi utiliser un service d’authentification ?................................................................ 4 1.1.2 Les acteurs d’authentification............................................................................................. 4 1.1.3 Les services d’authentification........................................................................................... 5 1.1.4 Les protocoles d’authentification ....................................................................................... 6 1.2 Méthodes d’authentification...................................................................................................... 7 1.2.1 Présentation ........................................................................................................................ 7 1.3 Analyse de l’existant ................................................................................................................. 8 1.3.1 Probléme de l’utilisateur..................................................................................................... 8 1.3.2 Probléme de l’administrateur ............................................................................................. 8 1.3.3 Probléme general................................................................................................................ 9 1.4 Justification du theme.............................................................................................................. 10 1.4.1 Centraliser l’authentification............................................................................................ 10 1.4.2 Authentification unique.................................................................................................... 11 1.4.3 La délégation d’identités .................................................................................................. 12 Chapitre 2 : Choix de la solution, conception et mise oeuvre ........................................................... 13 2.1 Choix de la solution................................................................................................................. 13 2.1.1 Présentation des solutions................................................................................................. 13 2.1.2 Le choix de la solution cas-shibboleth ............................................................................. 15 2.2 Conception............................................................................................................................... 16
  11. 11. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc xi Sommaire LIRT 2011-2012 2.2.1 Le mecanisme de cas........................................................................................................ 16 2.2.1.1 Architecture............................................................................................................... 16 2.2.1.2 Fonctionnement de base ............................................................................................ 17 2.2.1.3 Accès à une ressource protegée apres authentification.............................................. 18 2.2.1.4 Accès à une ressource protegee sans authentification préalable…………………….19 2.2.1.5 Principe de mandat avec cas..................................................................................... 20 2.2.2 Le mécanisme de shibboleth ............................................................................................ 21 2.2.2.1 Architecture............................................................................................................... 21 2.2.2.2 Fonctionnement de shibboleth sans cas..................................................................... 23 2.2.2.3 Fonctionnement de shibboleth avec sso .................................................................... 26 2.2.2.4 Fonctionnement de shibboleth dans une fédération .................................................. 28 2.3 Mise en oeuvre ........................................................................................................................ 31 2.3.1 Présentation de l’intranet.................................................................................................. 31 2.3.2 Centralisation de l’authentification .................................................................................. 32 2.3.3 Configuration des serveurs............................................................................................... 34 2.3.3.1 Installations ............................................................................................................... 34 2.3.3.2 Configuration du serveur idp shibboleth ................................................................... 37 Chapitre 3 : Résultats obtenus et perspectives .................................................................................. 40 3.1 Résultats obtenus..................................................................................................................... 40 3.2 Perspectives............................................................................................................................. 43 3.2.1 Authentification forte ....................................................................................................... 44 3.2.1.1 L’otp.......................................................................................................................... 44 3.2.1.2 Authentification biometrique..................................................................................... 44 3.2.2 Une fédération d’identités fonctionnelle ......................................................................... 45 Conclusion générale .............................................................................................................................. 46 Bibliographie......................................................................................................................................... 47 Annexes................................................................................................................................................. 48
  12. 12. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 1 Cahier des charges LIRT 2011-2012 Cahier des charges THEME : Mise en œuvre d’un système d’authentification centralisé SSO avec fournisseur d’identité dans un intranet. Définition des mots clés SSO : service d’authentification unique pour l’accès à un ensemble d’application. Fournisseur d’identité : organisation membre d'une fédération gérant l'identité informatique d'un ensemble d'utilisateurs et offrant un service d'authentification à ses utilisateurs, afin de s'authentifier sur le réseau. Problématique Comment permettre aux utilisateurs d’applications d’entreprise, des universités ou de toutes autres instances de s’authentifier une seule fois pour un accès global aux différentes ressources tout en se rassurant de leur identité ? Motif Répondre aux besoins d’authentification unique et de fourniture d’identités de plus en plus réclamés dans les entreprises et les universités dans le cadre d’un accès à un service. Identification du projet Il est question ici de mettre sur pied un système qui authentifie une seule fois un utilisateur pour qu’il accède à toutes les applications de l’intranet centralisées par un référentiel. En outre, c’est aussi un système constituant un fournisseur d’identités. Cela s’explique simplement par les procédures à mettre en place pour la participation d’un intranet à une fédération d’identités.
  13. 13. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 2 Cahier des charges LIRT 2011-2012 Travaux préliminaires :  Brève présentation des systèmes d’authentification  Présenter les avantages des systèmes d’authentification centralisée  Présenter les apports d’authentification SSO et d’un fournisseur d’identités  Inventaire des solutions possibles  Présenter la solution motivée et son fonctionnement  Donner une architecture du système Moyens  Utilisation des systèmes d’exploitations GNU/LINUX distribution DEBIAN version 6.0.1 et Microsoft Windows pour les clients.  Utilisation des logiciels libre tels que OpenLDAP, SAMBA, Tomcat, Shibboleth, CAS client et CAS server. Fonctionnalités attendues :  Authentification centralisée avec l’annuaire LDAP  Contrôleur de domaine avec le serveur SAMBA  Génération de l’arbre de base au sein de l’annuaire LDAP pour le contrôleur de domaine SAMBA.  Déployer le fournisseur d’identité avec la brique Shibboleth pour avoir la possibilité d’accéder à une fédération.  Serveur de SSO déployé avec CAS, si possible Shibboleth pour donner la possibilité d’une authentification unique. Durée du projet : 4 mois Encadreur : M. LIENOU Jean Pierre
  14. 14. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 3 Introduction générale LIRT 2011-2012 Introduction générale L’universalité du protocole HTTP4 a depuis longtemps séduit les développeurs car les applications portées sur le web sont de plus en plus nombreuses et l’accès à ces applications est engendré par l’authentification. Avec un nombre croissant d'applications à leur disposition, et donc avec autant de mots de passe à mémoriser, les utilisateurs et les administrateurs font de leur mieux : ils inscrivent ces codes secrets dans leur agenda papier, les notent sur des Post-it5 qu'ils collent autour de leur écran ou, plus simple, laissent leurs connexions ouvertes lorsqu'ils quittent leur poste de travail. La fédération d’identité dans les systèmes d’authentification unique en ligne est depuis quelques années déjà au cœur de multiples débats, en entreprise, au sein des universités, et parmi les acteurs majeurs du Web. Le fournisseur d’identité permettra d'offrir à l'internaute un service web plus optimisé. Il apporte sécurité et confort à l’utilisateur aussi bien dans sa vie privée que dans sa vie professionnelle, tout en renforçant l'attractivité des médias. Le présent rapport est structuré en trois chapitres, dans lequel, nous présenterons une grande majorité des méthodes d’authentification et aussi les différents services d’authentification sans oublier de déclarer certaines problématiques qui nous permettrons de justifier notre projet. En plus, nous présenterons certaines solutions pour ce projet et nous insisterons sur le mécanisme de fonctionnement des solutions choisies telles que CAS et Shibboleth. Nous détaillerons les différentes étapes de la réalisation de ce projet et sa configuration. Le dernier chapitre sera un dossier spécifiquement centré sur les résultats obtenus et les perspectives concernant le renforcement de la sécurité, et une fédération d’identités pour notre université. Pour des raisons de temps, de moyens et de compatibilité entre les systèmes, ces perspectives n’ont pas fait parti de nos objectifs. Mais cela reste possible selon nos pronostics. 4 Protocol d’application utilisé par le navigateur servant au transfert des pages web 5 Papier destiné à enregistrer les petites informations le plus souvent provisoire
  15. 15. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 4 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012 HAPITRE 1 : GENERALITES SUR L’AUTHENTIFICATION Introduction Ce chapitre est consacré à l’étude de l’authentification dans un intranet, de l’analyse des systèmes existants et de la justification du thème. Cette étude va nous permettre par la suite de mener à bien le projet. 1.1 LES ACTEURS ET SERVICES D’AUTHENTIFICATION 1.1.1 POURQUOI UTILISER UN SERVICE D’AUTHENTIFICATION ? Tout d'abord, il faut se souvenir que dans des temps très reculés à l'échelle de l'informatique, dans les années 70, les terminaux étaient reliés au serveur par des liens spécialisés. Pour s'infiltrer, un hacker devait donc obligatoirement se brancher physiquement sur ces liens. Lorsque les réseaux ont commencé à utiliser un modèle client-serveur6 et que les terminaux ont été remplacés par les PC, les administrateurs ne pouvaient plus avoir confiance aux utilisateurs. En effet, ceux-ci peuvent désormais modifier un logiciel ou écouter le réseau. Il a donc fallu mettre en place un système permettant de rétablir cette confiance sur le réseau. La solution proposée est la mise en place d'un système d'authentification, permettant de rétablir la confiance dans le réseau, car dès lorsque les interlocuteurs se connaissent et peuvent s’identifier. Elle a été proposée pour la sécurité, afin que seules les personnes concernées puissent consulter les informations confidentielles. 1.1.2 LES ACTEURS D’AUTHENTIFICATION Ce sont les concepts et objets manipulés pendant l’authentification.  Un utilisateur Désigne une personne physique ayant les natures suivantes :  un étudiant 6 Système disposant d’un client pour les requêtes vers un serveur répondant à ces requêtes C
  16. 16. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 5 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012  un membre du personnel ou un client  une entité administrative  un administrateur informatique  un invité etc…  Un groupe Les utilisateurs peuvent être regroupés en groupe statique ou dynamique. Ces groupes sont utilisés pour faciliter la gestion en masse des habilitations. On peut regrouper ces acteurs en 3 natures : un client, un serveur proposant le service demandé et un serveur d'authentification.  Un compte A chaque personne peuvent être associés des comptes d’accès aux différents systèmes et applications. Le compte est défini par l’identifiant d’accès, un mot de passe, et plusieurs attributs supplémentaires, en fonction de l’environnement dans lequel il est crée comme : la politique de mot de passe associée, l’accès externe autorisé ou non, l’état du compte, les modes d’authentifications autorisés etc… Il existe quatre types de compte : Le compte global : Compte unique, identifie une personne dans le référentiel central et est utilisé par tous les processus d’attribution des droits. Le compte utilisateur : compte qui donne accès à un utilisateur dans un environnement particulier auquel cet utilisateur est habilité. Chaque compte utilisateur est obligatoirement associé à une personne. Le compte d’administration : Ce compte donne l’accès à un administrateur dans un environnement particulier. Il n’est pas associé à une personne. Le compte « de service fonctionnel ou technique » : Compte utilisé par les composants d’un système pour accéder aux services applicatifs et/ou données d’un autre système. Aucune personne n’est autorisée à l’utiliser. 1.1.3 LES SERVICES D’AUTHENTIFICATION Les termes associés aux services d’authentification sont : Identification, Authentification et Autorisation. Le travail de ces services est avant tout l'authentification. L'identification permet de vérifier l'identité d'une personne via un login par exemple. L'authentification permet de s'assurer qu'une personne est bien celle qu'elle prétend être par login et mot de passe.
  17. 17. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 6 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012 L'autorisation permet à partir de l'identification et l'authentification de définir des droits à une personne. Après la phase d’authentification des utilisateurs, le système pourra autoriser ces utilisateurs sur le service auquel ils tentent d’accéder par le contrôle de leurs droits d’accès. Le service d’autorisation est chargé d’évaluer les droits effectifs sur la base des informations fournies par le service d’authentification :  Authentification Windows pour SAMBA  Authentification accès distant (Radius)  Authentification Web Apache/IIS  Authentification SGBD Oracle/MySQL  Authentification messagerie (Webmail) On peut distinguer deux types d'authentification : l'authentification d'un tiers et l'authentification de la source des données. L'authentification d'un tiers consiste à prouver son identité. L'authentification de la source des données sert à prouver que les données reçues viennent de l’émetteur déclaré. 1.1.4 LES PROTOCOLES D’AUTHENTIFICATION De nombreux protocoles d’authentification requièrent une authentification de l’identité ou de l’équipement avant d’accorder des droits d’accès. Les principaux protocoles d’authentification sont :  RADIUS  TACACS  Kerberos. Les protocoles de la famille TACACS sont assez répandus. Ils utilisent le protocole TCP contrairement à RADIUS qui s’appuie sur UDP. Toutefois, ce ne sont pas des standards définis par un organisme de standardisation comme l’IETF. Seuls RADIUS et Kerberos sont des standards. Kerberos est mis en place dans l’authentification Windows 2000 au sein d’Active Directory. Ce protocole permet l’authentification des entités communicantes (clients et serveurs) et des utilisateurs.
  18. 18. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 7 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012 1.2 METHODES D’AUTHENTIFICATION Les méthodes d’authentification doivent être choisies en fonction du caractère stratégique et du risque liés aux ressources devant être protégées. 1.2.1 PRESENTATION Toutes les techniques d'authentification reposent sur l'utilisation d'un secret qui doit être unique et non falsifiable. Il existe plusieurs façons pour authentifier une personne (ou plus généralement, une entité). On peut se baser sur :  ce qu'il sait  ce qu'il a  ce qu'il est « Ce qu'il sait » est tout simplement un mot de passe qui va permettre, par comparaison ou par décryptage, par exemple, de vérifier que la personne est bien celle qu'elle dit être. « Ce qu'il a » est plus subtil car il fait appel à un objet que la personne à authentifier, a en sa possession. Le plus souvent, il s'agit d'un appareil générant « aléatoirement » une suite de nombres/caractères. Cette suite qui ne sera valable que pendant un temps donné, permettra d'utiliser des clés beaucoup plus longues, pour augmenter encore la sécurité pendant l’authentification. « Ce qu'il est » est justement une méthode encore peu utilisée pour le moment, et fait appel à des mécanismes de biométrie (empreinte digitale, rétine...). Cette technique n'est pas encore totalement utilisée, les raisons étant entre autres, le manque de logiciels l'utilisant réellement, ainsi que la rareté de matériels encore onéreux. L'intérêt de ce type de système est qu'il supprime la duplication, le vol, l'oubli et la perte. Cependant, à long terme, cette technique risque de ne pas être exempte de piratage.
  19. 19. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 8 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012 1.3 ANALYSE DE L’EXISTANT On constate de plus en plus de nos jours dans les universités un nombre croissant d’applications dédiées à la fois au personnel et aux étudiants engendrant un nombre incalculable de mots de passe à retenir pour chacune d’elle. 1.3.1 PROBLEME DE L’UTILISATEUR Généralement pas doué d’une expertise informatique, certains utilisateurs se retrouvent en général dans l’embarra, car ne sachant que faire de ces multiples mots de passe à leur disposition. C’est ainsi qu’ils les gardent dans des blocs notes ou à des endroits propices à leur divulgations, et parfois même les oublies. . 1.3.2 PROBLEME DE L’ADMINISTRATEUR Face aux problèmes de perte, d’oubli de mot de passe par les utilisateurs également face aux différentes tâches d’administration de l’ensemble des serveurs, il vient se poser le problème d’une possibilité d’administration et de gestion des mots des mots de passe des différents utilisateurs et des différents services configurés. L’on note :  Gestion du serveur d’authentification pour chaque application  Administration du réseau non centralisée. Figure 1: problème de l’utilisateur
  20. 20. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 9 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012  perte d’efficacité et de crédibilité des systèmes de sécurité multipliant les mots de passe.  Sans une centralisation : Une annuaire/bd par application 1.3.3 PROBLEME GENERAL Un fournisseur d’identité se trouve tenu à une disponibilité quasi permanente de ses équipes informatiques pour accomplir une tâche sans réelle valeur ajoutée. Comment proposer à nos utilisateurs un passeport unique pour accéder à leurs applications habituelles, qu’elles soient internes à leurs entreprises, externes, ou proposées par un partenaire ? Car 65 % des utilisateurs ont entre 4 et 10 mots de passe à retenir. Figure 2 : problème de l’administrateur Figure 3 : problème générale
  21. 21. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 10 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012 1.4 JUSTIFICATION DU THEME Mettre en place un système d’authentification pouvant répondre aux problèmes sus cités tout en garantissant l’identité des utilisateurs au sein d’une entreprise, d’une instance (à l’exemple du ministère des forêts et du ministère des finances) et même d’une fédération universitaire en particulier l’université de Dschang et ses différents établissements affiliés ( à l’exemple de l’iut-fv de bandjoun) tout en garantissant la confiance dans le réseau. Cela passe par : 1.4.1 CENTRALISER L’AUTHENTIFICATION C’est pour mettre en place un système central de gestion des identités pour l’accès à toutes les applications de l’intranet. Elle nous permet de partager une base commune. Le principe est de disposer d'une base de données globale pour centraliser toutes les demandes d’authentification des utilisateurs. Elle unifie la gestion des authentifications et des autorisations. Cela permet également de centraliser la gestion de la politique de sécurité. Un annuaire (LDAP) est un type particulier de base de données pour ce genre d’authentification. Figure 4 : centralisation de l'authentification Figure 5 : authentification centralisée à l'annuaire LDAP
  22. 22. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 11 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012 1.4.2 AUTHENTIFICATION UNIQUE Le Single Sign-On est une technique qui consiste à soumettre l’utilisateur à une procédure d’authentification unique et une seule fois par rapport aux différents services accessibles : applications web ou fonctions protégées du système. Il peut aussi prononcer les autorisations ou interdictions d’accès de l’utilisateur à l’ensemble des services, suivre l’activité et tracer les opérations effectuées. Son architecture est en général basée sur un serveur d’authentification (certificat X509, Kerberos). Il est composé : D’un serveur d’authentification C’est l’élément central du SSO puisqu’il assure :  L’authentification.  La persistance de la connexion.  La propagation de l’identité de l’utilisateur auprès des applications Il a la charge de vérifier le mot de passe de l’utilisateur auprès d’une base de référence (NIS, LDAP, /etc/passwd …). De l’agent d’authentification L’agent d’authentification est la brique SSO intégrée aux applications (librairie, module apache). L’agent vérifie que l’utilisateur est authentifié. S’il n’est pas authentifié, il le redirige vers le serveur d’authentification. Figure 6 : principe d'authentification unique
  23. 23. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 12 Chap. 1 : Généralité sur l’authentification LIRT 2011-2012 1.4.3 LA DELEGATION D’IDENTITES Le fournisseur d'identités permettra de déléguer l'identification des utilisateurs au sein d’un fournisseur de services externe. L’utilisateur peut se connecter de n’ importe où et pourquoi pas profiter d'un SSO. Mais le gain ne porte pas uniquement sur une plus grande simplicité d'utilisation des applications. Du point de vue de la sécurité, le fait de fédérer des applications autour d'une architecture Web unique permet de profiter d'une sécurité accrue grâce au chiffrement SSL.  Lorsqu’un utilisateur A accède à un service A1, l’authentification est basée sur le fournisseur d’identité A interne.  Lorsqu’ un utilisateur B externe à l’entreprise A accède à un service A2 l’authentification est basée sur le fournisseur d’identité B de son entreprise  Lorsqu’un utilisateur B accède à un service A2 externe à son entreprise et un service B1 interne à son entreprise, les deux services s’appuient sur le fournisseur d’identité de son entreprise. L’utilisateur B peut bénéficier ainsi d’un SS0 entre deux services. Tous les mécanismes de fédération d’identités se basent sur le principe fondamental d’existence d’une relation de confiance entre les partenaires qui ont décidé de collaborer. . Figure 7 : principe de la fédération d'identités
  24. 24. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 13 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 HAPITRE 2 : CHOIX DE LA SOLUTION, CONCEPTION ET MISE OEUVRE Introduction Au fil des années, différentes solutions de SSO et fournisseur d’identité ont été mis en œuvre. Si elles apportent satisfaction dans certains cas, certaines présentent aussi des particularités qui peuvent nous pousser à les choisir pour construire un système en fonction de nos besoins. 2.1 CHOIX DE LA SOLUTION Dans de nombreux domaines, les applications Web pour entreprise ont su se rendre incontournables. Plus rapide et moins coûteuses à déployer, avec une complexité d'administration au niveau des infrastructures réseaux, ces applications permettent aussi de simplifier, d'accélérer et d'amplifier les échanges entre l'entreprise et ses partenaires, clients ou fournisseurs. 2.1.1 PRESENTATION DES SOLUTIONS Il existe trois grandes classes d'approches pour la mise en œuvre des systèmes d'authentification : les approches centralisées, les approches fédératives et les approches coopératives. Derrière ces approches, on distingue des solutions libres telles que : OpenSSO, SAML, CAS, Shibboleth, OpenID et Liberty Alliance. 3.1.1.1 LA SOLUTION OpenSSO/OpenAM Portant le nom d’oracle OpenSSO en juillet 2008 puis le nom OpenAM depuis 2010, c’est l’un des serveurs d’authentifications unique et de fédération complet de l’OpenSource. 2.1.1.2 LA SOLUTION SAML SAML pour Security Assertion Markup Language permet entre autres la délégation d’authentification et sert de fondation à deux autres normes, Shibboleth et Liberty Alliance. 2.1.1.3 LA SOLUTION CAS C’est un service d'authentification centralisé SSO pour les applications Web, inspiré de Kerberos et basé sur le protocole HTTP(S). CAS pour Central Authentication Service a été C
  25. 25. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 14 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 développé par l'université de Yale aux Etats-Unis est un serveur d'authentification accessible par WWW, composé de servlets java, qui fonctionne sur tout moteur de servlets (Tomcat par exemple), ce qui fait ses points forts. 2.1.1.4 LA SOLUTION SHIBBOLETH Shibboleth est développé depuis 2001 par Internet2 et désigne à la fois une norme et un produit open source. C’est une extension de SAML qui enrichit ses fonctionnalités de fédération d’identités, en facilitant pour un ensemble de partenaires la mise en place de deux fonctionnalités importantes : la délégation d’authentification et la propagation d’attributs. Shibboleth a été conçu pour répondre aux besoins des communautés de l’enseignement supérieur et est déjà utilisé dans plusieurs pays : Etats-Unis, Angleterre, Suisse, France, etc… 2.1.1.5 LA SOLUTION OpenID OpenID implémenté et utilisé par les sociétés clés de l'Internet (Yahoo, MySpace, Google, Microsoft…), propose un protocole ouvert pour une gestion décentralisée d’identités, mettant l'utilisateur au centre des décisions le concernant. OpenID est développé et supporté par la fondation OpenId. Acteurs privés importants: Google, Yahoo, Microsoft et IBM. 2.1.1.6 LA SOLUTION LIBERTY ALLIANCE Liberty Alliance, implémenté par IBM et utilisé par Sun et Novell, utilise des jetons SAML. Ce modèle a été développé pour répondre à un besoin de gestion décentralisée des utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de sécurité, comme par exemple un ensemble de sites marchands indépendants d'un point de vue commercial et organisationnel. 2.1.1.7 LES AUTRES SOLUTIONS Aucune des sociétés de services internet vivant exclusivement de la publicité (payée par des professionnels) n'est actuellement capable de vérifier et de garantir les données saisies par les internautes. De plus chacune a développé son propre système d'authentification :  Yahoo avec Yahoo ID  Microsoft avec Live ID  Google avec Google Account  WS-Federation : Standard Web implémenté par Microsoft dans ses produits Active Directory Federation
  26. 26. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 15 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012  Sxipper  LemonLDAP:NG 2.1.2 LE CHOIX DE LA SOLUTION CAS-SHIBBOLETH Les solutions d’authentification présentées ci-dessus nous ont permis de voir certaines particularités ou certains avantages des unes par rapport aux autres. Pour répondre aux exigences de notre système, les particularités impressionnantes des solutions CAS et Shibboleth ne nous ont pas laissé seulement le choix de l’un d’entre eux. Nous avons donc associé ces deux solutions et cela se justifie : CAS est proposé comme mécanisme d’authentification centralisé de web SSO. Il ne traite pas les besoins liés aux autorisations (droits applicatifs), ni aux fédérations d’identités et au transport d'attributs. En outre, la base d’authentification est locale, au niveau de l’établissement. Les aspects inter-établissements ne sont donc pas pris en compte. Par contre, Shibboleth propose un mécanisme de transport d’attributs et d’authentification inter-établissements. De récentes discussions autour de Shibboleth laissent entendre qu’un mécanisme de SSO pourrait être proposé. Mais, Shibboleth à la possibilité de déléguer le SSO à CAS. CAS CAS est en production dans plusieurs Universités américaines, avec des authentifications internes Kerberos ou LDAP, ce qui permet d’être confiant sur sa fiabilité.  La sécurité est assurée par les dispositifs suivants : le mot de passe de l'utilisateur ne circule qu'entre le navigateur client et le serveur d’authentification, nécessairement à travers un canal crypté.  Des librairies clientes en Java, Perl, JSP, ASP, PL/SQL et PHP sont livrées. Cela permet une grande souplesse sur les serveurs d'applications. L’intégration dans des outils utilisés dans le monde universitaire est d’ores et déjà faite, comme celle d’uPortal.  L'utilisation de cookies exclusivement privés dans CAS (passage de tickets entre serveur d’authentification et applications uniquement sous forme de paramètres de GET HTTP) permet à CAS d'être opérationnel sur des serveurs situés dans des domaines DNS différents.
  27. 27. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 16 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012  Un module Apache (mod_cas) permet d'utiliser CAS pour protéger l'accès à des documents web statiques, les librairies clientes ne pouvant être utilisées dans ce cas.  Un module PAM (pam_cas) permet de « CAS-ifier » des services non web, tels que FTP, IMAP, ... SHIBBOLETH Le Comité Réseau des Universités a retenu Shibboleth pour construire une infrastructure de fédération d’identités pour l’enseignement supérieur français. Surtout la topologie d’une fédération de type Shibboleth correspond bien à la structuration d’un ensemble d’établissements de l’enseignement supérieur. De plus c’est un produit open source, soutenu par une communauté active et ouverte.  Ouvrir l’accès à une ressource locale (thèses, cours en ligne) à d’autres Etablissements  Gérer un intranet pour une population disséminée dans plusieurs établissements On considère ici un groupe de personnes appartenant à différents établissements et amenés à travailler ensemble, donc à partager des documents, des outils de travail collaboratif (forums, wikis, gestionnaires d’enquêtes, autres outils métiers).  Gérer l’authentification pour des populations à la frontière de l’établissement (anciens ou futurs étudiants) Les applications de pré-inscription des étudiants ou d’enquêtes auprès des anciens étudiants, concernent des populations qui ne sont pas encore ou plus gérées dans le système d’information de l’établissement. On ne dispose donc pas de service d’authentification pour ces utilisateurs qui ne rentrent pas forcément dans le moule (déjà complexe) des utilisateurs (étudiants, chercheurs, enseignants, autres personnels…). 2.2 CONCEPTION 2.2.1 LE MECANISME DE CAS 2.2.1.1 ARCHITECTURE L’architecture de CAS [1] tourne autour de trois principaux acteurs : le serveur CAS, le client CAS et le navigateur.
  28. 28. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 17 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012  Le serveur CAS L'authentification est centralisée sur une machine unique (le serveur CAS). Ce serveur est le seul acteur du mécanisme CAS à avoir connaissance des mots de passe des utilisateurs. Son rôle est double : authentifier les utilisateurs et transmettre certifier l'identité de la personne authentifiée (aux clients CAS) : c’est le serveur d’authentification.  Le client CAS C’est l’agent d’authentification. Il peut être une application web munie d'une librairie cliente ou un serveur web utilisant le module mod_cas. Il ne délivre les ressources qu'après s’être assuré que le navigateur qui y accède se soit authentifié auprès du serveur CAS. Parmi les clients CAS, on trouve : des librairies (Perl, Java, JSP, PHP, ASP), un module Apache et un module PAM, qui permet d'authentifier les utilisateurs au niveau système.  Le navigateur C’est l’élément disposant d'un moteur de chiffrement leur permettant d'utiliser le protocole HTTPS. Il doit être capable savoir effectuer des redirections http, interpréter le langage JavaScript et savoir stocker des cookies : Il représente l’utilisateur. Ces exigences sont en général satisfaites par tous les navigateurs classiquement utilisés, à savoir MicroSoft Internet Explorer (depuis 5.0), Netscape Navigator (depuis 4.7) et Mozilla. 2.2.1.2 FONCTIONNEMENT DE BASE Un utilisateur non précédemment authentifié, ou dont l'authentification a expiré, et qui accède au serveur CAS se voit proposer un formulaire d'authentification, dans lequel il est invité à entrer son nom de connexion et son mot de passe. Figure 8 : architecture du serveur CAS
  29. 29. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 18 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Si les informations sont correctes, le serveur renvoie au navigateur un cookie appelé TGC (Ticket Granting Cookie). Le TGC est le passeport de l’utilisateur auprès du serveur CAS. Le TGC, à durée de vie limitée (typiquement quelques heures), est le moyen pour les navigateurs d'obtenir auprès du serveur CAS des tickets pour les clients CAS sans avoir à se ré-authentifier. C'est un cookie privé (n'est jamais transmis à d'autres serveurs que le serveur CAS) et protégé (toutes les requêtes des navigateurs vers le serveur CAS se font sous HTTPS). 2.2.1.3 ACCES A UNE RESSOURCE PROTEGEE APRES AUTHENTIFICATION Lors de l'accès à une ressource protégée par un client CAS, celui-ci redirige le navigateur vers le serveur CAS dans le but d'authentifier l'utilisateur (le navigateur), précédemment authentifié auprès du serveur CAS et lui présente le TGC. Redirection vers le serveurCAS d'un navigateur non authentifié auprès du client CAS Redirection par le serveur CAS d'un navigateur vers un client CAS après authentification Figure 9 : fonctionnement de base de CAS Figure 10 : redirection transparente vers le serveur CAS
  30. 30. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 19 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Sur présentation du TGC, le serveur CAS délivre au navigateur un Service Ticket (ST). C’est un ticket opaque, qui ne transporte aucune information personnelle. Il n’est utilisable que par le « service » (l'URL) qui en a fait la demande. Dans le même temps, il le redirige vers le service demandeur en passant le Service Ticket en paramètre. Le Service Ticket est alors validé auprès du serveur CAS par le client CAS, directement en http, et la ressource peut être délivrée au navigateur. Il est à noter que toutes les redirections présentées sont complètement transparentes pour l’utilisateur. Celui-ci ne voit pas les redirections et a l'impression d'accéder directement à la ressource désirée, sans authentification. Un navigateur ne sachant pas effectuer les redirections ou n'interprétant pas le langage JavaScript forcera l'utilisateur à effectuer un clic à chaque redirection (qui ne sera alors plus transparente). Un navigateur ne stockant pas les cookies forcera l'utilisateur à entrer ses informations d'authentification à chaque passage par le serveur d'authentification. 2.2.1.4 ACCES A UNE RESSOURCE PROTEGEE SANS AUTHENTIFICATION PREALABLE Si l’utilisateur n'est pas déjà authentifié auprès du serveur CAS avant d'accéder à une ressource, son navigateur est, comme précédemment, redirigé vers le serveur CAS, qui lui propose alors un formulaire d'authentification. Lors de la soumission du formulaire par le navigateur au serveur CAS, si les informations fournies sont correctes, le serveur CAS : - délivre un TGC (Ticket Granting Cookie) au client, qui lui permettra ultérieurement de ne pas avoir à se ré-authentifier Figure 11 : validation pour l'accès à une ressource
  31. 31. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 20 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 - délivre au client un Service Ticket à destination du client CAS - redirige le client vers le client CAS 2.2.1.5 PRINCIPE DE MANDAT AVEC CAS Dans le fonctionnement de base, le client CAS est toujours en lien direct avec le navigateur. Dans un fonctionnement n-tiers, le navigateur accède à un client CAS à travers un mandataire CAS. Le mécanisme de redirection vu dans le fonctionnement de base n'est alors plus applicable.  Fonctionnement 2-tiers Un mandataire CAS, lorsqu'il valide un Service Ticket pour authentifier un utilisateur, effectue, dans le même temps, une demande de PGT (Proxy Granting Ticket). Le PGT est le passeport d’un mandataire CAS, pour un utilisateur, auprès du serveur CAS. Récupération d'un PGT par un mandataire CAS auprès du serveur CAS Validation d'un PT par un client CAS accédé par un mandataire CAS Figure 12 : accès à l'application sans authentification Figure 13 : validation du PT pour l'accès à une ressource
  32. 32. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 21 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012  Fonctionnement n-tiers On voit aisément que le client CAS accédé par le mandataire CAS du fonctionnement 2- tiers peut également être mandataire à son tour. Les mandataires peuvent ainsi être chaînés. CAS est à notre connaissance, le seul mécanisme de SSO proposant un tel fonctionnement multi-tiers sans aucune propagation de mot de passe. CAS permet l'implémentation de plusieurs méthodes d'authentification plus ou moins traditionnelles : annuaires LDAP, bases de données, domaines NIS, et fichiers. Cette classe peut être aisément étendue à d'autres méthodes d'authentification, selon les besoins des administrateurs de sites (Novell, Kerberos, Active Directory, ...) 2.2.2 LE MECANISME DE SHIBBOLETH L’objectif est de montrer les interactions entre les acteurs du système qui permettent la délégation de l’authentification et la propagation des attributs utilisateurs. Afin de mieux appréhender un fonctionnement globalement complexe, nous présentons d’abord les acteurs du système, puis détaillons les interactions entre les acteurs du système lors de l’accès par un navigateur à une ressource web. 2.2.2.1 ARCHITECTURE  Le navigateur Le premier acteur de l’architecture Shibboleth [2] est donc logiquement le navigateur de l’utilisateur. Le navigateur doit répondre aux exigences habituelles en matière de navigation web, notamment l’interprétation des codes de retour HTTP (redirections), ainsi que l’acceptation et la transmission des cookies selon les normes en vigueur.  Le fournisseur de services (Service Provider ou SP) Figure 14 : CAS dans l'architecture n-tiers
  33. 33. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 22 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 C’est une entité proposant des ressources web sur la base d’un contexte de sécurité SAML et sera par la suite nommée SP (Service Provider). Le fournisseur de ressource a en particulier la charge de donner ou non l’accès aux ressources, en fonction des attributs utilisateur.  Le fournisseur d’identités (Identity Provider ou IdP) C’est une entité authentifiant les utilisateurs et fournissant leurs attributs. Elle sera par la suite notée IdP. Le fournisseur d’identités s’appuie sur le SI de l’établissement, tant pour l’authentification que pour la récupération des attributs utilisateur à propager. De ce fait, il est en général situé au plus proche du SI.  Le WAYF Le WAYF (pour Where Are You From?, « d’où êtes-vous ? ») est un service dont le but est d’orienter l’utilisateur vers son IdP. Seul l’objectif du WAYF est défini dans les spécifications de Shibboleth : – Proposer aux utilisateurs une liste d’IdP, parmi lesquels les utilisateurs sont invités à sélectionner celui de leur établissement de rattachement ; – Une fois le choix effectué, il redirige les utilisateurs vers l’IdP correspondant à leur choix. L’architecture d’une offre applicative d’un établissement dont l’authentification est confiée à Shibboleth sera donc souvent celle décrite par la figure : Figure 15 : fonctionnement du WAYF
  34. 34. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 23 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 2.2.2.2 FONCTIONNEMENT DE SHIBBOLETH SANS CAS Dans ce premier cas d’étude, nous considérons que le SP connaît l’établissement de rattachement de l’utilisateur, c’est-à-dire l’établissement qui pourra l’authentifier. Le navigateur effectue donc une requête HTTP vers le SP afin d’accéder à une ressource et le SP, sans information d’authentification, le redirige vers l’IdP de l’établissement de rattachement de l’utilisateur. La réponse de l’IdP est une demande d’authentification, sous la forme d’une erreur 401 Unauthorized ou d’un formulaire web. L’utilisateur entre alors son identifiant et son mot de passe. Une fois authentifié, l’IdP redirige alors le navigateur vers le SP, accompagné d’une assertion SAML. Cette assertion signée par l’IdP, le SP pourra donc faire confiance à l’assertion. Elle contient un identifiant appelé nameIdentifier. Cet identifiant est opaque, c’est-à-dire qu’il ne contient pas d’information personnelle concernant l’utilisateur. Il n’est utilisé que dans le cadre des échanges entre les différentes briques de Shibboleth, et n’est connu ni de la ressource accédée ni du SI de l’établissement. Un exemple de nameIdentifier est montré ci-dessous. Figure 16 : requête du navigateur vers le fournisseur de service Figure 17 : redirection de l'IdP vers le SP
  35. 35. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 24 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 <saml:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="https://idp.iut-fv.cm/shibboleth"> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameIdentifier> C’est cet identifiant opaque qui va permettre au SP de récupérer les attributs de l’utilisateur auprès de l’IdP. Ces attributs de l’utilisateur sont transmis au SP par l’IdP, via l’appel d’un Web Service, l’échange du nameIdentifier. Le SP peut alors effectuer le contrôle d’accès, éventuellement utiliser les attributs de l’utilisateur dans la logique applicative, puis retourner une réponse au navigateur. Architecture logique du fournisseur de services (SP) Le fournisseur de services est composé de trois briques logicielles : – Le consommateur d’assertions (Assertion Consumer Service), – Le demandeur d’attributs (Attribute Requester), – Le contrôleur d’accès. Figure 18 : le SP demande les attributs de l’utilisateur Figure 19 : réponse du SP au navigateur
  36. 36. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 25 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Le consommateur d’assertions agit comme un pré-filtre. C’est lui qui redirige vers l’IdP lorsque l’utilisateur n’est pas authentifié. Il peut être implémenté au niveau du serveur HTTP (par un module Apache ou un filtre J2EE par exemple). Lorsque l’utilisateur est authentifié, alors le consommateur d’assertions transmet le nameIdentifier au demandeur d’attributs. Le demandeur d’attributs est chargé de la récupération des attributs des utilisateurs auprès de l’IdP. Il peut être implémenté comme un démon (dédié, interrogeable par les processus du SP) ou par une librairie, interrogeable par un applicatif web. Les attributs récupérés par le demandeur d’attributs sont fournis au contrôleur d’accès. Le contrôleur d’accès est chargé d’autoriser ou non l’accès aux ressources demandées. Il peut être implémenté au niveau du serveur HTTP (par un module Apache ou un filtre J2EE par exemple) ou encore par une librairie, appelée par un applicatif web. Architecture logique du fournisseur d’identités (IdP) Un fournisseur d’identités est composé de trois briques logicielles : – Le service d’authentification (Authentication Service), – L’autorité d’authentification (Authentication Authority), – L’autorité d’attributs (Attribute Authrority). Le service d’authentification est chargé de l’authentification des utilisateurs vis-à-vis de l’ensemble de l’IdP. C’est lui qui, par exemple, demande à l’utilisateur un couple user/password, puis le valide auprès de la base d’authentification du SI. Les implémentations du service d’authentification peuvent être très variées, depuis un module Apache authentifiant les utilisateurs auprès d’un annuaire LDAP, jusqu’à un client de Single Sign-On comme nous le verrons ultérieurement. L’autorité d’authentification associe le nameIdentifier à l’identifiant de l’utilisateur. L’autorité d’attributs délivre, en réponse à une demande d’un SP, les attributs de l’utilisateur correspondant à un nameIdentifier. L’association entre l’identifiant de l’utilisateur et le nameIdentifier étant maintenue par l’autorité d’authentification.
  37. 37. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 26 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Figure 20 : fonctionnement de Shibboleth sans CAS 2.2.2.3 FONCTIONNEMENT DE SHIBBOLETH AVEC SSO Dans le modèle de CAS, l’authentification n’est pas directement prise en charge par le service d’authentification de l’IdP. Celui-ci ne fait que rediriger le navigateur vers le serveur de SSO, qui renvoie alors à l’utilisateur un formulaire d’authentification. Une fois le formulaire remplit, le navigateur effectue une nouvelle requête vers le serveur SSO, qui le redirige vers l’IdP. Le service d’authentification de l’IdP, client SSO, effectue alors une nouvelle redirection vers le SP et l’authentification se déroule ensuite comme vu précédemment. Figure 21 : redirection du navigateur vers le serveur de SSO
  38. 38. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 27 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 . Requêtes suivantes au même SP Comme vu précédemment, une session étant mise en place entre le navigateur et le SP, ni l’IdP ni le serveur SSO n’interviennent par la suite pour l’accès au même SP. Requêtes suivantes vers un autre SP Lorsque l’utilisateur est déjà authentifié auprès du serveur SSO, le navigateur dispose d’un identificateur de session (par exemple un TGC pour CAS) qui lui permet de ne pas avoir à s’authentifier à nouveau. Figure 22 : fonctionnement de Shibboleth avec SSO Figure 23 : requete suivant le meme SP
  39. 39. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 28 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 2.2.2.4 FONCTIONNEMENT DE SHIBBOLETH DANS UNE FEDERATION Considérons le cas où un SP est accessible à des utilisateurs rattachés à des établissements différents. C’est par exemple le cas d’une université souhaitant mettre à disposition de tous les personnels de l’enseignement supérieur de sa région les archives de ses thèses et publications scientifiques. Le problème qui se pose alors est que le SP ne sait pas vers quel IdP rediriger le navigateur pour l’authentification. Il est résolu grâce au WAYF, dont le rôle est d’orienter les utilisateurs pour sélectionner leur IdP. Première requête vers un SP Lors de la première requête au SP, celui-ci ne sachant pas quel IdP sera utilisé, le SP redirige le navigateur vers le WAYF. Figure 24 : délégation d'authentification vers un autre SP Figure 25 : redirection transparente vers le WAYF
  40. 40. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 29 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Le WAYF affiche alors à l’utilisateur alors une liste d’IdP possibles. La requête suivante, vers le WAYF, redirige le navigateur vers l’IdP choisi par l’utilisateur, qui à son tour redirige le navigateur vers le serveur SSO, qui propose alors un formulaire d’authentification. Le navigateur s’authentifie alors auprès du serveur SSO, et l’authentification se déroule ensuite comme vu précédemment. Requêtes suivantes vers le même SP Figure 26 : redirection du WAYF vers le serveur de SSO Figure 27 : réponse du SP après authentification du serveur SSO
  41. 41. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 30 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Comme vu précédemment, une session étant mise en place entre le navigateur et le SP, ni le WAYF, ni l’IdP ni le serveur SSO n’interviennent par la suite pour l’accès au même SP. Requêtes suivantes vers un autre SP Lors du choix de l’IdP par l’utilisateur, il est possible pour le WAYF de mémoriser ce choix dans le navigateur (à l’aide d’un cookie). Dans ce cas, le WAYF peut utiliser ultérieurement cette information, et faire en sorte que les requêtes suivantes soient non bloquantes (en redirigeant automatiquement vers l’IdP choisi la première fois). La figure montre comment, dans ce cas, l’authentification de l’utilisateur est totalement transparente lors de l’accès à un autre SP. Figure 28 : réponse du SP sans authentification Figure 29 : le WAYF en action dans une fédération
  42. 42. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 31 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 2.3 MISE EN OEUVRE Une fois la méthodologie du travail décrite, il ne nous reste plus qu’à mettre sur pied notre système. Ainsi, dans ce paragraphe, il est question de présenter étape par étape le travail effectué et d’accompagner ces différentes étapes par des résultats qui, seront présentés par des captures d’écran. 2.3.1 PRESENTATION DE L’INTRANET L'intranet est la partie sécurisée de notre réseau informatique basé sur les mêmes technologies qu’Internet (protocoles de communication TCP/IP). L'intranet est connecté au réseau Internet pour permettre la communication avec le monde extérieur. En effet, notre intranet peut être constitué de plusieurs serveurs parmi lesquels on peut citer :  Le contrôleur de domaine (samba)  Le serveur web  Le serveur DNS  Le serveur DHCP  L’annuaire LDAP  Le serveur de SSO (CAS)  Le serveur de fourniture d’identités ou de SSO (Shibboleth) Nous ne devons pas nous attarder sur la présentation de la configuration de tous ces serveurs car, le plus important ici ce sont les serveurs SSO et le fournisseur d’identités [3]. Nous avons choisi « iut-fv.cm » comme domaine. L’architecture simplifiée se présente comme suit :
  43. 43. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 32 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 2.3.2 CENTRALISATION DE L’AUTHENTIFICATION Installation de l’annuaire LDAP LDAP (Lightweight Directory Access Protocol) [4] représente la norme des systèmes d'annuaires, incluant un modèle de données, un modèle de nommage, un modèle fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de réplication. Afin d'installer tout ce dont nous avons besoin nous allons exécuter une seule commande dans le serveur Debian rassemblant tous les programmes.  Le paquet “slapd” installe le serveur OpenLDAP. Il contient avant tout le démon qui permet de démarrer/arrêter/redémarrer le serveur OpenLDAP.  Le paquet “ldap-utils” contient les commandes dites clientes qui permettent à l'utilisateur d'interagir avec l'annuaire LDAP.  Le paquet “apache2” installe le serveur HTTP. Nous n'allons pas nous attarder sur tous les fichiers que le paquet apache installe. Le module PROXY ou encore le module SSL pour utiliser le protocole HTTPS.  Les paquets “php5” et "php5-ldap" sont nécessaires au fonctionnement de PhpLDAPAdmin puisque cette application est écrite en PHP.  Le paquet PhpLDAPAdmin est une interface accessible par internet écrite en PHP #apt-get install slapd ldap-utils apache2 php5 php5-gd php5-ldap phpldapadmin Figure 30 : architecture du système
  44. 44. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 33 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 et qui permet d'administrer un annuaire LDAP à distance et de manière sécurisée avec le protocole HTTPS. Il est tout à fait possible d'utiliser des logiciels comme jXplorer (écrit en JAVA) pour se connecter et administrer l'annuaire LDAP seulement cela nécessite l'installation du logiciel sur la machine cliente. D'où le choix d'une administration par le web. Pour terminer l'installation, il suffit de répondre aux questions posées par le système pour la configuration du demon slapd. Faut il omettre la configuration d’OpenLDAP ? Non Nom de domaine : iut-fv.cm Nom de votre organisation : iut-fv Mot de passe administrateur : ******** Faut-il autoriser le protocole LDAPv2 : Non Pour la configuration de phpldapadmin : Adresse du serveur LDAP : 127.0.0.1 (si votre annuaire est sur un autre serveur donnez lui son adresse bien sûr) Faut-il gérer le protocole LDAPS : non Nom distinctif de la base de recherche : dc=iut-fv, dc=cm Type d’authentification : session (vous avez le choix entre session, cookie, config) Identifiant dn de connexion au serveur LDAP : cn=admin, dc=iut-fv, dc=cm Serveur web à reconfigurer automatiquement : apache2 (vous avez le choix entre apache, apache-ssl, apache-perl et apache2). Faut-il redémarrer le serveur web : oui Attention : Dans la nouvelle version d’openldap dans debian 6.0.1, le fichier slapd.conf n’existe plus il est remplacé par le répertoire /slapd.d. Configuration du contrôleur de domaine avec SAMBA Nous allons maintenant installer le serveur samba. La librairie libnss-ldap permettant d’utiliser l’annuaire et la librairie libpam-ldap permettant de s’authentifier sous Unix. Cette configuration est très longue et nous n’allons pas nous attardé sur cette dernière. Joindre le serveur SAMBA à l’annuaire LDAP fonctionne avec des schémas, par défaut 4 schémas sont déjà présents, pour utiliser samba avec LDAP il faut le schéma approprié. Celui-ci se trouve dans le paquet samba-doc. #apt-get install samba-doc samba smbclient smbfs smbldap-tools libnss-ldap libpam-ldap
  45. 45. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 34 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Il reste maintenant à éditer le fichier de configuration du serveur OpenLDAP : /etc/ldap/slapd.conf 2.3.3 CONFIGURATION DES SERVEURS Nous rappelons ici que nos serveurs sont partagés différentes plate forme : serveur 1 (DNS+LDAP+samba), le serveur 2 (Shibboleth) et le serveur 3 (CAS). Le serveur 1 est déjà configuré à ce niveau. Nous pouvons passer au serveur 2 ensuite, le serveur 3 sera suivit. 2.3.3.1 INSTALLATIONS Installation du paquet java 6 JDK-JRE Java 6 JDK sera installé vers le chemin /usr/lib/jvm/java-6-openjdk. Pour éviter les confilts avec un autre serveur de machine virtuelle comme gcj. Désinstaller simplement gcj. Inclure les lignes suivantes dans /etc/profile (vérifier avec la commande : java –version). Exécutons les commandes suivantes pour définir la variable JAVA_OPTS pour assurer à l'exécution de la JVM, de Tomcat et de la servlet IdP. Il est conseillé d'allouer au moins 512Mo de mémoire à la servlet IdP. Installation du serveur Tomcat include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema #apt-get openjdk-6-jre-headless # export JAVA_HOME=/usr/java/latest/ # export JAVA_OPTS="-Xmx1000m -XX:MaxPermSize=512m" JAVA_HOME=/usr/lib/jvm/java-6-openjdk export JAVA_HOME
  46. 46. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 35 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Apache Tomcat est un serveur d'applications JAVA. C’est lui qui exécutera la brique Shibboleth IdP. Apache Tomcat 6.0.17 ou plus avancé est la version exigée pour démarrer le fournisseur d’identités. Pour allouer à la JVM une mémoire maximale de 512MBytes et de 128MBytes autorisée, Dans le fichier /etc/default/tomcat6, modifions la variable java_OPTS pour ceci : Installation de l’IdP Shibboleth Shibboleth est disponible au site : http://shibboleth.internet2.edu/downloads/shibboleth/idp/ Les deux dernières lignes de copier les bibliothèques xml de Shibboleth dans la variable $CATALINA_HOME/endorsed sachant que $CATALINA_HOME=/opt/tomcat. Pour utiliser MyQL JDBC pour la sauvegarde, téléchargeons le dans le site dev.mysql.com. Démarrons l’installation de Shibboleth avec un certificat de trois ans signé par Idp. #cd /usr/local/src #unzip mysql-connector-java-5.1.22.zip mysql-connector-java-5.1.15/mysql-connector-java- 5.1.22-bin.jar #mv mysql-connector-java-5.1.22/mysql-connector-java-5.1.15-bin.jar /opt/shibboleth-identityprovider-2.3.8/lib/ #apt-get install tomcat6 JAVA_OPTS="-Djava.awt.headless=true -Xmx512M -XX:MaxPermSize=128M - Dcom.sun.security.enableCRLDP=true" #curl –O http://shibboleth.internet2.edu/downloads/shibboleth/idp/2.3.8/shibboleth-identityprovider-2.2.1-bin.zip #cd /usr/local/src #unzip –xf /usr/local/src/shibboleth-identityprovider-2.3.8-bin.zip #cd shibboleth-identityprovider-2.3.8 #chmod u+x install.sh #cd /usr/local/src/shibboleth-identityprovider-2.3.8 #mkdir /usr/share/tomcat6/endorsed/ #cp ./endorsed/*.jar /usr/share/tomcat6/endorsed/ #cd /usr/local/src/shibboleth-identityprovider-2.3.8/ #env IdPCertLifetime=3 ./install.sh
  47. 47. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 36 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Déplaçons les annuaires de configuration de Shibbolet. Donnons la variable d’environnement dans le fichier /etc/profile. Créons le répertoire pour la description de l’IdP : Installation de MySQL Server Installons la version 5.1 disponible dans debian6 (annexe 1) Installation CAS server Il s’agit ici du server de SSO [5] : La suite de la configuration de CAS a été faite grâce au fichier à l’adresse : http://www.artduweb.com/tutoriels/cas-sso #ln -s /opt/shibboleth-idp/conf /etc/shibboleth #ln -s /opt/shibboleth-idp/logs /var/log/shibboleth #export IDP_HOME=/opt/shibboleth-idp #cd /etc/tomcat6 #mkdir -p Catalina/localhost #vim etc/tomcat6/Catalina/localhost/idp.xml <Context docBase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiResourceLocking="false" antiJARLocking="false" unpackWAR="false" swallowOutput="true" cookies="false" /> #wget http://downloads.jasig.org/cas/cas-server-3.4.11-release.tar.gz #tar xvzf cas-server-3.4.11-release.tar.gz #more cas-server-3.4.11/INSTALL.txt #cd cas-server-3.4.11/cas-server-webapp vi pom.xml <!-- Dependance support LDAP --> <dependency> <groupId>${project.groupId}</groupId> <artifactId>cas-server-support-ldap</artifactId> <version>${project.version}</version> </dependency>
  48. 48. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 37 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 2.3.3.2 CONFIGURATION DU SERVEUR IdP SHIBBOLETH La configuration de l’idp Schibboleth [6] se fait en plusieurs étapes : Création des certificats Configuration d’apache La génération du certificat nous devons éditer le fichier ssl.conf. Ajoutons les lignes suivantes pour que Apache utilise ces éléments. Apache sera configuré avec le module mod_ssl supportant SSL et le module mod_proxy_ajp pour rediriger les requêtes à Tomcat. Obtenir un certificat de SWITCHpki à l’adresse : www.switch.ch/quovadis/quvsslica.crt.pem. Améliorons le degré de sécurité de notre serveur, ajoutons dans de directive /etc/apache2/conf.d/security. #openssl genrsa -out pcserver.iut-fv.cm.key 1024 #openssl req -new -x509 -days 365 -key pcserver.iut-fv.cm.key -out pcserver.iut- fv.cm.crt SSLCertificateFile / etc/pki/tls/certs/pcserver .iut-fv.cm.crt SSLCertificateKeyFile / etc/pki/tls/private/pcserver.iut-fv.cm.key #cp pcserver.iut-fv.cm.key /etc/ssl/private/ #cp pcserver.iut-fv.cm.crt /etc/ssl/certs/ #mv qvsslica.crt.pem /etc/ssl/certs/ ServerTokens Prod
  49. 49. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 38 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Le fichier de configuration /etc/apache2/site-availabe/pcserver sera présenté en annexe 2. Ensuite survient l’activation de l’host virtuel, l’activation du module SSL et l’activation du module proxy ajp. Configuration du module JAAS pour l’authentification des utilisateurs Il faut configurer l'authentification pour Shibboleth IdP avec le module JAAS. http://docs.oracle.com/javase/1.5.0/docs/guide/security/jaas/JAASRefGuide.html Configurons JAAS in /opt/shibboleth-idp/conf/login.config avec VTLdap pour LDAPS. Configuration de tomcat Dans /etc/tomcat6/server.xml, configurons le connecteur AJP 1.3 au port 8009: Configuration de l’IdP Les qualifications employées par Shibboleth IdP sont dans /opt/shibboleth- idp/credentials/annuaire. L'installateur produit d'un certificat individuel signé qui sera employé dans la fédération de SWITCHaai. Le certificat est également inclus dans le metadata de l'IdP dans le dossier/opt/shibboleth-idp/metadata/idp-metadata.xml. Toutes les fois que les qualifications de l'IdP sont changées, ce dossier doit être aussi bien changé. Etant donné que nous ne faisons pas partie de la fédération SWITCHaai, nous préparons l’IdP pour une fédération. ShibUserPassAuth { // Example LDAP authentication edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldaps://ldap.iut-fv.cm" baseDn="ou=people,dc=iut-fv,dc=cm" bindDn="cn=idp-user,dc=iut-fv,dc=cm" bindCredential="password for idp-user"; }; <!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" address="127.0.0.1" enableLookups="false" redirectPort="443" protocol="AJP/1.3" tomcatAuthentication="false" /> <!-- <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /> -->
  50. 50. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 39 Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012 Le dossier spécifique de SWITCHaai relying-party.xml [7] peut être téléchargé comme calibre pour l’installation. Ce fichier de configuration est présenté en annexe 3. Résolution d'attribut et de filtrage Téléchargons le dossier spécifique attribute-resolver.xml de configuration de SWITCHaai et l'adapter. Le fichier /opt/shibboleth-idp/conf/attribute-resolver.xml se présente en annexe 4. Redéployons l'application Shibboleth IdP. Tomcat rechargera l'application d'enchaînement à condition que le descripteur de contexte se dirige au dossier/opt/shibboleth-idp/war/idp.war. répondez no à la question Would you like to overwrite this Shibboleth configuration? Après le redémarrage de Tomcat, vous pourrez vérifier que l'application Shibboleth a correctement démarrée. Conclusion La fédération d’identités vise justement à simplifier la gestion des identités dans un contexte distribué entre plusieurs entreprises. Si on caricature le fonctionnement d’une fédération d’identité, on peut imaginer un douanier qui ne fait pas forcément confiance à une personne lui présentant son passeport. Néanmoins notre douanier aura confiance au gouvernement qui a délivré le passeport. Ainsi notre individu est authentifié par son gouvernement et présente la preuve de son authentification au douanier qui le laisse alors franchir la douane. #cd /opt/shibboleth-idp/credentials #chown root idp.key #chgrp tomcat6 idp.{key,crt} #chmod 440 idp.key #chmod 644 idp.crt #cd /opt/shibboleth-idp/conf/ #mv relying-party.xml relying-party.xml.orig #curl -Ok https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying- party.xml #vim /opt/shibboleth-idp/metadata/metadata.aaitest.xml #cd /opt/shibboleth-idp/conf/ #curl -Ok https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/attribute- resolver.xml
  51. 51. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 40 Chap. 3 : résultats obtenus et perspectives LIRT 2011-2012 HAPITRE 3 : RESULTATS OBTENUS ET PERSPECTIVES Introduction Ce système implémenté est une préparation de l’IUT-FV de bandjoun pour joindre une fédération d’identités future grâce à l’IdP shibboleth. Le serveur de SSO est un agent d’authentification délégué par l’IdP pour favoriser les accès aux services. 3.1 RESULTATS OBTENUS Voici le résultat de la création d’un arbre de base au sein de l’annuaire LDAP du contrôleur de domaine SAMBA pour la centralisation de l’authentification. Visualisation des entrées au sein de l’annuaire LDAP dans le domaine iut-fv.cm C
  52. 52. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 41 Chap. 3 : résultats obtenus et perspectives LIRT 2011-2012 Recherche de la reference au sein de l’annuaire Active directory Vérification des tables dans la base de donnée Shibboleth
  53. 53. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 42 Chap. 3 : résultats obtenus et perspectives LIRT 2011-2012 Vérification du fonctionnement de Shibboleth Serveur Shibboleth déployé Page d’accueil pour l’authentification Shibboleth
  54. 54. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 43 Chap. 3 : résultats obtenus et perspectives LIRT 2011-2012 Page d’authentification du serveur CAS pour le service de SSO Authentification réussie 3.2 PERSPECTIVES Malgré tous les efforts qui ont été fait, les problèmes de sécurité et de fonction restent des challenges qui suscitent des efforts. Mais, nous avons bien découvert ces problèmes et trouvé des solutions qui ne sont pas du tout facile à mettre en œuvre. Dans paragraphe, nous présentons les améliorations à venir pour compléter ce projet surtout dans le domaine de la sécurité. Ces améliorations n’ont pas été réalisées pour des raisons de temps et de moyens matériels.
  55. 55. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 44 Chap. 3 : résultats obtenus et perspectives LIRT 2011-2012 3.2.1 AUTHENTIFICATION FORTE Parmi les perspectives ouvertes à ce projet, l’utilisation des méthodes d’authentification pour « ce que je possède » et « ce que je suis » ou la combinaison de ces deux sont des assurances que l’utilisateur est bien celui qui prétend être. Ce projet à besoin d’un système d'authentification forte permettant de sécuriser les accès aux ressources internes depuis un réseau non sécurisé comme Internet. 3.2.1.1 L’OTP L’OTP sera un avantage pour nous parce que chaque individu possède une ligne GSM propre à lui pour utiliser la carte SIM comme un deuxième facteur d'authentification. Il permet d'assurer l'authenticité des utilisateurs en vérifiant la validité de leur code PIN et la possession de leur téléphone portable. A part son serveur d'authentification, le système doit comporter un logiciel d'administration permettant la gestion, la visualisation des fichiers d'historique et la supervision en temps réel. L’application Open source « Linotp » est un serveur capable de faire cela mais la difficulté de l’intégrer ou de la synchroniser avec notre solution CAS-Shibboleth a été remarquée. Aujourd'hui, avec l'arrivée des techniques d'authentification forte, la sécurité n'est plus un frein pour des solutions de mobilité. 3.2.1.2 AUTHENTIFICATION BIOMETRIQUE L'avantage principal de ce qu'on appelle "mot de passe biométrique" est lié au fait qu'il ne pourrait pas être volé, oublié ou transmis à une autre personne. En effet, chaque membre de la population possède sa propre caractéristique biométrique, et elle est relativement stable. Figure 31 : principe de l'OTP
  56. 56. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 45 Chap. 3 : résultats obtenus et perspectives LIRT 2011-2012 Malheureusement pour nous, shibboleth dans sa version utilisée ne prend pas par défaut l’authentification biométrique. Cela ne veut pas dire que l’authentification biométrique est impossible pour la solution CAS-Shibboleth. Il suffit du temps pour une conception. Mais OpenSSO est une solution qui prend par défaut l’identification par empreinte digital grâce au logiciel Biobex. Malheureusement, nous avons constaté que le logiciel Biobex n’est plus disponible. 3.2.2 UNE FEDERATION D’IDENTITES FONCTIONNELLE Une fédération est simplement « un regroupement de fournisseurs de services et de fournisseurs d’identités ». La mise en place d’un test de l’IdP auprès de RENATER et de notre propre fédération fonctionnelle soulève en effet d’autres ressources que nous n’avons pas en notre disposition. Le problème est de mettre sur pied une fédération de huit universités d’état du pays y compris les universités et les instituts privés. Comme dans le cadre académique, RENATER, Esup- Portail et SWITCHaai sont des fédérations qui simplifient et sécurisent les connexions à leurs sites web dont l'accès est contrôlé : plate-forme d'enseignement à distance, portail documentaire, application métier, etc. La fédération répond bien aux besoins de mutualisation entre organismes, aux problématiques de nomadisme et facilite le respect de la loi “Informatique et libertés”. Conclusion Comme le SSO donne accès à de nombreuses ressources, une fois l'utilisateur authentifié, il a les "clés du château". Les pertes peuvent être lourdes si une personne mal intentionnée a accès à des informations d'identification des utilisateurs. Avec le SSO, une attention particulière doit donc être prêtée à ces informations, et des méthodes d'authentification forte devraient idéalement être combinées.
  57. 57. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 46 Conclusion générale LIRT 2011-2012 Conclusion générale Parvenue au terme de ce projet, nous pouvons affirmer qu’il nous a non seulement permis de mieux nous familiariser avec les réalités du monde professionnel, aussi de mettre en pratique nos compétences en découvrant de nombreuses plates formes dans le domaine des réseaux informatiques. Nous n’avons pas vite remarqué les difficultés en terme de ressource pour la réalisation de ce projet car cela a engendré beaucoup de temps. A la première étape (indispensable), il fallait implémenter un contrôleur de domaine avec le serveur SAMBA, le synchroniser avec l’annuaire LDAP et ensuite gérer la centralisation de l’authentification avec ce dernier. En effet, plusieurs solutions ont été parcourues en fonction des systèmes d’exploitation Linux à la recherche du succès et la solution Shibboleth-CAS a été favorable même si les documentations et la compréhension n’étaient pas évidentes. La mise sur pied d’un fournisseur d’identités conduit à une fédération d’identités. De nos jours, nous rencontrons beaucoup d’entreprises qui forment un domaine de confiance en disposant chacun d’un fournisseur d’identités (exemple fecebook-netlog, facebook-twitter) certains encordent même le SSO (exemple facebook-yahoo). Mais, la fédération d’identités est manifestée par un portail et est faite pour des services de l’enseignement supérieur. Nous espérons qu’un pays émergent comme le notre convergera vers ce système dans les moments à venir surtout dans le secteur éducatif (enseignement supérieur) et bien d’autres.
  58. 58. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 47 Bibliographie LIRT 2011-2012 Bibliographie Sites internet visités [1] http://www.gsefr.org/open-source/documents/prives/GuideShare%20- %20Presentation%20SSO.odp , CAS serveur de SSO, visité le 2 mai 2013. [2] http://2005.jres.org/tutoriel/shibboleth-jres2005-article.pdf, explication du fonctionnement de Shibboleth, visité le 2 avril 2013. [3] http://www.arismore.fr/wp-content/uploads/F%C3%A9d%C3%A9ration- Identit%C3%A9s_F.JAN-Arismore.pdf, les fournisseurs d’identités, visité le 2 avril 2013. [4] http://monblog.system-linux.net/blog/2008/11/04/creer-un-controleur-principal-de- domaine-avec-samba-et-un-annuaire-ldap/, configuration de ldap, visité le 2 avril 2013. [5] http://www.artduweb.com/export/xhtml/tutoriels/cas-sso, configuration de cas sso, visité le 6 mai 2013. [6] https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/install-idp-2.3-debian.html, installation de l’idp shibboleth, visité le 23 avril 2013. [7] https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying- party.xml, fichier de configuration relying-party, visité le 6 mai 2013. Documents [8] Olivier Salaün, Florent Guilleux, Pascal Aubry, Fédération d'identités et propagation d'attributs avec Shibboleth. http://www.google.cm/url?q=http://perso.univ- rennes1.fr/pascal.aubry/sites/default/files/shibboleth-jres2005- article.pdf&sa=U&ei=yBHkUc2bHsSv0QXXvoH4DQ&ved=0CBkQFjAA&usg=AFQjCNG xhZYGEFAHuPYH82Kvtur29Rz1xA [9] Vincent Mathieu, Pascal Aubry, Julien Marchal, Single Sign-On open-source avec CAS (Central Authentication Service). http://www.google.cm/url?q=http://www.esup- portail.org/consortium/espace/SSO_1B/cas/jres/cas-jres2003- article.pdf&sa=U&ei=5hPkUba0PPGb1AXlmIGQBg&ved=0CBkQFjAA&usg=AFQjCNH6z xL2y1ShZCCHLYjbYxWRCBzJPw [10] DANG Quang Vu, Mémoire de fin d’étude, IFI, support de source d’authentification multiples dans un portail de travail collaboratif, Institut National des Télécommunication, novembre 2006.
  59. 59. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 48 Annexes LIRT 2011-2012 Annexes Annexe 1 : Installation de Mysql-server Créons la base de données « shibboleth » et la table « shibpid » Créons un utilisateur shibboleth avec pour mot de passe « demo » et limiter les permissions à la base de données shibboleth. #mysql -u root -p mysql> SET NAMES 'utf8'; SET CHARACTER SET utf8; CHARSET utf8; CREATE DATABASE IF NOT EXISTS shibboleth CHARACTER SET=utf8; USE shibboleth; CREATE TABLE IF NOT EXISTS shibpid ( localEntity TEXT NOT NULL, peerEntity TEXT NOT NULL, principalName VARCHAR(255) NOT NULL DEFAULT '', localId VARCHAR(255) NOT NULL, persistentId VARCHAR(36) NOT NULL, peerProvidedId VARCHAR(255) DEFAULT NULL, creationDate timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deactivationDate TIMESTAMP NULL DEFAULT NULL, KEY persistentId (persistentId), KEY persistentId_2 (persistentId, deactivationDate), KEY localEntity (localEntity(16), peerEntity(16), localId), KEY localEntity_2 (localEntity(16), peerEntity(16), localId, deactivationDate) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; USE mysql; INSERT INTO user (Host,User,Password,Select_priv, Insert_priv,Update_priv,Delete_priv,Create_tmp_table_priv, Lock_tables_priv,Execute_priv) VALUES ('localhost','shibboleth',PASSWORD('demo'), 'Y','Y','Y','Y','Y','Y','Y'); FLUSH PRIVILEGES; GRANT ALL ON shibboleth.* TO 'shibboleth'@'localhost' IDENTIFIED BY 'demo'; FLUSH PRIVILEGES; QUIT #apt-get install mysql-server #/usr/bin/mysqladmin -u root password ‘0123456789'
  60. 60. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 49 Annexes LIRT 2011-2012 Annexe 2 : fichier de configuration d’apache ... ServerName pcserver.iut-fv.cm <VirtualHost _default_:443> ServerName pcserver.iut-fv.cm:443 ServerAdmin admin@iut-fv.cm DocumentRoot /var/www SSLEngine On SSLCipherSuite HIGH:MEDIUM:!ADH SSLProtocol all -SSLv2 SSLCertificateFile /etc/ssl/certs/pcserver.iut-fv.crt SSLCertificateKeyFile /etc/ssl/private/pcserver.iut-fv.key SSLCertificateChainFile /etc/ssl/certs/qvsslica.crt.pem <Proxy ajp://localhost:8009> Allow from all </Proxy> ProxyPass /idp ajp://localhost:8009/idp retry=5 BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 # MSIE 7 and newer should be able to use keepalive BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown </VirtualHost> <VirtualHost _default_:8443> ServerName pcserver.iut-fv.cm:8443 ServerAdmin admin@iut-fv.cm DocumentRoot /var/www SSLEngine On SSLCipherSuite HIGH:MEDIUM:!ADH SSLProtocol all -SSLv2 SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key SSLVerifyClient optional_no_ca SSLVerifyDepth 10 <Proxy ajp://localhost:8009> Allow from all </Proxy>
  61. 61. Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 50 Annexes LIRT 2011-2012 Annexe 3 : fichier de configuration /opt/shibbolethidp/metadata/metadata.aaitest.xml Annexe 4 : fichier /opt/shibboleth-idp/conf/attribute-resolver.xml <!-- ... --> <!-- ========================================== --> <!-- Relying Party Configurations --> <!-- ========================================== --> <rp:AnonymousRelyingParty provider="https://pcserver.iut-fv.cm/idp/shibboleth" defaultSigningCredentialRef="IdPCredential" /> <rp:DefaultRelyingParty provider="https://pcserver.iut-fv.cm/idp/shibboleth" defaultSigningCredentialRef="IdPCredential" defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport "> < <rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile" /> </rp:DefaultRelyingParty> <!-- See https://www.switch.ch/aai/SAML1/Attribute-Push for more information --> <rp:RelyingParty id="https://www.switch.ch/aai/SAML1/Attribute-Push" provider="https://pcserver.iut-fv.cm/idp/shibboleth" --- --- <!-- Example LDAP Connector --> <resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory" ldapURL="ldap://ldap.iut-fv.cm" baseDN="ou=people,dc=iut-fv,dc=cm" principal="cn=admin,dc=iut-fv,dc=cm" principalCredential="secret-password"> <dc:FilterTemplate> <![CDATA[ ---- sourceAttributeID="swissEduPersonUniqueID" salt="your random string here"> <resolver:Dependency ref="swissEduPersonUniqueID" /> <dc:ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver" jdbcURL="jdbc:mysql://localhost:3306/shibboleth?autoReconnect=true" jdbcUserName="shibboleth" jdbcPassword="demo" /> ---- <resolver:PrincipalConnector xsi:type="pc:StoredId" id="saml2Persistent" nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" storedIdDataConnectorRef="myStoredId" /> </resolver:AttributeResolver>

×