MEMOIRE DE FIN DE CYCLE. fédération d identité pour l Université Virtuelle du Sénégal

Transcription

1 REPUBLIQUE DU SENEGAL ***** * * ******** Ecole Centrale des Logiciels Libres et de Télécommunications MEMOIRE DE FIN DE CYCLE Pour l obtention du Diplôme de master en Télécommunications/Réseaux Option: Réseaux et Services SUJET : Conception et implémentation d'une plateforme de fédération d identité pour l Université Virtuelle du Sénégal Lieu de stage : RTN Période stage : Août Décembre 2013 Présenté et soutenu par Professeur encadreur : Dr. Samuel OUYA Année universitaire :

2 Dédicaces Je dédie ce travail à mes parents: Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma considération pour les sacrifices que vous avez consenti pour mon instruction et mon bien être. Je vous remercie pour tout le soutient et l amour que vous me portez depuis mon enfance et j espère votre bénédiction m accompagne toujours. Que ce modeste travail soit l exaucement de vos vœux tant formulés, que Dieu, le Très Haut, vous accorder santé, bonheur et longue vie. A mon père CHEIKH NIANG Rien au monde ne vaut les efforts fournis jour et nuit pour mon éducation et mon bien être. Ce travail est le fruit de tes sacrifices que tu as consenti pour mon éducation et ma formation. A ma mère ANNE MARIE BA A ma tante AMINATA GUEYE Vous êtes l exemple de dévouement qui n a pas cessé de m encourager et de prier pour moi. Puisse ALLAH, le tout puissant, vous préserve et vous accorde santé, longue vie et bonheur. i

3 Remerciements Je ne saurais commencer ce mémoire sans remercier ALLAH le tout puissant, qui a toujours guidé mes pas vers le chemin de la connaissance, par sa protection et sa bénédiction. Je tiens aussi à remercier et à témoigner toute ma reconnaissance : A mon père Cheikh Mor Niang et ma tante Bousso Kassé et toute la famille. Au Docteur Samuel OUYA, notre encadreur, pour sa disponibilité et ses multiples recommandations. A Monsieur Amadou Dahirou Gueye et Jean Diokh pour leurs contributions A Monsieur Alfatma THIAM et Abdou Salam BA A mes frère Aly Niang et El hadji Mamadou Niang pour tout leur soutient A mes sœurs Kine, Diatou et Mami A tous les membres du laboratoire TICE du groupe RTN : Mouhamadou Yaya Sow, Achiraf Amoussa, Alkhali Saleh, Yvan Kalia, Yanness Allabi, Gilchrist Ayeboua, Cherif Tchagbele A tout le personnel de RTN et EC2LT A toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce document. ii

4 AVANT PROPOS L école Centrale des Logiciels Libres et des Télécommunications (EC2LT) est une école privée d enseignement supérieur universitaire et professionnelle qui offre une palette de formations axée sur l'informatique, les réseaux et télécommunications en partenariat avec le groupe RTN (Réseaux et Techniques Numériques). La formation en master est sanctionnée par deux années d études théoriques et pratiques suivi d'un stage dans une entreprise. Le stage en entreprise est un moment important de mise en pratique des enseignements reçus. Il permet tout d abord à l étudiant de faire une application réelle des connaissances théoriques, ensuite, mène l étudiant à exprimer les acquis pédagogiques en savoir-faire et savoir être, lui permettant de se positionner dans le monde du travail. En outre, il permet à l étudiant de travailler sur un projet de fin d études et de mener à bien l élaboration de celui-ci depuis l étude préalable jusqu à sa mise en œuvre. Durant son stage l étudiant exprime son niveau de maturité d autonomie, et de sa capacité à évoluer en dehors du milieu scolaire, dans le strict respect des règles du monde du travail. Les étudiants issus de cette formation vont capitaliser des compétences professionnelles diverses leur permettant d intégrer le monde professionnel pour répondre aux besoins et exigences des entreprises dans les domaines des technologies de l'information et de la communication et le développement des applications autour des logiciels propriétaires et libres. C est dans cette optique que nous avons effectué un stage de quatre (4) mois à la R.T.N. Durant cette période, notre travail consistait à concevoir et d implémenter un système de fédération d'identité qui entre dans le cadre du projet de l'université Virtuelle du Sénégal. Ce document tient lieu de mémoire de fin de formation et a pour objectif de présenter le travail effectué sur le thème proposé dont, la soutenance est publique et sera soumis à l appréciation d'un jury. iii

5 RESUME/ABSTRACT RESUME La multiplication et la diversité des systèmes d authentification liée aux ressources numériques constituent un enjeu majeur pour les entreprises, en effet chaque application est soumise à une procédure de contrôle d accès spécifique. De ce fait chaque opération à réaliser peut nécessiter un contrôle d accès et des droits associés, pouvant entrainer une confusion pour l utilisateur qui, par exemple perd, ou oublie ses mots de passe. Le présent mémoire consiste à concevoir et à mettre en place une fédération d indenté via l application Shibboleth pour répondre aux besoins d interconnexion des systèmes d authentification d organismes hétérogènes en proposant deux services : la délégation de l authentification et la propagation d attributs utilisateur afin d'ouvrir l accès à des ressources partagées. Les technologies de l information et de la communication mis en œuvre ont alors pour objectif de mettre en relation les membres de la fédération et les systèmes d informations des organisations physiques d origine impliquées dans le partenariat. La difficulté réside alors dans les différences au niveau des infrastructures et des politiques de sécurités implémentées par chacun des partenaires. Chacun d entre eux doit s interconnecter avec les autres et permettre le partage des ressources tout en préservant la sécurité de sa propre organisation. Mots clefs : Fédération d identités, propagation d attributs, organisation virtuelle, SAML, Shibboleth. iv

6 RESUME/ABSTRACT ABSTRACT Multiplication and diversity of authentication systems related to digital resources is a major challenge for companies, in fact each application is subject to a procedure specific access control. Thus each operation to be performed may require access control and related rights, that could cause confusion for the user, for example lost or forgotten passwords. Herein is to design and implement an indented federation via Shibboleth software to meet the interconnection needs of heterogeneous organizations authentication systems by offering two services: authentication delegation and propagation of user attributes to provide access to shared resources. The information technology and communication implemented then aim to bring together members of the federation and the information of the physical origin of organizations involved in the partnership systems. The difficulty lies in the differences in infrastructure and security policies implemented by each partner. Each must interconnect with each other and enable the sharing of resources while preserving the security of its own organization. Keywords: Federation of identities, propagation attributes, virtual organization, SAML, Shibboleth. v

7 TABLES DES MATIERES DEDICACES... i REMERCIEMENTS...ii AVANT-PROPOS...iii RESUME / ABSTRACT...iv TABLE DES MATIERES...vi LISTE DES TABLEAUX... ix LISTE DES FIGURES...x SIGLES ET ABREVIATIONS... xi INTRODUCTION Chapitre 1: Présentation Générale Présentation de l entreprise RTN Missions de RTN Organigramme de RTN Domaine d activités Présentation de l'université Virtuelle du Sénégal(UVS) Mission de l'université Virtuelle du Sénégal Concept d'espace Numérique Ouvert (ENO) Présentation du sujet Contexte du sujet Problématique vi

8 1.8.3 Objectifs attendus Chapitre 2: État de l art de la fédération d'identité Concepts d organisations virtuelles Définition de la fédération d'identité Cercle de confiance Fonctionnement des fédérations d'identités Chapitre 3 : Système d authentification centralisé Single Sign-On (SSO) Méthode d'authentification SSO Les différents types d authentification unique Approche fédératif Approche centralisé Approche coopérative Présentation du CAS Fonctionnement du CAS Généralités sur les annuaires électroniques Présentation Différences entre annuaire et une Base de Données Protocole LDAP Les classes d'objets Les schémas La norme Supann Les objectifs de la norme Supann Présentation des schémas Structure du DIT (Directory Information Tree) vii

9 3.7.1 Sécurité LDAP Les solutions techniques Les solutions propriétaires La solution libre : Shibboleth Le choix de Shibboleth Chapitre 4: Le système Shibboleth Les composants de Shibboleth Fournisseur de services Fournisseur d'identités(idp) Service de découverte Le fonctionnement de Shibboleth Le fonctionnement de Shibboleth sans SSO Le fonctionnement de Shibboleth avec SSO Le fonctionnement de Shibboleth avec SSO et WAYF Fédération d identités avec Shibboleth Métadonnées Relations de confiance entre les membres d'une fédération Sécuriser l information échangée entre les différents composants Security Assertion Markup Language (SAML) Web Services-Federation (WS-Federation) Liberty alliance Chapitre 5: Implémentation de Shibboleth Conception de l annuaire LDAP Installation de l IdP viii

10 5.3 Installation du SP Installation du WAYF Shibbolisation de quelques ressources Moodle Authentification shibboleth pour Moodle Intégration de Shibboleth à ESUP-PORTAIL Le projet ESUP-PORTAIL Shibbolisation de Esup Conclusion REFERENCES Bibliographie Webographie ANNEXES ix

11 Liste des Tableaux Table 1.3. Attributs shac de l annuaire LDAP...34 Tableau 3.1. Comparaison des produits de fédération d'identité...40 Tableau 5.1. Attributs communs aux utilisateurs...55 Table 5.2. Attributs spécifiques aux personnels...55 Table 5.3. Attributs spécifiques aux étudiants...56 Table 5.4. Attributs spécifiques aux enseignants x

12 Liste des Figures Figure 1.1- Organigramme RTN...14 Figure 2.1- Organisation virtuelle...23 Figure Fonctionnement d un cercle de confiance...25 Figure 2.3- Schéma récapitulatif d une fédération d identité...26 Figure 3.1- Authentification SSO...28 Figure 3.2- Fonctionnement du CAS...30 Figure3.3-Structure du DIT...37 Figure 3.4- Architecture des annuaires maitre esclaves...38 Figure 3.5-Architecture Fonctionnelle d un annuaire en referral...39 Figure 4.1- Authentification et envoie du nameid vers le SP...47 Figure 4.2- Récupération des attributs de l utilisateur par ls SP...47 Figure 4.3- Envoi de la réponse de SP à l utilisateur...48 Figure 4.4- Point de vue côté utilisateur...48 Figure 4.5- Première requête vers un SP...49 Figure 4.6- Point de vue utilisateur dans un contexte SSO...50 Figure 4.7- Redirection vers le WAYF puis vers le CAS...51 Figure 4.8- Redirection du serveur SSO vers l IdP puis le SP...52 Figure 4.9- Point de vue utilisateur dans un contexte SSO et WAYF...52 xi

13 Figure 5.1- Déploiement de l IdP par Tomcat...62 Figure 5.2- Service de découvertes...69 Figure 5.3- Authentification via SSO natif de Shibboleth...70 Figure 5.4- Authentification via CAS...70 Figure 5.5- Page d accueil de la ressource...71 Figure 5.6- Portail Esup...72 Figure 5.7- Authentification Shibboleth dans Esup...73 xii

14 Sigles et Abréviations Nous présentons ici quelques sigles et abréviations que nous utiliserons dans le document. CAS HTTPS LDAP IdP SP WAYF SAML PHP PT RTN UVS ENO SSL SSO ST PGT TGC TIC TICE XML ARP CNAES STEM Central Authentication Service HyperText Transfert Protocol Secure Lightweight Directory Access Protocol Identifier Provider Service Provider Where Are You From Security Assertion Markup Language Hypertext Preprocessor Proxy Ticket Réseaux et Techniques Numériques Université Virtuelle du Sénégal Espace Numérique Ouvert Secure Sockets Layer Single Sign On Service Ticket Proxy Granting Ticket Ticket Granting Cookies Technologies de l Information et de la Communication Technologies de l Information et de la Communication pour l Enseignement extensible Markup Language Attribute Release Policy Concertation Nationale sur l Avenir de l Enseignement Supérieur Sciences, Technologie, Ingénierie Mathématiques xiii

15 Introduction L émergence des Technologies de l Information et de la Communication (T.I.C) et plus particulièrement du réseau de communication Internet est sans conteste la prouesse du millénaire réalisée par les hommes. Elle a abouti à une croissance exponentielle d échanges d'applications web via les réseaux informatiques. Cette multiplication des applications web est une réalité dans les établissements, entraînant nécessairement une authentification des utilisateurs. Ces derniers sont amenés à fournir de nombreuse fois auprès de chacune de ces applications, en multipliant les couples identifiant/mot de passe à retenir. Le déploiement des annuaires LDAP, outre leur apport fonctionnel pour la gestion des groupes, a permis de simplifier la situation en utilisant un référentiel d'authentification commun à la majorité des applications. Ainsi pour les applications utilisant ce référentiel d authentification, l utilisateur peut utiliser un mot de passe unique. La mise en place d'un système de Single Sign On (SSO) doit permettre à l'utilisateur de saisir un mot de passe une seule fois pour accéder à toutes les applications web de l établissement, améliorant ainsi à la fois l'ergonomie d'accès aux applications et la sécurité du système d'information en limitant la circulation des mots de passe. La fédération d identité répond à ce besoin d interconnexion des systèmes d authentifications et offre un cadre technique et de confiance permettant à ses participants de sécuriser et de simplifier l'accès à des ressources Web. Elle permet également aux utilisateurs ayant droit sur les ressources de réduire le nombre de mots de passe à retenir, et aussi une meilleure maîtrise de la diffusion de données à caractère personnel Le présent mémoire comporte cinq (05) chapitres : Dans le premier chapitre nous présenterons la structure d accueil ainsi que le contexte, la problématique, et les objectifs visées à travers cette étude. 1

16 Le deuxième chapitre mettra l accent sur l état de l art et les concepts de fédération d identité afin de mieux s imprégner du sujet à traiter. Dans le troisième chapitre nous parlerons des systèmes d authentifications qui sont indispensable dans une fédération d identité. Dans le quatrième chapitre une étude détaillée de la technologie Shibboleth sera effectuée Enfin dans le cinquième chapitre une phase d implémentation des différents composants de Shibboleth et a réalisé pour obtenir une fédération d identité digne de ce nom. 2

17 Chapitre 1: Présentation Générale Ce chapitre présente la structure d accueil du stage ainsi que le cadre général du projet à travers la problématique, les objectifs visés, et la présentation de l Université Virtuelle du Sénégal. 1.1 Présentation de l entreprise RTN Réseaux et Techniques Numériques est une société dirigée par une équipe de professionnels qualifiés, spécialisée en logiciels libres et centrée sur les services informatiques, techniques numériques et télécommunications. La société offre une large gamme de formations se basant sur des supports de cours, fruits de recherches approfondies. Ces supports testés et avérés permettent aux apprenants d être aussitôt opérationnels. RTN dispose d une équipe de recherche pluridisciplinaire (informaticiens, Mathématiciens, Télécommunicants, etc.) travaillant sur l administration et la sécurité des réseaux informatiques, des travaux de recherche sur les technologies innovantes, les nouvelles techniques de simulations numériques, des problèmes économiques, environnementaux et d ingénierie. 1.2 Missions de RTN La mission du groupe RTN vise à accroître la compétitivité de ses clients par la valorisation des composantes informatiques, logicielles et réseaux constituants le système d'information de ces derniers. Cela leur confère des gains importants en produisant plus et mieux à budget réduit, grâce à l exploitation de la puissance des logiciels libres existants et ceci, sans rupture des cycles d'exploitation de service de ces entreprises et sans remise en cause organisationnelle. Leur principal objectif est de conseiller et de former le personnel des entreprises qui veulent disposer des logiciels libres et adaptés à leurs besoins minimisant ainsi les coûts d'investissements en réseaux informatiques tout en leur apportant une sécurité avancée. 1.3 Organigramme de RTN 3

18 Conseil d'orientation Scientifique DG Service acceuil, info, animation scolaire Service Ressource Technique et Documentaire Directeur Formation Recherche EC2LT Service scolarité, recouvrement et caisse Service Recherche déploiement & formation Départements Service comptabilité et finance Conseil de la vie scolaire et des études (DFR) Service marketing communicatio n & commerciales Bureau des étudiants Commissions permanentes ou adhoc 0-1 Figure 1.1-Organigramme RTN 1.4 Domaine d activités La société RTN offre une palette de services dans le domaine de la technologie de l information et de la communication. Les services de RTN sont orientées Open Source et réalisées selon les besoins et l'exploration des opportunités d'entreprise. Elles répondent par conséquent aux problèmes réels. RTN met également un accent sur le développement des services à valeurs ajoutées, et l interconnexion des réseaux Linux et Windows, participant ainsi à la cohabitation et l harmonisation des réseaux hétérogènes Linux-Windows. Depuis septembre 2013 la RTN a mis en place trois laboratoires de recherche dans les domaines suivants : 4

19 le laboratoire de Cloud Computing le laboratoire des technologies de l information et de la communication pour l enseignement(tice) est chargé d implémenter des technologies et outils pour l efficacité de l enseignement avec des plateformes variées comme Moodle, BigBlueButton Wims Shibboleth, EsupPortal. le laboratoire de Virtualisation La RTN intervient également dans les domaines suivants : Conseils et orientations professionnelles pour la gestion d un réseau d entreprise Mise à niveau du personnel des entreprises La RTN dispense aussi un éventail de formations dont la liste non exhaustive est la suivante Téléphonie sur IP avec le protocole SIP Téléphonie sur IP avec le protocole H323 Téléphonie sur IP avec l IPBX open source Asterisk Mise en place de la Téléphonie sur IP avec le Call Manager de Cisco Messagerie collaborative Les services réseaux RTN intervient également dans les domaines suivants : Une expertise approfondie en logiciels libres Une expertise en ingénierie des réseaux Une expertise dans les plateformes de formation à distance (e-learning) Une expertise dans les plateformes d environnement numérique de travail Une expertise dans les plateformes de fédération d identités Une expertise en cloud computing Une expertise en virtualisation 1.5 Présentation de l'université Virtuelle du Sénégal(UVS) En décidant de mettre en place l Université virtuelle du Sénégal (UVS), l Etat du Sénégal à 5

20 travers le Ministère de l Enseignement Supérieur et de la Recherche s engage dans un extraordinaire pari sur l avenir qui peut changer à jamais le visage de l enseignement supérieur en particulier et de la formation en général au Sénégal. L UVS [W01] est la sixième université publique sénégalaise, elle est de ce point de vue une université comme les autres. Toutefois la spécificité de l UVS tient au fait que le modèle de livraison des enseignements fait essentiellement appel aux Technologies de l Information et de la Communication (TIC) alors que dans le modèle traditionnel la livraison des enseignements se fait en présentiel, face à face. Pour ce qui est du modèle d évaluation des étudiants, l UVS se retrouve dans le même modèle que les universités traditionnelles en ce sens que les évaluations se feront en présentiel et sous surveillance. L UVS s inscrit naturellement dans la mouvance du système LMD (Licence Master Doctorat). Les étudiants de l UVS sont tenus d effectuer les différents parcours de formation qui leur sont proposés dans les mêmes délais et avec les mêmes contraintes académiques que leurs homologues du système traditionnel. Le dispositif ci-dessus décrit est celui de la formation initiale qui est proposées aux bacheliers nouvellement orientés à l UVS. Toutefois, l UVS a l ambition de toucher très rapidement d autres segments demandeurs en formations, et pour ces derniers les formats d apprentissage adéquats seront proposés. Pour mener à bien sa mission l UVS, s appuie sur un réseau d Espaces Numériques Ouverts (ENO). Les ENO sont les terminaisons physiques de l UVS, ce sont de véritables synapses à partir desquelles l université interagit avec ses apprenants et son environnement. Le réseau des ENO ira en se densifiant au cours des années à venir permettant ainsi à l UVS de procéder à un maillage optimal du territoire sénégalais. L UVS apparaît de ce fait comme étant un élément majeur de l aménagement numérique du territoire national. Cependant, l UVS sera partout où le réseau la portera, c est donc dire que l ambition de l UVS à terme ne se limite pas seulement au territoire physique du pays. L UVS propose une palette de formations que sont : Anglais - Assistanat/Secrétariat de direction bilingue - Tourisme et industrie culturelle 6

21 - Marketing et Communication - Littérature et civilisation Anglophone - Métiers de l humanitaire et du développement social Sciences économiques et de Gestion - Licence Comptabilité Finance - Licence Economie sociale et solidaire (ESS) - Licence Management des petites et moyennes organisations - Licence Micro finance Assurance - Licence Management des organisations sanitaires et sociales Sciences juridiques et Politiques - Licence Droit Public - Licence Droit Privé - Licence Sciences Politiques Mathématiques appliquées et informatique (MAI) - Mathématique - Informatique Sociologie - Intervention sociale Une filière est composée de modules qui apportent aux étudiants des compétences et savoir-faire utiles à la maitrise de leur environnement de travail, à leur développement personnel et qui seront capitalisés comme des éléments d enrichissement de leur profil au terme de leur formation. - La maitrise de l environnement de travail - Les outils de bureautiques courants - L anglais et bien d autres modules qui seront délivrés tout au long du parcours de l étudiant 7

22 Les études à l UVS démarrent par certains modules jugés fondamentaux pour une mise à niveau des étudiants et le partage d un minimum de compétences communes. 1.6 Mission de l'université Virtuelle du Sénégal La création de l UVS par décret N est une mise en œuvre de la décision 02 du Conseil Présidentiel du 14 août 2013 qui consiste à "Mettre les Technologies de l Information et de la Communication (TIC) au cœur du développement de l enseignement supérieur et de la recherche pour améliorer l accès à l enseignement supérieur et l efficacité du système". Cette décision porte sur les directives suivantes: Mettre en place l Université virtuelle sénégalaise (UVS) et des Espaces numériques ouverts (ENO) dans chacune des régions du Sénégal et au sein des universités publiques. Mettre en place le système d Information et de Gestion de l'enseignement Supérieur et de la Recherche(SIGESR). Interconnecter tous les établissements d enseignement supérieur public et privé. Créer une bibliothèque nationale virtuelle pour partager les ressources numériques. Créer le Centre de Mutualisation et de Partage(CMP) de l'enseignement supérieur et de la recherche. Développer l enseignent à distance et encourager le personnel d enseignant et de recherche à utiliser les TIC. Le but principal de l'uvs est de contribuer au développement du capital humain à travers une formation qualifiante et efficiente par les TIC pour un développement économique inclusif du pays. Pourquoi avoir crée l UVS? Pour répondre à une demande croissante d accès à l'enseignement supérieur. Pour avoir une université qui s intègre au tissu social, délivrer des formations en adéquation avec la demande du marché (emploi & auto emploi). Pour être le vecteur de concepts liés : à l usage des TIC à des fins pédagogiques, aux capacités liées à l apprentissage tout au long de la vie, à l autonomie, aux capacités liées au travail collaboratif. 8

23 Pour faire du concept une formation pour tous une réalité, accélérer l'aménagement numérique du territoire. Pour renforcer la position du pays dans l économie de la connaissance. L université Virtuelles du Sénégal est destinée pour les: Les nouveaux bacheliers (priorité de l UVS); Les personnes à mobilité réduite ou dans l impossibilité de suivre des enseignements dans les universités traditionnelles ; Les femmes qui trouveront à travers l UVS un modèle capable de les accueillir et de les maintenir dans l enseignement supérieur ; Les professionnels en activité Les exclus du système universitaire traditionnel ; Les cibles des partenaires tels que les ministères, entreprises, universités nationales et étrangères, organismes internationaux. 1.7 Concept d'espace Numérique Ouvert (ENO) Le Ministère de l Enseignement Supérieur et de la Recherche (MESR), prenant en compte les aspects socioculturels et les contraintes liées à l enseignement à distance, prévoit un dispositif original pour accompagner et faciliter l accès aux diverses ressources et services. Ce dispositif est l Espace Numérique Ouvert (ENO). Les ENO sont conçus pour offrir un cadre technologique performant aux étudiants, élèves, enseignants et chercheurs, groupements socio-économiques et autres acteurs. Dans le cadre de l UVS, le réseau des ENO ira en se densifiant au fil des ans. Les étudiants de l UVS trouveront toutefois dans leur ENO de rattachement des équipements, des ressources et des outils informatiques nécessaires au bon déroulement des activités pédagogiques. Espaces de socialisation par excellence, les étudiants trouveront dans leur ENO les appuis en cas de difficulté mais aussi les conditions et les activités propices à l affermissement d un sentiment d appartenance. Pour faciliter à tous, et en particulier aux étudiants, l accès aux ressources numériques et aux équipements informatiques, l UVS mettra en place sur l ensemble du territoire national des ENO. Ces ENO permettront aux étudiants d accéder à des équipements, à des ressources et à des outils 9

24 informatiques nécessaires au bon déroulement des activités pédagogiques. Ils permettront également de disposer de relais physiques pour un bon déploiement de l UVS, et en ce sens, ils permettront à la fois de disposer d espaces pour les enseignements présentiels ou pour les travaux collaboratifs. 1.8 Présentation du sujet Contexte du sujet A l heure où la société de l information et du savoir s impose un peu partout à travers le monde et que les technologies de l information et de la communication envahissent chaque jour un peu plus tous les secteurs de l activité humaine, l enseignement supérieur et de la recherche ne peuvent rester en marge de ce phénomène. Dans le cadre des réformes universitaires lancées au Sénégal en vue d améliorer la qualité de l enseignement comme de la recherche, de faciliter l accès aux ressources numériques, d appuyer le développement de l enseignement à distance, et surtout de mieux armer les étudiants en vue d une insertion réussie dans le monde du travail, l' État du Sénégal a décidé d investir massivement dans les TIC. Pour ce faire, le gouvernement du Sénégal a organisé une Concertation nationale sur l avenir de l enseignement supérieur, en désignant un comité de pilotage dont les membres proviennent de toutes les composantes de la société (universitaires, chercheurs, entrepreneurs, parlementaires, membres de la société civile). La principale orientation de cette réforme est la réorientation du système d enseignement supérieur sénégalais vers les sciences, la technologie, l ingénierie et les mathématiques (STEM) ainsi que la promotion des formations professionnelles. En outre, le Contrat de performance, signé entre l État et les universités public du Sénégal avec l appui technique et financière de la Banque mondiale, va mettre à la disposition des universités, des crédits additionnels pour une perspective d excellence. Toutes les universités ont formulés leurs besoins pour atteindre le pari de la performance, cependant elles ont tous un point commun : disposer d'une plate-forme d'enseignement à distance. Suite au besoin énuméré ci-dessus, l Etat du Sénégal a recommandé la création de l Université virtuelle du Sénégal qui s appuie sur : des espaces numériques ouverts, un environnement de travail 10

25 numérique(ent) et une plateforme d e-learning afin d offrir un accès partagé à des ressources numériques. L UVS qui repose sur la formation à distance, préconise de mettre en place une solution d e- Learning basée sur MOODLE pour mettre à la disposition des universités des ressources numériques dont les cours seront rédigés et postés par des professeurs issus des différents établissements afin de fournir des contenus de qualités. Fort de ce constat, le partenariat entre les différents organismes dispersés géographiquement, notamment les universités est généralement pressenti comme une nécessité tant pour les étudiants que pour les formateurs. En effet, il constitue une réponse à la carence de ressources disponibles et permet d ouvrir l accès à une ressource locale à d'autres établissements, mais aussi un levier pour faire de l'enseignement supérieure le moteur du processus devant conduire le Sénégal vers l émergence économique et sociale Problématique Les entreprises comme les établissements supérieurs connaissent un réel besoin de coopérer en extériorisant leurs ressources ; particulièrement web qui ont l'apanage d être plus rapide et moins coûteuses à mettre en œuvre, délivrant souvent les entreprises de la complexité d'administration de l'infrastructure. Les applications Web permettent aussi de simplifier, d'accélérer et d'amplifier les échanges entre l'entreprise et ses partenaires, cependant à chaque connexion sur une application, l'utilisateur doit fournir un identifiant et un mot de passe spécifiques à la plate-forme Web visitée. Chaque utilisateur doit donc retenir plus d'une dizaine d'identifiants et de mots de passe, plus ou moins complexes selon les exigences de sécurité de l'application. Soucieux des pertes ou d oublis des paramètres des connexions chez les usagers, alors il s avère nécessaire de mettre en place une solution palliative pour contourner le problème d authentification multiple. Pour résoudre les problèmes énumérés ci-dessus en toute sécurité tout en réduisant les coûts et en améliorant la productivité, alors on a recours à la fédération d identité qui met à la disposition de nos utilisateurs un passeport unique pour accéder aux différentes applications via un mécanisme de propagation d identités. 11

26 1.8.3 Objectifs attendus Les objectifs principaux de ce mémoire consistent à : mettre en place un système d information (référentiel utilisateur) concevoir et déployer un système de fédération d identité 12

27 Chapitre 2: État de l art de la fédération d'identité Ce chapitre présente l état de l art de la fédération d'identité, dont l objectif est d identifier et cerner les concepts liés aux organisations virtuelles et leurs modes de fonctionnement. La fédération d'identité fournit un moyen de délégation de l'authentification et du processus d'affectation d'accréditations. Ceci permet à une organisation de ne gérer que ses propres utilisateurs et déléguer la tâche de gestion des utilisateurs externes à leurs organisations de rattachement fournissant ainsi une solution à l'hétérogénéité des systèmes d'authentification et d'accréditation adoptés au niveau des sites partenaires. Une fédération repose à la fois sur une infrastructure informatisée et une architecture de services. 2.1 Concepts d organisations virtuelles Les besoins de collaboration entre organisations et les facilités technologiques donnent aujourd hui naissance à une nouvelle forme d organisation et de coopération dénommée : Virtuelle Eva Fueher (1997) dans [B01] définit l'organisation virtuelle(ov) comme un réseau temporaire d'institutions indépendantes, entreprises ou individus, qui à travers l'utilisation des technologies de l'information et de la communication s'unissent spontanément pour atteindre leurs objectifs qui sont généralement orientés sur la mobilisation des ressources et des compétences distinctives placées dans différents lieux géographiques. Contrairement aux organisations traditionnelles, les frontières de l organisation virtuelle restent ambiguës. Ces frontières sont définies par la stratégie de chacune des organisations pour réaliser les tâches qui lui sont confiées. 13

28 Figure2.1-Organisation virtuelle 2.2 Définition de la fédération d'identité Une fédération d identité est une organisation virtuelle constituée d un groupe d organisations qui sont liées entre elles par des intérêts communs dans un ou plusieurs domaines d affaires. Chaque organisation de la fédération est autonome et délègue à celle-ci la gestion des accès. Cette gestion permet l authentification et l autorisation des usagers selon un niveau de confiance défini par des politiques de la fédération. Les services de la fédération offrent les opérations suivantes : Émission, validation et transmissions des informations relatives aux utilisateurs, des demandes de justification, des attributs et des assertions relatives à la sécurité; Intégration des informations relatives à la sécurité; Application des politiques qui utilisent les informations relatives à la sécurité, afin de valider l autorisation pour une demande ou une action sur une ressource ou un service 14

29 Les solutions de fédération d identités permettent à une application, dans un organisme, d interagir avec un système d authentification d une autre entité. L application, appelée fournisseur de service(ou SP, Service Provider), délègue la phase d authentification d un utilisateur à l organisme auquel il est rattaché, appelé fournisseur d identité(ou IdP, Identity Provider). Le SP conserve la prérogative du contrôle d accès, mais peut pour cela utiliser des attributs de l utilisateur fournis par l IdP. Un SP peut être sollicité par des utilisateurs issus de différents IdP. Inversement, les utilisateurs rattachés à un IdP peuvent accéder à différents SP. 2.3 Cercle de confiance La définition des relations de confiance entre les IdP et les SP à un plus haut niveau est cruciale. Un SP se repose sur les IdP pour assurer une authentification sûre de ses utilisateurs et la qualité de ses attributs. Réciproquement un IdP fait confiance aux SP quant à la bonne utilisation des attributs nominatifs. La formalisation de ces relations de confiance peut se faire de gré à gré entre chaque paire d IdP/SP. Cependant, il est naturel de vouloir formaliser la définition de ces relations de confiance pour [B08] un ensemble de fournisseurs qui forment alors un cercle de confiance. L inscription à un tel cercle impose de respecter des règles communes. Au sein d un cercle de confiance, des règles existent pour assurer la protection des données personnelles des utilisateurs qui peuvent être communiquées entre fournisseurs. 15

30 Figure2.2 Fonctionnement d un cercle de confiance 2.4 Fonctionnement des fédérations d'identités Les types d utilisateurs : Les utilisateurs finaux sont les personnes qui vont effectivement se connecter à des sites web via une fédération d'identités. En général elles ne savent pas et ne voient pas que leur connexion a lieu vers une fédération d'identités, c'est transparent pour elles les fournisseurs d'identités sont les organismes auxquels sont rattachés les utilisateurs finaux. Un fournisseur d'identités a pour rôle d'authentifier ses utilisateurs quand ceux-ci accèdent un site web via la fédération d'identité. les ressources sont les sites web auxquels peuvent accéder les utilisateurs finaux via une fédération d'identités. Il peut s'agir par exemple de sites d'enseignement à distance, d'outils collaboratifs en ligne, de portail de documentations numérisées. l'opérateur de la fédération est l'entité qui gère la fédération, a défini ses règles de fonctionnement et prend en charge l'inscription des fournisseurs d'identités et des ressources dans la fédération. Déroulement de l'accès à une ressource d une fédération d'identités l'utilisateur se rend avec son navigateur sur la page d'accueil d'une ressource il est redirigé vers une page ou il choisit son organisme de rattachement l'utilisateur est automatiquement renvoyé vers la page d'authentification classique de son organisme sur laquelle il peut saisir son identifiant et mot de passe si l'authentification réussit, le logiciel fournisseur d'identités de l'organisme va automatiquement récupérer des informations sur l'utilisateur dans le ou les référentiels de l'organisme l'utilisateur est renvoyé sur la ressource où il est alors automatiquement authentifié et peut alors l'utiliser. 16

31 lors de la redirection de l'utilisateur depuis le fournisseur d'identités vers la ressource, cette dernière reçoit de la part du fournisseur d'identités une preuve informatique d'authentification de l'utilisateur et éventuellement des informations sur l'utilisateur. Figure2.3 - schéma récapitulatif d une fédération d identité 17

32 Chapitre 3 : Système d authentification centralisé Dans ce chapitre, nous examinons en premier lieu le mécanisme du Single Sign-On (SSO), pour centraliser l'authentification afin de permettre à l'utilisateur d'accéder à toutes les ressources auxquelles il est autorisé d'accéder, en s identifiant une seule fois sur le réseau, ensuite faire une étude générale sur les annuaires, et enfin terminer par une étude comparative des différentes technologies pour l authentification unique. Dans le projet l'objectif du SSO est de propager l'information d'authentification aux différents services du réseau, et d'éviter ainsi à l'utilisateur la saisie de multiples identifications par mot de passe. 3.1 Single Sign-On (SSO) Les organisations actuelles possèdent un réseau complexe composé de ressources diverses telles que des applications internes, des applications web ou différents systèmes d exploitations. L utilisateur se voit obligé de saisir à chaque fois un identifiant et un mot de passe. Dans certains cas, on a plusieurs applications différentes, toutes ayant une authentification propre. Une telle situation n est pas sans créer des problèmes: non seulement la saisie manuelle coûte un temps précieux, mais il est extrêmement difficile de se souvenir de plusieurs mots de passe. Ainsi, les utilisateurs utilisent toutes sortes de méthodes, peu sûres, pour faire face à cette multiplication des identifiants. Le plus souvent, ils notent leurs mots de passe sur un post-it, le glissent sous le clavier ou choisissent un mot de passe très simple. Par ailleurs, il est très fréquent que les utilisateurs appellent le support informatique à cause d un mot de passe oublié. Les avantages de l'authentification unique sont : La réduction de la fatigue de mot de passe : manque de souplesse liée à l'utilisation de différentes combinaisons de nom d'utilisateur et de mot de passe La centralisation des systèmes d'authentification La centralisation des informations de contrôles d'accès pour les tests de conformités aux différentes normes 18

33 Les technologies fournissant des SSO utilisent des serveurs centralisés d'authentification que toutes les autres applications et systèmes utilisent pour l'authentification, combinant ceux-ci avec des techniques logicielles pour s'assurer que les utilisateurs n'aient pas à entrer leurs identifiants plus d'une fois 3.2 Méthode d'authentification SSO Les services numériques accessibles par le web (intranet, courrier électronique, forums, agendas, applications spécifiques) à disposition des étudiants, enseignants, personnels administratifs se sont multipliés en quelques années. Ces services nécessitent très souvent une authentification. L'utilisation de techniques de synchronisation entre domaines d'authentification hétérogènes, puis de serveurs LDAP a permis la mise en œuvre d'un compte unique (login / mot de passe) pour chaque utilisateur, ce qui est un progrès. Toutefois on est contraint à des problèmes suivants : L'authentification unique (ou identification unique ; en anglais Single Sign-On : SSO) est une méthode permettant à un utilisateur de ne procéder qu'à une seule authentification pour accéder à plusieurs applications informatiques (ou sites web sécurisés). L universalité du protocole HTTP fait que les applications portées sur le web sont de plus en plus nombreuses. La mise en place d annuaires (LDAP par exemple) permettra aux utilisateurs de mémoriser qu un seul mot de passe, mais ils devront s authentifier à chaque fois qu il accède à une application Les mécanismes de SSO [B02] (authentification unique pour accéder à plusieurs applications) tentent de résoudre ces problèmes en utilisant tous des techniques assez semblables, à savoir : une centralisation de l authentification sur un serveur qui est le seul à recueillir les mots de passe des utilisateurs, à travers un canal chiffré ; des redirections HTTP transparentes du navigateur client, depuis les applications vers le serveur d authentification, puis du serveur vers les applications le passage d informations entre le serveur d authentification et les applications à l aide de cookies, et/ou de paramètres CGI de requêtes HTTP (GET ou POST). 19

34 Figure Authentification SSO 3.3 Les différents types d authentification unique Approche fédérative Dans ce mécanisme, dont le système Liberty Alliance est le principal exemple, chaque service gère une partie des données d'un utilisateur (l'utilisateur peut donc disposer de plusieurs comptes), mais partage les informations dont il dispose sur l'utilisateur avec les services partenaires. Ce mécanisme 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é Approche centralisé Le principe de base est ici de disposer d'une base de données globale et centralisée de tous les utilisateurs ou d'un annuaire. Cela permet également de centraliser la gestion de la politique de sécurité Approche coopérative Le mécanisme coopératif, dont les systèmes Shibboleth et CAS sont les principaux représentants, part du principe que chaque utilisateur dépend d'une des entités partenaires. Ainsi, lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est authentifié par le partenaire dont il 20

35 dépend. Comme dans l'approche fédérative, cependant, chaque service du réseau gère indépendamment sa propre politique de sécurité. 3.4 Présentation du CAS Le Service central d authentification (CAS) [B03] est un système d'authentification unique (SSO) pour le web développé par l'université Yale. On s'authentifie sur un site Web, et on est alors authentifié sur tous les sites Web qui utilisent le même serveur CAS. Il évite de s'authentifier à chaque fois qu'on accède à une application en mettant en place un système de ticket. 3.5 Fonctionnement du CAS 1- Le client web tente une connexion vers une application web à partir d une requête initiale en http. L application web redirige la requête vers une page d authentification du serveur CAS. Le client peut accéder directement en https au CAS (1 ). 2- Le serveur CAS réalise l authentification grâce à LDAP (login + mot de passe) 3- Le CAS génère un ticket ST (Service Ticket) au client. Ce dernier envoie les paramètres de connexion à l application web et passe en paramètre le ticket ST. 4- L application web accède directement au CAS en http ou en https et passe en paramètre l ID de service (l ID de service est l URL du service). 5- Le CAS génère un ticket TGC (Ticket Granting Cookies). Le CAS envoie le TGC à l application web. C'est un cookie de session qui est transmis par le serveur CAS au navigateur du client lors de la phase de login. 6- Le CAS valide le ticket ST et retourne l UID de l utilisateur. En ce moment l utilisateur est authentifié et peut maintenant accéder à la page 21

36 Formulaire CAS Figure 3.2- Fonctionnement du CAS 3.6 Généralités sur les annuaires électroniques Dans le cadre de la mise en place d'une fédération d identité, une grande quantité d informations relatives aux acteurs sont manipulées. Ces informations doivent être stockées dans une base d'informations afin d'en assurer la cohérence, la sécurité, l accessibilité et la centralisation. Ainsi la base d'information étant beaucoup plus sollicitée en lecture, nous avons porte notre choix sur les annuaires LDAP qui sont réputés être performants pour les accès en lecture. Pour une homogénéité de la représentation des données dans un annuaire LDAP concernant l'enseignement supérieur, une norme a été définie : c'est la norme Supann Présentation Un annuaire électronique peut être vu comme une base de données spécialisée, dont la fonction première est de retourner un ou plusieurs attributs d'un objet grâce à des fonctions de recherche multicritères. 22

37 Les objets peuvent être de nature très diverse. Par exemple, un objet de l annuaire peut représenter une personne et les attributs de cet objet seront alors son nom, son prénom, son numéro de téléphone, etc. Un annuaire électronique va centraliser des informations et les rendre disponibles, via le réseau, à des applications, des systèmes d exploitation ou des utilisateurs Différences entre annuaire et une Base de Données Bien qu un annuaire soit comparable à une base de données pour un grand nombre de fonctionnalités, il en diffère en de nombreux points. Un annuaire est très performant en consultation (c est-à-dire en lecture ou en recherche). Par contre, un annuaire n est pas très adapté pour des mises à jour fréquentes (écriture). Les données contenues dans un annuaire sont en effet beaucoup plus pérennes, et il est donc totalement inutile d optimiser les fonctions de mise à jour. Une base de données doit, par contre, généralement supporter des applications qui la remettent constamment à jour. Cela signifie que la fonctionnalité écriture dans une base de données est importante et doit par conséquent être optimisée. Un annuaire LDAP organise les données de manière arborescente, tandis que les bases de données le font au sein de tableaux à deux dimensions Protocole LDAP LDAP (Lightweight Directory Access Protocol, ou Protocole d'accès aux annuaires léger) est un protocole standard permettant de gérer des annuaires, c'est-à-dire d'accéder à des bases d'informations sur les utilisateurs d un réseau par l intermédiaire du protocole TCP/IP. Les bases d'informations sont généralement relatives à des utilisateurs, mais elles sont parfois utilisées à d autres fins comme pour gérer du matériel dans une entreprise. Il est normalisé par l IETF (Internet Engineering Task Force) dans sa version 3 en 1997, LDAP est un protocole client-serveur et offre quatre modèles prédéfinis. L objectif de cette modélisation est de favoriser le partage et de simplifier la gestion des informations concernant des personnes, et plus généralement toutes les ressources de l entreprise, ainsi que des droits d accès des utilisateurs sur ces ressources. 23

38 Les modèles LDAP : Modèle d information : Il définit la nature des données stockées dans l annuaire. Celles-ci sont constituées d un ensemble d enregistrements dans lequel chaque enregistrement est l instance d une classe d objet comportant une série d attributs. Chaque attribut est défini par un type (entier, chaine de caractère etc.) et contient un ou plusieurs valeurs, qui peuvent être obligatoire ou non. Modèle de désignation : Il définit la façon d organiser et de designer les entrées dans l annuaire. Les données sont classées de façon hiérarchique dans un arbre, reflétant en général l organisation de l entreprise. Le nom d une entrée contient le nom des différents nœuds de l arbre puis l identifiant de celle-ci. Modèle des services : Il décrit les fonctions offertes par un annuaire LDAP. Ces fonctions comprennent la recherche et la consultation des entrées de l annuaire, la mise a jour de celui-ci, et l authentification des utilisateurs auprès de ces services. Modèle de sécurité : Il définit la manière de s identifier de façon sécurisée à un annuaire LDAP et le concept des droits d accès aux différents objets de l annuaire. La gestion de la sécurité est pointue car elle permet de définir des droits d accès non seulement au niveau d un objet, mais aussi au niveau d un attribut de cet objet Les classes d'objets La classe d objet d un annuaire LDAP permet de spécifier les attributs possibles pour une entrée représentant un objet particulier du monde réel. Cette liste d'attributs est subdivisée en deux parties : la première liste définit quels sont les attributs obligatoires que doit posséder une entrée, la seconde liste définit les attributs optionnels que peut posséder cette entrée. En effet, les classes d'objet d un annuaire LDAP sont définies par plusieurs caractéristiques. En premier lieu, une classe d'objet possède au moins un nom de façon à l'identifier facilement. En second lieu, indiquer si la classe est structurelle ou auxiliaire. Les classes structurelles sont les seules qui permettent de construire des entrées. Ce qui signifie que toute entrée doit posséder au moins 24

39 une classe structurelle. Les classes auxiliaires permettent de rajouter facilement un certain nombre d'attributs à une entrée existante. Les classes d'objets ont une autre particularité très intéressante. On peut construire de nouvelles classes à partir de classes existantes. Autrement dit, la notion d'héritage existe également pour les classes d'objets Les schémas Les annuaires permettent de stocker et de gérer des identités, on y trouve des objets représentants des personnes et des attributs permettant d identifier et de définir la personne comme le nom, prénom, téléphone L ensemble des types d objets possible dans l annuaire, et pour chaque objet l ensemble des attributs utilisables est défini dans l annuaire. Le schéma contient la syntaxe et la liste des attributs connus de l'annuaire. Extension de schéma Parfois il arrive qu on veuille stocker dans l annuaire des informations de nature particulières pour les besoins propres à ses applications. Si le schéma d origine ne le permet pas, on peut réaliser une extension de schéma. L extension de schéma [B06] consiste à définir pour un annuaire de nouveaux types d objets, ou de nouveaux attributs pour un type d objet existant. Attributs LDAP Un attribut est une valeur contenue dans une entrée. Une entrée peut contenir plusieurs attributs. Format d échange de données LDIF LDIF (LDAP Data Interchange Format ou Format d échange des données LDAP) permet l exportation ou l importation des donnes depuis ou vers un annuaire LDAP. Il décrit le format de fichier de texte qui contient tout ou partie des donnes d un annuaire La norme Supann SUPANN [B05] est un groupe de travail ayant pour mission d'élaborer des recommandations annuaires compatibles avec les préconisations existantes au niveau interministériel ainsi qu'au niveau 25

40 international (IETF et Internet2) et satisfaisant les spécificités relatives aux établissements d'enseignement supérieur. Supann a rédigé des recommandations en matière d'annuaires d'établissements compatibles sur le plan national, au standard LDAP. Ces recommandations s'adressent à l'ensemble des établissements d'enseignement supérieur et s'inscrivent dans le cadre du schéma directeur des environnements de travail. Disposer d'un annuaire national de l'enseignement supérieur, permettre la mutualisation des ressources entre les établissements ou accéder à des ressources externes, offrir aux applications de l'enseignement supérieur une structure d'annuaire standardisée Les objectifs de la norme Supann Les principaux objectifs de la norme Supann sont : proposer aux établissements un cadre adéquat pour la mise en œuvre de leur base d informations en respectant les spécifications d'un noyau LDAP. favoriser la portabilité des logiciels utilisés par les établissements d enseignement supérieur, en homogénéisant les schémas d'annuaires. converger vers des compétences internes similaires en matière d'annuaire Faciliter l échange d informations entre les différents établissements Permettre un contrôle d accès à des ressources distantes, basées sur le profil de l utilisateur issu de l annuaire de son établissement de rattachement Présentation des schémas Pour la mise en place d'un annuaire LDAP digne de ce nom, il faut inclure le schéma Supann. Ce dernier comporte un ensemble de classes et d'attributs pour la représentation des informations relatives à l'enseignement supérieur. Par contre toutes les informations ne sont pas prise en compte par le schéma Supann, d où la nécessite d inclure d'autres schémas tels Internet2, Schac afin d'avoir une représentation optimale. Schéma Internet 2 Internet2 est conçus pour inclure des personnes largement utilisé et les caractéristiques organisationnelles de l'enseignement supérieur. 26

41 Le problème majeur d Internet2 est qu il n'existe pas de modèles établis pour la construction de répertoires institutionnels à usage général. Chaque institution doit commencer à partir de zéro, et il n'ya pas deux répertoires d'enseignement supérieur qui se ressemblent. La classe d'objet eduperson donnerait une liste d'attributs communs et des définitions. Le groupe de travail prévoit de s'appuyer sur les travaux des normes en vigueur dans l'enseignement supérieur, sélectionnez les éléments qui sont d'une grande utilité, et définir une représentation LDAP commun pour chacun d'eux. L'usage du schéma Internet2 nous permet d'avoir l attribut statut des acteurs de notre annuaire Présentation du schéma Schac SCHAC est une collection de schémas qui vise à définir et à promouvoir des schémas communs dans le domaine de l'enseignement supérieur pour faciliter l'échange de données entre organisations, il définit un ensemble d'attributs pour décrire les individus dans les institutions universitaires et de recherche et contient un profil LDAP approprié. L'usage du schéma Schac nous permets d'avoir les attributs suivants : Tableau 1.3-Attributs schac pour l annuaire LDAP Attributs Attributs correspondant Date de Naissance Pays d'origine Lieu de naissance Pays de résidence shacdateofbirth schaccountryofcitizenship schacplaceofbirth schaccountryofresidence 3.7 Structure du DIT (Directory Information Tree) La racine de l'arborescence est nommée par le nom DNS de l'établissement conformément aux recommandations préconisées par l'ietf (utilisation des Domain Component - RFC 2377). Ceci permet d'adresser de manière fiable les informations de tout établissement puisque l'unicité d'un domaine est assurée au sein d'internet. Exemple : pour l'uvs, nous aurons "dc=uvs, dc=sn" Trois «Organizational Unit» sont décrites par Supann : 27

42 la première appelée «people» désigne le conteneur de l'ensemble des informations concernant les personnes présentes dans l'établissement. Il s'agit d'informations décrites à l'aide des classes InetOrgPerson, eduperson, supannperson ; la seconde appelée «groups» désigne le conteneur des informations concernant la mise en cohorte d'individus. Ces informations sont décrites à l'aide des classes GroupOfNames et supanngroupe. la troisième appelée «structures» est le conteneur des structures matérielles (services, etc.) et des structures immatérielles (instances électives, modules d'enseignement, etc.). Ces informations sont décrites par les classes OrganizationalUnit et SupannEntite. Pour implémenter l annuaire on a nommé notre racine dc=uvs, dc=sn. Nous avons aussi créé une branche people pour les divers acteurs. Quant aux départements et filières ils ont été intégrés dans des structures organisationnelles. Il faut noter que nous avons fait une distinction significative entre les départements et filières. En effet, les filières sont reliées à une branche filière et les départements placés dans la branche direction générale DG). Figure3.3-Structure du DIT Sécurité LDAP La mise en place d un annuaire d'entreprise, nécessite une réflexion au modèle de sécurité à appliquer. LDAP fournit plusieurs mécanismes permettant de sécuriser les données 28

43 L'authentification simple, le binding L'annuaire met en place un mécanisme d'authentification pour avoir accès aux données qu'il contient. L'une des opérations préalables à l'interrogation de l'annuaire est cette opération dite de "binding" (dans le cas d'une authentification simple). Le client envoie alors le DN d'un compte contenu dans l'annuaire lui-même, ainsi que le mot de passe associé. On pourra par la suite appliquer des droits particuliers sur ce compte en utilisant les ACLs. Les ACL Les ACLs (Access Control Lists) interviennent après la notion de binding. Il sera possible de donner des droits de lecture, d'écriture (ou d'autres droits divers) sur des branches particulières de l'annuaire au compte connecté. Ceci permet de gérer finement les droits d'accès aux données. Le chiffrement des communications (SSL/TLS) Le chiffrement des communications, via SSL (Secure Socket Layer, ou TLS - Transport Layer Security) est également une méthode de protection de l'information. Il est possible, avec la plupart des annuaires existants, de chiffrer le canal de communication entre l'application cliente et l'annuaire. Ceci permet de garantir (un minimum) la confidentialité des données et d'éviter qu'un tiers n'écoute les communications sur le réseau. La réplication OpenLDAP, permet de manière native, de mettre en place un annuaire répliqué. Un annuaire dit maître envoie alors, par le biais du format LDIF, toutes les modifications effectuées sur un annuaire esclave. L'avantage d'une telle opération est double : permettre une meilleure montée en charge pour de gros annuaires : il est possible de rediriger le client vers l'un ou l'autre des annuaires répliqués disposer d'une copie conforme du premier annuaire, utile en cas de panne Deux types de réplication existent : le mode "maître-esclave", le plus courant : la réplication est unidirectionnelle, un annuaire maître envoie toutes les modifications à un annuaire esclave. Ceci n'autorise bien évidemment l'écriture que sur l'annuaire maître ; l'esclave est alors disponible uniquement en lecture. 29

44 le mode "maître-maître" : la réplication est bidirectionnelle, chaque annuaire peut être maître de l'autre. Ceci permet d'écrire indifféremment sur l'un ou l'autre des annuaires. Figure 3.4- Architecture des annuaires maitre esclaves La distribution (les referrals) La distribution est un mécanisme qui va permettre de faire pointer un lien vers un autre annuaire pour une branche particulière. Ceci va permettre de déléguer la gestion de cette branche, un peu au sens DNS lorsqu'on délègue la gestion d'un domaine. Fonctionnement des referrals L annuaire 1 possède un referral pour la branche ou=groups. Ce referral [B07] pointe vers l annuaire2 La gestion de cette branche est donc en quelques sortes "déléguée" à l'annuaire2. Au niveau de l annuaire 1, ceci se traduit par une entrée de la classe "referral", qui contient alors un attribut "ref" contenant l adresse de suite de l arborescence. 30

45 dc=uvs,dc=sn Ou=people, dc=uvs, dc=sn ou=groups, dc=uvs, dc=sn uid=papis.niang,ou=people, dc=uvs,dc=sn uid=amoussa.achiraf,ou=people,dc=uvs,dc=sn Annuaire 1: ldap1.uvs.sn Ou=groups, dc=uvs, dc=sn Referral cn=étudiants, ou=groups, dc=uvs, dc=sn cn=enseignants, ou=groups, dc=uvs, dc=sn Annuaire 2: ldap2.uvs.sn Figure 3.5-Architecture Fonctionnelle d un annuaire en referral 3.8 Les solutions techniques Différentes solutions d authentification et de contrôle d accès aux applications ont été développées, apportant des satisfactions dans certains cas, mais présentant néanmoins certains défauts. Pour palier à ces difficultés la délégation d authentification a été préconisée. En effet, la phase d authentification avant l accès à une application sera assuré par les services d authentification de l établissement de rattachement de l utilisateur. Ce service enverra une assertion à l application indiquant si l utilisateur s est bien authentifié. Par contre, le contrôle d accès est toujours effectué au niveau de l application. 31

46 3.8.1 Les solutions propriétaires CA SiteMinder Federation Security Services et CA SOA Security Manager HP OpenView Select Federation IBM Tivoli Federated Identity Manager Microsoft Active Directory Federation Services Ping Identity PingFederate et Ping Identity Ping Trusts RSA Federated Identity Manager La solution libre : Shibboleth Shibboleth [W02] est développé depuis 2001 par Internet2 et désigne à la fois une norme et un produit, il repose sur un mécanisme de propagation d'identités. Son objectif est double : d'une part il permet, lors de la connexion à un service enregistré dans la fédération, de déléguer l'authentification à l'établissement d'origine de l'utilisateur. d'autre part il contribue à obtenir certains attributs (données annuaire) de l'utilisateur, afin de gérer le contrôle d'accès ou personnaliser les contenus. Shibboleth s'appuie en général sur un système CAS et offre donc également les fonctionnalités de SSO standards (fenêtre d'authentification unique, plus besoin de retaper son mot de passe lorsque l'utilisateur passe d'un service à l'autre). 32

47 Tableau 3.1. Comparaison des produits de fédération d'identité CA SiteMinder FSS CA SOA SecurityManager HP OpenView Select Federation Facilité de déploiement et de configuration Moyen Moyen Moyen Conformité aux langages d échange de l information de sécurité Possibilité de fédérer des identités entre des Web Services Coût Support pour différents Systèmes et technologies d authentification SAML 2.0 et SAML 2.0 et SAML 2.0 et WS-Federation WS-Federation WS-Federation Non Oui Oui pour maintenance annuelle (licence pour 4cpu) pour Maintenance annuelle pour une connexion mots de passe, jetons, mots de passe, jetons, mots de passe, jetons, certificatsx.509, certificatsx.509, cartes à puce, certificats techniques biométrique techniques d identité X.509, biométriques Niveau de sécurité offert -clustering, haute disponibilité - load balancing, -Cluster, haute disponibilité Respect de la vie privée Protégée Protégée Protégée 33

48 IBM Tivoli FIM Microsoft Ping Identity ADFS PingFederate Facilité de déploiement Difficile Moyen Facile et de configuration Approche adoptée pour Intégrée à Tivoli Intégrée à Autonome gérer la fédération Access Manager Windows Server 2003 Conformité aux langages SAML 2.0 et WS-Federation SAML 2.0 et d échanges de WS-Federation WS-Federation l information de sécurité Possibilité de fédérer Oui Oui Non des identités entre des Web Services Coût 8200 pour une prix de 8000 pour 1 licence en plus de licences annuelles connexion par an licences pour les logiciels requis Support pour différents Les mécanismes Microsoft Active Mots de passe, cartes systèmes et supportés par Tivoli Directory (Kérberos, à puce, techniques technologies Access Manager cartes à puce et biométriques, clésusb, d authentification (cartes à puce, certificats d identité certificats X.509, technique biométriques, X.509) et LDAP Kerberos, etc.) Niveau de sécurité -cluster pour - Possibilité de -cluster pour une offert une haute déploiement de serveurs haute disponibilité et performance et de fédération récupération disponibilité additionnels pour load balancing et évolutivité Respect de la vie privée Protégée Protégée Protégée 34

49 Ping Identity RSA Federated Internet2 PingTrust Identity ManagerRSA Shibboleth Federated Identity Manager Facilitéde déploiement Facile Moyen Moyen et de configuration Approche adoptée pour Autonome Autonome Intégré à un WAM gérer la fédération Conformité aux SAML 2.0 et SAML 2.0 SAML 2.0 et languages d échange de WS-Federation WS-Federation l information de sécurité Possibilité de fédérer Oui Oui Non des identités entre des Web Services Coût 8000 pour pour Logiciel libre connexion par an 3 connexions pour 10 connexions Support pour différents mots de passe, cartes à Authentification à Active Directory, systèmes et puce, techniques 2 facteurs basés LDAP, Kerberos technologies biométriques, clés sur RSA d authentification USB, certificats X.509, Niveau de sécurité -cluster, haute -cluster, haute -haute disponibilité offert disponibilité disponibilité - load balancing Respect de la vie privée Protégée Protégée Protégée 35

50 3.9 Le choix de Shibboleth De cette étude, il ressort que les produits de fédération étudiés présentent un fort potentiel en termes d interopérabilité, de niveau de sécurité offert, de support de standards d échange d information de sécurité, etc. Cependant, tous ces produits bien qu efficaces en termes de gestion d identité, présentent des insuffisances en termes de gestion d accès. Après l étude des différentes solutions, nous avons porté notre choix sur Shibboleth pour plusieurs raisons : Les fonctionnalités offertes par Shibboleth sont moins étendues, mais correspondent aux principaux cas d usages de notre communauté. Surtout la topologie d une fédération de type Shibboleth correspond bien à la structuration d un ensemble d établissements d enseignement supérieur. De plus c est un produit open source, soutenue par une communauté active et ouverte, et qui s interface bien avec les briques préexistantes d un système d information. 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. 36

51 Chapitre 4: Le système Shibboleth L objectif de ce chapitre 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étailler les interactions entre les acteurs du système lors de l accès par un navigateur à une ressource web. 4.1 Les composants de Shibboleth L architecture Shibboleth est basée sur trois composants ou briques Fournisseur de services C est la brique qui propose les ressources aux clients, en donnant ou non l accès aux ressources en fonction des attributs utilisateurs. Il comporte trois (3) sous composants : Le consommateur d assertions (Assertion Consumer Service) est comme un pré filtre. C est lui qui redirige vers l IDP lorsque l utilisateur n est pas authentifié. Lorsque l utilisateur est authentifié, alors le consommateur d assertion transmet le nameidentifier au demandeur d attributs. Le demandeur d attributs (Assertion Requester) est chargé de la récupération des attributs utilisateurs auprès de l IDP. 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 (Acces control) 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 ou un filtre J2EE) ou encore par une librairie, appelée par un applicatif web Fournisseur d'identités(idp) C est l entité authentifiant les utilisateurs en fournissant leurs attributs. Il s appuie sur le système d information de l établissement, tant pour l authentification que pour la récupération des attributs utilisateurs à propager. L IdP est subdivisé en trois sous couche : le service d authentification (Authentication Service ou SSO Service) est chargé de l authentification des utilisateurs vis-à-vis de l ensemble de l IdP. 37

52 C est lui qui demande à l utilisateur les paramètres de connexions puis valide auprès du service d authentification. Les implémentations du service d authentifications peuvent être très variées, depuis un module Apache authentifiant les utilisateurs auprès d un annuaire LDAP, jusqu au client de Single Sign On. Le service d authentification n est pas une partie intégrante de l IdP, on ne peut néanmoins pas concevoir d IdP sans service d authentification. N importe quel système d authentification web (formulaire applicatif, certificat x509, SSO) peut être utilisé. Le service d authentification est chargé de transmettre à l autorité d authentification l identifiants unique de l utilisateur au sein du système d information. l autorité d authentification (Authentication Authority) fait une association du nameidentier à l identifiant de l utilisateur. l autorité d attributs (Attribute Authority) 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. Les attributs de l utilisateur sont récupérées dans le système d information de l établissement, plusieurs sources pouvant être envisagées (annuaire ldap, base de données) Service de découverte Le service de découverte ou WAYF (pour Where Are You From?, «d où êtes-vous?») est un service dont le but est d orienter l utilisateur vers son IdP. Il propose une liste aux utilisateurs pour qu ils sélectionnent l IdP de leur établissement de provenance. 4.2 Le fonctionnement de Shibboleth Shibboleth comprend trois modes de fonctionnements : fonctionnement de Shibboleth sans SSO fonctionnement de Shibboleth avec SSO fonctionnement de Shibboleth avec SSO et WAYF Le fonctionnement de Shibboleth sans SSO Dans ce cas d utilisation, on considère que l établissement de rattachement de l utilisateur est connu du SP. En effet, les ressources disponibles chez le fournisseur de services sont proposées à un 38

53 seul établissement. Lorsque l utilisateur veut accéder à une ressource, il renseigne son url dans un navigateur web. Ce dernier effectue une requête http vers le SP pour accéder à la ressource. Sans information d authentification il est redirigé par le SP vers l IdP de son établissement de rattachement. Le fournisseur d attributs affiche un formulaire à l utilisateur pour qu il soumette ses paramètres de connexions. Figure 4.1- Authentification et envoie du nameid vers le SP Une fois l authentification réussie, l IdP redirige l utilisateur vers le SP avec une assertion SAML. Cette assertion est signée par l IdP et permettra au SP de lui faire confiance. Elle contient un nameidentifier. C est un identifiant opaque utilisé dans le cadre des échanges entre les différentes briques de Shibboleth. C est grâce à cet identifiant que le SP va récupérer les attributs de l utilisateur souhaitant accéder à la ressource auprès de l IdP. 39

54 Figure 4.2 Récupération des attributs de l utilisateur par le SP Une fois les attributs reçu, le SP peut alors effectuer le contrôle d accès pour retourner une réponse à l utilisateur (une autorisation ou non à la ressource). Figure 4.3 Envoi de la réponse du SP à l utilisateur 40

55 Figure 4.4-Point de vue côté utilisateur Au niveau de l utilisateur, on note quatre(4) phases : 1. requête (via un navigateur web) auprès du SP 2. demande d authentification de l IdP 3. authentification de l utilisateur auprès de l IdP 4. réponse du SP (accès à l application) Le fonctionnement de Shibboleth avec SSO On suppose que l établissement dispose d un système SSO, cas d un CAS. L authentification n est pas dans ce cas prise en charge par le service d authentification de l IdP. Il se charge plutôt de rediriger l utilisateur vers le serveur CAS, qui renvoie un formulaire d authentification à l utilisateur. 41

56 Figure 4.5- Première requête vers un SP L utilisateur remplit les champs du formulaire et effectue une nouvelle requête vers le serveur CAS, qui le redirige vers l IdP. Le service d authentification de l IdP qui est un client SSO, effectue une nouvelle redirection vers le fournisseur de service. C est la principale différence de fonctionnement sans SSO, la suite du processus est identique à celui vu précédemment. Figure 4.6 -Point de vue utilisateur dans un contexte SSO 42

57 Du point de vu utilisateur on a le scenario suivant : 1. l utilisateur effectue une requête vers le SP 2. réception d une demande d authentification du serveur SSO 3. authentification de l utilisateur auprès du serveur SSO 4. réception d une réponse du SP, donnant l accès ou non à la ressource demandée Pour de nouvelles requêtes vers ce même SP, une session est mise en place entre ce dernier et le navigateur, afin d empêcher l utilisateur de s authentifier à nouveau. Par contre dans le cas des requêtes vers un autre SP l authentification est complètement transparente Le fonctionnement de Shibboleth avec SSO et WAYF Nous nous plaçons dans 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 à la disposition de tous les personnels de l enseignent supérieur de sa région les archives de ses thèses et publications scientifiques. Le problème qui peut alors se poser est que le SP ne sait pas vers quel IdP rediriger l utilisateur pour l authentification. La solution est apportée par WAYF. Lors de la première requête vers le SP, ce dernier ne connaissant pas l IdP qui sera utilise, le SP redirige l utilisateur vers le service de découverte. Ce dernier affiche alors la liste des IdP disponibles. Apres sélection du fournisseur d identités de son établissement, l utilisateur est à nouveau redirigé. Mais cette fois vers le serveur SSO. 43

58 Figure 4.7- Redirection vers le WAYF puis vers le serveur CAS Un formulaire d authentification est présenté à l utilisateur qui renseigne les différents champs. Apres validation des ses paramètres la suite du processus est identique à celui du mode de fonctionnement avec SSO. Figure 4.8-Redirection du serveur SSO vers l IdP puis le SP 44

59 Figure 4.9-Point de vue utilisateur dans un contexte SSO et WAYF Les différentes étapes suivies par l utilisateur : 1. requête de l utilisateur auprès du SP 2. r réception d une demande d aiguillage du WAYF 3. sélection de l IdP auprès du WAYF 4. demande d authentification du serveur SSO 5. authentification auprès du serveur SSO 6. réception d une réponse du SP (autorisation ou non à la ressource demandée 4.3 Fédération d identité avec Shibboleth Métadonnées Les métadonnées listent tous les membres d une fédération d identité. Pour qu'un fournisseur de services soit reconnu dans une fédération par les fournisseurs d'identités, il doit être listé dans ce fichier. Inversement, pour qu'un fournisseur d'identités soit reconnu dans la fédération par des 45

60 fournisseurs de services, il doit être listé dans les métadonnées. Le fichier de métadonnées inclut également les certificats de chaque entité. Les métadonnées constituent donc le socle de confiance d'une fédération. Pour assurer leur intégrité le fichier des métadonnées est signé électroniquement. Dans une fédération en production, l'enregistrement d'un nouveau fournisseur ou la mise à jour des informations d'un fournisseur existant est soumis à un processus permettant de vérifier la validité et la légitimité de la demande. Pour chaque fournisseur, les métadonnées indiquent son identifiant unique (attribut entityid), des adresses de contact organisationnel et technique, le certificat utilisé par ce fournisseur, l'adresse du SSO pour un fournisseur d'identités et l'adresse de réception des attributs pour un fournisseur de services. Les métadonnées sont gérées de façon centralisée pour la fédération et partagées par tous les sites participants qui doivent mettre en place une tâche périodique de synchronisation. Chaque site peut enrichir ses métadonnées s il participe à plusieurs fédérations ou pour les besoins de relations bilatérales. Ces méta données n'obligent pas un site à avoir des relations avec tous les autres sites qui y sont listés : chaque site est libre de définir avec quels partenaires il travaille Relations de confiance entre les membres d'une fédération Dans une fédération il faut avoir des relations de confiance entre les membres. Le service provider repose sur les services d identités pour vérifier une authentification sûre de ses utilisateurs. Il fait confiance dans les attributs d utilisateurs que les IdP propagent. Par contre l IdP délivre des attributs sur ses utilisateurs aux services providers alors il leur fait aussi confiance. Pour une fédération il doit y avoir un acteur définissant des engagements et centralisant leur gestion. Ceci permet d éviter la multiplication des relations entre les différents fournisseurs dans la fédération. Cet acteur donne aussi les services centraux : tels que le service de découverte, la distribution des métadonnées. Le fournisseur d identités utilise une ARP (Attribute Release Policy) qui contient un ensemble de règles. Chaque règle définit un contexte d application et des attributs avec des valeurs autorisées pour chaque attribut. Une ARP peut être définie pour un fournisseur de service à fin de filtrage des données. 46

61 Un mécanisme équivalent aux ARP est défini dans un fournisseur de service, permettant de filtrer les attributs reçus 4.4 Sécuriser l information échangée entre les différents composants Afin de préserver la sécurité de l information, les fournisseurs d identité et fournisseurs de services s échangent des informations de sécurité entre eux. Ces informations incluent la preuve de l authentification de l utilisateur auprès de son organisation de rattachement, la méthode d authentification utilisée, la date et l heure de l authentification, etc. Ceci, permet aux fournisseurs de services d appliquer des politiques de sécurité dépendamment du contexte d authentification de l utilisateur. L information de sécurité inclut aussi les accréditations de l utilisateur (ses accréditations, ses droits, etc.) qui vont permettre aux fournisseurs de services d accepter sa requête d accès à une ressource protégée ou pas. Etant donné que dans le cadre d un réseau distribué collaboratif, les systèmes déployés sont plutôt hétérogènes, il s est révélé indispensable d exprimer l information de sécurité dans un langage qui soit compréhensible par tous les systèmes et les technologies existants. L information de sécurité échangée entre les sites partenaires, peut être exprimée en utilisant des standards tels que Security Assertion Markup Language (SAML), Liberty Alliance ou bien des spécifications telles que Web Services-Federation (WS-Federation) Security Assertion Markup Language (SAML) L OASIS (Organisation for the Advancement of Structured Information Standards) a défini le standard SAML [W05] basé sur le langage XML pour l échange de données d authentification et d autorisation entre les domaines de sécurité distribués. SAML permet aux partenaires de générer des assertions concernant l identité, les attributs et les droits d une entité (utilisateur) et, les transférer à d autres entités (organisations, applications, etc.). Il définit la syntaxe et les règles pour demander, créer, communiquer et utiliser les assertions SAML au format spécifié. Les assertions SAML, encapsulées dans des messages SOAP (Simple Object Access Protocol) et transférées par le biais du protocole HTTP, permettent à la fédération de surpasser les limites imposées par les différences entre les infrastructures déployées chez les différents partenaires. 47

62 4.4.2 Web Services-Federation (WS-Federation) WS-Federation est une spécification définie par IBM, Microsoft et d autres sociétés, propose aux organisations un moyen pour l échange d identités et d attributs entre systèmes d authentification et d autorisation distribués. WS-Federation définit des mécanismes de fédération d'espaces de confiance hétérogènes. Elle offre la possibilité de fédérer des domaines de sécurité et permet d'établir des contextes de sécurité entre des applications utilisant des spécifications de sécurité distinctes Liberty alliance Liberty Alliance, aussi connu sous le nom de Project Liberty, est un projet qui réunit des acteurs des mondes industriel, informatique, bancaire et gouvernemental sous la forme d'un consortium. L'objectif est de définir des ensembles de spécifications de protocoles de fédération d'identité et de communication entre services web. Ces protocoles sont conçus pour être mis en œuvre aussi bien dans le cadre de déploiements intra-entreprise qu'inter-entreprise. La Liberty Alliance rajoute à SAML une pile de protocoles lui permettant de supporter la jonction de comptes (account linking) et la fédération à base de rôles. 48

63 Chapitre 5: Implémentation de Shibboleth L objectif de ce chapitre est de procéder à l installation de la solution retenue pour atteindre nos objectifs dans ce projet en exposant les outils et technologies utilisés. Pour ce faire, il faut au préalable faire une conception d un référentiel utilisateur basé sur LDAP pour gérer les accès aux ressources mutualisées. 5.1 Conception de l annuaire LDAP LDAP définit un ensemble de classes et d attributs par défaut convenant pour la grande majorité des applications. Ces attributs doivent impérativement être implémentés par les serveurs d annuaire LDAP. Cela permet de garantir une certaine homogénéité entre les différents annuaires. Chaque entrée dans people représente un individu. Pour la conception de l annuaire on a spécifié les attributs selon les utilisateurs de l annuaire. Tableau 5.1. Attributs communs aux utilisateurs Schémas Informations Attributs LDAP SCHAC SUPANN Nom Prénom Téléphone Mail Mot de passe Date de Naissance Lieu de naissance Pays d origine Pays de résidence Login Civilité Mail institutionnel Cn givenname TelephoneNumber Mail userpassword schacdateofbirth schacplaceofbirth schaccountryofcitizenship schaccountryofresidence supannaliaslogin supanncivilite supannmailperso 49

64 Tableau 5.2. Attributs spécifiques aux personnels Schémas Informations Attributs Internet 2 Statut du personnel edupersonaffiliation Grade title SUPANN Service SupannRoleEntity Code personnel SupannEmpID statut de la personne edupersonaffiliation Tableau 5.3.Attributs spécifiques aux étudiants Schémas Informations Attributs SUPANN Date d inscription Type de diplôme voulu Cursus Numéro d inscription Mail institutionnel Login Mot de passe supannanneinscription supannetudiplome supanncursusannee supannetuid mail supannaliaslogin UserPassword Tableau 5.4.Attributs spécifiques aux enseignants Schémas Informations Attributs Internet2 Statut edupersonaffiliation Grade title SUPANN Statut professionnel supannroleentity Numéro d identification supannempid 50

65 5.2 Installation de l IdP Les différentes composantes de Shibboleth, ont été installées sur une machine Centos 6 Installation des prés-requis La brique logicielle IdP de Shibboleth [W03] est une servlet JAVA et utilise n importe quel Java Servlet 2.4 Container comme serveur d application. Dans notre cas nous avons choisi Tomcat comme conteneur de servlet. Installation de JAVA # yum install java openjdk.i686 java openjdk-devel.i68 Installation du serveur Tomcat Apache Tomcat est un serveur d applications JAVA; c est lui qui exécutera la brique Shibboleth IdP. Nous avons installé sa version 6.36 # wget Il faudra ensuite positionner la variable d environnement CATALINA _HOME qui doit indiquer le chemin d accès au répertoire d installation du serveur Tomcat. Il faut ensuite créer un fichier XML qui permettra à Tomcat de déployer automatiquement la brique IdP sans avoir à recopier l archive (.war) dans son répertoire webapps/. Cette méthode de déploiement permet aussi d éviter des problèmes de mise en cache. Pour cela, il faut créer l arborescence suivante # mkdir -p /usr/local/tomcat/conf/catalina/localhost/ Ensuite créer le fichier idp.xml comme suit #vim /usr/local/tomcat/conf/catalina/localhost/idp.xml <Context docbase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiresourcelocking="false" antijarlocking="false" unpackwar="false" /> 51

66 Il faut à présent créer un répertoire qui va servir à stocker les bibliothèques utilisées par la servlet IdP. # mkdir /usr/local/tomcat/endorsed/ On démarre le serveur Tomcat. # /etc/init.d/tomcat start Using CATALINA_BASE: /usr/local/tomcat Using CATALINA_HOME: /usr/local/tomcat Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JRE_HOME: /usr/java/latest/ Après avoir démarré Tomcat, il faut vérifier les logs pour voir si le serveur s est bien lancé avec la commande suivante #tail -f /usr/local/tomcat/log/catalina.out Installation de l IdP de Shibboleth avec la version # cd /usr/local/src # wget shibboleth-identityprovider bin.zip # wget -O KEYS # wget shibboleth-identityprovider bin.zip.asc # gpg --import KEYS # gpg --verify shibboleth-identityprovider bin.zip.asc # unzip shibboleth-identityprovider bin.zip 52

67 On copie les bibliothèques dont a besoin la servlet IdP pour fonctionner dans le sous répertoire de Tomcat crée précédemment # cd /usr/local/src/shibboleth-identityprovider-2.3.8/ # cp endorsed/*.jar /usr/local/tomcat/endorsed/ Nous passons à présent à l'installation de l'idp # chmod +x install.sh #./install.sh Where should the Shibboleth Identity Provider software be installed? [/opt/shibboleth-idp] taper entrer What is the fully qualified hostname of the Shibboleth Identity Provider server? [idp.example.org] idp.uvs.sn A keystore is about to be generated for you. Please enter a password that will be used to protect it. taper 'password' BUILD SUCCESSFUL Total time: 44 seconds # chown -R tomcat /opt/shibboleth-idp/ L'arborescence de l'idp : bin/ : contient les outils en ligne de commandes permettant un test rapide des attributs de l'idp et connaitre son numéro de version conf/ : contient les fichiers de configuration de l'idp credentials/ : les clés, certificats qui ont été générés lors de l'installation de votre IdP. Ces éléments sont exclusivement utilisés pour sécuriser les échanges SAML ; ils ne sont pas vus par les utilisateurs et ne nécessitent pas de signature par une autorité de confiance. lib/ : les librairies (jar) sur lesquelles s'appuie l'idp. Ces librairies sont par ailleurs contenues dans le fichier idp.war ; elles ne sont utilisées que par les outils en ligne de commandes. logs/ : là où se trouvent tous les fichiers de logs (créés au démarrage de l'idp) o idp-process.log : fichier de log principal de l'idp 53

68 o idp-access.log : journalisation des accès à l'idp war/ : contient l'archive de l'idp # vim /usr/local/tomcat/conf/tomcat-users.xml <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="manager"/> <user username="tomcat" password="tomcat" roles="manager"/> </tomcat-users> On peut accéder à l interface de Tomcat après redémarrage pour vérifier si notre servlet IdP est bien démarrée. Figure déploiement de l IdP par Tomcat Les fichiers de configuration du fournisseur d'identités sont installés par défaut dans /opt/shibboleth-idp/conf/ 54

69 Il est conseillé de garder une copie des principaux fichiers de configuration de l'idp Shibboleth. En production, il est fortement recommandé de «versionner» ces fichiers de configuration, avec SVN. Exemple de configuration du fichier de métadonnées de l IdP #vim /opt/shibboleth-idp/conf/relying-party.xml <metadata:metadataproviderid="shibbolethmetadata" xsi:type="metadata:chainingmetadataprovider>" <!-- Load the IdP's own metadata. This is necessary for artifact support. --> <metadata:metadataprovider id="idpmd" xsi:type="metadata:filesystemmetadataprovider" metadatafile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxrefreshdelay="p1d" /> <!-- Example metadata provider. --> <!-- Declaration des Métadonnées d'un SP locale --> <MetadataProvider id="localsp" xsi:type="filebackedhttpmetadataprovider" metadataurl=" backingfile="/opt/shibboleth-idp/metadata/localsp.xml"> </MetadataProvider> </metadata:metadataprovider> 5.3 Installation du SP Configuration du serveur Apache Il faut éditer le fichier de configuration de votre serveur Apache pour spécifier les éléments suivants : 55

70 la directive UseCanonicalName doit être positionnée à On. Cette directive est requise pour permettre le routage des requêtes via la fonctionnalité RequestMap détaillée plus loin la directive ServerName doit être correctement configurée au nom de votre machine # vim /etc/httpd/conf/httpd.conf ServerName servpro.sn:80... UseCanonicalName On Configurer le dépôt de Shibboleth pour une machine CentOS 6 # wget -O /etc/yum.repos.d/security_shibboleth.repo 6/security:shibboleth.repo # echo "protect=1" >> /etc/yum.repos.d/security_shibboleth.repo # wget -O /etc/pki/rpm-gpg/rpm-gpg-key-shibboleth-security 6/repodata/repomd.xml.key # rpm --import /etc/pki/rpm-gpg/rpm-gpg-key-shibboleth-security Commande à exécuter pour les différentes architectures : # yum install shibboleth (32 bits) # yum install shibboleth.x86_64(64 bits) Positionner les droits shibd pour le répertoire du SP : chown -R shibd /etc/shibboleth Certificat X.509 pour le démon shibd Le processus shibd a besoin d un certificat pour signer et/ou chiffrer les requêtes SAML transmises aux fournisseurs d identités (IdP). # openssl genrsa 1024 > /tmp/servpro.sn.key 56

71 # openssl req -new -x509 -nodes -sha1 -days 365 -key -key /tmp/servpro Il faudrait ensuite déplacer ces deux clés associées (privée et publique) dans /etc/shibboleth : # mv /tmp/servpro.sn.crt /etc/shibboleth/ # mv /tmp/servpro.sn.key /etc/shibboleth/ Exemple du fichier de configuration de métadonnées du SP # vim /etc/shibboleth/shibboleth2.xml <SPConfig.>... <ApplicationDefaults entityid=" REMOTE_USER="mail eppn persistent-id targeted-id"> <! Activation du wayf--> <SSO discoveryprotocol="samlds" discoveryurl=" SAML2 SAML1 </SSO> <!-- Charger les métadonnées de l IdP : dans notre cas idp.uvs.sn--> <MetadataProvider type="xml" uri=" backingfilepath="idp-metadata.xml" reloadinterval="7200"> </MetadataProvider>... </SPconfig> entityid: est l'identifiant unique qui permet de distinguer l'application au sein de la fédération. SSO : décrit comment Shibboleth réagit à une requête de session pour une application c'est-àdire de quelle manière il va demander une authentification de l'utilisateur (interrogation directe 57

72 d'un IdP donné, passage par un DS/WAYF, etc.). Dans notre exemple, le SP va utiliser de préférence le protocole SAML2. Si l'idp avec lequel le SP communique ne connait que le protocole SAML1, le SP se rabattra sur cette version du protocole. Handler: type= Status Location= /Status est une URL qui renvoie un rapport du statut opérationnel du SP au format xml MetadaProvider/uri : permet de spécifier le fichier de métadonnées» qui est utilisé par le SP Installation du WAYF L'avantage d'installer un service de découverte au plus près de vos applications est de pouvoir le mettre en conformité avec la charte graphique de l'application. De plus, il est possible de filtrer à ce niveau les fournisseurs d'identités acceptés pour votre application. Cela évite de lister des fournisseurs d'identités qui ne sont pas acceptés et laisser leurs utilisateurs s'authentifier pour se voir refuser l'accès par la suite. # cd /usr/local/src # mkdir SWITCHwayf_ # wget no-check-certificate # unzip -d SWITCHwayf_ SWITCHwayf_1.17.1_ zip # cp -pr SWITCHwayf_1.17.1/ /usr/local/switchwayf # chown -R apache.apache /usr/local/switchwayf # yum install php php-xml Installation et configuration Apache Configurer le serveur web pour ouvrir l'accès au WAYF en créant le fichier de configuration #vim/etc/httpd/conf.d/wayf.conf 58

73 <Files WAYF> ForceType application/x-httpd-php </Files> Alias /wayf /usr/local/switchwayf Les fichiers de configuration L'arborescence est la suivante par défaut : config.dist.php : modèle pour le fichier de configuration principal, default-* : tous les fichiers de configuration préfixés par default- sont personnalisables en dérivant un fichier ayant pour préfixe IDProvider.conf.dist.php : modèle pour le fichier qui permet de gérer manuellement des IdPs (identifiants et URL SSO). Le WAYF peut se baser directement sur ce fichier au lieu d'extraire la liste depuis un fichier de métadonnées XML. IDProvider.metadata.conf.php : contiendra le résultat de l'exécution du script readmetadata.php images/ : répertoire contenant des images pour la personnalisation du WAYF readmetadata.php : ce script extrait la liste des IdP (Identifiant et URL SSO) d'un fichier de métadonnées en XML spécifié dans config.php WAYF : le script PHP métier qui gère les redirections HTTP, positionnement de cookies du WAYF ainsi que la gestion du WAYF embarqué Exemple de configuration du WAYF #vim / usr/local/switchwayf/idprovider.conf.php 59

74 $IDProviders['university'] = array ( 'Type' => 'category', 'Name' => 'Universites',); $IDProviders[' = array( // déclaration de l IdP de l uvs 'SSO' => ' 'Name' => 'UVS Université Virtuelle Du Sénégal', 'Type' => 'university',); 5.4 Shibbolisation de quelques ressources Pour la mise en œuvre des fonctionnalités de notre plateforme de fédération d identité on a utilisé Moodle et Esup comme ressources Moodle En signant le contrat de performance, les différentes universités publiques du Sénégal ont jugé nécessaire de disposer d une plateforme d enseignement à distance pour atteindre les objectifs de la clause du CDP. Le choix de moodle est motivé par sa notoriété, et son utilisation par la majorité des établissements pour proposer des cours à distance. MOODLE [W08] est une plateforme d'apprentissage en ligne servant à créer des communautés d'apprenants autour de contenus et d'activités pédagogiques. Dotée d'un système de gestion de contenu (SGC), MOODLE a aussi des fonctions pédagogiques ou communicatives lui permettant de créer un environnement d'apprentissage en ligne. Ces fonctionnalités permettent de créer des interactions entre pédagogues, apprenants et ressources pédagogiques formant ainsi un réseau et parfois même une véritable communauté autour d'un thème choisi par les membres de la plateforme Authentification shibboleth pour Moodle Moodle est une ressource «Shibbolisée» par défaut. C est à dire qu il est déjà compatible avec Shibboleth. Il faut néanmoins activer l authentification Shibboleth dans l application. Pour activer Shibboleth dans Moodle, il faut se connecter en mode administrateur. Une fois sur la page d accueil il faut activer Shibboleth. 60

75 Ensuite dans Apache, il faut renseigner les directives : ScriptAlias /moodle "/var/www/html/moodle/auth/shibboleth/index.php" <Location /moodle > AuthType shibboleth ShibRequestSetting RequireSession 1 ShibRequestSetting applicationid default require valid-user </Location> Apres l activation de l authentification Shibboleth sur moodle, on peut à présent accéder à la ressource via un navigateur web en tapant l url de la ressource ( L utilisateur est redirigé vers le service de découverte (wayf) ou il choisit son établissement de provenance. Figure 5.2- Service de découverte 61

76 Suite au choix de l utilisateur dans la liste qui lui est affichée, il sera redirigé vers une page d authentification(le système d authentification de son établissement) pour se connecter. Deux choix s offrent à nous : une connexion via le SSO natif de Shibboleth ou le CAS. Figure 5.3- Authentification via SSO natif de Shibboleth Figure 5.4- Authentification via CAS 62

77 Une fois les paramètres de connexions validés, l utilisateur peut accéder à la ressource demandée qui est dans notre cas moodle. Figure5.5-Page d accueil de la ressource 5.5 Intégration de Shibboleth à ESUP-PORTAIL Le projet ESUP-PORTAIL En tenant compte des besoins de l UVS de disposer un portail pour l accès à diverses ressources à la disposition des utilisateurs, nous avons porté notre choix sur l environnement numérique de travail (E.N.T) Esup-Portail utilisant le socle uportal pour l intégrer dans Shibboleth pour les raisons suivantes : Esup-Portail est un E.N.T libre qui intègre des modules libres et ouverts, et a une forte communauté très active permettant le maintient et l évolution des logiciels accompagnés d une documentation accessible et disponible. Cette une solution qui est déployée dans plusieurs universités Esup-Portail utilise une technologie basée sur le socle uportal qui garantit une maintenance souple. 63

78 ESUP-PORTAIL [W07] est un projet en code source libre parmi d autres solutions, basé sur le produit libre Uportal et sur l'intégration de logiciels libres. Il intègre un bureau virtuel offrant des espaces de stockages partageable, des outils de communication, agenda, listes d'échanges... L'organisation des services est assurée suivant le profil des usagers, ce qui permet d'offrir à chaque usager un espace de travail adapté à son activité. Il utilise les technologies suivantes : Le langage JAVA Une authentification LDAP Un socle uportal ESUP-PORTAIL est une plate-forme structurée et sécurisée, respectant les principaux standards et normes d'interopérabilité. Tous les services (en version open-source), ressources et informations nécessaires à un établissement sont accessibles à chaque utilisateur, ce dernier peut personnaliser son environnement de travail et l'ouvrir, de manière sécurisé qu à des personnes choisies, grâce à une authentification unique (l'authentification CAS, annuaires LDAP et systèmes de certificats). Figure 5.6- Portail Esup 64

79 5.5.2 Authentification Shibboleth pour Esup Figure 5.7- Authentification de Shibboleth dans Esup 1. L utilisateur veut accéder à l ENT, protégé par Shibboleth. La requête est interceptée par le SP 2. Le SP interroge l IdP pour savoir si l utilisateur a le droit d accéder à la ressource. 3. L IdP demande à l utilisateur ses informations de connexions. 4. L utilisateur fournit son login et mot de passe. 5. L IdP interroge par exemple un annuaire LDAP pour vérifier les informations fournis par l utilisateur. 6. Le référentiel utilisateur confirme ou infirme les paramétrés fournis avant de transmettre à l IdP les informations de l utilisateur. 7. L IdP transmet les attributs de l utilisateur authentifié au SP. 8. En fonction des attributs de l utilisateur, le SP va permettre l accès à la page sécurisée de l ENT 65

80 5.5.3 Shibbolisation d Esup Le serveur d application Tomcat doit être branché sur un serveur Apache en frontal. Il convient de disposer des briques de Shibboleth déjà fonctionnels. Configuration d Apache Pour mettre en place le SP sur le serveur Apache il faut activer le module mod_shib, fourni avec le SP. Il conviendra d ajouter le chargement du module à la configuration du serveur httpd. Une fois le module chargé, il faut le configurer. Configuration du SP L identification s effectue à partir des attributs de l annuaire LDAP relié à l IdP. Il faut alors s assurer que le fournisseur de service a été bien configuré pour transmettre le bon attribut dans la variable remote_user. Par défaut c est l attribut uid qui est utilisé pour l authentification. Il convient donc de modifier la configuration du SP. Configuration d Esup Après la configuration du serveur Apache en frontal avec le SP, il faut à présent passer à la configuration du portail pour l authentification via Shibboleth. Cette authentification se fait par la variable REMOTE_USER : l utilisateur est identifié par Shibboleth, et est transmis au portail. 66

81 Conclusion L usage des Technologies de l Information et de la Communication constitue un tournant décisif dans le milieu de l enseignement et de la recherche en donnant naissance aujourd hui à une nouvelle forme d organisations que l on nomme Organisation virtuelle, qui regroupe des entités géographiquement dispersées. Le contexte actuel de l enseignement supérieur au Sénégal est caractérisé par la diversification et l'accroissement de l'offre de formation, s y ajoute l université virtuelle du Sénégal qui va constituer une révolution cruciale dans la carte universitaire par la mutualisation au niveau national sous forme de fédération des contenus numériques pédagogiques pour chaque domaine disciplinaire. Les ressources numériques mise à la disposition de la fédération sont privées, donc nécessitent une authentification au préalable des utilisateurs, et contrôler l accès à ces applications sans multiplier les référentiels utilisateurs. Dans le cadre du projet de l Université Virtuelle du Sénégal, il nous a été confié la tâche de mettre en place une fédération d identité qui a fait l objet du thème de notre mémoire pour répondre au besoin d interconnecter des systèmes d authentifications distribués pour offrir un cadre technique et de confiance permettant à ses participants de sécuriser et de simplifier l'accès à des ressources Web. Durant notre stage nous avons traité le contrôle d accès aux ressources web en adoptant les concepts de fédération d identité basée sur Shibboleth. Cette expérience nous a permis de mieux appréhender la collaboration entre les organismes pour le partage et l exploitation des applications en toute sécurité. Notre solution s intègre parfaitement dans le système d information existant dans les établissements en toute transparence. En effet, il se base sur le système d authentification et le référentiel utilisateur en vigueur dans l université pour assurer ses fonctions de propagation d attributs et de délégation d authentification. Compte tenue de l évolution des besoins en matière de modernisation du système de l enseignement supérieur au Sénégal, la constitution des établissements supérieurs à des espaces virtuels de collaboration sous forme de fédération constitue une perspective pour : permettre l échange des connaissances sur les bonnes pratiques dans le champ d expertise. contribuer au développement des compétences et la formation des acteurs universitaires développer des projets communs et ainsi bénéficier d une synergie novatrice sur le plan des savoir faire. 67

82 Créer un partenariat entre les universités pour favoriser la mobilité des universitaires. travail collaboratif. e-learning. accès nomade à la documentation électronique. L enseignement supérieur du Sénégal avec l appuie de l UVS peut s engager dans la voie d une identité numérique fédérée pour une meilleure cohérence entre les établissements supérieurs afin de résoudre plusieurs problématiques d ordres économique, infrastructurel et social. 68

83 REFERENCES Bibliographie [B01] : Hafida BOUARFA, L'entreprise virtuelle : dimension ou structure organisationnelle, 1991 [B02] : Olivier Salaün, Introduction aux architectures web de Single Sign-on, octobre 2003 [B03] : Julien Marchal Vincent Mathieu, Pascal Aubry. Single Sign-On open-source avec CAS(Central Authentication Service), Octobre [B04] : Florent Guilleux Olivier Salaün, Pascal Aubry. Fédération d identités et propagation d attributs avec Shibboleth, Décembre [B05] : Le groupe supann tech. Recommandations pour les annuaires de l enseignement supérieur : SUPANN 2009, Décembre [B06]: Sébastien BOBILLIER Préparation à la certification LPIC-2, 6 décembre 2010 [B07]: Gerad Carter, LDAP System Administration O'Reilly March [B08]: Amadou Dahirou Gueye, Davy E. Moussavou, Samuel Ouya, Hamadou Saliah-Hassane and Claude Lishou, "Proposal of a standard mutual authentication system in a virtual organization", International Network for Engineering Education and Resaerch INEER, International Conference on Engineering Education and Reasearch ICEER, Marrakech, juillet Webographie [W01] : http :// Consulté en Novembre 2013 [W02] : http ://fr.wikipedia.org/wiki/shibboleth. Consulté en Septembre [W03]: Consulté Octobre 2013 sla-decennie.html Consulté en Octobre 2013 [W05]: Consulté en Novembre [W06]: [W07]:[ consulté Decembre2013 [W08]: Consulté Octobre

84 [W09] : en Octobre [W10] : Consulté en Octobre A. ANNEXES : Installation du serveur LDAP ANNEXES Installation à partir des paquets #apt-get install slapd ldap-utils phpldapadmin A.2 Ajout des schémas Supann schac et internet2 Configuration du serveur dans slapd.conf 70

85 Le contenu de l annuaire avec l outil graphique phpldapadmin 71