Memoire Shibboleth PDF

Mémoire de fin de cycle
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 :
NIANG Pape Saer Dr. Samuel OUYA
Année universitaire : 2011– 2013

NIANG Pape Saer
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.
Conception et implémentation d'une plateforme de fédération d’identité pour l’uvs
i
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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 ........................................................................................................ 3
1.1 Présentation de l’entreprise RTN ............................................................................................ 3
1.2 Missions de RTN ..................................................................................................................... 3
1.3 Organigramme de RTN ........................................................................................................... 3
1.4 Domaine d’activités................................................................................................................. 4
1.5 Présentation de l'Université Virtuelle du Sénégal(UVS) ........................................................ 5
1.6 Mission de l'Université Virtuelle du Sénégal.............................................................................. 8
1.7 Concept d'Espace Numérique Ouvert (ENO).......................................................................... 9
1.8 Présentation du sujet.............................................................................................................. 10
1.8.1 Contexte du sujet ............................................................................................................... 10
1.8.2 Problématique.................................................................................................................... 11
vi
NIANG Pape Saer
1.8.3 Objectifs attendus .............................................................................................................. 12
Chapitre 2: État de l’art de la fédération d'identité .......................................................................... 13
2.1 Concepts d’organisations virtuelles ...................................................................................... 13
2.2 Définition de la fédération d'identité ..................................................................................... 14
2.3 Cercle de confiance ............................................................................................................... 15
2.4 Fonctionnement des fédérations d'identités........................................................................... 16
Chapitre 3 : Système d’authentification centralisé ............................................................................ 18
3.1 Single Sign-On (SSO) ........................................................................................................... 18
3.2 Méthode d'authentification SSO............................................................................................ 19
3.3 Les différents types d’authentification unique ...................................................................... 20
3.3.1 Approche fédératif............................................................................................................. 20
3.3.2 Approche centralisé ........................................................................................................... 20
3.3.3 Approche coopérative ....................................................................................................... 20
3.4 Présentation du CAS ............................................................................................................. 21
3.5 Fonctionnement du CAS ....................................................................................................... 21
3.6 Généralités sur les annuaires électroniques .......................................................................... 22
3.6.1 Présentation ....................................................................................................................... 22
3.6.2 Différences entre annuaire et une Base de Données ......................................................... 23
3.6.3 Protocole LDAP ................................................................................................................ 23
3.6.4 Les classes d'objets ............................................................................................................ 24
3.6.5 Les schémas....................................................................................................................... 25
3.6.6 La norme Supann .............................................................................................................. 25
3.6.7 Les objectifs de la norme Supann ..................................................................................... 26
3.6.8 Présentation des schémas .................................................................................................. 26
3.7 Structure du DIT (Directory Information Tree) .................................................................... 27
vii
NIANG Pape Saer
3.7.1 Sécurité LDAP .................................................................................................................. 28
3.8 Les solutions techniques........................................................................................................ 31
3.8.1 Les solutions propriétaires ................................................................................................ 32
3.8.2 La solution libre : Shibboleth ............................................................................................ 32
3.9 Le choix de Shibboleth .......................................................................................................... 36
Chapitre 4: Le système Shibboleth ...................................................................................................... 37
4.1 Les composants de Shibboleth .............................................................................................. 37
4.1.1 Fournisseur de services ..................................................................................................... 37
4.1.2 Fournisseur d'identités(IDP).............................................................................................. 37
4.1.3 Service de découverte........................................................................................................ 38
4.2 Le fonctionnement de Shibboleth ......................................................................................... 38
4.2.1 Le fonctionnement de Shibboleth sans SSO .................................................................... 38
4.2.2 Le fonctionnement de Shibboleth avec SSO .................................................................... 41
4.2.3 Le fonctionnement de Shibboleth avec SSO et WAYF ................................................... 43
4.3 Fédération d’identités avec Shibboleth ................................................................................. 45
4.3.1 Métadonnées...................................................................................................................... 45
4.3.2 Relations de confiance entre les membres d'une fédération .............................................. 46
4.4 Sécuriser l’information échangée entre les différents composants ...................................... 47
4.4.1 Security Assertion Markup Language (SAML) ................................................................ 47
4.4.2 Web Services-Federation (WS-Federation) ...................................................................... 48
4.4.3 Liberty alliance .................................................................................................................. 48
Chapitre 5: Implémentation de Shibboleth ........................................................................................ 49
5.1 Conception de l’annuaire LDAP .......................................................................................... 49
5.2 Installation de l’IdP ............................................................................................................... 51
viii
NIANG Pape Saer
5.3 Installation du SP .................................................................................................................. 55
5.3.1 Installation du WAYF ....................................................................................................... 58
5.4 Shibbolisation de quelques ressources .................................................................................. 60
5.4.1 Moodle .............................................................................................................................. 60
5.4.2 Authentification shibboleth pour Moodle ......................................................................... 60
5.5 Intégration de Shibboleth à ESUP-PORTAIL ...................................................................... 63
5.5.1 Le projet ESUP-PORTAIL ............................................................................................... 63
5.5.3 Shibbolisation de Esup ...................................................................................................... 66
Conclusion ............................................................................................................................................... 67
REFERENCES ........................................................................................................................................ 69
Bibliographie ........................................................................................................................................... 69
Webographie ........................................................................................................................................... 69
ANNEXES .............................................................................................................................................. 70
ix
NIANG Pape Saer
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 .................................................................................. 56
x
NIANG Pape Saer
Liste des Figures
Figure 1.1- Organigramme RTN ...........................................................................................................14
Figure 2.1- Organisation virtuelle .........................................................................................................23
Figure 2.2 - 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
NIANG Pape Saer
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
NIANG Pape Saer
Sigles et Abréviations
Nous présentons ici quelques sigles et abréviations que nous utiliserons dans le document.
CAS Central Authentication Service

HTTPS HyperText Transfert Protocol Secure
LDAP Lightweight Directory Access Protocol
IdP Identifier Provider
SP Service Provider
WAYF Where Are You From
SAML Security Assertion Markup Language
PHP Hypertext Preprocessor
PT Proxy Ticket
RTN Réseaux et Techniques Numériques
UVS Université Virtuelle du Sénégal
ENO Espace Numérique Ouvert
SSL Secure Sockets Layer
SSO Single Sign On
ST Service Ticket
PGT Proxy Granting Ticket
TGC Ticket Granting Cookies
TIC Technologies de l’Information et de la Communication
TICE Technologies de l’Information et de la Communication pour l’Enseignement
XML eXtensible Markup Language
ARP Attribute Release Policy
CNAES Concertation Nationale sur l’Avenir de l’Enseignement Supérieur
STEM Sciences, Technologie, Ingénierie Mathématiques
xiii
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
Conseil
d'Orientation
Scientifique
DG
Directeur Service Service

Service
Formation Recherche marketing
comptabilité
Recherche déploiement & communicatio
et finance
EC2LT formation n&
commerciales
Service Service Service Conseil de la
acceuil, info, Ressource scolarité, vie scolaire et
Départements
animation Technique et recouvrement des études
scolaire Documentaire et caisse (DFR)
Commissions
Bureau des
permanentes
étudiants
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
NIANG Pape Saer
 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
NIANG Pape Saer
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
NIANG Pape Saer
- 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
NIANG Pape Saer
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° 2013-1294 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
NIANG Pape Saer
 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
NIANG Pape Saer
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
1.8.1 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
NIANG Pape Saer
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.
1.8.2 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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
 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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
Figure 3.1 - Authentification SSO
3.3 Les différents types d’authentification unique
3.3.1 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é.
3.3.2 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é
3.3.3 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
NIANG Pape Saer
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
NIANG Pape Saer
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 Supann2009
3.6.1 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
NIANG Pape Saer
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.
3.6.2 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.
3.6.3 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
NIANG Pape Saer
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.
3.6.4 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
NIANG Pape Saer
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.
3.6.5 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.
3.6.6 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
NIANG Pape Saer
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.
3.6.7 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.
3.6.8 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
NIANG Pape Saer
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 shacDateOfBirth
Pays d'origine schacCountryOfCitizenship
Lieu de naissance schacPlaceOfBirth
Pays de résidence 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
NIANG Pape Saer
 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
3.7.1 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
NIANG Pape Saer
 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
NIANG Pape Saer
 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
NIANG Pape Saer
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
NIANG Pape Saer
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
3.8.2 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
NIANG Pape Saer
Tableau 3.1. Comparaison des produits de fédération d'identité
CA SiteMinder FSS CA SOA HP OpenView Select

SecurityManager Federation
Facilité de déploiement
et de configuration Moyen Moyen Moyen
Conformité aux SAML 2.0 et SAML 2.0 et SAML 2.0 et

langages d’échange de WS-Federation WS-Federation WS-Federation
l’information de
sécurité
Possibilité de fédérer
des identités entre des Non Oui Oui
Web Services
Coût 21000 € + 4000€ pour 100000€ (licence pour 18500 € pour une
maintenance annuelle 4cpu) + 2000 € pour connexion
Maintenance annuelle
Support pour différents mots de passe, jetons, mots de passe, jetons, mots de passe, jetons,
Systèmes et technologies
certificatsX.509, certificatsX.509, cartes à puce, certificats
d’authentification
techniques biométrique techniques d’identité X.509,
biométriques
Niveau de sécurité offert -clustering, haute - load balancing, -Cluster, haute

disponibilité disponibilité
Respect de la vie privée Protégée Protégée Protégée
33
NIANG Pape Saer
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 3000€ + 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
additionnels pour
disponibilité
load balancing et
évolutivité
34
NIANG Pape Saer
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 1 37000 € pour Logiciel libre
connexion par an 3 connexions
74000 € 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
35
NIANG Pape Saer
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
NIANG Pape Saer
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.
4.1.1 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.
4.1.2 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
NIANG Pape Saer
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).
4.1.3 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
4.2.1 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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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)
4.2.2 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
NIANG Pape Saer
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
NIANG Pape Saer
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.
4.2.3 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
NIANG Pape Saer
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
NIANG Pape Saer
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
4.3.1 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
NIANG Pape Saer
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
4.3.2 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
NIANG Pape Saer
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).
4.4.1 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
NIANG Pape Saer
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.
4.4.3 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
NIANG Pape Saer
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
Nom Cn
Prénom givenName
LDAP Téléphone TelephoneNumber
Mail Mail
Mot de passe userPassword
Date de Naissance schacDateOfBirth
Lieu de naissance schacPlaceOfBirth
SCHAC Pays d’origine schacCountryOfCitizenship
Pays de résidence schacCountryOfResidence
Login supannAliasLogin
SUPANN Civilité supannCivilite
Mail institutionnel supannMailPerso
49
NIANG Pape Saer
Tableau 5.2. Attributs spécifiques aux personnels

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

Date d’inscription supannAnneInscription
Type de diplôme voulu supannEtuDiplome
Cursus supannCursusAnnee
SUPANN Numéro d’inscription supannEtuID
Mail institutionnel mail
Login supannAliasLogin
Mot de passe UserPassword
Tableau 5.4.Attributs spécifiques aux enseignants

Internet2 Statut eduPersonAffiliation
Grade title
SUPANN Statut professionnel supannRoleEntity
Numéro d’identification supannEmpID
50
NIANG Pape Saer
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-1.6.0-openjdk.i686 java-1.6.0-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 http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.36/bin/apache-tomcat-6.0.36.tar.gz
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
NIANG Pape Saer
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 2.3.8
# cd /usr/local/src
# wget http://shibboleth.net/downloads/identity-provider/2.3.8/ shibboleth-identityprovider 2.3.8-

bin.zip
# wget -O KEYS http://shibboleth.net/downloads/PGP\_KEYS
# wget http://shibboleth.net/downloads/identity-provider/2.3.8/ shibboleth-identityprovider 2.3.8-

bin.zip.asc
# gpg --import KEYS
# gpg --verify shibboleth-identityprovider-2.3.8-bin.zip.asc
# unzip shibboleth-identityprovider-2.3.8-bin.zip
52
NIANG Pape Saer
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
NIANG Pape Saer
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 5.1 - 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
NIANG Pape Saer
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>"

<metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetadataProvider"
metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml"
maxRefreshDelay="P1D" />


<MetadataProvider id="LocalSP" xsi:type="FileBackedHTTPMetadataProvider"
metadataURL="https://servpro.sn/Shibboleth.sso/Metadata"
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
NIANG Pape Saer
 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
http://download.opensuse.org/repositories/security://shibboleth/CentOS_CentOS-
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
http://download.opensuse.org/repositories/security:/shibboleth/CentOS_CentOS-
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
NIANG Pape Saer
# 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="https://servpro.sn"
REMOTE_USER="mail eppn persistent-id targeted-id">
<!—Activation du wayf-->
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://servpro.sn/wayf/WAYF">
SAML2 SAML1
</SSO>

<MetadataProvider type="XML" uri="https://idp.uvs.sn/idp/profile/Metadata/SAML"
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
NIANG Pape Saer
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
5.3.1 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_1.17.1
# wget –no-check-certificate
https://forge.switch.ch/redmine/attachments/download/647/SWITCHwayf_1.17.1_20120613.zip
# unzip -d SWITCHwayf_1.17.1 SWITCHwayf_1.17.1_20120613.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
NIANG Pape Saer
<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
NIANG Pape Saer
$IDProviders['university'] = array (
'Type' => 'category',
'Name' => 'Universites',);
$IDProviders['https://idp.uvs.sn/idp/shibboleth'] = array( // déclaration de l’ IdP de l’uvs
'SSO' => 'https://idp.uvs.sn/idp/profile/Shibboleth/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.
5.4.1 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.
5.4.2 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
NIANG Pape Saer
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 (https://servpro.sn/moodle).
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
NIANG Pape Saer
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
NIANG Pape Saer
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
5.5.1 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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
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
NIANG Pape Saer
 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
NIANG Pape Saer
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 2003.
[B04] : Florent Guilleux Olivier Salaün, Pascal Aubry. Fédération d’identités et propagation d’attributs
avec Shibboleth, Décembre 2005.
[B05] : Le groupe supann tech. Recommandations pour les annuaires de l’enseignement supérieur :
SUPANN 2009, Décembre 2009.
[B06]: Sébastien BOBILLIER Préparation à la certification LPIC-2, 6 décembre 2010

[B07]: Gerad Carter, LDAP System Administration O'Reilly March 2003.
[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 2013.
Webographie
[W01] : http ://www.uvs.sn. Consulté en Novembre 2013
[W02] : http ://fr.wikipedia.org/wiki/shibboleth. Consulté en Septembre 2013.

[W03]: https://services.renater.fr/federation/docs/installation/sp_decembre2012 Consulté Octobre 2013
sla-decennie.html Consulté en Octobre 2013
[W05]:http://thesesups.ups-tlse.fr/326/1/Kamel_Michel.pdf. Consulté en Novembre 2013.
[W06]:https://services.renater.fr/federation/introduction/comment-ca-marche
[W07]:[http://www.esup-portail.org/pages/viewpage.action?pageId=54722590 consulté Decembre2013
[W08]: http://www.uvt.rnu.tn/m/guide_moodle/platformeead/platformemoodle.html Consulté Octobre 2013.
69
NIANG Pape Saer
[W09] :http://www.connexions-normandie.fr/2009/03/11/environnementnumerique-travail-
enseignement-universite-normandie/1620/.Consulté en Octobre 2013.
[W10] :http://www.egilia.com/fr/articles/20976-la-federation-identites-single-sign-on-le-serpent-mer-
la-decennie.html Consulté en Octobre 2013.
ANNEXES
A. ANNEXES : Installation du serveur LDAP
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
NIANG Pape Saer
Le contenu de l’annuaire avec l’outil graphique phpldapadmin
71
NIANG Pape Saer
Exemple de quelques fédérations

Pays Nom de la fédération Site web des fédérations
France RENATER http ://www.renater.fr/
Etats Unis InCommon Fédération http ://www.incommonfederation.org/
Suisse Switch AAI http ://switch.ch/aai/
Allemagne DFN-AAI https ://www.aai.dfn.de/
Irlande eduGate http ://www.edugate.ie/
Portugal RCTS AAI http ://rctsaai.fccn.pt/
Espagne SIR http ://www.rediris.es/sir/
72

Memoire Shibboleth PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire Shibboleth PDF

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire de fin de cycle

Ecole Centrale des Logiciels Libres et de

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 :

NIANG Pape Saer Dr. Samuel OUYA

Année universitaire : 2011– 2013

Je dédie ce travail à mes parents:

A mon père CHEIKH NIANG

A ma mère ANNE MARIE BA

A ma tante AMINATA GUEYE

Conception et implémentation d'une plateforme de fédération d’identité pour l’uvs

Je tiens aussi à remercier et à témoigner toute ma reconnaissance :

 Au Docteur Samuel OUYA, notre encadreur, pour sa disponibilité et ses multiples

 A Monsieur Amadou Dahirou Gueye et Jean Diokh pour leurs contributions

 A Monsieur Alfatma THIAM et Abdou Salam BA

 A mes sœurs Kine, Diatou et Mami

 A tout le personnel de RTN et EC2LT

Conception et implémentation d'une plateforme de fédération d’identité pour l’uvs

La multiplication et la diversité des systèmes d’authentification liée aux ressources numériques

Conception et implémentation d'une plateforme de fédération d’identité pour l’uvs

Multiplication and diversity of authentication systems related to digital resources is a major

Keywords: Federation of identities, propagation attributes, virtual organization, SAML, Shibboleth.

Conception et implémentation d'une plateforme de fédération d’identité pour l’uvs

TABLES DES MATIERES

RESUME / ABSTRACT ...................................................................................................................iv

TABLE DES MATIERES .................................................................................................................vi

LISTE DES TABLEAUX ................................................................................................................ ix

LISTE DES FIGURES .......................................................................................................................x

SIGLES ET ABREVIATIONS ......................................................................................................... xi

Chapitre 1: Présentation Générale ........................................................................................................ 3

1.1 Présentation de l’entreprise RTN ............................................................................................ 3

1.2 Missions de RTN ..................................................................................................................... 3

1.3 Organigramme de RTN ........................................................................................................... 3

1.4 Domaine d’activités................................................................................................................. 4

1.5 Présentation de l'Université Virtuelle du Sénégal(UVS) ........................................................ 5

1.6 Mission de l'Université Virtuelle du Sénégal.............................................................................. 8

1.7 Concept d'Espace Numérique Ouvert (ENO).......................................................................... 9

1.8 Présentation du sujet.............................................................................................................. 10

1.8.1 Contexte du sujet ............................................................................................................... 10

Conception et implémentation d'une plateforme de fédération d’identité pour l’uvs

Chapitre 2: État de l’art de la fédération d'identité .......................................................................... 13

2.1 Concepts d’organisations virtuelles ...................................................................................... 13

2.2 Définition de la fédération d'identité ..................................................................................... 14

2.3 Cercle de confiance ............................................................................................................... 15

2.4 Fonctionnement des fédérations d'identités........................................................................... 16

Chapitre 3 : Système d’authentification centralisé ............................................................................ 18

3.1 Single Sign-On (SSO) ........................................................................................................... 18

3.2 Méthode d'authentification SSO............................................................................................ 19

3.3 Les différents types d’authentification unique ...................................................................... 20

3.3.1 Approche fédératif............................................................................................................. 20

3.3.2 Approche centralisé ........................................................................................................... 20

3.3.3 Approche coopérative ....................................................................................................... 20

3.4 Présentation du CAS ............................................................................................................. 21

3.5 Fonctionnement du CAS ....................................................................................................... 21

3.6 Généralités sur les annuaires électroniques .......................................................................... 22

3.6.1 Présentation ....................................................................................................................... 22

3.6.2 Différences entre annuaire et une Base de Données ......................................................... 23

3.6.3 Protocole LDAP ................................................................................................................ 23