Système d'authentification centralisée SSO ( Single Sign- On: une seule authentification pour plusieurs applications ) avec fournisseur d'identités

² 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 plusprofond 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'IUTFotso 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

251625472

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 3

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 concoursavec 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 SSO^1(*)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 etdestiné essentiellement à mettre en place les services avecconditions 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 plussollicités car ils ne s'authentifieront qu'une seule fois pouraccé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 CAS^2(*)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.

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 Erreur ! Signet non défini.

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.1Les 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 etoffrant 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éeet 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 HTTP^4(*) 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-it^5(*)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. Lefournisseur 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 etles 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.

CHAPITRE 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-serveur^6(*)et que les terminaux ont été remplacés par les PC, les administrateurs ne pouvaient plus avoir confiance auxutilisateurs. 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érifierl'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 surle service auquel ils tentent d'accéder par le contrôle de leurs droits d'accès. Le serviced'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 DEL'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

251641856

1.3.2 PROBLEME DEL'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èmed'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

251642880

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

251643904

1.4 JUSTIFICATION DU THEME

Mettre en place un système d'authentification pouvant répondre aux problèmes suscité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

251644928C'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 pourcentraliser 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.



251697152

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

251674624

1.4.2 AUTHENTIFICATION UNIQUE

Le Single Sign-On est une technique qui consiste à soumettre l'utilisateur à une procédure d'authentification uniqueet 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 architectureest 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

251645952

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

251646976

· 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 pourSecurity Assertion MarkupLanguage permet entreautres 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 Kerberoset basé sur le protocole HTTP(S). CASpour Central Authentication Service a été développé par l'université de Yale auxEtats-Unisest un serveur d'authentification accessible par WWW, composé de servlets java, qui fonctionne sur tout moteur de servlets(Tomcatpar 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 etShibboleth 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,Shibbolethpropose un mécanisme de transport d'attributs et d'authentification inter-établissements. De récentes discussions autour de Shibbolethlaissent 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 Kerberosou 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 clientesen 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 webstatiques, 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 defédération d'identités pour l'enseignement supérieur français. Surtout la topologie d'une fédération de type Shibbolethcorrespond bien à la structuration d'un ensembled'é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 quine 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.2CONCEPTION

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









251621376

Figure 8 : architecture du serveur CAS

251626496

ü 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 Apacheet un module PAM, qui permet d'authentifier les utilisateurs au niveau système.

ü Le navigateur

C'est l'élément disposantd'un moteur de chiffrementleur 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

251627520

Si les informations sont correctes, le serveur renvoie au navigateur un cookieappelé 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 cookieprivé (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 APRESAUTHENTIFICATION

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

251622400

Figure 10 : redirection transparente vers le serveur CAS

251628544

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. Iln'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 Ticketen paramètre.

Le Service Ticketest 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

251629568

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

251630592

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

251624448

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

251631616

ü 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

251675648

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

251632640

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

251676672

La réponse de l'IdP est une demande d'authentification, sous la forme d'une erreur 401Unauthorizedou 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

251679744

251678720

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

251681792

251680768

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 (AttributeRequester),

- 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 nameIdentifierau 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 (AuthenticationAuthority),

- L'autorité d'attributs (AttributeAuthrority).

Le service d'authentificationest 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'authentificationassocie le nameIdentifierà l'identifiant de l'utilisateur.

Figure 20 : fonctionnement de Shibboleth sans CAS

251683840L'autorité d'attributsdé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

251684864

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

251685888

.

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

251686912

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

251687936

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

251688960

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

251689984

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

251691008

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

251692032

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

251693056

2.3MISE 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 communicationTCP/IP). L'intranet est connecté au réseau Internet pour permettre la communication avec lemonde 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

251694080251696128

2.3.2 CENTRALISATION DE L'AUTHENTIFICATION

Installation de l'annuaire LDAP

LDAP(LightweightDirectory 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 installslapdldap-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

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

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 biensû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.confn'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 smbclientsmbfssmbldap-toolslibnss-ldaplibpam-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-cise 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-getopenjdk-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 commegcj. 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'allouerau 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-getinstall tomcat6

Apache Tomcat est un serveur d'applications JAVA. C'est lui qui exécutera la brique ShibbolethIdP. 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'IdPShibboleth

#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

#chmodu+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/

#envIdPCertLifetime=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

#vimetc/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

#opensslgenrsa -out pcserver.iut-fv.cm.key 1024

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

#cppcserver.iut-fv.cm.key/etc/ssl/private/

#cppcserver.iut-fv.cm.crt/etc/ssl/certs/

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

ServerTokensProd

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 etl'activation du module proxy ajp.

Configuration du module JAAS pour l'authentification des utilisateurs

Il faut configurer l'authentification pour ShibbolethIdP 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 VTLdappour 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" />

<!--

<ListenerclassName="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 ShibbolethIdP 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 ShibbolethIdP.Tomcat rechargera l'application d'enchaînement à condition que le descripteur de contexte se dirige au dossier/opt/shibboleth-idp/war/idp.war.

répondezno à 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.

HA

CHAPITRE 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'IdPshibboleth. Le serveur de SSO est un agent d'authentification délégué par l'IdP pour favoriser les accès aux services.

3.1RESULTATS 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éeShibboleth



Vérification du fonctionnement de Shibboleth



Serveur Shibboleth déployé



Page d'accueil pour l'authentification Shibboleth



Page d'authentification du serveurCAS pour le service de SSO





Authentification réussie



251640832

3.2PERSPECTIVES

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 fortepermettant de sécuriser les accès aux ressources internes depuis un réseau non sécurisé commeInternet.

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

251695104

251673600

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 paspar 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 quisimplifient 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écouvrantde 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 carcela 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, plusieurssolutions 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, installationde l'idpshibboleth, 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 etpropagation 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-sourceavec 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 installmysql-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>

ServerNamepcserver.iut-fv.cm:443

[e-mail]

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]" \

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

[e-mail]

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

SSLVerifyClientoptional_no_ca

SSLVerifyDepth 10

<Proxy ajp://localhost:8009>

Allow from all

</Proxy>

ProxyPass /idp ajp://localhost:8009/idp retry=5

BrowserMatch "MSIE [2-6]" \

nokeepalivessl-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:ProfileConfigurationxsi: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"

---

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

<![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:PrincipalConnectorxsi:type="pc:StoredId" id="saml2Persistent"

nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"

storedIdDataConnectorRef="myStoredId" />

</resolver:AttributeResolver>

* ¹ Single sign-on : une seule authentification pour plusieurs applications

* ² Serveur de SSO

* ³Fournisseur d'identités

* ⁴ Protocol d'application utilisé par le navigateur servant au transfert des pages web

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

* ⁶ Système disposant d'un client pour les requêtes vers un serveur répondant à ces requêtes