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