Epigraphe
« Je n'ai pas peur des
ordinateurs. Mais j'ai peur qu'ils viennent à nous
manquer »
Isaac ASIMOV
Dédicaces
A nos
parents
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 coeur. 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.
Liste des
abréviations
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
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
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
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
· 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 oeuvre d'un
système d'authentification centralisé (SSO) avec fournisseur
d'identités dans un intranet ».
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
Shibboleth3(*) 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.
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.
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
3
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
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
Cahier des charges
THEME : Mise en oeuvre 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.
Travaux préliminaires :
ü Brève présentation des systèmes
d'authentification
ü Présenter les avantages des systèmes
d'authentification centralisée
ü Présenter les apports d'authentification SSO et
d'un fournisseur d'identités
ü Inventaire des solutions possibles
ü Présenter la solution motivée et son
fonctionnement
ü Donner une architecture du système
Moyens
ü Utilisation des systèmes d'exploitations
GNU/LINUX distribution DEBIAN version 6.0.1 et Microsoft Windows pour les
clients.
ü Utilisation des logiciels libre tels que OpenLDAP,
SAMBA, Tomcat, Shibboleth, CAS client et CAS server.
Fonctionnalités attendues :
ü Authentification centralisée avec l'annuaire
LDAP
ü Contrôleur de domaine avec le serveur SAMBA
ü Génération de l'arbre de base au sein de
l'annuaire LDAP pour le contrôleur de domaine SAMBA.
ü Déployer le fournisseur d'identité avec
la brique Shibboleth pour avoir la possibilité d'accéder à
une fédération.
ü Serveur de SSO déployé avec CAS, si
possible Shibboleth pour donner la possibilité d'une authentification
unique.
Durée du projet : 4 mois
Encadreur : M. LIENOU Jean Pierre
Introduction
générale
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 coeur 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.
C
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
ü un membre du personnel ou un client
ü une entité administrative
ü un administrateur informatique
ü un invité etc...
· Un groupe
Les utilisateurs peuvent être regroupés en
groupe statique ou dynamique. Ces groupes sont utilisés pour faciliter
la gestion en masse des habilitations.
On peut regrouper ces acteurs en 3 natures : un client,
un serveur proposant le service demandé et un serveur
d'authentification.
· Un compte
A chaque personne peuvent être associés des
comptes d'accès aux différents systèmes et
applications.
Le compte est défini par l'identifiant d'accès,
un mot de passe, et plusieurs attributs supplémentaires, en fonction de
l'environnement dans lequel il est crée comme : la politique de mot
de passe associée, l'accès externe autorisé ou non,
l'état du compte, les modes d'authentifications autorisés etc...
Il existe quatre types de compte :
Le compte global : Compte unique, identifie une
personne dans le référentiel central et est utilisé par
tous les processus d'attribution des droits.
Le compte utilisateur : compte qui donne
accès à un utilisateur dans un environnement particulier auquel
cet utilisateur est habilité. Chaque compte utilisateur est
obligatoirement associé à une personne.
Le compte d'administration : Ce compte donne
l'accès à un administrateur dans un environnement particulier. Il
n'est pas associé à une personne.
Le compte « de service fonctionnel ou
technique » : Compte utilisé par les composants d'un
système pour accéder aux services applicatifs et/ou
données d'un autre système. Aucune personne n'est
autorisée à l'utiliser.
1.1.3 LES SERVICES D'AUTHENTIFICATION
Les termes associés aux services
d'authentification sont : Identification, Authentification et
Autorisation. Le travail de ces services est avant tout l'authentification.
L'identification permet de vérifier
l'identité d'une personne via un login par exemple.
L'authentification permet de s'assurer qu'une
personne est bien celle qu'elle prétend être par login et mot de
passe.
L'autorisation permet à partir de
l'identification et l'authentification de définir des droits à
une personne.
Après la phase d'authentification des
utilisateurs, le système pourra autoriser ces utilisateurs sur le
service auquel ils tentent d'accéder par le contrôle de leurs
droits d'accès. Le service d'autorisation est chargé
d'évaluer les droits effectifs sur la base des informations fournies par
le service d'authentification :
ü Authentification Windows pour SAMBA
ü Authentification accès distant (Radius)
ü Authentification Web Apache/IIS
ü Authentification SGBD Oracle/MySQL
ü Authentification messagerie (Webmail)
On peut distinguer deux types d'authentification :
l'authentification d'un tiers et l'authentification de la source des
données. L'authentification d'un tiers consiste à prouver son
identité. L'authentification de la source des données sert
à prouver que les données reçues viennent de
l'émetteur déclaré.
1.1.4 LES PROTOCOLES D'AUTHENTIFICATION
De nombreux protocoles d'authentification
requièrent une authentification de l'identité ou de
l'équipement avant d'accorder des droits d'accès. Les principaux
protocoles d'authentification sont :
ü RADIUS
ü TACACS
ü Kerberos.
Les protocoles de la famille TACACS sont assez
répandus. Ils utilisent le protocole TCP contrairement à RADIUS
qui s'appuie sur UDP. Toutefois, ce ne sont pas des standards définis
par un organisme de standardisation comme l'IETF. Seuls RADIUS et Kerberos sont
des standards.
Kerberos est mis en place dans l'authentification Windows 2000
au sein d'Active Directory. Ce protocole permet l'authentification des
entités communicantes (clients et serveurs) et des utilisateurs.
1.2 METHODES D'AUTHENTIFICATION
Les méthodes d'authentification doivent
être choisies en fonction du caractère stratégique et du
risque liés aux ressources devant être protégées.
1.2.1 PRESENTATION
Toutes les techniques d'authentification reposent sur
l'utilisation d'un secret qui doit être unique et non falsifiable. Il
existe plusieurs façons pour authentifier une personne (ou plus
généralement, une entité). On peut se baser sur :
ü ce qu'il sait
ü ce qu'il a
ü ce qu'il est
« Ce qu'il sait » est tout
simplement un mot de passe qui va permettre, par comparaison ou par
décryptage, par exemple, de vérifier que la personne est bien
celle qu'elle dit être.
« Ce qu'il a » est plus
subtil car il fait appel à un objet que la personne à
authentifier, a en sa possession. Le plus souvent, il s'agit d'un appareil
générant « aléatoirement » une suite
de nombres/caractères. Cette suite qui ne sera valable que pendant un
temps donné, permettra d'utiliser des clés beaucoup plus longues,
pour augmenter encore la sécurité pendant l'authentification.
« Ce qu'il est » est
justement une méthode encore peu utilisée pour le moment, et fait
appel à des mécanismes de biométrie (empreinte digitale,
rétine...). Cette technique n'est pas encore totalement utilisée,
les raisons étant entre autres, le manque de logiciels l'utilisant
réellement, ainsi que la rareté de matériels encore
onéreux. L'intérêt de ce type de système est qu'il
supprime la duplication, le vol, l'oubli et la perte. Cependant, à long
terme, cette technique risque de ne pas être exempte de piratage.
1.3 ANALYSE DE
L'EXISTANT
On constate de plus en plus de nos jours dans les
universités un nombre croissant d'applications dédiées
à la fois au personnel et aux étudiants engendrant un nombre
incalculable de mots de passe à retenir pour chacune d'elle.
1.3.1 PROBLEME DE L'UTILISATEUR
Généralement pas doué d'une
expertise informatique, certains utilisateurs se retrouvent en
général dans l'embarra, car ne sachant que faire de ces multiples
mots de passe à leur disposition. C'est ainsi qu'ils les gardent dans
des blocs notes ou à des endroits propices à leur divulgations,
et parfois même les oublies.
.
Figure 1: problème de
l'utilisateur
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.
ü 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
Figure 2 : problème de
l'administrateur
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 3 : problème
générale
1.4 JUSTIFICATION DU
THEME
Mettre en place un système d'authentification pouvant
répondre aux problèmes sus cités tout en garantissant
l'identité des utilisateurs au sein d'une entreprise, d'une instance
(à l'exemple du ministère des forêts et du ministère
des finances) et même d'une fédération universitaire en
particulier l'université de Dschang et ses différents
établissements affiliés ( à l'exemple de l'iut-fv de
bandjoun) tout en garantissant la confiance dans le réseau. Cela passe
par :
1.4.1 CENTRALISER L'AUTHENTIFICATION
Figure 4 : centralisation de
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 5 : authentification
centralisée à l'annuaire LDAP
1.4.2 AUTHENTIFICATION UNIQUE
Le Single Sign-On est une technique qui consiste
à soumettre l'utilisateur à une procédure
d'authentification unique et une seule fois par rapport aux différents
services accessibles : applications web ou fonctions
protégées du système. Il peut aussi prononcer les
autorisations ou interdictions d'accès de l'utilisateur à
l'ensemble des services, suivre l'activité et tracer les
opérations effectuées. Son architecture est en
général basée sur un serveur d'authentification
(certificat X509, Kerberos). Il est composé :
D'un serveur d'authentification
C'est l'élément central du SSO puisqu'il assure
:
· L'authentification.
· La persistance de la connexion.
· La propagation de l'identité de l'utilisateur
auprès des applications
Il a la charge de vérifier le mot de passe de
l'utilisateur auprès d'une base de référence (NIS, LDAP,
/etc/passwd ...).
Figure 6 : principe
d'authentification unique
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.
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.
Figure 7 : principe de la
fédération d'identités
· 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.
.
C
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
oeuvre. 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 oeuvre 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é
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
ü
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.
· 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.
Figure 8 : architecture du
serveur CAS
ü 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 9 : fonctionnement de
base de CAS
Si les informations sont correctes, le serveur renvoie au
navigateur un cookie appelé TGC (Ticket Granting Cookie).
Le TGC est le passeport de l'utilisateur auprès du
serveur CAS. Le TGC, à durée de vie limitée (typiquement
quelques heures), est le moyen pour les navigateurs d'obtenir auprès du
serveur CAS des tickets pour les clients CAS sans avoir à se
ré-authentifier. C'est un cookie privé (n'est jamais
transmis à d'autres serveurs que le serveur CAS) et
protégé (toutes les requêtes des navigateurs vers le
serveur CAS se font sous HTTPS).
2.2.1.3
ACCES A UNE RESSOURCE PROTEGEE APRES AUTHENTIFICATION
Lors de l'accès à une ressource
protégée par un client CAS, celui-ci redirige le navigateur vers
le serveur CAS dans le but d'authentifier l'utilisateur (le navigateur),
précédemment authentifié auprès du serveur CAS et
lui présente le TGC.
 
Redirection vers le serveurCAS d'un navigateur non
authentifié auprès du client CAS
Redirection par le serveur CAS d'un
navigateur vers un client CAS après
authentification
Figure 10 : redirection
transparente vers le serveur CAS
Sur présentation du TGC, le serveur CAS
délivre au navigateur un Service Ticket (ST). C'est un ticket
opaque, qui ne transporte aucune information personnelle. Il n'est utilisable
que par le « service » (l'URL) qui en a fait la demande. Dans le
même temps, il le redirige vers le service demandeur en passant le
Service Ticket en paramètre.
Le Service Ticket est alors validé
auprès du serveur CAS par le client CAS, directement en http, et la
ressource peut être délivrée au navigateur.
Il est à noter que toutes les redirections
présentées sont complètement transparentes pour
l'utilisateur. Celui-ci ne voit pas les redirections et a l'impression
d'accéder directement à la ressource désirée, sans
authentification.
 
Figure 11 : validation pour
l'accès à une ressource
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
- délivre au client un
Service Ticket à destination du client CAS
- redirige le client vers le client CAS
Figure 12 : accès
à l'application sans authentification
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 13 : validation du PT
pour l'accès à une ressource
ü Fonctionnement n-tiers
On voit aisément que le client CAS
accédé par le mandataire CAS du fonctionnement 2-tiers peut
également être mandataire à son tour. Les mandataires
peuvent ainsi être chaînés.
CAS est à notre connaissance, le seul mécanisme
de SSO proposant un tel fonctionnement multi-tiers sans aucune propagation de
mot de passe.
Figure 14 : CAS dans
l'architecture n-tiers
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)
C'est une entité proposant des ressources web
sur la base d'un contexte de sécurité SAML et sera par la suite
nommée SP (Service Provider). Le fournisseur de ressource a en
particulier la charge de donner ou non l'accès aux ressources, en
fonction des attributs utilisateur.
ü Le fournisseur d'identités (Identity
Provider ou IdP)
C'est une entité authentifiant les utilisateurs
et fournissant leurs attributs. Elle sera par la suite notée IdP. Le
fournisseur d'identités s'appuie sur le SI de l'établissement,
tant pour l'authentification que pour la récupération des
attributs utilisateur à propager. De ce fait, il est en
général situé au plus proche du SI.
ü Le WAYF
Le WAYF (pour Where Are You From?, « d'où
êtes-vous ? ») est un service dont le but est d'orienter
l'utilisateur vers son IdP.
Seul l'objectif du WAYF est défini dans les
spécifications de Shibboleth :
- Proposer aux utilisateurs une liste d'IdP, parmi lesquels
les utilisateurs sont invités à sélectionner celui de leur
établissement de rattachement ;
- Une fois le choix effectué, il redirige les
utilisateurs vers l'IdP correspondant à leur choix.
L'architecture d'une offre applicative d'un
établissement dont l'authentification est confiée à
Shibboleth sera donc souvent celle décrite par la figure :
Figure 15 : fonctionnement du
WAYF
2.2.2.2 FONCTIONNEMENT DE SHIBBOLETH SANS CAS
Dans ce premier cas d'étude, nous
considérons que le SP connaît l'établissement de
rattachement de l'utilisateur, c'est-à-dire l'établissement qui
pourra l'authentifier. Le navigateur effectue donc une requête HTTP vers
le SP afin d'accéder à une ressource et le SP, sans information
d'authentification, le redirige vers l'IdP de l'établissement de
rattachement de l'utilisateur.
Figure 16 : requête du
navigateur vers le fournisseur de service
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.
Figure 17 : redirection de
l'IdP vers le SP
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.
<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.
Figure 18 : le SP demande les
attributs de l'utilisateur
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.
Figure 19 : réponse du
SP 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.
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.
Figure 20 : fonctionnement de
Shibboleth sans CAS
L'autorité d'attributs délivre,
en réponse à une demande d'un SP, les attributs de l'utilisateur
correspondant à un nameIdentifier. L'association entre l'identifiant de
l'utilisateur et le nameIdentifier étant maintenue par l'autorité
d'authentification.
Figure 20 :
fonctionnement de Shibboleth sans CAS
2.2.2.3
FONCTIONNEMENT DE SHIBBOLETH AVEC SSO
Dans le modèle de CAS, l'authentification n'est
pas directement prise en charge par le service d'authentification de l'IdP.
Celui-ci ne fait que rediriger le navigateur vers le serveur de SSO, qui
renvoie alors à l'utilisateur un formulaire d'authentification.
Figure 21 : redirection du
navigateur vers le serveur de SSO
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 22 : fonctionnement de
Shibboleth avec SSO
.
Requêtes suivantes au même
SP
Comme vu précédemment, une session étant
mise en place entre le navigateur et le SP, ni l'IdP ni le serveur SSO
n'interviennent par la suite pour l'accès au même SP.
Figure 23 : requete suivant
le meme 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 24 :
délégation d'authentification vers un autre SP
2.2.2.4
FONCTIONNEMENT DE SHIBBOLETH DANS UNE FEDERATION
Considérons le cas où un SP est
accessible à des utilisateurs rattachés à des
établissements différents. C'est par exemple le cas d'une
université souhaitant mettre à disposition de tous les personnels
de l'enseignement supérieur de sa région les archives de ses
thèses et publications scientifiques.
Le problème qui se pose alors est que le SP ne sait pas
vers quel IdP rediriger le navigateur pour l'authentification. Il est
résolu grâce au WAYF, dont le rôle est d'orienter les
utilisateurs pour sélectionner leur IdP.
Première requête vers un
SP
Lors de la première requête au SP, celui-ci ne
sachant pas quel IdP sera utilisé, le SP redirige le navigateur vers le
WAYF.
Figure 25 : redirection
transparente vers le WAYF
Le WAYF affiche alors à l'utilisateur alors une liste
d'IdP possibles. La requête suivante, vers le WAYF, redirige le
navigateur vers l'IdP choisi par l'utilisateur, qui à son tour redirige
le navigateur vers le serveur SSO, qui propose alors un formulaire
d'authentification.
Figure 26 : redirection du
WAYF vers le serveur de SSO
Le navigateur s'authentifie alors auprès du serveur
SSO, et l'authentification se déroule ensuite comme vu
précédemment.
Figure 27 : réponse du
SP après authentification du serveur SSO
Requêtes suivantes vers le même
SP
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.
Figure 28 : réponse du
SP sans authentification
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 29 : le WAYF en action
dans une fédération
2.3 MISE EN OEUVRE
Une fois la méthodologie du travail
décrite, il ne nous reste plus qu'à mettre sur pied notre
système. Ainsi, dans ce paragraphe, il est question de présenter
étape par étape le travail effectué et d'accompagner ces
différentes étapes par des résultats qui, seront
présentés par des captures d'écran.
2.3.1 PRESENTATION DE L'INTRANET
L'intranet est la partie sécurisée de
notre réseau informatique basé sur les mêmes technologies
qu'Internet (protocoles de communication TCP/IP). L'intranet est
connecté au réseau Internet pour permettre la communication avec
le monde extérieur.
En effet, notre intranet peut être constitué de
plusieurs serveurs parmi lesquels on peut citer :
· Le contrôleur de
domaine (samba)
· Le serveur web
· Le serveur DNS
· Le serveur DHCP
· L'annuaire LDAP
· Le serveur de SSO (CAS)
· Le serveur de fourniture
d'identités ou de SSO (Shibboleth)
Nous ne devons pas nous attarder
sur la présentation de la configuration de tous ces serveurs car, le
plus important ici ce sont les serveurs SSO et le fournisseur
d'identités [3]. Nous avons choisi « iut-fv.cm »
comme domaine.
L'architecture simplifiée se présente comme
suit :
Figure 30 : architecture du
système
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.
#apt-get install slapd ldap-utils apache2 php5 php5-gd
php5-ldap phpldapadmin
· 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
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.
#apt-get install samba-doc samba smbclient smbfs smbldap-tools
libnss-ldap libpam-ldap
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. Il reste maintenant à éditer le fichier de
configuration du serveur OpenLDAP : /etc/ldap/slapd.conf
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
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
#apt-get openjdk-6-jre-headless
Installation du paquet java 6 JDK-JRE
JAVA_HOME=/usr/lib/jvm/java-6-openjdk
export JAVA_HOME
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.
# export JAVA_HOME=/usr/java/latest/
# export JAVA_OPTS="-Xmx1000m -XX:MaxPermSize=512m"
Installation du serveur Tomcat
#apt-get install tomcat6
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.
JAVA_OPTS="-Djava.awt.headless=true -Xmx512M
-XX:MaxPermSize=128M -Dcom.sun.security.enableCRLDP=true"
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
#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/
Shibboleth est disponible au site :
http://shibboleth.internet2.edu/downloads/shibboleth/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/
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.
#cd /usr/local/src/shibboleth-identityprovider-2.3.8/
#env IdPCertLifetime=3 ./install.sh
Démarrons l'installation de Shibboleth avec un
certificat de trois ans signé par Idp.
#ln -s /opt/shibboleth-idp/conf /etc/shibboleth
#ln -s /opt/shibboleth-idp/logs /var/log/shibboleth
#export IDP_HOME=/opt/shibboleth-idp
Déplaçons les annuaires de configuration de
Shibbolet. Donnons la variable d'environnement dans le fichier
/etc/profile.
#cd /etc/tomcat6
#mkdir -p Catalina/localhost
#vim etc/tomcat6/Catalina/localhost/idp.xml
Créons le répertoire pour la description de
l'IdP :
<Context
docBase="/opt/shibboleth-idp/war/idp.war"
privileged="true"
antiResourceLocking="false"
antiJARLocking="false"
unpackWAR="false"
swallowOutput="true"
cookies="false" />
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] :
#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>
La suite de la configuration de CAS a été faite
grâce au fichier à l'adresse :
http://www.artduweb.com/tutoriels/cas-sso
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
#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
Configuration d'apache
SSLCertificateFile /
etc/pki/tls/certs/pcserver .iut-fv.cm.crt
SSLCertificateKeyFile /
etc/pki/tls/private/pcserver.iut-fv.cm.key
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.
#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
Améliorons le degré de sécurité de
notre serveur, ajoutons dans de directive /etc/apache2/conf.d/security.
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.
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";
};
Configuration de tomcat
<!-- 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"
/>
-->
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.
#cd /opt/shibboleth-idp/credentials
#chown root idp.key
#chgrp tomcat6 idp.{key,crt}
#chmod 440 idp.key
#chmod 644 idp.crt
Le dossier spécifique de SWITCHaai relying-party.xml
[7] peut être téléchargé comme calibre pour
l'installation.
#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
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.
#cd /opt/shibboleth-idp/conf/
#curl -Ok
https://www.switch.ch/aai/docs/shibboleth/SWITCH/2.3/idp/deployment/attribute-resolver.xml
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.
C
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
Recherche de la reference au sein de l'annuaire Active
directory
Vérification des tables dans la base de donnée
Shibboleth
Vérification du fonctionnement de Shibboleth
Serveur Shibboleth déployé
Page d'accueil pour l'authentification Shibboleth
Page d'authentification du serveur CAS pour le service de SSO
Authentification réussie
3.2 PERSPECTIVES
Malgré tous les efforts qui ont
été fait, les problèmes de sécurité et de
fonction restent des challenges qui suscitent des efforts. Mais, nous avons
bien découvert ces problèmes et trouvé des solutions qui
ne sont pas du tout facile à mettre en oeuvre.
Dans paragraphe, nous présentons les
améliorations à venir pour compléter ce projet surtout
dans le domaine de la sécurité. Ces améliorations n'ont
pas été réalisées pour des raisons de temps et de
moyens matériels.
3.2.1 AUTHENTIFICATION FORTE
Parmi les perspectives ouvertes à ce projet,
l'utilisation des méthodes d'authentification pour « ce que je
possède » et « ce que je suis » ou la
combinaison de ces deux sont des assurances que l'utilisateur est bien celui
qui prétend être.
Ce projet à besoin d'un système
d'authentification forte permettant de sécuriser les accès aux
ressources internes depuis un réseau non sécurisé comme
Internet.
3.2.1.1 L'OTP
L'OTP sera un avantage pour nous parce que chaque
individu possède une ligne GSM propre à lui pour utiliser la
carte SIM comme un deuxième facteur d'authentification.
Il permet d'assurer l'authenticité des utilisateurs en
vérifiant la validité de leur code PIN et la possession de leur
téléphone portable.
A part son serveur d'authentification, le système doit
comporter un logiciel d'administration permettant la gestion, la visualisation
des fichiers d'historique et la supervision en temps réel. L'application
Open source « Linotp » est un serveur capable de faire cela
mais la difficulté de l'intégrer ou de la synchroniser avec notre
solution CAS-Shibboleth a été remarquée.
Aujourd'hui, avec l'arrivée des techniques
d'authentification forte, la sécurité n'est plus un frein pour
des solutions de mobilité.
Figure 31 : principe de
l'OTP
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.
Malheureusement pour nous, shibboleth dans sa version
utilisée ne prend pas par défaut l'authentification
biométrique. Cela ne veut pas dire que l'authentification
biométrique est impossible pour la solution CAS-Shibboleth. Il suffit du
temps pour une conception. Mais OpenSSO est une solution qui prend par
défaut l'identification par empreinte digital grâce au logiciel
Biobex. Malheureusement, nous avons constaté que le logiciel Biobex
n'est plus disponible.
3.2.2 UNE
FEDERATION D'IDENTITES FONCTIONNELLE
Une fédération est simplement « un
regroupement de fournisseurs de services et de fournisseurs d'identités
». La mise en place d'un test de l'IdP auprès de RENATER et de
notre propre fédération fonctionnelle soulève en effet
d'autres ressources que nous n'avons pas en notre disposition.
Le problème est de mettre sur pied une
fédération de huit universités d'état du pays y
compris les universités et les instituts privés. Comme dans le
cadre académique, RENATER, Esup-Portail et SWITCHaai sont des
fédérations qui simplifient et sécurisent les connexions
à leurs sites web dont l'accès est contrôlé :
plate-forme d'enseignement à distance, portail documentaire, application
métier, etc. La fédération répond bien aux besoins
de mutualisation entre organismes, aux problématiques de nomadisme et
facilite le respect de la loi «Informatique et libertés».
Conclusion
Comme le SSO donne accès à de nombreuses
ressources, une fois l'utilisateur authentifié, il a les "clés du
château". Les pertes peuvent être lourdes si une personne mal
intentionnée a accès à des informations d'identification
des utilisateurs. Avec le SSO, une attention particulière doit donc
être prêtée à ces informations, et des
méthodes d'authentification forte devraient idéalement être
combinées.
Conclusion générale
Parvenue au terme de ce projet, nous pouvons affirmer
qu'il nous a non seulement permis de mieux nous familiariser avec les
réalités du monde professionnel, aussi de mettre en pratique nos
compétences en découvrant de nombreuses plates formes dans le
domaine des réseaux informatiques.
Nous n'avons pas vite remarqué les
difficultés en terme de ressource pour la réalisation de ce
projet car cela a engendré beaucoup de temps.
A la première étape (indispensable), il
fallait implémenter un contrôleur de domaine avec le serveur
SAMBA, le synchroniser avec l'annuaire LDAP et ensuite gérer la
centralisation de l'authentification avec ce dernier. En effet, plusieurs
solutions ont été parcourues en fonction des systèmes
d'exploitation Linux à la recherche du succès et la solution
Shibboleth-CAS a été favorable même si les documentations
et la compréhension n'étaient pas évidentes.
La mise sur pied d'un fournisseur d'identités
conduit à une fédération d'identités. De nos jours,
nous rencontrons beaucoup d'entreprises qui forment un domaine de confiance en
disposant chacun d'un fournisseur d'identités (exemple fecebook-netlog,
facebook-twitter) certains encordent même le SSO (exemple
facebook-yahoo). Mais, la fédération d'identités est
manifestée par un portail et est faite pour des services de
l'enseignement supérieur.
Nous espérons qu'un pays émergent comme le notre
convergera vers ce système dans les moments à venir surtout dans
le secteur éducatif (enseignement supérieur) et bien d'autres.
Bibliographie
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=AFQjCNGxhZYGEFAHuPYH82Kvtur29Rz1xA
[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=AFQjCNH6zxL2y1ShZCCHLYjbYxWRCBzJPw
[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.
Annexes
Annexe 1 : Installation de
Mysql-server
#apt-get install mysql-server
#/usr/bin/mysqladmin -u root password
`0123456789'
Créons la base de données « shibboleth »
et la table « shibpid »
#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;
Créons un utilisateur shibboleth avec pour mot de passe
« demo » et limiter les permissions à la base de
données shibboleth.
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
Annexe 2 : fichier de configuration
d'apache
...
ServerName pcserver.iut-fv.cm
<VirtualHost _default_:443>
ServerName pcserver.iut-fv.cm:443
ServerAdmin admin@iut-fv.cm
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 admin@iut-fv.cm
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>
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>
Annexe 3 : fichier de configuration
/opt/shibbolethidp/metadata/metadata.aaitest.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"
---
Annexe 4 : fichier
/opt/shibboleth-idp/conf/attribute-resolver.xml
---
<!-- 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>
<
