LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE ORGANISATION

UNIVERSITE DE PICARDIE JULES VERNE
UNIVERSITE ABDELMALEK ESSAADI
ETUDES ET RECHERCHES
Effectué du 05 Mai au 05 Novembre 2012
Par
Ghislain Danny BATOMEN YANGA
Gisèle MEKUATE DEFO
Master M1 MIAGE
Méthodes Informatiques Appliquées à la Gestion des Entreprises
Tuteur de projet :
M. Yasser El Khamlichi
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET
DE LA RECHERCHE
ACADEMIE D’AMIENS
----------------------
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES :
MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE
ORGANISATION
Promotion de Janvier 2012 – Semestre 1
Année Académique 2011 – 2012

Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
ii
ii
LISTE DES FIGURES........................................................................................................................iv
INTRODUCTION............................................................................................................................ 1
Première partie : Généralités........................................................................................................ 2
Chapitre 1 : Pourquoi un système de gestion des identités et des accès ?....................................... 3
1.1. Etats des lieux ........................................................................................................................ 3
1.2. Justificatif d’un projet de gestion des identités et des accès ................................................ 4
1.2.1. Garantie de traçabilité et d’auditabilité.......................................................................... 5
1.2.2. Réduction des coûts d’administration............................................................................. 5
1.2.3. Amélioration de l’efficacité et de la réactivité................................................................ 5
1.2.4. Amélioration de la sécurité ............................................................................................. 6
Chapitre 2 : Les concepts .............................................................................................................. 7
2.1. Les concepts de base ............................................................................................................. 7
2.1.1. Utilisateur........................................................................................................................ 7
2.1.2. Compte............................................................................................................................ 7
2.1.3. Rôle.................................................................................................................................. 8
2.1.4. Profil ................................................................................................................................ 8
2.1.5. Poste opérationnel.......................................................................................................... 8
2.1.6. Groupe............................................................................................................................. 8
2.1.7. Périmètre......................................................................................................................... 8
2.1.8. Mode d’authentification ................................................................................................. 9
2.1.9. Ressource ........................................................................................................................ 9
2.1.10. Environnement de SI ................................................................................................... 9
2.1.11. Environnement externe............................................................................................... 9
2.2. Les concepts avancés : Fédération d’identités .................................................................... 10
2.2.1. L’identité fédérée.......................................................................................................... 10
2.2.2. La répartition des responsabilités ................................................................................. 10
2.2.3. Confiance entre les partenaires. ................................................................................... 11
2.2.4. La gestion d’identités fédérées ou Federated Identity Management........................... 11
Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information ............. 12
Chapitre 3 : La gestion des identités............................................................................................ 13
3.1. Notions d’identités............................................................................................................... 13
3.1.1. Définition....................................................................................................................... 13
3.1.2. Utilité et gestion............................................................................................................ 14
3.2. Modèles de gestion d’identités ........................................................................................... 15
3.2.1. Modèle isolé de gestion des identités........................................................................... 15
3.2.2. Modèle centralisé de gestion des identités .................................................................. 16
3.2.2.1. Modèle commun de gestion des identités............................................................ 16
3.2.2.2. Domaine d’identité avec authentification unique : SSO ....................................... 16
3.3. La fédération d’identités...................................................................................................... 17
3.3.2. Objectif de la Fédération d’identité ............................................................................. 18
Table des matières

iii
iii
3.3.3. Langages pour l’échange de l’information de sécurité ................................................. 19
3.4. Technologies de gestion d’identités .................................................................................... 20
3.4.1. Kerberos ........................................................................................................................ 20
3.4.2. Radius ............................................................................................................................ 20
3.4.3. Infrastructure à clé publique......................................................................................... 21
Chapitre 4 : La gestion des accès ................................................................................................. 23
4.1. La gestion d’accès : le concept............................................................................................. 23
4.1.1. Définition....................................................................................................................... 23
4.1.2. Principe de fonctionnement.......................................................................................... 23
4.2. Modèles de gestion d’accès................................................................................................. 25
4.2.1. Modèle RBAC................................................................................................................. 25
4.2.2. Modèle MAC.................................................................................................................. 27
4.2.3. Modèle DAC................................................................................................................... 27
4.3. Architectures de gestion d’accès ......................................................................................... 28
4.3.1. Architectures AAA ......................................................................................................... 28
4.3.2. Infrastructures de gestion à base de politiques............................................................ 29
Troisième partie : Implémentations et expérimentations ............................................................ 31
Chapitre 5 : Les solutions de contrôle d’accès.............................................................................. 32
5.1. Architectures de gestion d’accès ......................................................................................... 32
5.2. Les solutions de gestion d’identités et de droits d’accès .................................................... 33
5.2.1. Les solutions propriétaires ............................................................................................ 33
5.2.2. Les solutions propriétaires ............................................................................................ 35
Chapitre 6 : Implémentation d’une solution de contrôle d’accès.................................................. 37
6.1. Environnement de travail .................................................................................................... 37
6.2. Présentation d’Active Directory........................................................................................... 38
6.2.1. Active Directory et services d'accès et d'identité.......................................................... 38
6.2.2. Arborescence Active Directory...................................................................................... 39
6.3. Création d’une nouvelle forêt avec Windows Server 2008 ................................................. 40
6.4. Gestion des utilisateurs et des ordinateurs......................................................................... 41
6.4.1. Unité d’organisation...................................................................................................... 41
6.4.2. Compte d’utilisateurs.................................................................................................... 42
6.4.3. Groupe Active Directory................................................................................................ 44
6.4.4. Implémentation de la gestion a base des rôles en utilisant des groupes ..................... 45
6.4.5. Mises des machines clientes dans le domaine.............................................................. 48
6.5. Amélioration de la sécurité et piste d’audit ........................................................................ 48
6.5.1. Délégation des autorisations administratives............................................................... 49
6.5.1.1. Approche de la délégation .................................................................................... 49
6.5.1.2. Délégation des comptes utilisateurs. .................................................................... 49
6.5.2. Configuration des paramètres de mot de passe et de verrouillage.............................. 52
6.5.2.1. Configuration des stratégies de comptes du domaine ......................................... 52
6.5.2.2. Stratégie de mot de passe affinée......................................................................... 54
6.5.3. Audit de l’authentification de connexion...................................................................... 54
6.6. Configuration du service DNS .............................................................................................. 56
CONCLUSION GENERALE............................................................................................................. 59
BIBLIOGRAPHIE ...........................................................................................................................xv

iv
iv
LISTE DES FIGURES LISTE DES FIGURES
Première partie : Généralités et définition des concepts................................................................ 2
Chapitre 1 : Pourquoi un système de gestion des identités et des accès ?....................................... 3
Figure 1.1 : Existant standard de la gestion des identités et des droits d’accès.................................. 4
Figure 1.2 : Flux de mise à jour après la mise en place d’une gestion centralisée.............................. 6
Chapitre 2 : Les concepts .............................................................................................................. 7
Figure 2.1 : la fédération d’identités............................................................................................. 11
Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information ............. 12
Chapitre 3 : La gestion des identités............................................................................................ 13
Figure 3.1 : Entités, identités et identificateurs.................................................................................... 14
Figure 3.2 : Modèle isolé de gestion des identités................................................................................ 15
Figure 3.3 : le modèle commun de gestion d’identités......................................................................... 16
Figure 3.4 : le domaine d’identité avec authentification unique.......................................................... 17
Chapitre 4 : La gestion des accès ................................................................................................. 23
Figure 4.1 : Modèle RBAC de base ....................................................................................................... 25
Troisième partie : Implémentations et expérimentations ............................................................ 31
Chapitre 6 : Implémentation d’une solution de contrôle d’accès.................................................. 37
Figure 6.1 : Information système générale ........................................................................................... 37
Figure 6.2 : Arborescence Active Directory........................................................................................... 40
Figure 6.4 : Informations d’un utilisateur.............................................................................................. 43
Figure 6.5 : Liste des utilisateurs de l’OU « Personnels »...................................................................... 44
Figure 6.6 : Les groupes de rôles........................................................................................................... 46
Figure 6.7 : Utilisateurs membres d’un groupe..................................................................................... 46
Figure 6.8 : les propriétés d’un dossier partagé.................................................................................... 47
Figure 6.9: Les autorisations.................................................................................................................. 47
Figure 6.10 : Les groupes de règles....................................................................................................... 48
Figure 6.11 : Postes de l’OU « Privés ».................................................................................................. 48
Figure 6.12 : Délégation de contrôle..................................................................................................... 50
Figure 6.15 : Les paramètres de stratégies de mot de passe................................................................ 53
Figure 6.16 : Les paramètres de stratégie de verrouillage du compte ................................................. 54
Figure 6.17 : Les stratégies affinées ...................................................................................................... 54
Figure 6.18 : Paramètres d’audit........................................................................................................... 55
Figure 6.19 : Observateur d’événements.............................................................................................. 56
Figure 6.20 : La zone de recherche directe du domaine....................................................................... 57
Figure 6.21 : Assistant de création de la zone de recherche inversée.................................................. 57
Liste des figures

1
1
INTRODUCTION
De plus en plus d’entreprises et d’organismes appréhendent l’intérêt d’une mise en place du
système d’information pour la gestion des identités et la sécurité des accès. Ce système est perçu
comme un maillon clé dans la chaine de sécurité des organisations Elle permet de renforcer le niveau
de sécurité général en garantissant la cohérence dans l’attribution des droits d’accès aux ressources
hétérogènes du système d’information.
Notre étude porte sur ces systèmes de gestion d’identités et de droits d’accès, et c’est
l’occasion pour nous de comprendre les concepts, l’architecture, les modèles utilisés pour la mise en
place d’un tel système.
L’étude ainsi réalisée a été découpée en trois(03) parties : dans la première partie nous avons
aborder les « généralités » afin de maîtriser toutes les notions et concepts qui tournent autour des
systèmes de gestion d’identités et même de comprendre l’intérêt d’un système de gestion
d’identités et de droits d’accès : dans la seconde partie dénommé « gestion des identités et des
droits d’accès » nous avons présenté les modèles, architectures et technologies (protocoles) utilisés
pour la gestion des identités et des habilitations ; et enfin dans la troisième partie « implémentation
d’une solution des gestions de identités et des droits d’accès» c’était l’occasion pour nous d’étudier
non seulement les solutions de gestion d’identités et d’accès offerts sur le marché mais aussi
d’expérimenter une de ces solutions à travers son implémentation.
Introduction

2
2
Première partie : Généralités
1ère partie :
Généralités et définition
des concepts

3
3
CHAPITRE 1 : CONTEXTE GENERAL DU PROJET
Chapitre 1 : Pourquoi un système de gestion des identités et des accès ?
1.1. Etats des lieux
De nos jours, la multiplication et la diversité de systèmes de contrôle d’accès liés aux systèmes
d'exploitation et aux applications est devenue particulièrement contre-productive. En effet, chaque «
système» (OS, NOS, messagerie, groupware, applications métiers, ERP, CRM, etc.) est protégé par
une procédure de contrôle d'accès spécifique. De fait, chaque fonction à réaliser peut nécessiter un
code d’accès et des droits associés. Cette multiplicité de contrôles d’accès est source de confusion
pour l'utilisateur qui, par exemple, perd ou oublie ses mots de passe. Il lui reste alors deux solutions :
soit il sollicite le service de help-desk, au risque de l’engorger en lui faisant perdre trop de temps à
réinitialiser très souvent des mots de passe, soit il note lesdits codes sur un support à sa portée pour
ne plus les oublier ! Bien entendu, aucune de ces solutions n’est satisfaisante…
D’une manière générale, chaque système d’exploitation et/ou application est géré par un
administrateur unique ; de fait, toute vision globale est impossible. Dans ce cas, l’administration
autonome de chaque système est particulièrement source d’erreurs, de vulnérabilités et de perte de
temps. Par exemple, ne pas avoir la vision globale sur les droits de l’ensemble des utilisateurs peut
engendrer des problèmes de responsabilité (devenus importants dans le cadre des nouvelles lois ou
réglementations), tel qu’un acheteur qui validerait sa propre commande.
Généralement, les nouveaux arrivants se voient attribuer plus ou moins rapidement certaines
ressources (un bureau, un téléphone, un badge d’accès, un PC, etc.), mais ne peuvent pas travailler,
faute de droits d'accès. Ceci est notamment du au fait que le délai d’attribution des ressources et des
droits est trop long, que les circuits d’attribution sont trop « lourds», etc. Ils doivent même souvent
se débrouiller seuls : trouver le bon responsable pour l'accès à telle base de données, à telle
application, à l’Intranet, etc. La liste des interlocuteurs est à la mesure de la complexité du Système
d’Information.
D’autre part, on est rarement certain d'avoir supprimé tous les droits dont disposait un employé
partant ou d’avoir mis à jour les droits d’un employé en cas de changement de fonction. Le Système
d’Information regorge souvent de comptes dits « fantômes» (dormants et/ou périmés).
De plus, les comptes techniques génériques, installés par défaut, par les systèmes d’exploitation
et/ou les applications, ne sont pas toujours modifiés, voire supprimés, induisant d’autres failles. Ceci
étant d’autant plus grave que ces mots de passe sont facilement accessibles sur Internet… De même,
certaines personnes utilisent, lorsqu’elles arrivent dans l’entreprise, des comptes utilisateurs
«génériques» et partagés, simplement du fait de la durée importante de création de leur propre
compte.
Chapitre 1 : Pourquoi un système de
gestion des identités et des accès ?

4
4
Enfin, l’audit et la traçabilité sont souvent les parents pauvres de la mise en œuvre des droits
d’accès des utilisateurs. Pourtant, de plus en plus, les entreprises doivent respecter des normes, des
lois et/ou des réglementations strictes en matière de politique de contrôle interne.
La figure ci-dessous illustre l’état des lieux « standard »de la gestion des identités et des droits
d’accès dans une organisation
Figure 1.1 : Existant standard de la gestion des identités et des droits d’accès
1.2. Justificatif d’un projet de gestion des identités et des accès
Comme nous l’avons vu précédemment, l’absence de gestion globale des identités et des droits
d’accès peut générer de nombreux problèmes, parmi lesquels :
 la perte de productivité due aux délais d’obtention des droits d’accès,
 une charge importante d’administration (multiplication des administrateurs, réinitialisation
des mots de passe, etc.),
 l’impossibilité de tracer les actions d’administration des droits et d’en contrôler la cohérence
et la pertinence,
 la difficulté d’auditer les accès aux ressources,
 des entorses au principe de séparation des tâches,
 le non-respect des contraintes légales et/ou réglementaires (par exemple au travers d’un
mauvais paramétrage des règles de gestion).
La justification d’un projet de gestion des identités et des droits d’accès reposera sur les
améliorations suivantes :

5
5
1.2.1. Garantie de traçabilité et d’auditabilité
Il s’agit ici des principales lois et réglementations impliquant le SI et ayant des impacts directs sur
les aspects traitant de la sécurité (en particulier traçabilité et auditabilité)
D’une manière générale, ces lois et règlements « imposent» au Système d’Information des
exigences de :
 continuité d’activité,
 séparation des tâches : par exemple, une même personne ne doit pas à la fois commander
une fourniture ou prestation et valider sa réception,
 traçabilité et d’auditabilité : permettant de valider « qui a fait quoi » au sein du système
d’information, et « qui a habilité qui », de respect de la vie privée.
Déroger à ces exigences peut entraîner un risque juridique pour les responsables de l’entreprise.
1.2.2. Réduction des coûts d’administration
Un système de gestion des identités et des droits d’accès permet d’alléger la charge de travail de
l’équipe de « support informatique» (administration, help desk). Cet allègement résulte d’une part
de l’automatisation de tâches de gestion de comptes (réduction du nombre d’administrateurs) et
d’autre part de la diminution du nombre d’appels d’utilisateurs (perte ou oubli de nombreux mots de
passe, relance de demandes d’accès, etc. .).
Le système de gestion des identités peut permettre aux utilisateurs la gestion directe de certains
aspects de leur profil (par exemple le mot de passe, l’adresse, les numéros de téléphone, etc.).
1.2.3. Amélioration de l’efficacité et de la réactivité
Un système de gestion des identités et des droits d’accès permet de réduire le nombre
d’interventions humaines par une automatisation de la propagation des droits sur les différents
environnements concernés. La conséquence est à la fois une réduction des délais de mise à
disposition des droits d’accès et une réduction des sources d’erreur (prise en compte systématique
de tous les besoins liés à l’activité de l’utilisateur, garantie de cohérence dans les droits attribués).
Les gains générés concernent à la fois les utilisateurs internes (gain de productivité) et externes
(amélioration de la qualité du service et de l’image de l’entreprise).
Sur un autre plan, lors d’une fusion ou d’une acquisition, il faut fournir le plus rapidement
possible un accès aisé aux ressources rassemblées d’entreprises auparavant autonomes. Là encore,
une solution de gestion des identités et des droits d’accès aidera à relever ce défi au

6
6
Travers d’un service d’intégration des informations multi-plates-formes permettant de connecter
les systèmes de chaque entreprise à la plupart des systèmes (nouveaux ou préexistants) de la
nouvelle entité.
1.2.4. Amélioration de la sécurité
Un système de gestion des identités et des droits d’accès permet de renforcer la sécurité. Une
telle approche conduit à établir des liens entre toutes les applications, bases de données et
annuaires en s’appuyant sur des notions de rôle et de profil. Cette solution offre un point unique de
gestion des règles de sécurité pour l’ensemble des systèmes concernés. Elle permet de créer
simplement des règles d’accès et de sécurité, en cohérence avec la Politique de Sécurité des
Systèmes d’Information et les besoins métier, puis de les propager automatiquement à tous les
systèmes de l’entreprise.
La gestion centralisée des identités permet d’éliminer une source considérable d’erreurs
d’administration pouvant causer des failles de sécurité d’accès au SI de l’entreprise. Elle permet
également de résilier complètement et immédiatement les droits d’accès sur l’ensemble des
systèmes lorsque des salariés ou personnels extérieurs quittent l’entreprise ou changent
d’affectation et supprimer ainsi les comptes « fantômes ».
En mettant en place des processus maîtrisés d’habilitation, le système permet d’impliquer les
responsables métiers dans le circuit d’habilitation et de ne plus laisser au seul administrateur
technique la maîtrise des droits d’accès.
La figure ci-dessous illustre les flux d’information d’une organisation ayant un système de gestion
des identités et des accès
Figure 1.2 : Flux de mise à jour après la mise en place d’une gestion centralisée

7
7
Chapitre 2 : Les concepts
Dans ce chapitre nous allons présenter les concepts utilisées dans le domaine de la sécurité des
systèmes d’information.
2.1. Les concepts de base
Les concepts de base portent sur les utilisateurs, groupes, profils,… donc il est question
d’expliciter ses notions parfois ambiguë.
2.1.1. Utilisateur
Désigne une personne physique : les employés d’entreprise, les prestataires, les partenaires et
les clients de l’entreprise qui, de par leur fonction, exercent une activité ayant vocation à leur
permettre de bénéficier des applications et des ressources mises à disposition par l’entreprise. Toute
personne déclarée dans un référentiel central de sécurité et de gestion des habilitations est
identifiée par un identifiant unique, un nom, un prénom, une durée de validité, un état (actif ou
suspendu), les périmètres d’accès autorisés….
2.1.2. Compte
À 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 (ou un authentifiant
d’une autre nature), 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’authentification autorisés etc.
Il existe quatre types de comptes :
 Compte global : il est unique à un utilisateur et identifie cet utilisateur dans le référentiel de
gestion des habilitations et est utilisé par tous les processus d’attribution des droits.
 Compte utilisateur : Ce compte donne l’accès à un utilisateur dans un environnement
particulier auquel cet utilisateur est habilité. Exemples : compte d’OS, de NOS, de
messagerie, de LDAP.
 Compte d’administration : Ce compte donne l’accès à un administrateur dans un
environnement particulier. Ce compte n’est pas associé à une personne. Il ne correspond
donc à aucune entrée dans le référentiel central de gestion des habilitations et son usage est
limité aux actes d’administration techniques des applications et environnements.
Chapitre 2 : Les concepts

8
8
 Compte technique ou de service fonctionnel : Ces comptes sont utilisés par les composants
d’un système pour accéder aux services applicatifs et/ou données d’un autre système.
2.1.3. Rôle
Un rôle définit les permissions nécessaires à l’utilisation des objets (applications et/ou des
ressources).Une habilitation donne à un utilisateur un ensemble de permissions dans une
application. Elle est attribuée en fonction du poste opérationnel au sein de l’organisation et non à
titre individuel. C’est le poste opérationnel qui détermine les rôles et les périmètres nécessaires.
2.1.4. Profil
Un profil regroupe un ensemble de rôles nécessaires à l’exécution d’une fonction métier. Le
profil peut également être vu comme un package de rôles applicatifs ou un niveau supérieur dans la
hiérarchie des.
Un utilisateur peut avoir un ou plusieurs profils.
Le profil correspond généralement à la fonction exercée par l’acteur affecté au poste
opérationnel ainsi qu’à son niveau d’expertise. Il peut aussi correspondre à un ensemble
d’habilitations spécifiques.
2.1.5. Poste opérationnel
Le poste opérationnel (position de travail) correspond à une fonction métier exercée au sein d’un
élément de structure (service, département, …). Un poste opérationnel est toujours défini au sein
d’un et un seul élément de structure. Le responsable de structure indique les postes qui lui sont
attribués.
Un poste peut éventuellement être partagé par plusieurs acteurs.
Le poste opérationnel n’est pas modélisé dans le référentiel central.
2.1.6. Groupe
Les utilisateurs peuvent être regroupés, dans le référentiel central, en groupes statiques ou
dynamiques. Ces groupes sont utilisés pour faciliter la gestion en masse des habilitations.
2.1.7. Périmètre
Le périmètre est utilisé par les applications et/ou systèmes pour affiner le contrôle d’autorisation
qu’ils réalisent.
Le périmètre peut être associé à : une personne, un compte (uniquement dans le cas de
limitation des autorisations d’accès à des ressources d’un environnement) et un rôle.

9
9
Le périmètre peut être :
 Temporel : permet de restreindre les possibilités d’accès d’un utilisateur dans le temps en
utilisant une période, une plage horaire ou un calendrier
 Géographique : permet de restreindre les possibilités d’accès d’un utilisateur en fonction du
lieu à partir duquel il accède au SI.
 Fonctionnel : permet de gérer la sécurité applicative : le programme autorisera ou non
certains traitements en fonction des données qui lui seront communiquées par le système
d’habilitation (identifiant acteur, poste de travail, éventuellement lieu de présence ou
d’affectation d’utilisateur, etc.).
2.1.8. Mode d’authentification
Certaines applications critiques imposent un mode d’authentification particulier (authentification
forte). Le système d’authentification fournit (dans le contexte de sécurité) l’information indiquant le
mode d’authentification utilisé lors de l’ouverture de la session. Cette information est exploitée par
le système de contrôle d’accès et /ou l’application.
Le mode d’authentification peut être associé à : un rôle, une ressource.
2.1.9. Ressource
La ressource est définie par : un libellé, les modes d’authentification nécessaires pour y accéder,
les périmètres d’accès autorisés, les rôles ou les groupes de comptes autorisés sur cette ressource.
Une ressource peut être : une ou des adresses IP des serveurs, une URL, une commande de
lancement d’une application….
2.1.10. Environnement de SI
Le terme d’environnement du SI désigne un ensemble de ressources et de processus (système,
sous-système, application, etc.) dont les droits d’accès sont gérés par un système de contrôle unique
et autonome et administré par l’entité responsable.
Exemples : les fichiers, répertoires, files d’attente, services de NOS, les fichiers, répertoires d’OS,
les ressources et les services applicatifs, les messageries et groupware, les bases de données
relationnelles,
2.1.11. Environnement externe
Le terme d’environnement externe désigne un ensemble de ressources et de processus
(système, sous-système, application, etc.) gérés par des tiers et dont les droits d’accès sont gérés par
un système de contrôle autonome et administrés par l’organisme tiers. Dans certains cas le contrôle

10
10
d’accès peut s’appuyer sur les informations de sécurité fournies par le SI de l’entreprise (identité
et/ou rôle).
L’intégration avec ce type d’environnement peut être faite de deux manières :
- délégation complète d’administration des habilitations et d’authentification
- provisioning du référentiel tiers.
Le développement constant des échanges commerciaux entre les partenaires via l’Internet est un
facteur important de multiplication des infrastructures mettant en œuvre ce type d’interaction. Le
besoin des possibilités d’intégration rapide des nouveaux partenaires a stimulé les multiples travaux
de normalisation.
Le concept général d’architecture permettant l’interaction entre les systèmes autonomes des
différents partenaires porte le nom de « Fédération des Identités ».
2.2. Les concepts avancés : Fédération d’identités
La fédération d’identité ou authentification répartie est un partage d’informations d’identité
concernant les utilisateurs d’un établissement avec un ou plusieurs organismes partenaires qui vise à
permettre l’accès à distance contrôlé et sécurisé aux ressources de ces partenaires.
Les solutions de fédération d’identités s’appuient sur quelques concepts tels que :
2.2.1. L’identité fédérée
C’est un ensemble d’attributs fédérés, c’est-à-dire d’informations relatives à l’identité provenant
de différentes sources et pouvant être mises en commun, apporte des gains fonctionnels pour
l’utilisateur : la possibilité de partager son identité entre les différents systèmes, ou pour
l’entreprise ; la possibilité de s’associer avec d’autres partenaires au sein d’une fédération, afin que
les identités d’un domaine puissent donner accès aux services d’un autre domaine sans être obligé
de mettre en œuvre une gestion lourde (et souvent pratiquement impossible) de gestion des
identités des utilisateurs de chaque partenaire.
2.2.2. La répartition des responsabilités
La propagation d’identités et la fédération inter partenaires s’appuient sur une organisation tri
partite
 un fournisseur d’identité (Identity Provider ou IDP) : chargé d’authentifier l’utilisateur et de
gérer son identité (enregistrement, provisioning, gestion de comptes et de mots de passe),
 un fournisseur de services (Service Provider ou SP) : chargé de lui fournir des services en
fonction de ses habilitations sur la base des informations fournies par le fournisseur
d’identités à qui il fait confiance, l’utilisateur.

11
11
2.2.3. Confiance entre les partenaires.
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. Il est primordial que
ces relations de confiance soient établies et gérés sur trois niveaux :
 métier où seront définis les services concernés par la fédération, les engagements de qualité
de service et les conditions de mise en œuvre. En particulier le fournisseur de service pourra
exiger une garantie de fiabilité et de niveau d’authentification de la part du fournisseur
d’identité,
 légal où seront formalisées et contractualisées les exigences métier et définis les moyens et
les procédures de résolution de cas de litiges,
 technique où seront définis les moyens techniques de mise en œuvre des liens sécurisés
entre les sites, les formats de jetons de sécurité et les processus de validation de
l’authenticité des informations échangées.
2.2.4. La gestion d’identités fédérées ou Federated Identity Management
C’est une façon standardisée de gérer de bout en bout le cycle de vie des identités, au sein de
l’entreprise et entre les entreprises,
Son rôle est de:
• étendre les pratiques de gestion des identités de l’entreprise,
• simplifier la gestion des identités au-delà des frontières de l’entreprise,
• faciliter l’intégration métier des partenaires via des relations de confiance et le partage
d’information dans un environnement sécurisé.
Figure 2.1 : la fédération d’identités

12
12
Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information
2ème partie :
La gestion des identités
et des accès pour la
sécurité de l’information

13
13
Chapitre 3 : La gestion des identités
Dans ce chapitre, nous décrivons le concept de l’identité et les modèles de gestion d’identité
traditionnels. Nous détaillons, par la suite, la fédération d’identité qui offre des solutions aux
contraintes sécuritaires imposées par le déploiement d’un réseau distribué. Nous décrivons, en
détail, les langages utilisés pour l’échange de l’information de sécurité dans le cadre d’une
fédération.
3.1. Notions d’identités
3.1.1. Définition
Une identité est une représentation d’une entité dans un domaine d’application spécifique. Il
permet de singulariser, nommer, isoler une entité prise parmi un ensemble.
A priori, on attend d’une identité, qu’elle soit associée à une entité unique : une hypothèse
simplificatrice considère qu’une identité unique ne pourra jamais être associée à plusieurs entités
différentes. Il ne faut pas la confondre avec une identité commune, qui est associée à des entités
élémentaires ayant une relation de groupe. Ainsi, dans une famille l’identité commune est donnée
par le nom de famille, qui devient alors une caractéristique appartenant aux différents membres du
groupe. Dans la mesure où le fournisseur de services est concerné, ce dernier traite l’entité réelle (la
famille) et non pas un ensemble d’individus.
Une entité peut avoir des identités multiples, certaines pouvant être des synonymes. Suivant le
contexte, une entité peut avoir de zéro à N identités. Par exemple, dans une université, une
personne peut avoir deux identités : l’une en qualité d’étudiant parce qu’elle prépare un doctorat,
l’autre en qualité d’enseignant parce qu’elle exerce en qualité d’ATER (Attaché Temporaire
d’Enseignement et de Recherche). Les règles d’enregistrement des identités dans un domaine
spécifique déterminent si une entité a le droit d’avoir plusieurs identités dans ce domaine spécifique.
Une personne peut toujours avoir plusieurs identités dans des domaines différents. Par exemple, une
personne peut avoir une identité associée en tant que client d’une banque et une autre identité
associée car il est employé d’une entreprise.
On comprend dès lors les difficultés sous jacentes qui naissent de la création et de la
manipulation des identités dans un système. Une identité est construite à partir d’un ensemble de
caractéristiques nommées des “identificateurs”. Ces caractéristiques peuvent avoir diverses
propriétés telles qu’être temporaires ou permanentes, auto choisies par l’entité ou bien affectées
par une autorité, avoir une portée limitée à une organisation, ou bien transgresser cette même
organisation.
Les caractéristiques retenues pour la construction d’une identité peuvent être Différentes selon
le type d’entités identifiées. Par exemple, la date de naissance est valable pour des personnes ; par
contre, le numéro national d’enregistrement est valable seulement pour une organisation.
Chapitre 3 : La gestion des identités

14
14
La relation entre entités, identités et caractéristiques/identificateurs est présentée dans ci-dessous :
Figure 3.1 : Entités, identités et identificateurs
La Figure ci-dessus illustre le fait qu’une entité, une personne ou une organisation, peut avoir
plusieurs identités, et où chaque identité est construite à partir d’un ensemble de caractéristiques
qui peuvent être des identificateurs uniques (ou non uniques). La séparation entre les deux notions «
identité » et « identificateurs » n’est pas toujours évidente. Le terme identité est généralement
utilisé dans le sens d’un identificateur spécialement quand l’identité est reconnue par un seul
identificateur dans un contexte donné. Un domaine d’identité est un domaine où chaque identité est
unique. En définissant un espace de noms d’identificateurs uniques dans un domaine, des relations
de type « un à un » entre identités et identificateurs sont possibles. Toutes les caractéristiques des
identités ne peuvent être des identificateurs uniques d’où la nécessité de l’établissement d’un
espace de nom qui soit conforme aux normes.
3.1.2. Utilité et gestion
Au-delà de la construction d’une identité, viennent se greffer toutes les problématiques
associées aux actions que l’on peut exercer en revendiquant cette identité. Le simple fait de disposer
d’une identité, donne un certain nombre de prérogatives vis-à-vis d’une organisation.
Chaque fois qu’un fournisseur de services veut mettre ses services et ses ressources à la
disposition des autres, il doit vérifier l’identité de l’utilisateur demandant le service ou la ressource et
s’assurer qu’il a bien le droit d’utiliser ce service ou cette ressource. Dans ce contexte, la gestion des
identités consiste en l’attribution d’un identificateur unique et d’attributs à l’utilisateur durant la
phase d’enregistrement de ce dernier. Ces identificateurs et attributs sont vérifiés par le fournisseur
de services pour prendre sa décision (autoriser/refuser l’accès de l’utilisateur à la ressource
demandée).

15
15
Plusieurs technologies sont utilisées de nos jours pour gérer les identités dans un domaine de
sécurité ou au moins, permettre aux administrateurs IT des organisations de contrôler les identités
des utilisateurs internes et externes. Nous entendons par gérer une identité le fait de vérifier
l’identité d’une entité à travers des moyens physiques (par exemple, rencontre de l’entité en
question), attribuer à cette entité les accréditations (identificateurs et caractéristiques uniques) et
enfin l’authentifier chaque fois qu’elle désire accéder à un service protégé.
3.2. Modèles de gestion d’identités
Les modèles de gestion d’identité expliquent comment un administrateur donne des
identificateurs aux utilisateurs afin qu’ils soient reconnus et authentifiés par les fournisseurs de
services.
3.2.1. Modèle isolé de gestion des identités
Le modèle de gestion des identités le plus courant permet aux fournisseurs de services d’agir en
tant que fournisseurs d’identificateurs et d’attributs pour leurs clients. Il leur incombe alors de
contrôler l’espace de noms pour la mise en œuvre d’un service donné et d’affecter les identifiants
aux utilisateurs. Un utilisateur recevra un identificateur unique et des attributs pour
l’authentification (par exemple, des mots de passe) ; Si un usager met en œuvre simultanément
plusieurs services, il doit alors recevoir de tels éléments en provenance de chacun des fournisseurs
de services avec qui il communique. Les utilisateurs sont obligés de gérer des identités égales au
nombre de fournisseurs de services qu’ils veulent contacter pour demander des services.
Figure 3.2 : Modèle isolé de gestion des identités
Cette approche fournit des moyens pour une gestion des identités simple par les fournisseurs de
services mais qui devient rapidement ingérable pour les utilisateurs. Ceci rend ces systèmes

16
16
inadaptés aux environnements distribués collaboratifs où le nombre d’utilisateurs et de ressources
partagées ne cesse d’augmenter. En effet, la croissance du nombre de services en ligne induit au fait
que les utilisateurs deviennent débordés par les identificateurs et les attributs qu’ils doivent gérer. La
perte ou l’oubli de ces identificateurs et attributs coûtent chers aux fournisseurs de services qui
doivent mettre en place un centre de support (helpdesk) pour la récupération de ces éléments et
répondre aux demandes des utilisateurs.
3.2.2. Modèle centralisé de gestion des identités
Pour apporter une solution au problème de plus en plus critique d’exploitation des modèles
isolés, on peut alors chercher à centraliser l’information au sein d’un système. Un tel modèle se
décompose alors en un ensemble de sous modèles :
3.2.2.1. Modèle commun de gestion des identités
Pour ce modèle, un seul fournisseur d’identificateurs et d’attributs est utilisé par tous les
fournisseurs de services pour gérer les comptes de leurs utilisateurs. Dans ce cas de figure, une seule
autorité endosse les responsabilités d’identifier, d’affecter et de valider l’identité des utilisateurs
communiquant avec l’ensemble des fournisseurs de services .Un utilisateur s’authentifie auprès de
l’ensemble de fournisseurs de services en utilisant les mêmes identificateurs et attributs.
Figure 3.3 : le modèle commun de gestion d’identités
3.2.2.2. Domaine d’identité avec authentification unique : SSO
Cette approche étend le modèle de gestion des identités commun en permettant aux
utilisateurs de s’authentifier auprès d’un seul fournisseur de services du domaine et d’être par la
suite considérés comme authentifiés auprès des autres fournisseurs. Cette approche est

17
17
communément appelée authentification unique ou SSO parce qu’un utilisateur doit s’authentifier
une seule fois pour accéder à l’ensemble de services offerts par les fournisseurs du domaine
Figure 3.4 : le domaine d’identité avec authentification unique
Un exemple à citer utilisant ce modèle c’est Microsoft Windows Live ID (anciennement .Net
Passport) [Windows Live] qui est une implémentation de SSO pour le commerce électronique.
Windows Live ID permet, grâce à une unique adresse de messagerie et à un mot de passe, de se
connecter sur tous les sites web autorisés. L’affectation d’attributs et l’authentification des
utilisateurs sont deux fonctions centralisées sous le contrôle de Microsoft.
3.3. La fédération d’identités
3.3.1. Principe de fonctionnement
La fédération d’identité *Clusif 2007+ ou authentification répartie est un partage d’informations
d’identité concernant les utilisateurs d’un établissement, avec une organisation partenaire qui vise à
permettre l’accès à distance contrôlé et sécurisé aux ressources de ce partenaire.
La fédération concrétise, pour un groupement d’organisations, l'interconnexion de leurs services
d'authentification et l'utilisation d'un ensemble commun d'attributs utilisateurs.
Un établissement qui gère un ensemble d'utilisateurs (identificateurs et attributs) est appelé
fournisseur d'identités (IdP : Identity Provider). Un fournisseur de services (SP) est une entité (e.g.
établissement, administration, entreprise, etc.) qui propose une ressource numérique en ligne au
sein de la fédération.

18
18
Etablir une fédération d’identité entre organisations revient à définir un cercle de confiance
entre des fournisseurs d’identité et des fournisseurs de services de sorte que ces derniers acceptent
des accréditations émises par les fournisseurs d’identité pour leurs propres utilisateurs
Techniquement, les relations de confiance entre les membres d'une fédération reposent sur des
certificats électroniques et des métas donnés partagées. En outre, la confiance s'établit
administrativement entre les participants de la fédération au travers d'une convention (e.g. signature
de contrats entre organisations).
Une même organisation peut participer à plusieurs fédérations et gérer des partenariats de
manière bilatérale. Elle peut également jouer à la fois le rôle de fournisseur d'identités et de
fournisseur de services. La fédération d'identité est fondée sur deux concepts :
 la délégation de l'authentification qui consiste à authentifier l'utilisateur depuis le service
d'authentification interne (organisation mère de l’utilisateur), et non pas depuis celui du
fournisseur de l'application (fournisseur de service)
 la propagation des attributs utilisateurs qui permet de prolonger depuis l’organisation mère
de l’utilisateur l’exploitation d’un identifiant unique et des attributs de comptes internes afin
de communiquer avec le fournisseur de services.
3.3.2. Objectif de la Fédération d’identité
L’intérêt de l’adoption du principe de fédération d’identité est le fait que la fédération ne fait
qu’utiliser les moyens d’authentification, d’autorisation et de sécurisation implémentés par les
organisations partenaires ce qui favorise un déploiement rapide et à faible coût du réseau
collaboratif en évitant un blocage qui pourrait naître de l’absence d’un mécanisme commun
d’authentification.
Les principaux objectifs d’une fédération d’identité sont :
 L’interconnexion de tout ou partie des Systèmes d’Information des organisations d’une façon
sécurisée et aisée,
 Le partage de ressources de manière contrôlée et sécurisée. De ce fait, elle fournit le moyen
d’échanger de l’information de sécurité entre les domaines de sécurité *Federation 2007+.
Cette information permet de « reconnaître » un utilisateur au niveau du site partenaire et de
prendre la décision d’autorisation (autoriser/refuser l’accès de l’utilisateur à la ressource
demandée). Avec la fédération d’identité, l’hétérogénéité des systèmes d’authentification
(RADIUS, Kerberos, ICP X.509, etc.) des partenaires n’est plus un problème. Chaque
partenaire utilise les systèmes d’authentification et d’accréditation déployés au niveau de
son SI, gère les comptes et les accréditations de ses propres utilisateurs et transmet aux sites
partenaires l’information de sécurité qui sert à la prise de décision d’autorisation.

19
19
3.3.3. Langages pour l’échange de l’information de sécurité
Etant donné que dans le cadre d’un réseau distribué collaboratif, les systèmes déployés sont
plutôt hétérogènes, il s’est révélé indispensable d’exprimer l’information de sécurité dans un langage
qui soit compréhensible par tous les systèmes et les technologies existants : un langage indépendant
des plateformes ce qui permet un meilleur dimensionnement et favorise le passage à l’échelle. Ainsi,
un besoin de langages standardisés, pour l’expression de l’information de sécurité et pour offrir le
moyen de surpasser les limites des plateformes implémentées aux niveaux des sites partenaires, est
né.
L’information de sécurité (preuve d’authentification et les accréditations d’un utilisateur),
échangée entre les sites partenaires, peut être exprimée en utilisant des standards tels que Security
Assertion Markup Language (SAML) ou bien des spécifications telles que Web Services-Federation
(WS-Federation).
Sécurity Assertion Markup Language : SAML
SAML suppose qu’une entité (utilisateur ou application) possède déjà une identité unique gérée
par un IdP qui fournit localement un service pour authentifier cette entité. SAML ne spécifie pas (et
ne s’intéresse pas à) comment le service d’authentification local est implémenté ; c’est de cette
manière qu’il fournit une solution à l’hétérogénéité des systèmes d’authentification implémentés
chez les différentes organisations.
SAML 2.0, dans sa conception, fournit des solutions pour l’authentification unique(SSO),
interaction de Services Web en plus de la fédération d’identité. Ceci, dans le but de faire collaborer
des entités appartenant à des domaines de sécurité différents.
Web Services Fédération : WS-Fédération
WS-Federation, une spécification définie par IBM, Microsoft et d’autres sociétés, propose aux
organisations un moyen pour l’échange d’identités et d’attributs entre systèmes d’authentification et
d’autorisation distribués.
Le cadre de fédération défini par la spécification s’appuie sur la famille de spécifications
destinées aux Services Web WS-*. WS-Federation repose, en particulier, sur WS-Security3 et WS-
Trust4 et définit de nouveaux mécanismes de fédération étendant ces différentes spécifications. En
fait, l’objectif visé par WS Federation est d’aborder les exigences d’identités et de sécurité des
applications et des services Web. Ceci n’était pas un objectif de base lors de la définition du standard
SAML 2.0.
Les mécanismes de fédération définis dans la spécification WS-Federation peuvent être utilisés
par :
- Des Web Services (application cliente) supportant les mécanismes de WS-Security e
- WS-Trust et, pouvant communiquer avec un Web Service (application serveur)
- Des navigateurs Web étant donné que la spécification définit les mécanismes nécessaires à
l’encapsulation de messages WS-* en messages HTTP.WS-Federation adopte une approche
d’émission/d’échange de jetons de sécurité

20
20
En définitive des langages pour l’échange de l’information de sécurité, SAML 2.0 et WS-
Federation sont similaires en termes de fonctionnalités offertes.
Leurs spécifications introduisent les briques nécessaires à la gestion des cas de figures traitant la
fédération d’identité et le Web SSO.
D’un côté, SAML 2.0 est une spécification autonome. Le standard définit les profils et les
protocoles nécessaires à la prise en considération des cas de figures sans s’appuyer sur d’autres
technologies ou spécifications. De son côté, WS-Federation et en raison de son approche
composable, permet le déploiement des cas d'utilisation de différentes manières, mais cela se fait au
détriment de la simplicité. WS-Federation s’appuie sur WS-Trust, WSSecurityPolicy et sur d’autres
standards et spécifications pour traiter un cas d’utilisation. C’est cette approche composable qui
permet à WS-Federation d’être plus adaptée, que le standard SAML 2.0, aux architectures orientées
services (Web Services) en ce qui concerne la prise en considération de contraintes telles que la
propagation de l’identité du demandeur d’un Web Service, la délégation entre Web Services, etc.
3.4. Technologies de gestion d’identités
Parmi les technologies existantes qui fournissent un moyen de contrôler l’identité sans toutefois
être un vrai et un système complet de gestion des identités, nous citons :
3.4.1. Kerberos
Kerberos, créé au Massachusetts Institute of Technology (MIT), est un protocole d’identification
réseau conçu pour fournir un mode d’authentification forte pour les applications clients/serveurs en
utilisant le principe de chiffrement à clé secrète. Kerberos [Kerberos 1996] [Kerberos 2005] utilise un
système de tickets au lieu de mots de passe en texte clair ; ce principe renforce la sécurité du
système et empêche que des personnes non autorisées interceptent les mots de passe des
utilisateurs. Le ticket joue le rôle d'une carte d'identité à péremption assez courte.
L’identification Kerberos est utilisée par des protocoles/applications tels que Windows Server
2000, le serveur Web Apache, le client de transfert de fichiers FileZilla, etc.
Dans cette solution deux points particuliers sont à noter : les mécanismes de Chiffrement
renforcent l’aspect sécuritaire en proposant l’exploitation d’un système de gestion de clés. Le
système de tickets quant à lui offre une décorrélation entre celui qui en réclame l’obtention et
l’usage que l’on peut en faire. A la limite, en supposant que préalablement il y ‘ait eu une usurpation
d’identité réalisée en amont, le pirate peut obtenir très légitimement un droit d’accès à une
ressource sans qu’aucun mécanisme ne permette de revenir en arrière.
3.4.2. Radius
Remote Authentication Dial-In User Service (RADIUS), mis au point par la société Livingston
Enterprises, est un protocole client/serveur permettant de centraliser des données d'identification.
RADIUS [RADIUS 2000a] [RADIUS 2000b] est conçu pour gérer les connexions d'utilisateurs à des
services distants, et notamment ce qui relève de la politique d'autorisation, des droits d'accès et de
la traçabilité. Il base son identification sur le principe du couple nom d’utilisateur/mot de passe.

21
21
Le protocole RADIUS repose principalement sur un serveur RADIUS, relié à une base
d'identification (base de données, annuaire, etc.) et un client RADIUS, appelé Network Access Server
(NAS), faisant office d'intermédiaire entre l'utilisateur final et le serveur. L'ensemble des transactions
entre le client RADIUS et le serveur RADIUS est chiffré et authentifié grâce à un secret partagé. Le
serveur RADIUS peut transmettre les requêtes du client à d'autres serveurs RADIUS.
En termes de sécurité, les données transportées par RADIUS transitent en clair, seul le mot de
passe (de l’utilisateur final) est chiffré.
La sécurité impose la sécurisation des échanges entre les utilisateurs et le serveur par sécurité
physique ou à travers des solutions comme les Réseaux Privés Virtuels (VPN) [Scott et al. 1999].
RADIUS n'offre pas de mécanisme d’identification du serveur; il est alors tentant dans le cadre de
certaines attaques de se faire passer pour un serveur afin de récolter des noms et mots de passe.
Pour remédier à toutes ces faiblesses, des extensions ont été proposées pour RADIUS :
a) Extensible Authentication Protocol (EAP) [Saillard 2003] conçu pour étendre les fonctions du
protocole RADIUS à des types d'identification plus complexes. EAP permet ainsi une
identification mutuelle du client et du serveur.
b) Diameter [Calhoun et al. 2003] qui n'est pas vraiment une extension mais un successeur du
protocole RADIUS, est basé sur Transmission Control Protocol (TCP) alors que RADIUS est en
User Datagram Protocol (UDP)
Diameter utilise des attributs de grande taille et il est destiné aux échanges entre serveurs sur
des liaisons sûres en utilisant Internet Protocol Security (IPsec) et Transport Layer Security (TLS) par
exemple.
RADIUS est conçu pour fonctionner dans des réseaux d’infrastructures explicitement configurés
(réseaux des fournisseurs d’accès Internet, réseaux locaux sans fil, etc.). Il n’est pas adapté aux
réseaux d’ordinateurs et des stations de travail. En plus, il n’offre pas la fonctionnalité
d’authentification unique comme Kerberos.
Le principe de fonctionnement de Kerberos et de RADIUS repose respectivement sur La notion
de tickets et des mots de passe pour l’authentification des utilisateurs auprès des contrôleurs de
domaine (respectivement KDC et le serveur RADIUS). Afin de renforcer le niveau d’authentification
offert par les mots de passe et les tickets de services, la notion de clés publiques et de certificats
numériques est introduit. Clés publiques et certificats numériques sont gérés au niveau
d’infrastructures appelées Infrastructures à Clés Publiques.
3.4.3. Infrastructure à clé publique
Les Infrastructures à Clés Publiques ou PKI sont un ensemble de composants
Physiques (ordinateurs, équipements cryptographiques), de procédures humaines (vérification,
validation) et de logiciels (systèmes et applications) en vue de gérer le cycle de vie des certificats
numériques. Un certificat numérique est une carte d'identité numérique dont l'objet est d'identifier
une entité physique ; c’est un lien entre l'entité physique (le sujet) et l'entité numérique (clé
publique).
Une clé publique est une quantité numérique, attachée à une ressource ou un individu, qui
la distribue aux autres afin qu'ils puissent lui envoyer des données chiffrées ou pour qu’il puisse

22
22
déchiffrer sa signature. A chaque clé publique correspond une clé privée qui va être transmise à
l’entité physique avec son certificat numérique.
Une clé privée est une quantité numérique secrète attachée à une ressource ou à un
individu, lui permettant de déchiffrer des données chiffrées avec la clé publique correspondante ou
d'apposer une signature au bas de messages envoyés vers des destinataires.

23
23
Chapitre 4 : La gestion des accès
Il est évident que la gestion des identités des utilisateurs à elle seule n’est pas suffisante surtout
dans des environnements ouverts où les contraintes de sécurité pèsent énormément sur les
organisations membres. En effet, il ne suffit pas de répondre à la question : « qui peut accéder à la
ressource » mais en plus, il faut préciser « il peut faire quoi une fois qu’il a accédé ».
Les solutions telles que le SSO et la fédération d’identité étudiée dans le chapitre 3 offrent un
certain niveau d’autorisation lié à l’identité de l’utilisateur. En effet, avec le SSO, un utilisateur
s’authentifie une seule fois auprès d’un système et depuis, il peut accéder à tous les autres systèmes
qui sont dans le même domaine de confiance de ce système. De même pour la fédération d’identité
mais avec en plus l’accès à des systèmes qui se trouvent dans d’autres domaines de sécurité. Mais,
de notre point de vue et, dans les cas de figures où les contraintes de sécurité sont énormes, un tel
type d’autorisation n’est pas suffisant et devra être amélioré et renforcé. Dans ce chapitre, nous
expliciterons le concept de contrôle d’accès, puis présenterons les modèles existants de gestion des
accès et enfin nous expliciterons les architectures de gestion d’autorisation utilisées.
4.1. La gestion d’accès : le concept
4.1.1. Définition
Par la gestion des accès, nous entendons les systèmes qui peuvent avoir recours aux services
d'authentification et d'autorisation, afin de mieux maîtriser l'utilisation d'un réseau de ressources.
Chaque ressource, fournie par une organisation, est protégée par des règles qui la rendent accessible
uniquement aux entités ayant les accréditations nécessaires.
4.1.2. Principe de fonctionnement
La gestion des habilitations est basée sur les principes suivants :
 tout accès au Système d’Information est conditionné par une authentification et une
autorisation. L’authentification peut être déléguée à un système tiers de confiance,
 tout acteur du système est déclaré d’une manière unique dans un référentiel central de
sécurité en tant que personne physique et peut disposer de comptes dans différents
environnements et de permissions dans les applications en fonction des habilitations
accordées. La cohérence de ces informations est maintenue automatiquement par le système
de gestion des habilitations,
 toute habilitation est attribuée en fonction du poste opérationnel au sein de l’organisation
et non à titre individuel. Le poste opérationnel détermine les rôles et les périmètres
Chapitre 4 : La gestion des accès

24
24
nécessaires. Le poste opérationnel (position de travail) correspond à une fonction métier
exercée au sein d’un élément de structure,
 un utilisateur peut avoir un ou plusieurs profils. L’attribution se fait en fonction du poste
opérationnel de l’utilisateur,
 un profil regroupe un ensemble de rôles nécessaires à l’exécution d’une fonction métier,
 un rôle définit les permissions nécessaires à l’utilisation d’une application ou des ressources,
 Les définitions des rôles, profils ainsi que l’attribution des profils aux personnes se font via un
outil central qui propage ensuite les informations nécessaires vers toutes les applications et
environnements concernés. L’association personne / rôle applicatif (ou profil applicatif) est
gérée hors application, lorsque l’application l’autorise. Cela permet d’éviter d’avoir à
développer une gestion des droits des utilisateurs dans l’application,
 l’association personne / rôle applicatif est gérée de façon statique et explicite dans l’annuaire
de sécurité (plutôt que de façon dynamique à base de règles de gestion organisationnelles).
L’évaluation des droits, par le système de contrôle d’accès, doit être basée pour l’essentiel
sur la consultation de ce rôle applicatif explicite (pas d’interprétation de règles complexes
dans le processus d’autorisation),
 un contrôle permanent de l’adéquation des profils attribués aux rôles effectifs des
personnes, la définition des droits d’accès aux ressources ou aux groupes de ressources est
administré dans les environnements cibles via les outils natifs de ces environnements. Les
administrateurs locaux continuent de gérer les ressources elles-mêmes et leurs associations
avec les habilitations,
 le contrôle d’accès lui-même est assuré soit par les composants du socle technique (cas de
ressources et applications Web) soit par les mécanismes natifs des environnements (OS,
NOS, messagerie, groupware, etc) soit par les applications.
Il est à noter donc que les informations nécessaires à la gestion des habilitations sont distribuées
dans différents référentiels. On distingue :
a. le référentiel des habilitations, référentiel mis à jour lors de la gestion des utilisateurs,
des habilitations et des mots de passe,
b. les annuaires de sécurité, qui ne contiennent qu’une partie des données du référentiel
des habilitations (par exemple, les profils n’y figurent pas) et sont utilisés par les services
d’authentification et d’autorisation, tels que :
o Systèmes d’exploitation,
o Sous systèmes de gestion des droits,
o LDAP,
o NOS (Network Operating Systems) et systèmes de partage des fichiers,
o Messageries et systèmes collaboratifs.

25
25
4.2. Modèles de gestion d’accès
4.2.1. Modèle RBAC
Le modèle de sécurité RBAC (Role Based Access Control) est principalement issu d'Internet afin
de prendre en compte des applications déployées sur de vastes organisations ou des applications
inter-organisations (Extranet par exemple). Ce modèle permet en particulier de simplifier
l'administration des droits et de prendre en compte la délégation de l'administration.
Le modèle RBAC modélise des fonctions métiers plutôt que des accès à des ressources
informatiques. Un rôle correspond à une fonction au sein d'une organisation. Le principe de base du
RBAC est que deux utilisateurs ayant les mêmes rôles ont les mêmes droits sur le système.
Modèle RBAC de base
Le standard propose un modèle de base (Core RBAC) ainsi que les extensions présentées dans
les sous-chapitres suivants.
Les concepts manipulés par le modèle RBAC sont les suivants : USERS (utilisateurs), ROLES, OBS
(objets), OPS (opérations), PRMS(Permissions), SESSIONS.
Suivant le schéma ci-dessus :
Figure 4.1 : Modèle RBAC de base
Principe de privilège minimum
Le fonctionnement de ce modèle et l’intégrité du système sont garantis si l’attribution des
permissions respecte le principe de privilège minimum.
Ce principe exige que l’utilisateur ne dispose pas de plus de droits que nécessaire à son travail.
Ce qui implique que les permissions affectées à un rôle constituent le strict minimum nécessaire à
l’accomplissement des tâches relatives à ce rôle.

26
26
Modèle RBAC hiérarchique
Le modèle RBAC hiérarchique (Hierarchical RBAC) ajoute au modèle de base le support de
hiérarchie des rôles.
La hiérarchie établit les liens de parenté entre plusieurs niveaux des rôles et permet aux rôles «
parents » de disposer des permissions attribuées aux rôles « enfants ».
Le standard admet deux types de hiérarchies :
a) Le modèle hiérarchique général (General Hierarchical RBAC) : cette variante établie des
relations multiples entre plusieurs « parents » et « enfants »,
b) Le modèle hiérarchique limité (Limited Hierarchical RBAC) : cette version limite la
relation à une simple structure d’arborescence. Ce qui veut dire qu’un rôle ne peut avoir
qu’un seul « parent ».
Cette extension du modèle permet une administration plus efficace dans les grandes structures
qui gèrent de très nombreuses permissions d’un grand nombre d’utilisateurs. D’autre part ce
principe permet de bien gérer les situations où certains rôles différents (du niveau supérieur) doivent
bénéficier de certaines permissions communes.
Modèle RBAC avec contraintes
Le modèle RBAC avec contraintes (Constrained RBAC) ajoute au modèle la contrainte de
séparation des pouvoirs. Cette contrainte permet d’inclure dans le modèle la gestion de conflits
d’intérêts et assurer que les utilisateurs bénéficieront des permissions selon la politique définie par
l’organisation et ne pourront pas abuser de cumul non contrôlé de droits.
a) Séparation Statique des Pouvoirs (SSD - Static Separation of Duty Relations)
La contrainte de séparation des pouvoirs est utilisée pour assurer le respect de la politique des
habilitations. Un conflit d’intérêts peut arriver (dans un système du type RBAC) quand l’utilisateur
obtient simultanément les droits associés à des rôles incompatibles.
L’exclusion mutuelle de certains rôles est spécifiée par les règles de SSD. Ces règles sont
interprétées lors du processus d’affectation des rôles par l’administrateur et l’empêchent d’affecter
des rôles incompatibles au même utilisateur. De cette manière, à une personne qui bénéficie d’un
rôle, on ne pourra pas affecter un deuxième rôle interdit par la règle de SSD.
b) Séparation Dynamique des Pouvoirs (DSD - Dynamic Separation of Duty Relations)
La séparation dynamique limite comme la SSD les rôles accessibles à un utilisateur. Par contre le
contexte est différent. La limitation n’est pas exploitée au moment de l’affectation des rôles mais au
moment de leur activation dans une session. Dans une même session, un utilisateur a la possibilité
de ne pas activer tous ses rôles, mais uniquement le sous-ensemble de ses rôles nécessaires à la

27
27
réalisation de la tâche à accomplir. Ce mécanisme permet de garantir l’application des permissions
minimales nécessaires dans une période d’exécution d’une tâche. On peut parler, dans ce contexte,
de révocation temporaire des privilèges. La mise en œuvre de ce mécanisme peut se révéler très
complexe et le plus souvent n’est pas réalisée.
4.2.2. Modèle MAC
En opposition avec le DAC où le propriétaire d’une ressource jouit de tous les droits sur une
ressource qu’il a créée, le modèle Mandatory Access Control est utilisé quand la politique de sécurité
d’une organisation définit que :
a) les décisions de protection d’une ressource ne doivent pas être sous la responsabilité de
son propriétaire,
b) le système doit mettre en œuvre les mécanismes permettant de respecter la politique de
sécurité et interdire au propriétaire d’une ressource d’agir à sa guise.
Afin d’aboutir à ces principes, ce modèle introduit la notion d’accès aux ressources en regard de
la sensibilité des informations qu’elles contiennent et repose sur la labellisation systématique de ces
ressources et des utilisateurs du système considéré. En hiérarchisant ces entités en plusieurs niveaux
de confiance et sensibilité, puis en les labélisant en conséquence, on aboutit à une décomposition à
laquelle il faudra ensuite ajouter des règles d’accès. On notera qu’un système informatique adhérant
à ce principe est dit multi-level security (MLS).
Les labels suivent une logique hiérarchique (ex: Confidentiel, Secret, Très secret, non classifié) et
décrivent ainsi différents niveaux d’habilitation. Les droits d’accès aux ressources sont attribués en
fonction du niveau d’habilitation de l’utilisateur et sont définis selon la problématique de sécurité à
adresser : Confidentialité ou Intégrité.
4.2.3. Modèle DAC
Le DAC (Discretionary Access Controls) est un modèle conceptuel dont le principe est de limiter
l’accès à des objets en regard de l’identité des utilisateurs (humain, machines, etc.) et/ou des
groupes auxquels ils appartiennent. Les contrôles sur une ressource sont dits discrétionnaires dans le
sens où un utilisateur avec une autorisation d'accès définie est capable de la transmettre
(indirectement ou directement) à n'importe quel autre utilisateur.
Ce modèle est principalement utilisé au sein d’implémentations informatiques car les notions
développées sont surtout adaptées à la gestion d’accès sur des ressources informatiques. Ainsi, les
implémentations adhérant à ce concept, doivent mettre en œuvre des mécanismes permettant
d’enregistrer un ensemble de droits d’accès ou d’actions représentées sous la forme d’une matrice
de contrôle d’accès.
Fichier Gisèle Fichier Danny
Gisèle rwx r
Léa r
Danny r rwx

28
28
Parmi les différentes implémentations réalisées, les plus connues sont :
 Protection Bits: Popularisée par les systèmes Unix, cette implémentation représente la
matrice de droits d’accès par colonne. Son principe consiste à définir pour une ressource
si elle est partagée pour tous les utilisateurs, un groupe ou seulement son propriétaire,
 Access Control Lists (ACLs): Le principe des ACLs implémente la matrice de contrôle
d’accès par colonne en créant des listes d’utilisateurs pouvant accéder à la ressource
et/ou des listes d’utilisateurs interdits d’accès à celle-ci,
 Capabilities: Comme pour les ACL une liste est créée, mais elle est liée à un utilisateur et
non à une ressource, ainsi la représentation de la matrice est faite par ligne.
4.3. Architectures de gestion d’accès
4.3.1. Architectures AAA
Une architecture d’autorisation doit complémenter le concept de fédération d’identité que nous
avons adopté pour l’échange d’information de sécurité sur les utilisateurs entre les fournisseurs
d’identité et les fournisseurs de services.
Des architectures d’autorisation bâties autour d’un serveur unique qui assure des fonctionnalités
d’authentification, d’autorisation et de comptabilité (AAA : Authentication Authorization Accounting)
se révèlent comme une solution possible pour répondre aux besoins relevés en termes de gestion
d’accès (qui a droit de faire quoi, comment et dans quelles circonstances).
Les entités de base qui participent à une autorisation dans le cadre d’une architecture AAA sont :
- Un utilisateur qui demande un service,
- L’organisation de tutelle de l’utilisateur concomitante du contrat établi et qui doit vérifier
sous une forme active ou passive si l’utilisateur est habilité ou non à déclencher l’exécution
du service,
- Le serveur AAA du fournisseur de services qui autorise l’accès au service en se basant sur le
contrat signé avec l’organisation mère de l’utilisateur et
- L’équipement du fournisseur de services dédié à l’approvisionnement du service
Ce concept de serveur AAA permet de faire la rupture définitive entre services d’authentification
et d’autorisation d’un côté et les applications gérées d’un autre côté mais, ça reste une solution de
gestion centralisée.

29
29
Figure 4.2 : Architecture AAA
4.3.2. Infrastructures de gestion à base de politiques
Les systèmes de gestion à base de politiques sont une solution de remplacement des ACLs
intégrées habituellement aux applications gérées. Elles rendent la gestion plus dynamique et
évolutive. Avec une telle approche, pour une autorisation efficace, deux actions doivent être
réalisées :
- Une décision d’autorisation doit être prise après consultation de politiques et,
- La décision doit être appliquée.
Ces deux fonctions sont accomplies par deux entités distinctes nommées
Respectivement PDP (Policy Décision Point) et PEP (Policy Enforcement Point).
Un PDP est une entité logique qui prend des décisions d’autorisation en considérant les
informations suivantes :
o La ressource demandée et l’action requise (consultation, modification, etc.),
o L’entité qui demande la ressource et,
o La politique qui gère l’accès à la ressource.
Un PEP est une entité logique qui applique la décision d’autorisation prise par le PDP. C’est le PEP
qui réalise techniquement l’attribution ou le refus d’une demande d’accès à une ressource. Les
interactions entre PDPs et PEPs peuvent suivre l’un des modèles suivants :
 Modèle Agent, permet à l’utilisateur d’adresser sa requête de demande de ressource, à une
partie tierce (le serveur d’autorisation : PDP/PEP). Ce dernier joue le rôle d’agent entre
l’utilisateur et l’équipement fournissant le service.
 Modèle Push, L’utilisateur adresse sa requête directement au fournisseur de service (i.e. la
ressource demandée) et en particulier, au serveur d’autorisation (PDP) qui gère l’accès à la
ressource
 Modèle Pull. Le modèle Pull laisse la responsabilité de la récupération de l’information
d’autorisation au PEP seul. Une fois que l’utilisateur a demandé l’accès à une ressource

30
30
4.3.3. Infrastructures de gestion des privilèges
Une IGP fournit un cadre d’autorisation basé sur les attributs des utilisateurs pour gérer les
accès aux ressources et aux services. L’utilisation de certificats d’attributs rend le service
d’autorisation plus flexible et rigide et, c’est pour cette raison que nous avons adopté le concept
d’IGP pour bâtir une architecture de contrôle d’accès.
Une IGP fournit un cadre dans lequel il est possible d’appliquer la politique d’autorisation
d’accès ou d’attribution au niveau des applications ou des ressources en fonction du rôle des
utilisateurs ou de leur appartenance à un groupe. Un rôle dépend de la position de l’utilisateur (e.g.
ingénieur, cadre, technicien) dans son organisation de rattachement. Le processus de définition de
rôles est fondé sur une analyse approfondie de la façon dont fonctionne une organisation et intègre
une contribution d'un large éventail d'utilisateurs dans une organisation.
En d’autres termes, une IGP permet l’allocation, la délégation, la révocation et le retrait des
privilèges ou droits des utilisateurs d’une façon électronique.
Au sein d’une Infrastructure de Gestion de Privilèges, des politiques de contrôle d’accès gérant
l’accès aux ressources protégées doivent être définies, évaluées et appliquées. Ces politiques de
contrôle d’accès viennent remplacer les listes de contrôle d’accès (ACLs) qui étaient définies et
intégrées aux ressources auxquelles elles s’appliquent.

31
31
Troisième partie : Implémentations et expérimentations
3ème partie :
Implémentations et
expérimentations

32
32
Chapitre 5 : Les solutions de contrôle d’accès
Dans ce chapitre, il sera question d’étudier quelques logiciels de gestion d’identités et des droits
d’accès qui sont présents actuellement sur le marché, tant sur l’environnement windows et
l’environnement linux.
5.1. Architectures de gestion d’accès
De nombreuses offres de solutions de gestion des identités et des droits d’accès existent sur le
marché ; et de plus en plus d’entreprise ont du mal à faire un choix de solutions optimales en
présence de ces nombreux logiciels d’IAM.
Cependant une solution de gestion d’accès doit respecter au minimum certains critères et c’est à
partir de ces critères que le choix des logiciels présentés ci-dessous s’est opérer. Parmi les critères de
choix d’une solution de gestion des identités et des accès nous avons retenus:
 Facilité de déploiement et de configuration
Ce critère est intéressant car il n’est pas question de demander à l’entreprise de modifier la
structure de son système d’information. La solution devra être déployé et configuré facilement
indépendamment de l’existant.
 Approche adoptée pour gérer la fédération
Ce critère permet d’évaluer la facilité de l’intégration de l’outil à l’existant dans l’entreprise et
définir la stratégie de déploiement de l’outil dans l’infrastructure TI.
 Conformité au langage d’échange de l’information SAML 2 et WS-Federation
Un outil qui ne supporte pas les langages SAML ou WS-Federation, ne pourra pas être utilisé
sinon un problème d’hétérogénéité surgit.
 Possibilité de fédérer l’identité entre les web-services
Ce critère permet d’évaluer l’efficacité de l’outil car un jour ou l’autre, les organisations auront à
traiter des identités dans le cadre d’architectures orientées services.
 Le coût de la solution
Ce critère est toujours critique dans le choix d’une solution à déployer par les organisations.
 Support pour différents systèmes hétérogènes
Chapitre 5 : Les solutions de
contrôle d’accès

33
33
Un outil de fédération qui va s’intégrer au SI d’une organisation doit supporter les systèmes
d’authentification déployés et utilisés jusqu’à présent par l’organisation. Une remise à zéro ne sera
jamais acceptée.
 Niveau de sécurité offerte
Ceci présente un critère critique pour les organisations qui vont accepter d’ouvrir leurs SI aux
partenaires en s’appuyant sur l’outil de fédération. En aucun cas, les organisations n’accepteront de
se baser sur une solution de fédération pouvant leur risquer la perte de leurs actifs.
 Respect de la vie privée
Ceci pourrait être critique ou pas, tout dépend de la stratégie adoptée par les partenaires
concernant la conservation de la vie privée des entités communicantes.
5.2. Les solutions de gestion d’identités et de droits d’accès
5.2.1. Les solutions propriétaires
Tivoli Identity management d’ IBM
IBM Tivoli Identity Manager est une solution d'applications des accès utilisateur basée sur des
règles qui gère les rôles, identités et droits d'accès des utilisateurs dans toute l'infrastructure
informatique. Ce logiciel sécurisé de gestion des identités est facile à déployer et à utiliser. Il permet
aux organisations de se mettre en conformité avec les réglementations, de gérer les risques et
autorise une collaboration sécurisée.
Tivoli Identity Manager permet de réaliser des économies et d'améliorer la productivité grâce à
l'automatisation, le libre-service utilisateur et d'autres innovations.
IBM propose aussi la solution pour l’identité fédérée dénommé Tivoli Federated Identity
Manager (TFIM).
Identity & accès management d’Evidian
Des centaines de milliers d'utilisateurs accèdent à leurs applications chaque jour par
l'intermédiaire des solutions de gestion de l'authentification d'Evidian. Le single sign-on (SSO)
simplifie leur travail car ils n'ont pas besoin de mots de passe pour accéder à leurs applications. Cela
réduit considérablement la charge du help desk, assurant un retour sur investissement rapide. Les
accès aux PC et aux applications peuvent faire l'objet d'une authentification forte par carte à puce,
badge radio, biométrie ou mot de passe à usage unique. La demande de mot de passe en self-service
(SSPR) rend les utilisateurs autonomes : les employés en déplacement ne sont jamais bloqués parce
qu'ils ont oublié leurs données d'authentification.
Avec les solutions IAM d'Evidian, les entreprises déploient la gestion des identités et un
workflow d'approbation pour s'assurer que les utilisateurs individuels respectent la politique d'accès
aux applications. Les solutions d'Evidian sont conçues pour être adaptables et compatibles avec les

34
34
processus d'entreprise, notamment en termes de disponibilité et de mobilité. Ainsi, la sécurité
renforce l'activité de l'entreprise.
Oracle Identity and accès management
La suite complète d'Oracle offre le meilleur retour sur investissement : sécurité accrue, coûts
administratifs allégés, grande évolutivité et la garantie de support d'un leader du marché. Les
solutions offertes de sont :
 Oracle Access Management Suite Plus
 Oracle Access Manager
 Oracle Adaptive Access Manager
 Oracle Directory Services Plus
 Oracle Enterprise Single Sign-On Suite
 Oracle Entitlements Server
 Oracle Identity Analytics
 Oracle Identity Federation
 Oracle Identity Manager
 Oracle Identity & Access Management Suite Plus
 Oracle Information Rights Management
 Oracle Management Pack for Identity Management
 Oracle Role Manager
 Oracle Security Governor for Healthcare
 Oracle Web Services Manager
Oracle Identity and accès management est présenté comme l’offre de solutions la plus
complète.
Services Active directory de Microsoft
Les services Active Directory sont utilisés dans la plateforme système Windows server et
incluent :
 Les services de certificats Active Directory (AD CS),
 Les services de domaine Active Directory (AD DS),
 Les services AD FS (Active Directory Federation Services),
 Les services AD LDS (Active Directory Lightweight Directory Services) et les services AD RMS
(Active Directory Rights Management Services).
Ces services seront expérimentés dans le chapitre suivant

35
35
5.2.2. Les solutions propriétaires
Plusieurs solutions libres existent mais de nombreuses critiques sont apportés notamment :
souvent hétérogènes et non-interopérable, complexes à mettre en œuvre, souvent de qualité
médiocre, souvent mal supportées, souvent peu industrialisés, souvent peu robuste.
Cependant, Nous avons pu étudier quelques des solutions open source de gestion d’identité et
d’accès :
Internet2 shibboleth
Shibboleth est une suite de logiciels développée par le consortium Internet2, fournissant une
solution complète de fédération d’identités.
Les trois briques Shibboleth sont le fournisseur de services, le fournisseur d’identités et le
service de découverte (ou WAYF).
Le fournisseur de services est un module d'authentification pour le serveur Web ; il permet de :
- déléguer l'authentification des utilisateurs à un fournisseur d'identités ;
- transmettre le profil utilisateur ;
- gérer le contrôle d'accès de manière optionnelle.
Le fournisseur d'identités est une application Java (servlet) ; il permet de gérer l'authentification
des utilisateurs, en réponse à la requête d'un fournisseur de services. L'authentification peut être
déléguée à un serveur CAS (Central Authentication Service) : l'authentification se fait par login/mot
de passe ou certificat électronique ou encore propose les deux ; les attributs de l'utilisateur sont
extraits d'un annuaire LDAP, d'une base SQL ou bien calculés, puis propagés au fournisseur de
services.
Le service de découverte (WAYF) permet à un utilisateur de sélectionner son organisme de
rattachement, c'est-à-dire celui auprès duquel il pourra s'authentifier. Le service de découverte
propose un menu déroulant à l'utilisateur avec la liste des fournisseurs d'identités reconnus.
FederID
FederID est une solution qui intègre les projets libres suivants :
- Authentic : un fournisseur d'identités basé sur lasso (Liberty Alliance SSO) capable d'utiliser
un annuaire LDAP comme base d'authentification.
- LemonLDAP::NG : un portail SSO compatible Liberty Alliance, dont les autorisations sont
gérées directement dans l'annuaire LDAP.
- InterLDAP : un outil de gestion de contenu d'annuaires LDAP et fournisseur d'attributs sur un
cercle de confiance Liberty Alliance.

36
36
OpenIAM
Multiplate-forme (Unix, mac,windows), openIAM est la solution open source de gestion d’accès
et d’identité qui fournit les services tel que : provisionning, gestion des mots de passe, administration
déleguée, synchronisation active, moteur de workflow… Elle inclut les connecteurs pour LDAP,
Active Directory, Google Apps et les bases de données relationnelles.

37
37
Chapitre 6 : Implémentation d’une solution de contrôle d’accès
Dans ce chapitre, il sera question de présenter la solution de contrôle d’accès Active Directory et
ses services et de le mettre en œuvre par son déploiement.
6.1. Environnement de travail
La solution Active Directory est implémentée dans l’environnement serveur Windows Server
2008 R2.
Pour ce qui est de Windows Server 2008 R2, la version Windows Serveur 2008 R2 Edition Enterprise
a été utilisé.
Nous avons installé ce système serveur en dual boot sur une machine physique aux
caractéristiques telles que nous la voyons sur la copie d’écran :
Figure 6.1 : Information système générale
Nous avons bénéficié des nouvelles fonctionnalités de Windows Server 2008 R2 tel que Hyper-V
pour virtualiser les rôles de serveur et client sous forme de machines virtuelles séparées s’exécutant
sur l’unique ordinateur physique, sans avoir à acquérir un logiciel tiers.
Pour cela, nous avons créé 03 machines virtuelles (01 serveur et 02 clients) :
Les caractéristiques d’un poste serveur sont :
• Matériel : Processeur 1 Ghz, RAM 512 Mo, DD 40 Go, architecture 64bits
• Logiciel : Windows Server 2008 R2 Edition Entreprise
Les caractéristiques d’un poste client sont :
• Matériel : Processeur 1 Ghz, RAM 512 Mo, DD 20 Go, architecture 32bits
• Logiciel : Windows XP, Windows 7
Chapitre 6 : Implémentation d’une
solution de contrôle d’accès

LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE ORGANISATION

LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE ORGANISATION

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE ORGANISATION

Similar a LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE ORGANISATION (20)

LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE ORGANISATION