Rapport projet3

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc i

Epigraphe LIRT 2011-2012

Epigraphe

« Je n’ai pas peur des ordinateurs. Mais j’ai peur qu’ils viennent à nous manquer »

Isaac ASIMOV

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc ii

Dédicaces LIRT 2011-2012

Dédicaces

A nos parents

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc iii

Remerciements LIRT 2011-2012

Remerciements

Nous ne saurons amorcer la rédaction de ce mémoire sans penser à tous ceux qui

directement ou indirectement ont contribué à sa réalisation. Nous tenons donc à les remercier

du plus profond de notre cœur. Nous exprimons notre gratitude :

Au Dieu tout puissant pour nous avoir donné tout le nécessaire durant la réalisation de

ce travail.

A tout le corps administratif et enseignant de l’IUT Fotso Victor de Bandjoun pour

tout leur effort mené au quotidien pour notre formation.

A notre encadreur M. LIENOU pour son soutien professionnel, sa disponibilité et ses

encouragements qui ont été indispensables à la réalisation de ce travail.

A la famille KAPDJOU, notamment mon père M. KAPDJOU Mathias et ma mère

Mme WETTE Rachel pour leur soutient inestimable.

A la famille MODO, particulièrement à Mme. NGA MODO Germaine, Mme ESSO

Odile, Mme. NGO EOCK Nicole, M. ADETONAH Ricardo pour leur assistance et

soutient sans pareil.

A M. PENTANE K. Yaya chef section réseau à CAMTEL Douala pour sa

contribution précieuse à la réalisation de ce projet.

A mon oncle M. TCHEPKEU Etienne pour son aide social et ses nombreux conseils.

A toute la famille GTR de Bandjoun particulièrement LIRT 2011-2012 pour la

solidarité menée durant cette année académique.

A nos camarades notamment FANDOM Martial, DJIKI Armand, CHATUE Herman

et CHUMCHOUA Malcom.

A tous ceux qui, de prés ou de loin, ont participé à la réalisation de ce travail.

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc iv

Liste des abréviations LIRT 2011-2012

Liste des abréviations

ADN : Acide Désoxyribonucléique

BD : Base de Données

CAS : Central Authentication Service

CNIL : Commission Nationale Informatique

et Liberté

CRU : Commission Réseau des Universités

DNS : Domain Name System

HTTP : HyperTest Transport Protocol

IBM : Industry Business Machine

IdP : Identity Provider

IETF : Internet Engineering Task Force

IMAP : Internet Message Access Protocol

IP : Internet Protocol

JAAS : Java Authentication and Authorization

Service

JDBC : Java DataBase Connectivity

JRE : Java Runtime Environnement

JDK : Java Development Kit

LDAP : Lightweight Directory Access Protocol

OASIS : Advanced Open Standard for the

Information Society

OTP : One Time Password

PC : Personal Computer

PKI : Public Key Infrastructure

PME : Petite et Moyenne Entreprise

SGBD : Système de Gestion de Base de

Données

SMS : Short Message Service

SP : Service Provider

SSO : Single Sign-On

SSL : Secure Socket Layer

SAML : Security Assertion Markup Language

TCP : Transport Control Protocol

TGC : Ticket Granting Cookie

TPE : Très Petite Entreprise

UDP : User Datagram Protocol

URL : Uniform Resource Locator

VLDAP : Virginia tech LDAP module

VPN : Virtual Private Network

WAYF : Where Are You From

WWW : World Wide Web

XML : eXtended Markup Language

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc v

Liste des figures LIRT 2011-2012

Liste des figures

Figure 1: problème de l’utilisateur .......................................................................................................... 8

Figure 2 : problème de l’administrateur .................................................................................................. 9

Figure 3 : problème générale ................................................................................................................... 9

Figure 4 : centralisation de l'authentification ........................................................................................ 10

Figure 5 : authentification centralisée à l'annuaire LDAP ..................................................................... 10

Figure 6 : principe d'authentification unique ......................................................................................... 11

Figure 7 : principe de la fédération d'identités ...................................................................................... 12

Figure 8 : architecture du serveur CAS ................................................................................................. 17

Figure 9 : fonctionnement de base de CAS ........................................................................................... 18

Figure 10 : redirection transparente vers le serveur CAS ...................................................................... 18

Figure 11 : validation pour l'accès à une ressource ............................................................................... 19

Figure 12 : accès à l'application sans authentification ........................................................................... 20

Figure 13 : validation du PT pour l'accès à une ressource..................................................................... 20

Figure 14 : CAS dans l'architecture n-tiers............................................................................................ 21

Figure 15 : fonctionnement du WAYF .................................................................................................. 22

Figure 16 : requête du navigateur vers le fournisseur de service .......................................................... 23

Figure 17 : redirection de l'IdP vers le SP ............................................................................................. 23

Figure 18 : le SP demande les attributs de l’utilisateur ......................................................................... 24

Figure 19 : réponse du SP au navigateur ............................................................................................... 24

Figure 20 : fonctionnement de Shibboleth sans CAS ............................................................................ 25

Figure 21 : redirection du navigateur vers le serveur de SSO ............................................................... 26

Figure 22 : fonctionnement de Shibboleth avec SSO ............................................................................ 27

Figure 23 : requete suivant le meme SP ................................................................................................ 27

Figure 24 : délégation d'authentification vers un autre SP .................................................................... 28

Figure 25 : redirection transparente vers le WAYF .............................................................................. 28

Figure 26 : redirection du WAYF vers le serveur de SSO .................................................................... 29

Figure 27 : réponse du SP après authentification du serveur SSO ........................................................ 29

Figure 28 : réponse du SP sans authentification .................................................................................... 30

Figure 29 : le WAYF en action dans une fédération ............................................................................. 30

Figure 30 : architecture du système ....................................................................................................... 32

Figure 31 : principe de l'OTP ................................................................................................................ 44

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc vi

Avant-propos LIRT 2011-2012

Avant-propos

L’institut universitaire de technologie FOTSO Victor de BANDJOUN (IUT-FV) a été

construit en 1987, par le fondateur donateur FOTSO Victor dont l’établissement porte le nom

sous l’appellation initiale de « collège privé laïc polyvalent FOTSO Victor ». La structure a

été cédée à l’Etat camerounais le 12/08/1993. Elle devient plus tard Institut Universitaire de

Technologie FOTSO Victor de BANDJOUN suite à la réforme universitaire de janvier 1993.

Cet institut fait partie aujourd’hui des établissements de l’université de DSCHANG. Il forme

des techniciens et des ingénieurs de travaux dans quatre (04) cycles:

DUT (Diplôme Universitaire de Technologie) où l’admission se fait uniquement sur concours

avec pour diplôme de base : Bac C, D, E, F. Pour une durée de 2ans, Ses filières sont :

Génie Informatique (GI)

Génie Electrique (GE) : (02) options

Electronique (EN)

Electrotechnique (EL)

Génie des Télécommunications et Réseaux (GTR)

Génie Mécanique et Productique avec pour option Maintenance Industrielle et

Productique (MIP)

Génie Civil (GC)

BTS (Brevet de Technicien Supérieur) où l’entrée se fait sur étude de dossier et entretien.

Pour 2 ans également, les filières sont :

Comptabilité et Gestion des Entreprises (CGE)

Banque et finance (BF)

Secrétariat de Direction (SD)

Action Commerciale (AC)

Génie Civil (GC)

Génie Electrique (GEL) : (02) options

Electronique (EN)

Electrotechnique (EL)

LICENCE TECHNOLOGIQUE dans les spécialités :

Concepteur et Développeur Réseaux Internet

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc vii

Avant-propos LIRT 2011-2012

Génie Electrique

Ingénierie des Réseaux et Télécommunications

Maintenance Industrielle et Productique

Génie Géomatique

Génie Thermique, Energétique et Environnement

LICENCE PROFESSIONNELLE dans les spécialités :

Gestion Administrative et Management des Organisations (GAMO)

Gestion Comptable et Financière (GCF)

Commerce-Marketing (CM) : (02) options

Marketing Manager Opérationnel (MMO)

Banque et Gestion de la Clientèle (BGC)

L’IUT dispose en plus d’une formation CISCO dont la durée dépend de l’option choisie à

savoir:

CITE 1 & 2

CCNA 1 & 2

En somme, l’IUT FOTSO Victor de Bandjoun avec son administration entreprenante, des

enseignants dotés d’une conscience professionnelle et ses étudiants bénéficiant de son

lotissement très propice à l’enseignement, a un avenir promoteur. Tout étudiant en fin de

formation de licence de technologie doit faire un projet en vue de s’imprégner des réalités du

monde professionnel. Au terme de ce projet, l’étudiant devra rédiger un rapport, qui sera

exposé devant un jury, d’où la raison d’être du document porté sur « la mise en œuvre d’un

système d’authentification centralisé (SSO) avec fournisseur d’identités dans un intranet ».

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc viii

Résumé LIRT 2011-2012

Résumé

La mémorisation de multiples mots de passe est devenue un problème pour les

utilisateurs. Pendant qu’un système SSO1 mémorise les mots de passe pour chaque application

à la place des utilisateurs, le fournisseur d’identité permettra d’étendre le champ d’action de

ces utilisateurs hors de l’entreprise.

L'intranet est aujourd'hui une ressource informatique indispensable à une organisation et

destiné essentiellement à mettre en place les services avec conditions d'utilisation. Ainsi, la

centralisation d’authentifications est un élément important dans un intranet. Aussi, La mise en

place d’un système Single Sign-On avec fournisseur d’identité va épargner la tête des

utilisateurs en ne leur faisant mémoriser qu’un seul mot de passe et leur doigts ne seront plus

sollicités car ils ne s’authentifieront qu’une seule fois pour accéder à un nombre important

d’applications.

Ce projet de fin d’études implémenté est une association de plusieurs serveurs.

En effet, la configuration des serveurs CAS2 et Shibboleth

3 est un exercice professionnel qui

demande beaucoup de compréhension en ce qui concerne le principe de fonctionnement. C’est

la raison pour laquelle notre encadreur a attiré notre attention sur tous les éléments qui entrent

en jeux et à beaucoup insisté sur la sécurité pour l’accès au système. Cela nous a permis de

mieux cerner les notions sur l’authentification forte et les difficultés rencontrées nous ont

ainsi ouvert l’esprit en ce qui concerne le milieu professionnel en évaluant l’importance de la

formation reçue à l’IUT-FV.

1 Single sign-on : une seule authentification pour plusieurs applications

2 Serveur de SSO

3 Fournisseur d’identités

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc ix

Abstract LIRT 2011-2012

Abstract

The memorizing of multiple passwords became a problem for the users. While a system

SSO memorizes the passwords for each application to the place of the users, the supplier of

identity will allow to extend the sphere of activity of these users out of the company.

The Intranet is today a data-processing resource essential to an organization and primarily

intended to set up the services with conditions of use.Thus, the centralization of

authentifications is a significant element in an Intranet.Also, the installation of a system

Single Sign it with supplier of identity will save the head of the users by making them

memorize that only one password and their fingers will not be requested any more because

they will authenticate only once to reach a significant number of applications.

This project of end of studies implemented is an association of several waiters.

Indeed, the configuration of the waiters CASE and Shibboleth are a professional exercise

which requires much comprehension with regard to the principle of operation.This is why our

encadror drew our attention to all the elements which enter in plays and to insisted much on

safety for the access to the system.That enabled us to better determine the concepts on the

strong authentification and the encountered difficulties thus opened us the spirit with regard to

the professional environment by evaluating the importance of the formation received in Iut-fv.

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc x

Sommaire LIRT 2011-2012

Sommaire

Epigraphe ................................................................................................................................................. i

Dédicaces ................................................................................................................................................ ii

Remerciements ....................................................................................................................................... iii

Liste des abréviations ............................................................................................................................. iv

Liste des figures....................................................................................................................................... v

Avant-propos .......................................................................................................................................... vi

Resumé ................................................................................................................................................. viii

Abstract .................................................................................................................................................. ix

Sommaire ................................................................................................................................................ x

Cahier des charges ................................................................................................................................... 1

Introduction générale ............................................................................................................................... 3

Chapitre 1 : Géneralites sur l’authentification ..................................................................................... 4

1.1 Les acteurs et services d’authentification .................................................................................. 4

1.1.1 Pourquoi utiliser un service d’authentification ? ................................................................ 4

1.1.2 Les acteurs d’authentification ............................................................................................. 4

1.1.3 Les services d’authentification ........................................................................................... 5

1.1.4 Les protocoles d’authentification ....................................................................................... 6

1.2 Méthodes d’authentification ...................................................................................................... 7

1.2.1 Présentation ........................................................................................................................ 7

1.3 Analyse de l’existant ................................................................................................................. 8

1.3.1 Probléme de l’utilisateur..................................................................................................... 8

1.3.2 Probléme de l’administrateur ............................................................................................. 8

1.3.3 Probléme general ................................................................................................................ 9

1.4 Justification du theme .............................................................................................................. 10

1.4.1 Centraliser l’authentification ............................................................................................ 10

1.4.2 Authentification unique .................................................................................................... 11

1.4.3 La délégation d’identités .................................................................................................. 12

Chapitre 2 : Choix de la solution, conception et mise oeuvre ........................................................... 13

2.1 Choix de la solution ................................................................................................................. 13

2.1.1 Présentation des solutions................................................................................................. 13

2.1.2 Le choix de la solution cas-shibboleth ............................................................................. 15

2.2 Conception ............................................................................................................................... 16

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc xi

Sommaire LIRT 2011-2012

2.2.1 Le mecanisme de cas ........................................................................................................ 16

2.2.1.1 Architecture ............................................................................................................... 16

2.2.1.2 Fonctionnement de base ............................................................................................ 17

2.2.1.3 Accès à une ressource protegée apres authentification.............................................. 18

2.2.1.4 Accès à une ressource protegee sans authentification préalable…………………….19

2.2.1.5 Principe de mandat avec cas ..................................................................................... 20

2.2.2 Le mécanisme de shibboleth ............................................................................................ 21

2.2.2.1 Architecture ............................................................................................................... 21

2.2.2.2 Fonctionnement de shibboleth sans cas ..................................................................... 23

2.2.2.3 Fonctionnement de shibboleth avec sso .................................................................... 26

2.2.2.4 Fonctionnement de shibboleth dans une fédération .................................................. 28

2.3 Mise en oeuvre ........................................................................................................................ 31

2.3.1 Présentation de l’intranet .................................................................................................. 31

2.3.2 Centralisation de l’authentification .................................................................................. 32

2.3.3 Configuration des serveurs ............................................................................................... 34

2.3.3.1 Installations ............................................................................................................... 34

2.3.3.2 Configuration du serveur idp shibboleth ................................................................... 37

Chapitre 3 : Résultats obtenus et perspectives .................................................................................. 40

3.1 Résultats obtenus ..................................................................................................................... 40

3.2 Perspectives ............................................................................................................................. 43

3.2.1 Authentification forte ....................................................................................................... 44

3.2.1.1 L’otp .......................................................................................................................... 44

3.2.1.2 Authentification biometrique ..................................................................................... 44

3.2.2 Une fédération d’identités fonctionnelle ......................................................................... 45

Conclusion générale .............................................................................................................................. 46

Bibliographie ......................................................................................................................................... 47

Annexes ................................................................................................................................................. 48

Projet de fin d’étude |Rédigé et soutenu par KAPDJOU Narcisse et MODO NGA Eric Marc 1

Cahier des charges LIRT 2011-2012

Cahier des charges

THEME : Mise en œuvre d’un système d’authentification centralisé SSO avec

fournisseur d’identité dans un intranet.

Définition des mots clés

SSO : service d’authentification unique pour l’accès à un ensemble d’application.

Fournisseur d’identité : organisation membre d'une fédération gérant l'identité informatique

d'un ensemble d'utilisateurs et offrant un service d'authentification à ses utilisateurs, afin de

s'authentifier sur le réseau.

Problématique

Comment permettre aux utilisateurs d’applications d’entreprise, des universités ou de

toutes autres instances de s’authentifier une seule fois pour un accès global aux différentes

ressources tout en se rassurant de leur identité ?

Motif

Répondre aux besoins d’authentification unique et de fourniture d’identités de plus en plus

réclamés dans les entreprises et les universités dans le cadre d’un accès à un service.

Identification du projet

Il est question ici de mettre sur pied un système qui authentifie une seule fois un

utilisateur pour qu’il accède à toutes les applications de l’intranet centralisées par un

référentiel. En outre, c’est aussi un système constituant un fournisseur d’identités. Cela

s’explique simplement par les procédures à mettre en place pour la participation d’un intranet

à une fédération d’identités.


Cahier des charges LIRT 2011-2012

Travaux préliminaires :

Brève présentation des systèmes d’authentification

Présenter les avantages des systèmes d’authentification centralisée

Présenter les apports d’authentification SSO et d’un fournisseur d’identités

Inventaire des solutions possibles

Présenter la solution motivée et son fonctionnement

Donner une architecture du système

Moyens

Utilisation des systèmes d’exploitations GNU/LINUX distribution DEBIAN version

6.0.1 et Microsoft Windows pour les clients.

Utilisation des logiciels libre tels que OpenLDAP, SAMBA, Tomcat, Shibboleth, CAS

client et CAS server.

Fonctionnalités attendues :

Authentification centralisée avec l’annuaire LDAP

Contrôleur de domaine avec le serveur SAMBA

Génération de l’arbre de base au sein de l’annuaire LDAP pour le contrôleur de

domaine SAMBA.

Déployer le fournisseur d’identité avec la brique Shibboleth pour avoir la possibilité

d’accéder à une fédération.

Serveur de SSO déployé avec CAS, si possible Shibboleth pour donner la possibilité

d’une authentification unique.

Durée du projet : 4 mois

Encadreur : M. LIENOU Jean Pierre


Introduction générale LIRT 2011-2012

Introduction générale

L’universalité du protocole HTTP4 a depuis longtemps séduit les développeurs car les

applications portées sur le web sont de plus en plus nombreuses et l’accès à ces applications

est engendré par l’authentification. Avec un nombre croissant d'applications à leur

disposition, et donc avec autant de mots de passe à mémoriser, les utilisateurs et les

administrateurs font de leur mieux : ils inscrivent ces codes secrets dans leur agenda papier,

les notent sur des Post-it5 qu'ils collent autour de leur écran ou, plus simple, laissent leurs

connexions ouvertes lorsqu'ils quittent leur poste de travail.

La fédération d’identité dans les systèmes d’authentification unique en ligne est depuis

quelques années déjà au cœur de multiples débats, en entreprise, au sein des universités, et

parmi les acteurs majeurs du Web. Le fournisseur d’identité permettra d'offrir à l'internaute un

service web plus optimisé. Il apporte sécurité et confort à l’utilisateur aussi bien dans sa vie

privée que dans sa vie professionnelle, tout en renforçant l'attractivité des médias.

Le présent rapport est structuré en trois chapitres, dans lequel, nous présenterons une

grande majorité des méthodes d’authentification et aussi les différents services

d’authentification sans oublier de déclarer certaines problématiques qui nous permettrons de

justifier notre projet. En plus, nous présenterons certaines solutions pour ce projet et nous

insisterons sur le mécanisme de fonctionnement des solutions choisies telles que CAS et

Shibboleth. Nous détaillerons les différentes étapes de la réalisation de ce projet et sa

configuration.

Le dernier chapitre sera un dossier spécifiquement centré sur les résultats obtenus et les

perspectives concernant le renforcement de la sécurité, et une fédération d’identités pour notre

université. Pour des raisons de temps, de moyens et de compatibilité entre les systèmes, ces

perspectives n’ont pas fait parti de nos objectifs. Mais cela reste possible selon nos pronostics.

4 Protocol d’application utilisé par le navigateur servant au transfert des pages web

5 Papier destiné à enregistrer les petites informations le plus souvent provisoire


Chap. 1 : Généralité sur l’authentification LIRT 2011-2012

HAPITRE 1 : GENERALITES SUR L’AUTHENTIFICATION

Introduction

Ce chapitre est consacré à l’étude de l’authentification dans un intranet, de l’analyse des

systèmes existants et de la justification du thème. Cette étude va nous permettre par la suite de

mener à bien le projet.

1.1 LES ACTEURS ET SERVICES D’AUTHENTIFICATION

1.1.1 POURQUOI UTILISER UN SERVICE D’AUTHENTIFICATION ?

Tout d'abord, il faut se souvenir que dans des temps très reculés à l'échelle de

l'informatique, dans les années 70, les terminaux étaient reliés au serveur par des liens

spécialisés. Pour s'infiltrer, un hacker devait donc obligatoirement se brancher physiquement

sur ces liens.

Lorsque les réseaux ont commencé à utiliser un modèle client-serveur6 et que les

terminaux ont été remplacés par les PC, les administrateurs ne pouvaient plus avoir confiance

aux utilisateurs. En effet, ceux-ci peuvent désormais modifier un logiciel ou écouter le réseau.

Il a donc fallu mettre en place un système permettant de rétablir cette confiance sur le réseau.

La solution proposée est la mise en place d'un système d'authentification, permettant de

rétablir la confiance dans le réseau, car dès lorsque les interlocuteurs se connaissent et

peuvent s’identifier. Elle a été proposée pour la sécurité, afin que seules les personnes

concernées puissent consulter les informations confidentielles.

1.1.2 LES ACTEURS D’AUTHENTIFICATION

Ce sont les concepts et objets manipulés pendant l’authentification.

Un utilisateur

Désigne une personne physique ayant les natures suivantes :

un étudiant

6 Système disposant d’un client pour les requêtes vers un serveur répondant à ces requêtes

C



un membre du personnel ou un client

une entité administrative

un administrateur informatique

un invité etc…

Un groupe

Les utilisateurs peuvent être regroupés en groupe statique ou dynamique. Ces groupes sont

utilisés pour faciliter la gestion en masse des habilitations.

On peut regrouper ces acteurs en 3 natures : un client, un serveur proposant le service

demandé et un serveur d'authentification.

Un compte

A chaque personne peuvent être associés des comptes d’accès aux différents systèmes et

applications.

Le compte est défini par l’identifiant d’accès, un mot de passe, et plusieurs attributs

supplémentaires, en fonction de l’environnement dans lequel il est crée comme : la politique

de mot de passe associée, l’accès externe autorisé ou non, l’état du compte, les modes

d’authentifications autorisés etc… Il existe quatre types de compte :

Le compte global : Compte unique, identifie une personne dans le référentiel central et est

utilisé par tous les processus d’attribution des droits.

Le compte utilisateur : compte qui donne accès à un utilisateur dans un environnement

particulier auquel cet utilisateur est habilité. Chaque compte utilisateur est obligatoirement

associé à une personne.

Le compte d’administration : Ce compte donne l’accès à un administrateur dans un

environnement particulier. Il n’est pas associé à une personne.

Le compte « de service fonctionnel ou technique » : Compte utilisé par les composants d’un

système pour accéder aux services applicatifs et/ou données d’un autre système. Aucune

personne n’est autorisée à l’utiliser.

1.1.3 LES SERVICES D’AUTHENTIFICATION

Les termes associés aux services d’authentification sont : Identification, Authentification

et Autorisation. Le travail de ces services est avant tout l'authentification.

L'identification permet de vérifier l'identité d'une personne via un login par exemple.

L'authentification permet de s'assurer qu'une personne est bien celle qu'elle prétend être par

login et mot de passe.



L'autorisation permet à partir de l'identification et l'authentification de définir des droits à

une personne.

Après la phase d’authentification des utilisateurs, le système pourra autoriser ces

utilisateurs sur le service auquel ils tentent d’accéder par le contrôle de leurs droits d’accès.

Le service d’autorisation est chargé d’évaluer les droits effectifs sur la base des informations

fournies par le service d’authentification :

Authentification Windows pour SAMBA

Authentification accès distant (Radius)

Authentification Web Apache/IIS

Authentification SGBD Oracle/MySQL

Authentification messagerie (Webmail)

On peut distinguer deux types d'authentification : l'authentification d'un tiers et

l'authentification de la source des données. L'authentification d'un tiers consiste à prouver son

identité. L'authentification de la source des données sert à prouver que les données reçues

viennent de l’émetteur déclaré.

1.1.4 LES PROTOCOLES D’AUTHENTIFICATION

De nombreux protocoles d’authentification requièrent une authentification de l’identité

ou de l’équipement avant d’accorder des droits d’accès. Les principaux protocoles

d’authentification sont :

RADIUS

TACACS

Kerberos.

Les protocoles de la famille TACACS sont assez répandus. Ils utilisent le protocole TCP

contrairement à RADIUS qui s’appuie sur UDP. Toutefois, ce ne sont pas des standards

définis par un organisme de standardisation comme l’IETF. Seuls RADIUS et Kerberos sont

des standards.

Kerberos est mis en place dans l’authentification Windows 2000 au sein d’Active Directory.

Ce protocole permet l’authentification des entités communicantes (clients et serveurs) et des

utilisateurs.



1.2 METHODES D’AUTHENTIFICATION

Les méthodes d’authentification doivent être choisies en fonction du caractère stratégique

et du risque liés aux ressources devant être protégées.

1.2.1 PRESENTATION

Toutes les techniques d'authentification reposent sur l'utilisation d'un secret qui doit être

unique et non falsifiable. Il existe plusieurs façons pour authentifier une personne (ou plus

généralement, une entité). On peut se baser sur :

ce qu'il sait

ce qu'il a

ce qu'il est

« Ce qu'il sait » est tout simplement un mot de passe qui va permettre, par comparaison ou

par décryptage, par exemple, de vérifier que la personne est bien celle qu'elle dit être.

« Ce qu'il a » est plus subtil car il fait appel à un objet que la personne à authentifier, a en sa

possession. Le plus souvent, il s'agit d'un appareil générant « aléatoirement » une suite de

nombres/caractères. Cette suite qui ne sera valable que pendant un temps donné, permettra

d'utiliser des clés beaucoup plus longues, pour augmenter encore la sécurité pendant

l’authentification.

« Ce qu'il est » est justement une méthode encore peu utilisée pour le moment, et fait appel à

des mécanismes de biométrie (empreinte digitale, rétine...). Cette technique n'est pas encore

totalement utilisée, les raisons étant entre autres, le manque de logiciels l'utilisant réellement,

ainsi que la rareté de matériels encore onéreux. L'intérêt de ce type de système est qu'il

supprime la duplication, le vol, l'oubli et la perte. Cependant, à long terme, cette technique

risque de ne pas être exempte de piratage.



1.3 ANALYSE DE L’EXISTANT

On constate de plus en plus de nos jours dans les universités un nombre croissant

d’applications dédiées à la fois au personnel et aux étudiants engendrant un nombre

incalculable de mots de passe à retenir pour chacune d’elle.

1.3.1 PROBLEME DE L’UTILISATEUR

Généralement pas doué d’une expertise informatique, certains utilisateurs se retrouvent en

général dans l’embarra, car ne sachant que faire de ces multiples mots de passe à leur

disposition. C’est ainsi qu’ils les gardent dans des blocs notes ou à des endroits propices à leur

divulgations, et parfois même les oublies.

.

1.3.2 PROBLEME DE L’ADMINISTRATEUR

Face aux problèmes de perte, d’oubli de mot de passe par les utilisateurs également face

aux différentes tâches d’administration de l’ensemble des serveurs, il vient se poser le

problème d’une possibilité d’administration et de gestion des mots des mots de passe des

différents utilisateurs et des différents services configurés. L’on note :

Gestion du serveur d’authentification pour chaque application

Administration du réseau non centralisée.

Figure 1: problème de l’utilisateur



perte d’efficacité et de crédibilité des systèmes de sécurité multipliant les mots de

passe.

Sans une centralisation : Une annuaire/bd par application

1.3.3 PROBLEME GENERAL

Un fournisseur d’identité se trouve tenu à une disponibilité quasi permanente de ses

équipes informatiques pour accomplir une tâche sans réelle valeur ajoutée.

Comment proposer à nos utilisateurs un passeport unique pour accéder à leurs applications

habituelles, qu’elles soient internes à leurs entreprises, externes, ou proposées par un

partenaire ? Car 65 % des utilisateurs ont entre 4 et 10 mots de passe à retenir.

Figure 2 : problème de l’administrateur

Figure 3 : problème générale



1.4 JUSTIFICATION DU THEME

Mettre en place un système d’authentification pouvant répondre aux problèmes sus

cités tout en garantissant l’identité des utilisateurs au sein d’une entreprise, d’une instance (à

l’exemple du ministère des forêts et du ministère des finances) et même d’une fédération

universitaire en particulier l’université de Dschang et ses différents établissements affiliés ( à

l’exemple de l’iut-fv de bandjoun) tout en garantissant la confiance dans le réseau. Cela passe

par :

1.4.1 CENTRALISER L’AUTHENTIFICATION

C’est pour mettre en place un système central de gestion des identités pour l’accès à

toutes les applications de l’intranet. Elle nous permet de partager une base commune.

Le principe est de disposer d'une base de données globale pour centraliser toutes les demandes

d’authentification des utilisateurs. Elle unifie la gestion des authentifications et des

autorisations. Cela permet également de centraliser la gestion de la politique de sécurité. Un

annuaire (LDAP) est un type particulier de base de données pour ce genre d’authentification.

Figure 4 : centralisation de l'authentification

Figure 5 : authentification centralisée à l'annuaire LDAP



1.4.2 AUTHENTIFICATION UNIQUE

Le Single Sign-On est une technique qui consiste à soumettre l’utilisateur à une procédure

d’authentification unique et une seule fois par rapport aux différents services accessibles :

applications web ou fonctions protégées du système. Il peut aussi prononcer les autorisations

ou interdictions d’accès de l’utilisateur à l’ensemble des services, suivre l’activité et tracer les

opérations effectuées. Son architecture est en général basée sur un serveur d’authentification

(certificat X509, Kerberos). Il est composé :

D’un serveur d’authentification

C’est l’élément central du SSO puisqu’il assure :

L’authentification.

La persistance de la connexion.

La propagation de l’identité de l’utilisateur auprès des applications

Il a la charge de vérifier le mot de passe de l’utilisateur auprès d’une base de référence (NIS,

LDAP, /etc/passwd …).

De l’agent d’authentification

L’agent d’authentification est la brique SSO intégrée aux applications (librairie, module

apache). L’agent vérifie que l’utilisateur est authentifié. S’il n’est pas authentifié, il le redirige

vers le serveur d’authentification.

Figure 6 : principe d'authentification unique



1.4.3 LA DELEGATION D’IDENTITES

Le fournisseur d'identités permettra de déléguer l'identification des utilisateurs au sein

d’un fournisseur de services externe. L’utilisateur peut se connecter de n’ importe où et

pourquoi pas profiter d'un SSO.

Mais le gain ne porte pas uniquement sur une plus grande simplicité d'utilisation des

applications. Du point de vue de la sécurité, le fait de fédérer des applications autour d'une

architecture Web unique permet de profiter d'une sécurité accrue grâce au chiffrement SSL.

Lorsqu’un utilisateur A accède à un service A1, l’authentification est basée sur le

fournisseur d’identité A interne.

Lorsqu’ un utilisateur B externe à l’entreprise A accède à un service A2

l’authentification est basée sur le fournisseur d’identité B de son entreprise

Lorsqu’un utilisateur B accède à un service A2 externe à son entreprise et un service

B1 interne à son entreprise, les deux services s’appuient sur le fournisseur d’identité

de son entreprise. L’utilisateur B peut bénéficier ainsi d’un SS0 entre deux services.

Tous les mécanismes de fédération d’identités se basent sur le principe fondamental

d’existence d’une relation de confiance entre les partenaires qui ont décidé de collaborer.

.

Figure 7 : principe de la fédération d'identités


Chap. 2 : choix de la solution, conception et mise en œuvre LIRT 2011-2012

HAPITRE 2 : CHOIX DE LA SOLUTION, CONCEPTION

ET MISE OEUVRE

Introduction

Au fil des années, différentes solutions de SSO et fournisseur d’identité ont été mis en

œuvre. Si elles apportent satisfaction dans certains cas, certaines présentent aussi des

particularités qui peuvent nous pousser à les choisir pour construire un système en fonction de

nos besoins.

2.1 CHOIX DE LA SOLUTION

Dans de nombreux domaines, les applications Web pour entreprise ont su se rendre

incontournables. Plus rapide et moins coûteuses à déployer, avec une complexité

d'administration au niveau des infrastructures réseaux, ces applications permettent aussi de

simplifier, d'accélérer et d'amplifier les échanges entre l'entreprise et ses partenaires, clients

ou fournisseurs.

2.1.1 PRESENTATION DES SOLUTIONS

Il existe trois grandes classes d'approches pour la mise en œuvre des systèmes

d'authentification : les approches centralisées, les approches fédératives et les approches

coopératives. Derrière ces approches, on distingue des solutions libres telles que : OpenSSO,

SAML, CAS, Shibboleth, OpenID et Liberty Alliance.

3.1.1.1 LA SOLUTION OpenSSO/OpenAM

Portant le nom d’oracle OpenSSO en juillet 2008 puis le nom OpenAM depuis 2010,

c’est l’un des serveurs d’authentifications unique et de fédération complet de l’OpenSource.

2.1.1.2 LA SOLUTION SAML

SAML pour Security Assertion Markup Language permet entre autres la délégation

d’authentification et sert de fondation à deux autres normes, Shibboleth et Liberty Alliance.

2.1.1.3 LA SOLUTION CAS

C’est un service d'authentification centralisé SSO pour les applications Web, inspiré de

Kerberos et basé sur le protocole HTTP(S). CAS pour Central Authentication Service a été

C



développé par l'université de Yale aux Etats-Unis est un serveur d'authentification accessible

par WWW, composé de servlets java, qui fonctionne sur tout moteur de servlets (Tomcat par

exemple), ce qui fait ses points forts.

2.1.1.4 LA SOLUTION SHIBBOLETH

Shibboleth est développé depuis 2001 par Internet2 et désigne à la fois une norme et un

produit open source. C’est une extension de SAML qui enrichit ses fonctionnalités de

fédération d’identités, en facilitant pour un ensemble de partenaires la mise en place de deux

fonctionnalités importantes : la délégation d’authentification et la propagation d’attributs.

Shibboleth a été conçu pour répondre aux besoins des communautés de l’enseignement

supérieur et est déjà utilisé dans plusieurs pays : Etats-Unis, Angleterre, Suisse, France, etc…

2.1.1.5 LA SOLUTION OpenID

OpenID implémenté et utilisé par les sociétés clés de l'Internet (Yahoo, MySpace,

Google, Microsoft…), propose un protocole ouvert pour une gestion décentralisée d’identités,

mettant l'utilisateur au centre des décisions le concernant. OpenID est développé et supporté

par la fondation OpenId. Acteurs privés importants: Google, Yahoo, Microsoft et IBM.

2.1.1.6 LA SOLUTION LIBERTY ALLIANCE

Liberty Alliance, implémenté par IBM et utilisé par Sun et Novell, utilise des jetons

SAML. Ce modèle a été développé pour répondre à un besoin de gestion décentralisée des

utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de

sécurité, comme par exemple un ensemble de sites marchands indépendants d'un point de vue

commercial et organisationnel.

2.1.1.7 LES AUTRES SOLUTIONS

Aucune des sociétés de services internet vivant exclusivement de la publicité (payée par

des professionnels) n'est actuellement capable de vérifier et de garantir les données saisies par

les internautes. De plus chacune a développé son propre système d'authentification :

Yahoo avec Yahoo ID

Microsoft avec Live ID

Google avec Google Account

WS-Federation : Standard Web implémenté par Microsoft dans ses produits Active

Directory Federation

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

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

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

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

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



Sxipper

LemonLDAP:NG

2.1.2 LE CHOIX DE LA SOLUTION CAS-SHIBBOLETH

Les solutions d’authentification présentées ci-dessus nous ont permis de voir certaines

particularités ou certains avantages des unes par rapport aux autres. Pour répondre aux

exigences de notre système, les particularités impressionnantes des solutions CAS et

Shibboleth ne nous ont pas laissé seulement le choix de l’un d’entre eux. Nous avons donc

associé ces deux solutions et cela se justifie :

CAS est proposé comme mécanisme d’authentification centralisé de web SSO. Il ne traite pas

les besoins liés aux autorisations (droits applicatifs), ni aux fédérations d’identités et au

transport d'attributs. En outre, la base d’authentification est locale, au niveau de

l’établissement. Les aspects inter-établissements ne sont donc pas pris en compte.

Par contre, Shibboleth propose un mécanisme de transport d’attributs et d’authentification

inter-établissements. De récentes discussions autour de Shibboleth laissent entendre qu’un

mécanisme de SSO pourrait être proposé. Mais, Shibboleth à la possibilité de déléguer le SSO

à CAS.

CAS

CAS est en production dans plusieurs Universités américaines, avec des authentifications

internes Kerberos ou LDAP, ce qui permet d’être confiant sur sa fiabilité.

La sécurité est assurée par les dispositifs suivants : le mot de passe de l'utilisateur ne

circule qu'entre le navigateur client et le serveur d’authentification, nécessairement à

travers un canal crypté.

Des librairies clientes en Java, Perl, JSP, ASP, PL/SQL et PHP sont livrées. Cela

permet une grande souplesse sur les serveurs d'applications. L’intégration dans des

outils utilisés dans le monde universitaire est d’ores et déjà faite, comme celle

d’uPortal.

L'utilisation de cookies exclusivement privés dans CAS (passage de tickets entre

serveur d’authentification et applications uniquement sous forme de paramètres de

GET HTTP) permet à CAS d'être opérationnel sur des serveurs situés dans des

domaines DNS différents.

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

http://fr.wikipedia.org/wiki/LemonLDAP::NG



Un module Apache (mod_cas) permet d'utiliser CAS pour protéger l'accès à des

documents web statiques, les librairies clientes ne pouvant être utilisées dans ce cas.

Un module PAM (pam_cas) permet de « CAS-ifier » des services non web, tels que

FTP, IMAP, ...

SHIBBOLETH

Le Comité Réseau des Universités a retenu Shibboleth pour construire une infrastructure

de fédération d’identités pour l’enseignement supérieur français. Surtout la topologie d’une

fédération de type Shibboleth correspond bien à la structuration d’un ensemble

d’établissements de l’enseignement supérieur. De plus c’est un produit open source, soutenu

par une communauté active et ouverte.

Ouvrir l’accès à une ressource locale (thèses, cours en ligne) à d’autres

Etablissements

Gérer un intranet pour une population disséminée dans plusieurs établissements

On considère ici un groupe de personnes appartenant à différents établissements et amenés

à travailler ensemble, donc à partager des documents, des outils de travail collaboratif

(forums, wikis, gestionnaires d’enquêtes, autres outils métiers).

Gérer l’authentification pour des populations à la frontière de l’établissement

(anciens ou futurs étudiants)

Les applications de pré-inscription des étudiants ou d’enquêtes auprès des anciens étudiants,

concernent des populations qui ne sont pas encore ou plus gérées dans le système

d’information de l’établissement. On ne dispose donc pas de service d’authentification pour

ces utilisateurs qui ne rentrent pas forcément dans le moule (déjà complexe) des utilisateurs

(étudiants, chercheurs, enseignants, autres personnels…).

2.2 CONCEPTION

2.2.1 LE MECANISME DE CAS

2.2.1.1 ARCHITECTURE

L’architecture de CAS [1] tourne autour de trois principaux acteurs : le serveur CAS, le

client CAS et le navigateur.



Le serveur CAS

L'authentification est centralisée sur une machine unique (le serveur CAS). Ce serveur est

le seul acteur du mécanisme CAS à avoir connaissance des mots de passe des utilisateurs. Son

rôle est double : authentifier les utilisateurs et transmettre certifier l'identité de la personne

authentifiée (aux clients CAS) : c’est le serveur d’authentification.

Le client CAS

C’est l’agent d’authentification. Il peut être une application web munie d'une librairie

cliente ou un serveur web utilisant le module mod_cas. Il ne délivre les ressources qu'après

s’être assuré que le navigateur qui y accède se soit authentifié auprès du serveur CAS. Parmi

les clients CAS, on trouve : des librairies (Perl, Java, JSP, PHP, ASP), un module Apache et

un module PAM, qui permet d'authentifier les utilisateurs au niveau système.

Le navigateur

C’est l’élément disposant d'un moteur de chiffrement leur permettant d'utiliser le

protocole HTTPS. Il doit être capable savoir effectuer des redirections http, interpréter le

langage JavaScript et savoir stocker des cookies : Il représente l’utilisateur.

Ces exigences sont en général satisfaites par tous les navigateurs classiquement utilisés, à

savoir MicroSoft Internet Explorer (depuis 5.0), Netscape Navigator (depuis 4.7) et Mozilla.

2.2.1.2 FONCTIONNEMENT DE BASE

Un utilisateur non précédemment authentifié, ou dont l'authentification a expiré, et qui

accède au serveur CAS se voit proposer un formulaire d'authentification, dans lequel il est

invité à entrer son nom de connexion et son mot de passe.

Figure 8 : architecture du serveur CAS



Si les informations sont correctes, le serveur renvoie au navigateur un cookie appelé TGC

(Ticket Granting Cookie).

Le TGC est le passeport de l’utilisateur auprès du serveur CAS. Le TGC, à durée de vie

limitée (typiquement quelques heures), est le moyen pour les navigateurs d'obtenir auprès du

serveur CAS des tickets pour les clients CAS sans avoir à se ré-authentifier. C'est un cookie

privé (n'est jamais transmis à d'autres serveurs que le serveur CAS) et protégé (toutes les

requêtes des navigateurs vers le serveur CAS se font sous HTTPS).

2.2.1.3 ACCES A UNE RESSOURCE PROTEGEE APRES AUTHENTIFICATION

Lors de l'accès à une ressource protégée par un client CAS, celui-ci redirige le

navigateur vers le serveur CAS dans le but d'authentifier l'utilisateur (le navigateur),

précédemment authentifié auprès du serveur CAS et lui présente le TGC.

Redirection vers le serveurCAS

d'un navigateur non authentifié

auprès du client CAS

Redirection par le serveur CAS d'un

navigateur vers un client CAS après

authentification

Figure 9 : fonctionnement de base de CAS

Figure 10 : redirection transparente vers le serveur CAS



Sur présentation du TGC, le serveur CAS délivre au navigateur un Service Ticket (ST).

C’est un ticket opaque, qui ne transporte aucune information personnelle. Il n’est utilisable

que par le « service » (l'URL) qui en a fait la demande. Dans le même temps, il le redirige

vers le service demandeur en passant le Service Ticket en paramètre.

Le Service Ticket est alors validé auprès du serveur CAS par le client CAS, directement en

http, et la ressource peut être délivrée au navigateur.

Il est à noter que toutes les redirections présentées sont complètement transparentes pour

l’utilisateur. Celui-ci ne voit pas les redirections et a l'impression d'accéder directement à la

ressource désirée, sans authentification.

Un navigateur ne sachant pas effectuer les redirections ou n'interprétant pas le langage

JavaScript forcera l'utilisateur à effectuer un clic à chaque redirection (qui ne sera alors plus

transparente). Un navigateur ne stockant pas les cookies forcera l'utilisateur à entrer ses

informations d'authentification à chaque passage par le serveur d'authentification.

2.2.1.4 ACCES A UNE RESSOURCE PROTEGEE SANS AUTHENTIFICATION

PREALABLE

Si l’utilisateur n'est pas déjà authentifié auprès du serveur CAS avant d'accéder à une

ressource, son navigateur est, comme précédemment, redirigé vers le serveur CAS, qui lui

propose alors un formulaire d'authentification.

Lors de la soumission du formulaire par le navigateur au serveur CAS, si les informations

fournies sont correctes, le serveur CAS :

- délivre un TGC (Ticket Granting Cookie) au client, qui lui permettra ultérieurement de ne

pas avoir à se ré-authentifier

Figure 11 : validation pour l'accès à une ressource



- délivre au client un Service Ticket à destination du client CAS

- redirige le client vers le client CAS

2.2.1.5 PRINCIPE DE MANDAT AVEC CAS

Dans le fonctionnement de base, le client CAS est toujours en lien direct avec le

navigateur. Dans un fonctionnement n-tiers, le navigateur accède à un client CAS à travers un

mandataire CAS. Le mécanisme de redirection vu dans le fonctionnement de base n'est alors

plus applicable.

Fonctionnement 2-tiers

Un mandataire CAS, lorsqu'il valide un Service Ticket pour authentifier un utilisateur,

effectue, dans le même temps, une demande de PGT (Proxy Granting Ticket).

Le PGT est le passeport d’un mandataire CAS, pour un utilisateur, auprès du serveur CAS.

Récupération d'un PGT par

un mandataire CAS auprès

du serveur CAS

Validation d'un PT

par un client CAS

accédé par un

mandataire CAS

Figure 12 : accès à l'application sans authentification

Figure 13 : validation du PT pour l'accès à une ressource



Fonctionnement n-tiers

On voit aisément que le client CAS accédé par le mandataire CAS du fonctionnement 2-

tiers peut également être mandataire à son tour. Les mandataires peuvent ainsi être chaînés.

CAS est à notre connaissance, le seul mécanisme de SSO proposant un tel fonctionnement

multi-tiers sans aucune propagation de mot de passe.

CAS permet l'implémentation de plusieurs méthodes d'authentification plus ou moins

traditionnelles : annuaires LDAP, bases de données, domaines NIS, et fichiers. Cette classe

peut être aisément étendue à d'autres méthodes d'authentification, selon les besoins des

administrateurs de sites (Novell, Kerberos, Active Directory, ...)

2.2.2 LE MECANISME DE SHIBBOLETH

L’objectif est de montrer les interactions entre les acteurs du système qui permettent la

délégation de l’authentification et la propagation des attributs utilisateurs. Afin de mieux

appréhender un fonctionnement globalement complexe, nous présentons d’abord les acteurs

du système, puis détaillons les interactions entre les acteurs du système lors de l’accès par un

navigateur à une ressource web.

2.2.2.1 ARCHITECTURE

Le navigateur

Le premier acteur de l’architecture Shibboleth [2] est donc logiquement le navigateur

de l’utilisateur. Le navigateur doit répondre aux exigences habituelles en matière de

navigation web, notamment l’interprétation des codes de retour HTTP (redirections), ainsi que

l’acceptation et la transmission des cookies selon les normes en vigueur.

Le fournisseur de services (Service Provider ou SP)

Figure 14 : CAS dans l'architecture n-tiers



C’est une entité proposant des ressources web sur la base d’un contexte de sécurité SAML et

sera par la suite nommée SP (Service Provider). Le fournisseur de ressource a en particulier la

charge de donner ou non l’accès aux ressources, en fonction des attributs utilisateur.

Le fournisseur d’identités (Identity Provider ou IdP)

C’est une entité authentifiant les utilisateurs et fournissant leurs attributs. Elle sera par la

suite notée IdP. Le fournisseur d’identités s’appuie sur le SI de l’établissement, tant pour

l’authentification que pour la récupération des attributs utilisateur à propager. De ce fait, il est

en général situé au plus proche du SI.

Le WAYF

Le WAYF (pour Where Are You From?, « d’où êtes-vous ? ») est un service dont le but est d’orienter

l’utilisateur vers son IdP.

Seul l’objectif du WAYF est défini dans les spécifications de Shibboleth :

– Proposer aux utilisateurs une liste d’IdP, parmi lesquels les utilisateurs sont invités à

sélectionner celui de leur établissement de rattachement ;

– Une fois le choix effectué, il redirige les utilisateurs vers l’IdP correspondant à leur choix.

L’architecture d’une offre applicative d’un établissement dont l’authentification est confiée à

Shibboleth sera donc souvent celle décrite par la figure :

Figure 15 : fonctionnement du WAYF



2.2.2.2 FONCTIONNEMENT DE SHIBBOLETH SANS CAS

Dans ce premier cas d’étude, nous considérons que le SP connaît l’établissement de

rattachement de l’utilisateur, c’est-à-dire l’établissement qui pourra l’authentifier. Le

navigateur effectue donc une requête HTTP vers le SP afin d’accéder à une ressource et le

SP, sans information d’authentification, le redirige vers l’IdP de l’établissement de

rattachement de l’utilisateur.

La réponse de l’IdP est une demande d’authentification, sous la forme d’une erreur 401

Unauthorized ou d’un formulaire web. L’utilisateur entre alors son identifiant et son mot de

passe. Une fois authentifié, l’IdP redirige alors le navigateur vers le SP, accompagné d’une assertion

SAML. Cette assertion signée par l’IdP, le SP pourra donc faire confiance à l’assertion. Elle contient

un identifiant appelé nameIdentifier.

Cet identifiant est opaque, c’est-à-dire qu’il ne contient pas d’information personnelle

concernant l’utilisateur. Il n’est utilisé que dans le cadre des échanges entre les différentes

briques de Shibboleth, et n’est connu ni de la ressource accédée ni du SI de l’établissement.

Un exemple de nameIdentifier est montré ci-dessous.

Figure 16 : requête du navigateur vers le fournisseur de service

Figure 17 : redirection de l'IdP vers le SP



<saml:NameIdentifier

Format="urn:mace:shibboleth:1.0:nameIdentifier"

NameQualifier="https://idp.iut-fv.cm/shibboleth">

3f7b3dcf-1674-4ecd-92c8-1544f346baf8

</saml:NameIdentifier>

C’est cet identifiant opaque qui va permettre au SP de récupérer les attributs de l’utilisateur

auprès de l’IdP. Ces attributs de l’utilisateur sont transmis au SP par l’IdP, via l’appel d’un

Web Service, l’échange du nameIdentifier.

Le SP peut alors effectuer le contrôle d’accès, éventuellement utiliser les attributs de l’utilisateur dans

la logique applicative, puis retourner une réponse au navigateur.

Architecture logique du fournisseur de services (SP)

Le fournisseur de services est composé de trois briques logicielles :

– Le consommateur d’assertions (Assertion Consumer Service),

– Le demandeur d’attributs (Attribute Requester),

– Le contrôleur d’accès.

Figure 18 : le SP demande les attributs de l’utilisateur

Figure 19 : réponse du SP au navigateur



Le consommateur d’assertions agit comme un pré-filtre. C’est lui qui redirige vers l’IdP

lorsque l’utilisateur n’est pas authentifié. Il peut être implémenté au niveau du serveur HTTP

(par un module Apache ou un filtre J2EE par exemple). Lorsque l’utilisateur est authentifié,

alors le consommateur d’assertions transmet le nameIdentifier au demandeur d’attributs.

Le demandeur d’attributs est chargé de la récupération des attributs des utilisateurs auprès

de l’IdP. Il peut être implémenté comme un démon (dédié, interrogeable par les processus du

SP) ou par une librairie, interrogeable par un applicatif web. Les attributs récupérés par le

demandeur d’attributs sont fournis au contrôleur d’accès.

Le contrôleur d’accès est chargé d’autoriser ou non l’accès aux ressources demandées. Il

peut être implémenté au niveau du serveur HTTP (par un module Apache ou un filtre J2EE

par exemple) ou encore par une librairie, appelée par un applicatif web.

Architecture logique du fournisseur d’identités (IdP)

Un fournisseur d’identités est composé de trois briques logicielles :

– Le service d’authentification (Authentication Service),

– L’autorité d’authentification (Authentication Authority),

– L’autorité d’attributs (Attribute Authrority).

Le service d’authentification est chargé de l’authentification des utilisateurs vis-à-vis de

l’ensemble de l’IdP. C’est lui qui, par exemple, demande à l’utilisateur un couple

user/password, puis le valide auprès de la base d’authentification du SI. Les implémentations

du service d’authentification peuvent être très variées, depuis un module Apache authentifiant

les utilisateurs auprès d’un annuaire LDAP, jusqu’à un client de Single Sign-On comme nous

le verrons ultérieurement.

L’autorité d’authentification associe le nameIdentifier à l’identifiant de l’utilisateur.

L’autorité d’attributs délivre, en réponse à une demande d’un SP, les attributs de

l’utilisateur correspondant à un nameIdentifier. L’association entre l’identifiant de l’utilisateur

et le nameIdentifier étant maintenue par l’autorité d’authentification.



Figure 20 : fonctionnement de Shibboleth sans CAS

2.2.2.3 FONCTIONNEMENT DE SHIBBOLETH AVEC SSO

Dans le modèle de CAS, l’authentification n’est pas directement prise en charge par le

service d’authentification de l’IdP. Celui-ci ne fait que rediriger le navigateur vers le serveur

de SSO, qui renvoie alors à l’utilisateur un formulaire d’authentification.

Une fois le formulaire remplit, le navigateur effectue une nouvelle requête vers le serveur

SSO, qui le redirige vers l’IdP. Le service d’authentification de l’IdP, client SSO, effectue

alors une nouvelle redirection vers le SP et l’authentification se déroule ensuite comme vu

précédemment.

Figure 21 : redirection du navigateur vers le serveur de SSO



.

Requêtes suivantes au même SP

Comme vu précédemment, une session étant mise en place entre le navigateur et le SP, ni

l’IdP ni le serveur SSO n’interviennent par la suite pour l’accès au même SP.

Requêtes suivantes vers un autre SP

Lorsque l’utilisateur est déjà authentifié auprès du serveur SSO, le navigateur dispose d’un

identificateur de session (par exemple un TGC pour CAS) qui lui permet de ne pas avoir à

s’authentifier à nouveau.

Figure 22 : fonctionnement de Shibboleth avec SSO

Figure 23 : requete suivant le meme SP



2.2.2.4 FONCTIONNEMENT DE SHIBBOLETH DANS UNE FEDERATION

Considérons le cas où un SP est accessible à des utilisateurs rattachés à des

établissements différents. C’est par exemple le cas d’une université souhaitant mettre à

disposition de tous les personnels de l’enseignement supérieur de sa région les archives de ses

thèses et publications scientifiques.

Le problème qui se pose alors est que le SP ne sait pas vers quel IdP rediriger le navigateur

pour l’authentification. Il est résolu grâce au WAYF, dont le rôle est d’orienter les utilisateurs

pour sélectionner leur IdP.

Première requête vers un SP

Lors de la première requête au SP, celui-ci ne sachant pas quel IdP sera utilisé, le SP redirige

le navigateur vers le WAYF.

Figure 24 : délégation d'authentification vers un autre SP

Figure 25 : redirection transparente vers le WAYF



Le WAYF affiche alors à l’utilisateur alors une liste d’IdP possibles. La requête suivante, vers

le WAYF, redirige le navigateur vers l’IdP choisi par l’utilisateur, qui à son tour redirige le

navigateur vers le serveur SSO, qui propose alors un formulaire d’authentification.

Le navigateur s’authentifie alors auprès du serveur SSO, et l’authentification se déroule

ensuite comme vu précédemment.

Requêtes suivantes vers le même SP

Figure 26 : redirection du WAYF vers le serveur de SSO

Figure 27 : réponse du SP après authentification du serveur SSO



Comme vu précédemment, une session étant mise en place entre le navigateur et le SP, ni le

WAYF, ni l’IdP ni le serveur SSO n’interviennent par la suite pour l’accès au même SP.

Requêtes suivantes vers un autre SP

Lors du choix de l’IdP par l’utilisateur, il est possible pour le WAYF de mémoriser ce choix

dans le navigateur (à l’aide d’un cookie). Dans ce cas, le WAYF peut utiliser ultérieurement

cette information, et faire en sorte que les requêtes suivantes soient non bloquantes (en

redirigeant automatiquement vers l’IdP choisi la première fois). La figure montre comment,

dans ce cas, l’authentification de l’utilisateur est totalement transparente lors de l’accès à un

autre SP.

Figure 28 : réponse du SP sans authentification

Figure 29 : le WAYF en action dans une fédération



2.3 MISE EN OEUVRE

Une fois la méthodologie du travail décrite, il ne nous reste plus qu’à mettre sur pied

notre système. Ainsi, dans ce paragraphe, il est question de présenter étape par étape le travail

effectué et d’accompagner ces différentes étapes par des résultats qui, seront présentés par des

captures d’écran.

2.3.1 PRESENTATION DE L’INTRANET

L'intranet est la partie sécurisée de notre réseau informatique basé sur les mêmes

technologies qu’Internet (protocoles de communication TCP/IP). L'intranet est connecté au

réseau Internet pour permettre la communication avec le monde extérieur.

En effet, notre intranet peut être constitué de plusieurs serveurs parmi lesquels on peut citer :

Le contrôleur de domaine (samba)

Le serveur web

Le serveur DNS

Le serveur DHCP

L’annuaire LDAP

Le serveur de SSO (CAS)

Le serveur de fourniture d’identités ou de SSO (Shibboleth)

Nous ne devons pas nous attarder sur la présentation de la configuration de tous ces serveurs

car, le plus important ici ce sont les serveurs SSO et le fournisseur d’identités [3]. Nous avons

choisi « iut-fv.cm » comme domaine.

L’architecture simplifiée se présente comme suit :



2.3.2 CENTRALISATION DE L’AUTHENTIFICATION

Installation de l’annuaire LDAP

LDAP (Lightweight Directory Access Protocol) [4] représente la norme des systèmes

d'annuaires, incluant un modèle de données, un modèle de nommage, un modèle

fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de

réplication.

Afin d'installer tout ce dont nous avons besoin nous allons exécuter une seule commande

dans le serveur Debian rassemblant tous les programmes.

Le paquet “slapd” installe le serveur OpenLDAP. Il contient avant tout le démon

qui permet de démarrer/arrêter/redémarrer le serveur OpenLDAP.

Le paquet “ldap-utils” contient les commandes dites clientes qui permettent à

l'utilisateur d'interagir avec l'annuaire LDAP.

Le paquet “apache2” installe le serveur HTTP. Nous n'allons pas nous attarder

sur tous les fichiers que le paquet apache installe. Le module PROXY ou encore le

module SSL pour utiliser le protocole HTTPS.

Les paquets “php5” et "php5-ldap" sont nécessaires au fonctionnement de

PhpLDAPAdmin puisque cette application est écrite en PHP.

Le paquet PhpLDAPAdmin est une interface accessible par internet écrite en PHP

#apt-get install slapd ldap-utils apache2 php5 php5-gd php5-ldap phpldapadmin

Figure 30 : architecture du système



et qui permet d'administrer un annuaire LDAP à distance et de manière sécurisée avec le

protocole HTTPS. Il est tout à fait possible d'utiliser des logiciels comme jXplorer (écrit en

JAVA) pour se connecter et administrer l'annuaire LDAP seulement cela nécessite

l'installation du logiciel sur la machine cliente. D'où le choix d'une administration par le web.

Pour terminer l'installation, il suffit de répondre aux questions posées par le système pour la

configuration du demon slapd.

Faut il omettre la configuration d’OpenLDAP ? Non

Nom de domaine : iut-fv.cm

Nom de votre organisation : iut-fv

Mot de passe administrateur : ********

Faut-il autoriser le protocole LDAPv2 : Non

Pour la configuration de phpldapadmin :

Adresse du serveur LDAP : 127.0.0.1 (si votre annuaire est sur un autre serveur donnez lui son adresse

bien sûr)

Faut-il gérer le protocole LDAPS : non

Nom distinctif de la base de recherche : dc=iut-fv, dc=cm

Type d’authentification : session (vous avez le choix entre session, cookie, config)

Identifiant dn de connexion au serveur LDAP : cn=admin, dc=iut-fv, dc=cm

Serveur web à reconfigurer automatiquement : apache2 (vous avez le choix entre apache, apache-ssl,

apache-perl et apache2).

Faut-il redémarrer le serveur web : oui

Attention : Dans la nouvelle version d’openldap dans debian 6.0.1, le fichier slapd.conf

n’existe plus il est remplacé par le répertoire /slapd.d.

Configuration du contrôleur de domaine avec SAMBA

Nous allons maintenant installer le serveur samba.

La librairie libnss-ldap permettant d’utiliser l’annuaire et la librairie libpam-ldap permettant

de s’authentifier sous Unix. Cette configuration est très longue et nous n’allons pas nous

attardé sur cette dernière.

Joindre le serveur SAMBA à l’annuaire

LDAP fonctionne avec des schémas, par défaut 4 schémas sont déjà présents, pour utiliser

samba avec LDAP il faut le schéma approprié. Celui-ci se trouve dans le paquet samba-doc.

#apt-get install samba-doc samba smbclient smbfs smbldap-tools libnss-ldap libpam-ldap



Il reste maintenant à éditer le fichier de configuration du serveur OpenLDAP :

/etc/ldap/slapd.conf

2.3.3 CONFIGURATION DES SERVEURS

Nous rappelons ici que nos serveurs sont partagés différentes plate forme : serveur 1

(DNS+LDAP+samba), le serveur 2 (Shibboleth) et le serveur 3 (CAS). Le serveur 1 est déjà

configuré à ce niveau. Nous pouvons passer au serveur 2 ensuite, le serveur 3 sera suivit.

2.3.3.1 INSTALLATIONS

Installation du paquet java 6 JDK-JRE

Java 6 JDK sera installé vers le chemin /usr/lib/jvm/java-6-openjdk. Pour éviter les confilts

avec un autre serveur de machine virtuelle comme gcj. Désinstaller simplement gcj. Inclure

les lignes suivantes dans /etc/profile (vérifier avec la commande : java –version).

Exécutons les commandes suivantes pour définir la variable JAVA_OPTS pour assurer à

l'exécution de la JVM, de Tomcat et de la servlet IdP. Il est conseillé d'allouer au moins

512Mo de mémoire à la servlet IdP.

Installation du serveur Tomcat

include /etc/ldap/schema/core.schema

include /etc/ldap/schema/cosine.schema

include /etc/ldap/schema/nis.schema

include /etc/ldap/schema/inetorgperson.schema

include /etc/ldap/schema/samba.schema

#apt-get openjdk-6-jre-headless

# export JAVA_HOME=/usr/java/latest/

# export JAVA_OPTS="-Xmx1000m -XX:MaxPermSize=512m"

JAVA_HOME=/usr/lib/jvm/java-6-openjdk

export JAVA_HOME



Apache Tomcat est un serveur d'applications JAVA. C’est lui qui exécutera la brique

Shibboleth IdP. Apache Tomcat 6.0.17 ou plus avancé est la version exigée pour démarrer le

fournisseur d’identités.

Pour allouer à la JVM une mémoire maximale de 512MBytes et de 128MBytes autorisée,

Dans le fichier /etc/default/tomcat6, modifions la variable java_OPTS pour ceci :

Installation de l’IdP Shibboleth

Shibboleth est disponible au site : http://shibboleth.internet2.edu/downloads/shibboleth/idp/

Les deux dernières lignes de copier les bibliothèques xml de Shibboleth dans la variable

$CATALINA_HOME/endorsed sachant que $CATALINA_HOME=/opt/tomcat. Pour utiliser

MyQL JDBC pour la sauvegarde, téléchargeons le dans le site dev.mysql.com.

Démarrons l’installation de Shibboleth avec un certificat de trois ans signé par Idp.

#cd /usr/local/src

#unzip mysql-connector-java-5.1.22.zip mysql-connector-java-5.1.15/mysql-connector-java-

5.1.22-bin.jar

#mv mysql-connector-java-5.1.22/mysql-connector-java-5.1.15-bin.jar \

/opt/shibboleth-identityprovider-2.3.8/lib/

#apt-get install tomcat6

JAVA_OPTS="-Djava.awt.headless=true -Xmx512M -XX:MaxPermSize=128M -

Dcom.sun.security.enableCRLDP=true"

#curl –O http://shibboleth.internet2.edu/downloads/shibboleth/idp/2.3.8/shibboleth-identityprovider-2.2.1-bin.zip

#cd /usr/local/src

#unzip –xf /usr/local/src/shibboleth-identityprovider-2.3.8-bin.zip

#cd shibboleth-identityprovider-2.3.8

#chmod u+x install.sh

#cd /usr/local/src/shibboleth-identityprovider-2.3.8

#mkdir /usr/share/tomcat6/endorsed/

#cp ./endorsed/*.jar /usr/share/tomcat6/endorsed/

#cd /usr/local/src/shibboleth-identityprovider-2.3.8/

#env IdPCertLifetime=3 ./install.sh

Déplaçons les annuaires de configuration de Shibbolet. Donnons la variable

d’environnement dans le fichier /etc/profile.

Créons le répertoire pour la description de l’IdP :

Installation de MySQL Server

Installons la version 5.1 disponible dans debian6 (annexe 1)

Installation CAS server

Il s’agit ici du server de SSO [5] :

La suite de la configuration de CAS a été faite grâce au fichier à l’adresse :

http://www.artduweb.com/tutoriels/cas-sso

#ln -s /opt/shibboleth-idp/conf /etc/shibboleth

#ln -s /opt/shibboleth-idp/logs /var/log/shibboleth

#export IDP_HOME=/opt/shibboleth-idp

#cd /etc/tomcat6

#mkdir -p Catalina/localhost

#vim etc/tomcat6/Catalina/localhost/idp.xml

<Context

docBase="/opt/shibboleth-idp/war/idp.war"

privileged="true"

antiResourceLocking="false"

antiJARLocking="false"

unpackWAR="false"

swallowOutput="true"

cookies="false" />

#wget http://downloads.jasig.org/cas/cas-server-3.4.11-release.tar.gz

#tar xvzf cas-server-3.4.11-release.tar.gz

#more cas-server-3.4.11/INSTALL.txt

#cd cas-server-3.4.11/cas-server-webapp

vi pom.xml



<dependency>

<groupId>${project.groupId}</groupId>

<artifactId>cas-server-support-ldap</artifactId>

<version>${project.version}</version>

</dependency>



2.3.3.2 CONFIGURATION DU SERVEUR IdP SHIBBOLETH

La configuration de l’idp Schibboleth [6] se fait en plusieurs étapes :

Création des certificats

Configuration d’apache

La génération du certificat nous devons éditer le fichier ssl.conf. Ajoutons les lignes

suivantes pour que Apache utilise ces éléments.

Apache sera configuré avec le module mod_ssl supportant SSL et le module mod_proxy_ajp

pour rediriger les requêtes à Tomcat. Obtenir un certificat de SWITCHpki à l’adresse :

www.switch.ch/quovadis/quvsslica.crt.pem.

Améliorons le degré de sécurité de notre serveur, ajoutons dans de directive

/etc/apache2/conf.d/security.

#openssl genrsa -out pcserver.iut-fv.cm.key 1024

#openssl req -new -x509 -days 365 -key pcserver.iut-fv.cm.key -out pcserver.iut-fv.cm.crt

SSLCertificateFile / etc/pki/tls/certs/pcserver .iut-fv.cm.crt

SSLCertificateKeyFile / etc/pki/tls/private/pcserver.iut-fv.cm.key

#cp pcserver.iut-fv.cm.key /etc/ssl/private/

#cp pcserver.iut-fv.cm.crt /etc/ssl/certs/

#mv qvsslica.crt.pem /etc/ssl/certs/

ServerTokens Prod

http://www.switch.ch/quovadis/quvsslica.crt.pem

Le fichier de configuration /etc/apache2/site-availabe/pcserver sera présenté en annexe 2.

Ensuite survient l’activation de l’host virtuel, l’activation du module SSL et l’activation du

module proxy ajp.

Configuration du module JAAS pour l’authentification des utilisateurs

Il faut configurer l'authentification pour Shibboleth IdP avec le module JAAS.

http://docs.oracle.com/javase/1.5.0/docs/guide/security/jaas/JAASRefGuide.html

Configurons JAAS in /opt/shibboleth-idp/conf/login.config avec VTLdap pour LDAPS.

Configuration de tomcat

Dans /etc/tomcat6/server.xml, configurons le connecteur AJP 1.3 au port 8009:

Configuration de l’IdP

Les qualifications employées par Shibboleth IdP sont dans /opt/shibboleth-

idp/credentials/annuaire. L'installateur produit d'un certificat individuel signé qui sera

employé dans la fédération de SWITCHaai. Le certificat est également inclus dans le

metadata de l'IdP dans le dossier/opt/shibboleth-idp/metadata/idp-metadata.xml. Toutes les

fois que les qualifications de l'IdP sont changées, ce dossier doit être aussi bien changé. Etant

donné que nous ne faisons pas partie de la fédération SWITCHaai, nous préparons l’IdP pour

une fédération.

ShibUserPassAuth {

// Example LDAP authentication

edu.vt.middleware.ldap.jaas.LdapLoginModule required

ldapUrl="ldaps://ldap.iut-fv.cm"

baseDn="ou=people,dc=iut-fv,dc=cm"

bindDn="cn=idp-user,dc=iut-fv,dc=cm"

bindCredential="password for idp-user";

};



<Connector port="8009" address="127.0.0.1"

enableLookups="false" redirectPort="443"

protocol="AJP/1.3"

tomcatAuthentication="false" />



Le dossier spécifique de SWITCHaai relying-party.xml [7] peut être téléchargé comme

calibre pour l’installation.

Ce fichier de configuration est présenté en annexe 3.

Résolution d'attribut et de filtrage

Téléchargons le dossier spécifique attribute-resolver.xml de configuration de SWITCHaai et

l'adapter.

Le fichier /opt/shibboleth-idp/conf/attribute-resolver.xml se présente en annexe 4.

Redéployons l'application Shibboleth IdP. Tomcat rechargera l'application d'enchaînement à

condition que le descripteur de contexte se dirige au dossier/opt/shibboleth-idp/war/idp.war.

répondez no à la question Would you like to overwrite this Shibboleth configuration? Après le

redémarrage de Tomcat, vous pourrez vérifier que l'application Shibboleth a correctement

démarrée.

Conclusion

La fédération d’identités vise justement à simplifier la gestion des identités dans un

contexte distribué entre plusieurs entreprises.

Si on caricature le fonctionnement d’une fédération d’identité, on peut imaginer un douanier

qui ne fait pas forcément confiance à une personne lui présentant son passeport. Néanmoins

notre douanier aura confiance au gouvernement qui a délivré le passeport. Ainsi notre

individu est authentifié par son gouvernement et présente la preuve de son authentification au

douanier qui le laisse alors franchir la douane.

#cd /opt/shibboleth-idp/credentials

#chown root idp.key

#chgrp tomcat6 idp.{key,crt}

#chmod 440 idp.key

#chmod 644 idp.crt

#cd /opt/shibboleth-idp/conf/

#mv relying-party.xml relying-party.xml.orig

#curl -Ok https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying-

party.xml

#vim /opt/shibboleth-idp/metadata/metadata.aaitest.xml

#cd /opt/shibboleth-idp/conf/

#curl -Ok https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/attribute-

resolver.xml

https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying-party.xml

https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying-party.xml


Chap. 3 : résultats obtenus et perspectives LIRT 2011-2012

HAPITRE 3 : RESULTATS OBTENUS ET PERSPECTIVES

Introduction

Ce système implémenté est une préparation de l’IUT-FV de bandjoun pour joindre une

fédération d’identités future grâce à l’IdP shibboleth. Le serveur de SSO est un agent

d’authentification délégué par l’IdP pour favoriser les accès aux services.

3.1 RESULTATS OBTENUS

Voici le résultat de la création d’un arbre de base au sein de l’annuaire LDAP du contrôleur

de domaine SAMBA pour la centralisation de l’authentification.

Visualisation des entrées au sein de l’annuaire LDAP dans le domaine iut-fv.cm

C



Recherche de la reference au sein de l’annuaire Active directory

Vérification des tables dans la base de donnée Shibboleth



Vérification du fonctionnement de Shibboleth

Serveur Shibboleth déployé

Page d’accueil pour l’authentification Shibboleth



Page d’authentification du serveur CAS pour le service de SSO

Authentification réussie

3.2 PERSPECTIVES

Malgré tous les efforts qui ont été fait, les problèmes de sécurité et de fonction restent des

challenges qui suscitent des efforts. Mais, nous avons bien découvert ces problèmes et trouvé

des solutions qui ne sont pas du tout facile à mettre en œuvre.

Dans paragraphe, nous présentons les améliorations à venir pour compléter ce projet surtout

dans le domaine de la sécurité. Ces améliorations n’ont pas été réalisées pour des raisons de

temps et de moyens matériels.



3.2.1 AUTHENTIFICATION FORTE

Parmi les perspectives ouvertes à ce projet, l’utilisation des méthodes d’authentification

pour « ce que je possède » et « ce que je suis » ou la combinaison de ces deux sont des

assurances que l’utilisateur est bien celui qui prétend être.

Ce projet à besoin d’un système d'authentification forte permettant de sécuriser les accès aux

ressources internes depuis un réseau non sécurisé comme Internet.

3.2.1.1 L’OTP

L’OTP sera un avantage pour nous parce que chaque individu possède une ligne GSM

propre à lui pour utiliser la carte SIM comme un deuxième facteur d'authentification.

Il permet d'assurer l'authenticité des utilisateurs en vérifiant la validité de leur code PIN et la

possession de leur téléphone portable.

A part son serveur d'authentification, le système doit comporter un logiciel d'administration

permettant la gestion, la visualisation des fichiers d'historique et la supervision en temps réel.

L’application Open source « Linotp » est un serveur capable de faire cela mais la difficulté de

l’intégrer ou de la synchroniser avec notre solution CAS-Shibboleth a été remarquée.

Aujourd'hui, avec l'arrivée des techniques d'authentification forte, la sécurité n'est plus un

frein pour des solutions de mobilité.

3.2.1.2 AUTHENTIFICATION BIOMETRIQUE

L'avantage principal de ce qu'on appelle "mot de passe biométrique" est lié au fait qu'il

ne pourrait pas être volé, oublié ou transmis à une autre personne. En effet, chaque membre de

la population possède sa propre caractéristique biométrique, et elle est relativement stable.

Figure 31 : principe de l'OTP



Malheureusement pour nous, shibboleth dans sa version utilisée ne prend pas par défaut

l’authentification biométrique. Cela ne veut pas dire que l’authentification biométrique est

impossible pour la solution CAS-Shibboleth. Il suffit du temps pour une conception. Mais

OpenSSO est une solution qui prend par défaut l’identification par empreinte digital grâce au

logiciel Biobex. Malheureusement, nous avons constaté que le logiciel Biobex n’est plus

disponible.

3.2.2 UNE FEDERATION D’IDENTITES FONCTIONNELLE

Une fédération est simplement « un regroupement de fournisseurs de services et de

fournisseurs d’identités ». La mise en place d’un test de l’IdP auprès de RENATER et de

notre propre fédération fonctionnelle soulève en effet d’autres ressources que nous n’avons

pas en notre disposition.

Le problème est de mettre sur pied une fédération de huit universités d’état du pays y compris

les universités et les instituts privés. Comme dans le cadre académique, RENATER, Esup-

Portail et SWITCHaai sont des fédérations qui simplifient et sécurisent les connexions à leurs

sites web dont l'accès est contrôlé : plate-forme d'enseignement à distance, portail

documentaire, application métier, etc. La fédération répond bien aux besoins de mutualisation

entre organismes, aux problématiques de nomadisme et facilite le respect de la loi

“Informatique et libertés”.

Conclusion

Comme le SSO donne accès à de nombreuses ressources, une fois l'utilisateur authentifié,

il a les "clés du château". Les pertes peuvent être lourdes si une personne mal intentionnée a

accès à des informations d'identification des utilisateurs. Avec le SSO, une attention

particulière doit donc être prêtée à ces informations, et des méthodes d'authentification forte

devraient idéalement être combinées.


Conclusion générale LIRT 2011-2012

Conclusion générale

Parvenue au terme de ce projet, nous pouvons affirmer qu’il nous a non seulement permis

de mieux nous familiariser avec les réalités du monde professionnel, aussi de mettre en

pratique nos compétences en découvrant de nombreuses plates formes dans le domaine des

réseaux informatiques.

Nous n’avons pas vite remarqué les difficultés en terme de ressource pour la réalisation de

ce projet car cela a engendré beaucoup de temps.

A la première étape (indispensable), il fallait implémenter un contrôleur de domaine avec le

serveur SAMBA, le synchroniser avec l’annuaire LDAP et ensuite gérer la centralisation de

l’authentification avec ce dernier. En effet, plusieurs solutions ont été parcourues en fonction

des systèmes d’exploitation Linux à la recherche du succès et la solution Shibboleth-CAS a

été favorable même si les documentations et la compréhension n’étaient pas évidentes.

La mise sur pied d’un fournisseur d’identités conduit à une fédération d’identités. De nos

jours, nous rencontrons beaucoup d’entreprises qui forment un domaine de confiance en

disposant chacun d’un fournisseur d’identités (exemple fecebook-netlog, facebook-twitter)

certains encordent même le SSO (exemple facebook-yahoo). Mais, la fédération d’identités

est manifestée par un portail et est faite pour des services de l’enseignement supérieur.

Nous espérons qu’un pays émergent comme le notre convergera vers ce système dans les

moments à venir surtout dans le secteur éducatif (enseignement supérieur) et bien d’autres.


Bibliographie LIRT 2011-2012

Bibliographie

Sites internet visités

[1] http://www.gsefr.org/open-source/documents/prives/GuideShare%20-

%20Presentation%20SSO.odp , CAS serveur de SSO, visité le 2 mai 2013.

[2] http://2005.jres.org/tutoriel/shibboleth-jres2005-article.pdf, explication du fonctionnement

de Shibboleth, visité le 2 avril 2013.

[3] http://www.arismore.fr/wp-content/uploads/F%C3%A9d%C3%A9ration-

Identit%C3%A9s_F.JAN-Arismore.pdf, les fournisseurs d’identités, visité le 2 avril 2013.

[4] http://monblog.system-linux.net/blog/2008/11/04/creer-un-controleur-principal-de-

domaine-avec-samba-et-un-annuaire-ldap/, configuration de ldap, visité le 2 avril 2013.

[5] http://www.artduweb.com/export/xhtml/tutoriels/cas-sso, configuration de cas sso, visité

le 6 mai 2013.

[6] https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/install-idp-2.3-debian.html,

installation de l’idp shibboleth, visité le 23 avril 2013.

[7] https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying-

party.xml, fichier de configuration relying-party, visité le 6 mai 2013.

Documents

[8] Olivier Salaün, Florent Guilleux, Pascal Aubry, Fédération d'identités et propagation

d'attributs avec Shibboleth. http://www.google.cm/url?q=http://perso.univ-

rennes1.fr/pascal.aubry/sites/default/files/shibboleth-jres2005-

article.pdf&sa=U&ei=yBHkUc2bHsSv0QXXvoH4DQ&ved=0CBkQFjAA&usg=AFQjCNG

xhZYGEFAHuPYH82Kvtur29Rz1xA

[9] Vincent Mathieu, Pascal Aubry, Julien Marchal, Single Sign-On open-source avec CAS

(Central Authentication Service). http://www.google.cm/url?q=http://www.esup-

portail.org/consortium/espace/SSO_1B/cas/jres/cas-jres2003-

article.pdf&sa=U&ei=5hPkUba0PPGb1AXlmIGQBg&ved=0CBkQFjAA&usg=AFQjCNH6z

xL2y1ShZCCHLYjbYxWRCBzJPw

[10] DANG Quang Vu, Mémoire de fin d’étude, IFI, support de source d’authentification

multiples dans un portail de travail collaboratif, Institut National des Télécommunication,

novembre 2006.

http://www.gsefr.org/open-source/documents/prives/GuideShare%20-%20Presentation%20SSO.odp

http://www.gsefr.org/open-source/documents/prives/GuideShare%20-%20Presentation%20SSO.odp

http://2005.jres.org/tutoriel/shibboleth-jres2005-article.pdf,%20explication

http://www.arismore.fr/wp-content/uploads/F%C3%A9d%C3%A9ration-Identit%C3%A9s_F.JAN-Arismore.pdf

http://www.arismore.fr/wp-content/uploads/F%C3%A9d%C3%A9ration-Identit%C3%A9s_F.JAN-Arismore.pdf

http://monblog.system-linux.net/blog/2008/11/04/creer-un-controleur-principal-de-domaine-avec-samba-et-un-annuaire-ldap/

http://monblog.system-linux.net/blog/2008/11/04/creer-un-controleur-principal-de-domaine-avec-samba-et-un-annuaire-ldap/

http://www.artduweb.com/export/xhtml/tutoriels/cas-sso

https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/install-idp-2.3-debian.html,%20installation

https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/install-idp-2.3-debian.html,%20installation

https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying-party.xml,%20fichier

https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/relying-party.xml,%20fichier


Annexes LIRT 2011-2012

Annexes

Annexe 1 : Installation de Mysql-server

Créons la base de données « shibboleth » et la table « shibpid »

Créons un utilisateur shibboleth avec pour mot de passe « demo » et limiter les permissions à

la base de données shibboleth.

#mysql -u root -p

mysql> SET NAMES 'utf8';

SET CHARACTER SET utf8;

CHARSET utf8;

CREATE DATABASE IF NOT EXISTS shibboleth CHARACTER SET=utf8;

USE shibboleth;

CREATE TABLE IF NOT EXISTS shibpid (

localEntity TEXT NOT NULL,

peerEntity TEXT NOT NULL,

principalName VARCHAR(255) NOT NULL DEFAULT '',

localId VARCHAR(255) NOT NULL,

persistentId VARCHAR(36) NOT NULL,

peerProvidedId VARCHAR(255) DEFAULT NULL,

creationDate timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP

ON UPDATE CURRENT_TIMESTAMP,

deactivationDate TIMESTAMP NULL DEFAULT NULL,

KEY persistentId (persistentId),

KEY persistentId_2 (persistentId, deactivationDate),

KEY localEntity (localEntity(16), peerEntity(16), localId),

KEY localEntity_2 (localEntity(16), peerEntity(16),

localId, deactivationDate)

) ENGINE=MyISAM DEFAULT CHARSET=utf8;

USE mysql;

INSERT INTO user (Host,User,Password,Select_priv,

Insert_priv,Update_priv,Delete_priv,Create_tmp_table_priv,

Lock_tables_priv,Execute_priv) VALUES

('localhost','shibboleth',PASSWORD('demo'),

'Y','Y','Y','Y','Y','Y','Y');

FLUSH PRIVILEGES;

GRANT ALL ON shibboleth.* TO 'shibboleth'@'localhost'

IDENTIFIED BY 'demo';

FLUSH PRIVILEGES;

QUIT

#apt-get install mysql-server

#/usr/bin/mysqladmin -u root password ‘0123456789'



Annexe 2 : fichier de configuration d’apache

... ServerName pcserver.iut-fv.cm

<VirtualHost _default_:443>

ServerName pcserver.iut-fv.cm:443

ServerAdmin [email protected]

DocumentRoot /var/www

SSLEngine On

SSLCipherSuite HIGH:MEDIUM:!ADH

SSLProtocol all -SSLv2

SSLCertificateFile /etc/ssl/certs/pcserver.iut-fv.crt

SSLCertificateKeyFile /etc/ssl/private/pcserver.iut-fv.key

SSLCertificateChainFile /etc/ssl/certs/qvsslica.crt.pem

<Proxy ajp://localhost:8009>

Allow from all

</Proxy>

ProxyPass /idp ajp://localhost:8009/idp retry=5

BrowserMatch "MSIE [2-6]" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

# MSIE 7 and newer should be able to use keepalive

BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>

<VirtualHost _default_:8443>

ServerName pcserver.iut-fv.cm:8443

ServerAdmin [email protected]

DocumentRoot /var/www

SSLEngine On

SSLCipherSuite HIGH:MEDIUM:!ADH

SSLProtocol all -SSLv2

SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt

SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key

SSLVerifyClient optional_no_ca

SSLVerifyDepth 10

<Proxy ajp://localhost:8009>

Allow from all

</Proxy>

Annexe 3 : fichier de configuration /opt/shibbolethidp/metadata/metadata.aaitest.xml

Annexe 4 : fichier /opt/shibboleth-idp/conf/attribute-resolver.xml









<rp:AnonymousRelyingParty provider="https://pcserver.iut-fv.cm/idp/shibboleth"

defaultSigningCredentialRef="IdPCredential" />

<rp:DefaultRelyingParty provider="https://pcserver.iut-fv.cm/idp/shibboleth"

defaultSigningCredentialRef="IdPCredential"

defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

">

<

<rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile" />

</rp:DefaultRelyingParty>



<rp:RelyingParty id="https://www.switch.ch/aai/SAML1/Attribute-Push"

provider="https://pcserver.iut-fv.cm/idp/shibboleth"

---

--- 

<resolver:DataConnector id="myLDAP"

xsi:type="dc:LDAPDirectory"

ldapURL="ldap://ldap.iut-fv.cm"

baseDN="ou=people,dc=iut-fv,dc=cm"

principal="cn=admin,dc=iut-fv,dc=cm"

principalCredential="secret-password">

<dc:FilterTemplate>

<![CDATA[

----

sourceAttributeID="swissEduPersonUniqueID"

salt="your random string here">

<resolver:Dependency ref="swissEduPersonUniqueID" />

<dc:ApplicationManagedConnection

jdbcDriver="com.mysql.jdbc.Driver"

jdbcURL="jdbc:mysql://localhost:3306/shibboleth?autoReconnect=true"

jdbcUserName="shibboleth"

jdbcPassword="demo" />

----

<resolver:PrincipalConnector xsi:type="pc:StoredId" id="saml2Persistent"

nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"

storedIdDataConnectorRef="myStoredId" />

</resolver:AttributeResolver>

Rapport projet3

Technology

Transcript of Rapport projet3