Mémoire de fin de cycle - ekladata.comekladata.com/Owsd-qD0kNKjR-3HSnaJ8F2jD_8/memo_rendu2.pdf ·...

Mémoire de fin de cycle

REPUBLIQUE DU SENEGAL

***** * * ********

Ecole Centrale des Logiciels Libres et de

Télécommunications

SUJET : Conception et implémentation d'une plateforme de

fédération d’identité pour l’Université Virtuelle du Sénégal

MEMOIRE DE FIN DE CYCLE

Pour l’obtention du Diplôme de master en Télécommunications/Réseaux

Option: Réseaux et Services

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

Mémoire de fin de cycle NIANG Pape Saer

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

i

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.

Dédicaces



ii

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 mes frère Aly Niang et El hadji Mamadou Niang pour tout leur soutient

A mes sœurs Kine, Diatou et Mami

A Monsieur Amadou Dahirou Gueye et Jean Diokh

A tout le personnel de RTN et EC2LT

A Monsieur Alfatma THIAM et Abdou Salam BA

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 toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce document.

Remerciements



iii

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.

AVANT PROPOS



iv

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.

RESUME/ABSTRACT



v

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.

RESUME/ABSTRACT



vi

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

TABLES DES MATIERES



vii

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



viii

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



ix

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



x

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

Liste des Tableaux



xi

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

Liste des Figures



xii

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



xiii

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

Sigles et Abréviations



1

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.

Introduction



2

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.



3

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



4

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 :

0-1

Conseil d'Orientation Scientifique

DG

Directeur Formation Recherche EC2LT

Service acceuil, info, animation

scolaire

Bureau des étudiants

Service Ressource

Technique et Documentaire

Service scolarité,

recouvrement et caisse

Départements

Commissions permanentes

ou adhoc

Conseil de la vie scolaire et

des études (DFR)

Service Recherche

déploiement & formation

Service comptabilité

et finance

Service marketing

communication &

commerciales



5

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 à



6

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



7

- 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



8

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.



9

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



10

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



11

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.



12

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é



13

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.



14

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



15

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

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.



16

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.



17

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é



18

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

http://fr.wikipedia.org/w/index.php?title=Fatigue_de_mot_de_passe&action=edit&redlink=1



19

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).



20

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

http://fr.wikipedia.org/wiki/Liberty_Alliance

http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es

http://fr.wikipedia.org/wiki/Annuaire



21

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

http://fr.wikipedia.org/wiki/Authentification_unique

http://fr.wikipedia.org/wiki/Web

http://fr.wikipedia.org/wiki/Universit%C3%A9_Yale



22

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.



23

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.

http://www.commentcamarche.net/contents/531-protocoles

http://www.commentcamarche.net/contents/531-protocoles



24

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



25

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



26

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.



27

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 :



28

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



29

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.



30

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.



31

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 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.

Ou=groups, dc=uvs, dc=sn



32

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).



33

Tableau 3.1. Comparaison des produits de fédération d'identité

CA SiteMinder FSS CA SOA

SecurityManager

HP OpenView Select

Federation

Facilité de déploiement

et de configuration

Moyen

Moyen

Moyen

Conformité aux

langages d’échange de

l’information de

sécurité

SAML 2.0 et

WS-Federation

SAML 2.0 et

WS-Federation

SAML 2.0 et

WS-Federation

Possibilité de fédérer

des identités entre des

Web Services

Non

Oui

Oui

Coût 21000 € + 4000€ pour

maintenance annuelle

100000€ (licence pour

4cpu) + 2000 € pour

Maintenance annuelle

18500 € pour une

connexion

Support pour différents

Systèmes et technologies

d’authentification

mots de passe, jetons,

certificatsX.509,

techniques biométrique


certificatsX.509,

techniques

biométriques


cartes à puce, certificats

d’identité X.509,

Niveau de sécurité offert -clustering, haute

disponibilité

- load balancing,

-Cluster, haute

disponibilité

Respect de la vie privée Protégée Protégée Protégée



34

IBM Tivoli FIM Microsoft

ADFS

Ping Identity

PingFederate

Facilité de déploiement

et de configuration

Difficile Moyen Facile

Approche adoptée pour

gérer la fédération

Intégrée à Tivoli

Access Manager

Intégrée à

Windows Server

2003

Autonome

Conformité aux langages

d’échanges de

l’information de sécurité

SAML 2.0 et

WS-Federation

WS-Federation SAML 2.0 et

WS-Federation



Web Services

Oui Oui Non

Coût 8200 € pour une

licence en plus de

licences pour les

logiciels requis

3000€ + prix de

licences annuelles

8000€ pour 1

connexion par an


systèmes et

technologies


Les mécanismes

supportés par Tivoli

Access Manager

(cartes à puce,

technique biométriques,

Kerberos, etc.)

Microsoft Active

Directory (Kérberos,

cartes à puce et

certificats d’identité

X.509) et LDAP

Mots de passe, cartes

à puce, techniques

biométriques, clésUSB,

certificats X.509,

Niveau de sécurité

offert

-cluster pour

une haute

performance et

disponibilité

- Possibilité de

déploiement de serveurs

de fédération

additionnels pour

load balancing et

évolutivité

-cluster pour une

haute disponibilité et

récupération




35

Ping Identity

PingTrust

RSA Federated

Identity ManagerRSA

Federated Identity

Manager

Internet2

Shibboleth

Facilitéde déploiement

et de configuration

Facile Moyen Moyen

Approche adoptée pour

gérer la fédération

Autonome Autonome Intégré à un WAM

Conformité aux

languages d’échange de

l’information de

sécurité

SAML 2.0 et

WS-Federation

SAML 2.0 SAML 2.0 et

WS-Federation



Web Services

Oui Oui Non

Coût 8000€ pour 1

connexion par an

37000 € pour

3 connexions

74000 € pour

10 connexions

Logiciel libre


systèmes et

technologies


mots de passe, cartes à

puce, techniques

biométriques, clés

USB, certificats X.509,

Authentification à

2 facteurs basés

sur RSA

Active Directory,

LDAP, Kerberos

Niveau de sécurité

offert

-cluster, haute

disponibilité

-cluster, haute

disponibilité

-haute disponibilité

- load balancing




36

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.



37

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.



38

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



39

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.



40

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



41

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.



42

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



43

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.



44

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



45

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



46

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.



47

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.



48

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.



49

Chapitre 5: Implémentation de Shibboleth

L’objectif de ce chapitre est de procéder à l’installation de la solution retenue pour atteindre

nos objectifs dans ce projet en exposant les outils et technologies utilisés. Pour ce faire, il faut au

préalable faire une conception d’un référentiel utilisateur basé sur LDAP pour gérer les accès aux

ressources mutualisées.

5.1 Conception de l’annuaire LDAP

LDAP définit un ensemble de classes et d’attributs par défaut convenant pour la grande majorité

des applications. Ces attributs doivent impérativement être implémentés par les serveurs d’annuaire

LDAP. Cela permet de garantir une certaine homogénéité entre les différents annuaires.

Chaque entrée dans people représente un individu. Pour la conception de l’annuaire on a

spécifié les attributs selon les utilisateurs de l’annuaire.

Tableau 5.1. Attributs communs aux utilisateurs

Schémas Informations Attributs

LDAP

Nom Cn

Prénom givenName

Téléphone TelephoneNumber

Mail Mail

Mot de passe userPassword

SCHAC

Date de Naissance schacDateOfBirth

Lieu de naissance schacPlaceOfBirth

Pays d’origine schacCountryOfCitizenship

Pays de résidence schacCountryOfResidence

SUPANN

Login supannAliasLogin

Civilité supannCivilite

Mail institutionnel supannMailPerso



50

Tableau 5.2. Attributs spécifiques aux personnels


Internet 2 Statut du personnel eduPersonAffiliation

SUPANN

Grade title

Service SupannRoleEntity

Code personnel SupannEmpID

statut de la personne eduPersonAffiliation

Tableau 5.3.Attributs spécifiques aux étudiants


SUPANN

Date d’inscription supannAnneInscription

Type de diplôme voulu supannEtuDiplome

Cursus supannCursusAnnee

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

SUPANN

Grade title

Statut professionnel supannRoleEntity

Numéro d’identification supannEmpID



51

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" />



52

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



53

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

# 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

# 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



54

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/

55

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

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 :

<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>



56

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

Configurer le dépôt de Shibboleth pour une machine CentOS 6

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

ServerName servpro.sn:80

...

UseCanonicalName On

# 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

57

# 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

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

<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>



58

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.

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

# 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



59

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

<Files WAYF>

ForceType application/x-httpd-php

</Files>

Alias /wayf /usr/local/SWITCHwayf



60

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.

$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'

,);



61

Ensuite dans Apache, il faut renseigner les directives :

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

ScriptAlias /moodle "/var/www/html/moodle/auth/shibboleth/index.php"

<Location /moodle >

AuthType shibboleth

ShibRequestSetting RequireSession 1

ShibRequestSetting applicationId default

require valid-user

</Location>

https://servpro.sn/moodle



62

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



63

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.



64

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



65

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



66

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.



67

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.



68

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.



69

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.

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.

[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.

REFERENCES

https://services.renater.fr/federation/docs/installation/sp_decembre2012%20Consulté%20en%20Octobre%202013



70

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

ANNEXES



71

Le contenu de l’annuaire avec l’outil graphique phpldapadmin

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/

Mémoire de fin de cycle - ekladata.comekladata.com/Owsd-qD0kNKjR-3HSnaJ8F2jD_8/memo_rendu2.pdf ·...

Documents

Transcript of Mémoire de fin de cycle - ekladata.comekladata.com/Owsd-qD0kNKjR-3HSnaJ8F2jD_8/memo_rendu2.pdf ·...