Constitution d'un référentiel d'identités

Transcription

1 Constitution d'un référentiel d'identités Best Practice Document Document rédigé par le groupe de travail «Gestion des identités» animé par le GIP RENATER (BPD R4.1) Auteurs: Jean Benoit - jean@unistra.fr (Université de Strasbourg/GIP RENATER) Pascal Colombani - pascal.colombani@education.gouv.fr (Ministère de l éducation nationale, de l enseignement supérieur et de la recherche/gip RENATER) Jean-Philippe Floret - jp.floret@univ-amu.fr (Aix-Marseille Université/GIP RENATER) Nicolas Romero - nicolas.romero@ac-orleans-tours.fr (Ministère de l éducation nationale, de l enseignement supérieur et de la recherche/gip RENATER) Olivier Salaün olivier.salaun@renater.fr (GIP RENATER) Alain Zamboni - alain.zamboni@unistra.fr (Université de Strasbourg/GIP RENATER) V1-27/11/14

2 GIP RENATER 2014 TERENA All rights reserved. Document No: GN3plus-NA3-T2-R4.1 Version / date: V1-27/11/14 Original language : French Original title: Constitution d'un référentiel d'identités Original version / date: V1-27/11/14 Contact: cbp@listes.renater.fr RENATER bears responsibility for the content of this document. The work has been carried out by a RENATER led working group on metropolitan network as part of a joint-venture project within the HE sector in France. Parts of the report may be freely copied, unaltered, provided that the original source is acknowledged and copyright preserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/ ) under grant agreement n , relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'. 2

3 Table des matières Executive Summary 5 Introduction 6 1 Éléments de la gestion des identités Gestion des personnes (People Management) Référentiel des personnes (People Data Store) Référentiel des structures organisationnelles (Units Data Store) Référentiel des comptes (Accounts Data Store) Référentiel de groupes d'utilisateurs (Groups Data Store) Applications finales offrant des services (IT Services) Exemples d implémentation 10 2 Constitution d'un référentiel de comptes Analyser l existant Inventorier ses populations Inventorier les services potentiellement consommateurs d un référentiel de compte Analyser et prioriser Créer le référentiel de comptes Constituer son modèle Choisir la technologie Infrastructure technique 18 3 Cycle de vie et provisioning des identités Alimenter le référentiel de comptes Choix du mode d échange (R)évolution des processus métiers Gestion du référentiel de comptes Processus d activation Mises à jour Durée de vie et expiration Les identifiants Longueur des identifiants Format des identifiants Identifiant dédié à la connexion Recyclage 24 3

4 Conclusion 25 Références 27 Glossaire 28 Terminologie anglaise 29 4

5 Executive Summary Ce document propose une approche pour mettre en place le référentiel d'identités d un établissement d enseignement et de recherche. Le référentiel d'identités se positionne entre les applications produisant des identités en amont et les applications consommant les identités en aval. Nous recommandons un découpage fonctionnel du référentiel d'identités en deux couches. D une part, le référentiel des personnes et le référentiel des structures organisationnelles qui agrègent les données issues des applications sources et permettent de croiser, réconcilier et consolider ces données. D autre part le référentiel des comptes et le référentiel des groupes qui sont directement exploités par les applications consommant les identités. La constitution du référentiel d'identités nécessite une analyse de l existant ; nous proposons une méthode pour inventorier les populations, inventorier les applications gérant chaque population et évaluer les recouvrements de populations. L étape suivante consiste à définir un modèle de données, incluant des informations qui décrivent les personnes et des méta-informations associées (date d expiration, état, source de données). Un annuaire LDAP est un choix adapté pour mettre en œuvre le référentiel des comptes. La gestion des identités vise à automatiser le provisioning des identités. On peut envisager plusieurs modes de synchronisation entre les référentiels et leurs sources de données: la synchronisation batch complète, la synchronisation batch différentielle ou la synchronisation évènementielle. Cette automatisation va de pair avec la définition des processus d activation des comptes, de leur mise à jour, de leur expiration. La manipulation des identités implique l utilisation d identifiants permettant de faire référence à un utilisateur. Nous présentons différents formats d identifiants utilisables (nominatif, opaque et mixte) en évoquant les atouts et inconvénients de chacun. L identifiant de connexion est présenté comme une solution pour concilier ergonomie utilisateur et utilisation d identifiants opaques. Dans la mesure où ils sont associés à des droits applicatifs, les identifiants ne doivent pas être réassignés à un autre utilisateur. 5

6 Introduction On entend par identité numérique l'ensemble des informations concernant un utilisateur : les éléments permettant de l'identifier et l'authentifier (alias de login, mot de passe, certificat), les informations permettant des contrôles d'accès (identifiant, profil d'utilisateur, privilèges, groupes) et plus généralement les informations qui décrivent l'utilisateur (nom, prénom, adresse ). Chaque application gère certaines de ces données. Dans le contexte d'un système d'informations d'établissement, il est nécessaire de garantir la cohérence de ces identités au niveau global afin d'éviter les doublons, définir les profils des utilisateurs, contrôler la durée de vie des identités. Ce document propose une approche pour mettre en place le référentiel d'identités d un établissement d enseignement et de recherche. Nous évoquons également les questions liées au cycle de vie des identités (alimentation, expiration des comptes, format des identifiants). 1 Éléments de la gestion des identités La gestion des identités est une problématique complexe et transverse. Elle comprend évidemment la mise en place d'une infrastructure technique dédiée, mais le défi majeur de cette problématique réside dans les processus de gestion des identités: la création, mise à jour et suppression des données d'identités ont des impacts majeurs au-delà du simple référentiel d'identités. Le schéma suivant illustre cette notion en présentant les différents éléments fonctionnels d un système de gestion des identités ainsi que les flux majeurs théoriques de circulation d'information entre eux. Ces éléments seront explicités dans la suite de ce chapitre. 6

7 Figure 1 - Functionnal elements of Identity Management 7

8 1.1 Gestion des personnes (People Management) Les applications de gestion de personnes sont productrices d'informations de référence sur une personne. Elles ont une importance majeure dans le sens où elles seront les sources de données permettant d'automatiser de nombreux processus de gestion des identités. Sources de données autoritaires Dans un système d'information idéal, on ne devrait avoir qu'une source de données autoritaire pour chaque type de personne géré. Exemples de populations : étudiants, enseignants, administratifs, chercheurs, anciens diplômés. 1.2 Référentiel des personnes (People Data Store) Le référentiel des personnes est l élément fonctionnel garantissant la qualité des données de personnes au sein de l'établissement. Il contient des données métiers, mais il a essentiellement vocation à améliorer le fonctionnement global du système d'informations. Il s'agit donc d'un élément nécessitant une étroite collaboration entre la Direction des Systèmes d Informations et les directions métiers. Quelques exemples de fonctionnalités d un référentiel de personnes: dédoublonnage d entrées concernant une même personne, issues des différents applicatifs de gestion de personnes, croisement et réconciliation des données produites par les applications de gestion des personnes. Quand déployer une application spécifique comme référentiel de personnes? Un référentiel de personnes dédié devient pertinent lorsque les deux conditions suivantes sont réunies : plusieurs populations différentes, gérées par des applications différentes et étanches entre elles, présentent un taux de recouvrement significatif, l établissement a besoin de croiser les personnes entre ces applications : offrir un accès unique aux services authentifiés, disposer d une fiche personne recensant l ensemble des données de personnes. Dans cette situation, la démarche de mise en place d un référentiel des personnes implique encore plus fortement les directions métiers que le simple provisioning mono-source. En effet, la qualité et la cohérence des données ne sont plus simplement à garantir entre deux parties (référentiel de comptes et une application de gestion), mais entre toutes les parties (le référentiel des personnes et toutes les applications de gestion). Il s agit donc d un projet transversal d établissement mobilisant tous les processus de gestion de personnes de l établissement. Il est donc susceptible d être victime d une 8

9 inertie forte. Pour cette raison, nous recommandons généralement d entamer cette démarche après le déploiement d un référentiel de comptes qui permettra, lui, d offrir un service opérationnel plus rapidement. 1.3 Référentiel des structures organisationnelles (Units Data Store) Cet élément fonctionnel a le même objectif que le référentiel des personnes, mais pour les structures organisationnelles de l'établissement. Il contribue à la gestion des identités en permettant l'obtention des rôles des personnes au sein de l'établissement dans la mesure où ces rôles sont relatifs à une structure. De ces rôles pourront découler des autorisations pour l accès aux services utilisateurs. Il est en forte interaction avec le référentiel des personnes, et en conséquence souvent géré par le même applicatif. 1.4 Référentiel des comptes (Accounts Data Store) Cet élément fait office de base centralisée des utilisateurs de services authentifiés offerts par l'établissement. Il a pour vocation première d authentifier et d identifier les utilisateurs se connectant aux services. Il peut également fournir des informations permettant d autoriser l accès aux services restreints. Il est destiné à être utilisé par le plus grand nombre possible de services. Autres modes d authentification Pour simplifier la compréhension, le présent document traitera essentiellement de référentiel de compte basé sur une authentification par couple identifiant/mot de passe, mais son contenu reste valide pour tout autre type d authentification. Utiliser le référentiel de comptes Avantages : simplifie l'exploitation des comptes utilisateur dans l'applicatif final, simplifie l'expérience utilisateur et la sécurité : un seul mot de passe à retenir, donc moins de post-it, réduit les échanges directs entre services IT et applications de gestions de personnes. Inconvénients : l indisponibilité du référentiel des comptes bloque le fonctionnement de toutes les applications qui l utilisent, une compromission de compte a un impact potentiellement élevé, en donnant accès à un ensemble d'applicatifs. 1.5 Référentiel de groupes d'utilisateurs (Groups Data Store) Cette fonction vise à centraliser les groupes d'utilisateurs et à les rendre disponibles aux services finaux. Elle est dépendante du référentiel des comptes, car elle fait référence aux identités. Selon les stratégies 9

10 d'établissement, cet élément peut ne pas exister ou même cohabiter avec des informations métiers présentées par le référentiel des comptes (voire directement par le référentiel des personnes). Utiliser le référentiel de groupes Avantages : l application finale n a pas besoin d offrir une fonctionnalité de gestion de groupes ; la garantie d'une cohérence des groupes d'utilisateurs entre les applicatifs ; l'abstraction d'une information métier, propre à l'établissement, vers une donnée technique, respectant un standard interopérable. Exemple (groupe Unix): Jean Dupont est étudiant en licence 3 de mathématique devient l3math: jdupont. Inconvénients : perte de souplesse et d indépendance dans les applications finales. 1.6 Applications finales offrant des services (IT Services) Ces services finaux sont les consommateurs du référentiel des. Ils ne produisent aucune donnée de référence sur les utilisateurs. Si cela devait être le cas, ils deviendraient également des gestionnaire de personnes. 1.7 Exemples d implémentation Il faut noter que les éléments décrits ici sont fonctionnels et non des briques applicatives. Il semble théoriquement judicieux que chaque élément fonctionnel soit implémenté par une seule application. Mais, selon le contexte de l'établissement (taille, existant, organisation, stratégie SI, etc.), l architecture peut être différente tout en restant efficace. Une même application pourra ainsi avoir plusieurs rôles dans la gestion des identités. Le schéma suivant présente quelques exemples d implémentations possibles. 10

11 Figure 2 - Implementation examples of Identity Management Choisir ses applicatifs On peut catégoriser les applicatifs permettant d implémenter la gestion des identités selon deux critères : outils génériques versus outils spécialisés : les outils génériques ont théoriquement pour avantage de proposer des fonctionnalités étendues et permettre ainsi une rationalisation des technologies et compétences. En revanche, ils risquent de répondre plus difficilement à certains besoins très spécifiques. produit du marché vs. développement interne : les produits du marché permettent un démarrage rapide en limitant l investissement humain. Le développement interne garantit lui une adéquation forte avec les besoins de son établissement et une bonne maîtrise, mais au prix de coûts humains plus conséquents [homegrown]. Il n y a pas de meilleur choix. Ces choix dépendent fortement du besoin détaillé et de la stratégie 11

12 d établissement. 2 Constitution d'un référentiel de comptes Comme évoqué précédemment, le déploiement d un référentiel des comptes est à privilégier par rapport à celui d un référentiel de personnes dédié. La méthodologie permettra donc de constituer un référentiel des comptes tel que décrit dans les exemples 2 ou 3 du schéma Implementation examples of Identity Management, c est à dire se concentrant sur le provisioning des identités et mettant en arrière-plan les problématiques de gestions fonctionnelles des personnes. La problématique de gestion centralisée des groupes, qui peut s avérer un sujet complexe, est également ignorée ici. Nous considérerons que le référentiel des comptes propose les informations nécessaires pour que les services constituent leurs propres groupes locaux. 2.1 Analyser l existant L objectif de cette première étape est de recenser certaines informations de l existant qui permettront d effectuer des choix judicieux par la suite. Elle doit permettre d identifier les points positifs de la situation actuelle qui serviront de base de travail, tout en relevant les incohérences qui pourraient exister et qui gagneraient à être corrigées Inventorier ses populations Ce tableau recense les populations utilisatrices des services informatiques et pour chacune, l application utilisée pour les gérer. Nom de la population Application de gestion de la population Volume Administratif Enseignant Chercheur Etudiant... Tableau 1 : modèle de recensement de population Détail des colonnes : Nom de la population : nom donné à cette catégorie d utilisateurs ; 12

13 Application de gestion de la population : application du SI dans laquelle cette population est saisie informatiquement. Cette application contrôle les informations de la population ; Volume : nombre approximatif de personnes de ce type dans l établissement. Identifier les populations Quelques règles et conseils à suivre pour identifier les populations : Le couple population/source de données doit être unique Une même population ne devrait pas provenir de deux sources. Si c est le cas, vous devez pouvoir créer deux populations distinctes, en vous basant sur un critère de différenciation concret ; Une même application peut gérer plusieurs populations. Vous serez amené à les distinguer dans le tableau d inventaire si plusieurs des conditions suivantes sont réunies : la gestion de ces populations diffère beaucoup : services métiers responsables, cycle de vie, etc., l offre de services diffère beaucoup, il n y a pas ou peu de recouvrement entre ces populations. Cette typologie de premier niveau a pour objectif de déterminer une stratégie de mise en place, pas de spécifier des autorisations précises. Elle peut en conséquence rester de haut-niveau ; Cette typologie de premier niveau devrait, dans la mesure du possible, se baser sur l activité de la personne dans l établissement. Une ou plusieurs sous-catégories devront être déterminées lors de la conception du modèle afin de définir finement les autorisations. Par exemple, la population Enseignant pourrait se subdiviser en Enseignants permanents et Enseignants vacataires ; Dans les exemples nous utilisons l indication locale pour indiquer qu une population n est pas gérée par une application métier, mais directement dans la base d authentification des applications proposant les services à cette population ; Inventorier les services potentiellement consommateurs d un référentiel de compte Ce tableau permet d identifier les informations suivantes : les services potentiellement consommateurs du référentiel de comptes, les modes actuels d alimentation des comptes pour ces services. Service/application Base d authentification Populations utilisatrices : source de provisionning (issue du tableau 1; préciser si sous-ensemble) Volume d utilisateurs par population Messagerie électronique Intranet institutionnel Connexion Wifi... Tableau 2 : modèle de recensement des services 13

14 Remplir le tableau Certains services utilisent plusieurs bases d authentification (enchaînement). Dans ce cas, utiliser autant de lignes que de bases de comptes utilisateurs, en spécifiant pour chacune les populations concernées, les services/applications à l état de projet avancé doivent être pris en compte. Exemples de tableaux remplis : Nom de la population Application de gestion de la population Volume Administratif Harpège Enseignant Harpège Chercheur Graal Etudiant Apogée Lecteur de bibliothèque locale 100 Tableau 3 : exemple de recensement de population Service/application Base d authentification Populations utilisatrices : sources de provisionning Volume d utilisateurs par population Messagerie électronique Annuaire LDAP Administratif : manuel Enseignant : manuel Chercheur : manuel Messagerie électronique locale Etudiant : Apogée Connexion Wifi Annuaire LDAP Administratif : manuel Enseignant : manuel Chercheur : manuel Connexion Wifi locale Etudiant : Apogée Lecteur de bibliothèque : manuel Cours en ligne locale Enseignant : manuel Etudiant : Apogée Gestion de la scolarité (Apogée) locale Administratif (scolarité) : manuel 400 Connexion au poste de travail Active Directory Administratif : manuel Enseignant : manuel Tableau 4 : exemple de recensement des services 14

15 2.2 Analyser et prioriser La mise en place de bout en bout d un système de gestion des identités est une démarche d ampleur. La progression doit être itérative et chaque étape doit se terminer par une évolution significative améliorant la qualité du service ou rationalisant les ressources. Ces étapes doivent être réfléchies dès le départ et donner naissance à une feuille de route globale. La première étape visera à mettre en place les fondations. De sa réussite dépendra la suite des évolutions. Il convient donc de faire en sorte de se focaliser sur la mise en place d une infrastructure robuste et évolutive. Les travaux requérant des évolutions organisationnelles majeures risquant de ralentir la mise en service du référentiel de comptes devraient être planifiés dans une itération ultérieure. Les recensements doivent faire apparaître les pistes facilitant cette première étape. Il conviendra de privilégier : la fourniture d identités pour les populations à fort volume et gérées par des applications de gestion de personnes identifiées, l intégration des services proposés à un grand nombre d utilisateurs potentiels, la désignation d une base d authentification déjà utilisée par plusieurs services comme référentiel d'identités. Évidemment, ces règles sont à modérer selon les possibilités techniques. Par exemple : s il s avère très difficile d extraire des informations de l application de gestion de la plus grande population, il devient raisonnable de commencer la démarche par une population plus accessible ; si la qualité des données métiers pour une population est reconnue comme mauvaise, il est là aussi préférable d ignorer cette dernière pour la première étape ; si la base d authentification déjà utilisée n est pas extensible hors de son périmètre actuel, il conviendra de monter un autre référentiel. Dans une étape suivante, cette base de comptes devra être asservie au référentiel. Une fois le référentiel des comptes déployé, avec ses premières populations et ses premiers services consommateurs, les itérations suivantes peuvent consister, selon les priorités de l établissement à : étendre la gestion à de nouvelles populations ; étendre l usage par de nouveaux services ; faire évoluer le modèle de données pour ajouter des possibilités de catégorisation des identités (cf 2.3 Créer le référentiel de comptes ) ; contrôler et améliorer la qualité des données. Les paragraphes suivants présenteront les étapes majeures de la création du référentiel de comptes. Son évolution lors des itérations suivantes nécessitera des réflexions similaires, mais dans une optique d évolution plutôt que de création. Exemple - analyse de l existant Sur la base des tableaux d exemples 3 et 4, on pourrait identifier pour une première étape les objectifs suivants : La messagerie électronique et l accès Wi-Fi sont offerts à toutes les populations. Ces services doivent donc être traités en priorité ; Ces deux services utilisent déjà une base d authentification commune (LDAP) qui a le mérite de suivre un protocole standard et ouvert. Cette base de compte devrait donc être désignée comme référentiel de comptes de l établissement ; Les comptes étudiants sont provisionnés par des extractions de l application de gestion des étudiants (Apogée). Il est donc probablement peu coûteux d alimenter un référentiel de comptes commun de cette manière ; Les employés administratifs et enseignants proviennent d une application commune (Harpège) 15

16 et représentent plus de 20% de la population. La mise en place d un provisioning automatique depuis l application Harpège offrirait un bon retour sur investissement. Une deuxième étape de mise en œuvre pourrait concerner les sujets suivants : Étendre l utilisation du référentiel des comptes à l enseignement en ligne ou à la connexion au poste de travail ; automatiser le provisioning des comptes de chercheurs. L application de gestion de la scolarité ou la gestion des comptes lecteurs de bibliothèque concernent des populations moins nombreuses ; leur traitement nous apparaît donc moins prioritaire. 2.3 Créer le référentiel de comptes Constituer son modèle Sur un plan technique, le référentiel des comptes consiste en une base de données recensant les utilisateurs du système d information. Il convient donc de définir quelles sont les informations nécessaires pour modéliser une identité. Ces informations peuvent être de plusieurs types : informations d identification, données opérationnelles pour gérer le cycle de vie de l identité, données de contact, données métiers pour permettre l attribution de droits d accès aux services. Voici quelques données utilisateur basiques permettant de prendre un bon départ. Cette liste est cependant à adapter selon les besoins des services utilisant le référentiel d'identités, notamment les données métiers utilisées par ceux-ci. Information Identifiant de connexion mot de passe Identifiant immuable Date d expiration Etat Description Identifiant connu de l utilisateur pour s identifier. De préférence convivial. Potentiellement réattribué, donc ne doit pas servir de référence pour le stockage de données personnelles. Aussi appelé alias de login authentifiant Si différent de l identifiant de connexion. Peut-être opaque, immuable pour une même identité et non réattribué. A utiliser pour les références aux données personnelles ou les synchronisations de données. Date à laquelle l identité ne doit plus être utilisable. Selon le cycle de vie défini, plusieurs dates peuvent être nécessaires (désactivation, suppression, purge, etc.) L identité peut traverser plusieurs états pendant son cycle de vie. Quelques exemples : nouvelle, activé, verrouillé, en sursis. Ces états définissent les actions qui seront réalisables sur l identité et indiquent si le compte peut être utilisé. Selon les processus choisis par l établissement, l implémentation de cette notion peut se faire par un seul attribut prenant plusieurs valeurs, ou bien plusieurs attributs booléens, ou encore un mélange des deux. 16

17 Source de données Identifiant dans la source de données Prénom Nom patronymique Nom d usage Date de naissance Adresse électronique Numéro(s) de téléphone Adresse(s) postale(s) Population(s) Structure(s) d affectation Définit la base source pour les identités créées par synchronisation automatique depuis des applications métiers. Indispensable pour garantir la synchronisation des données. Identifiant référençant la personne dans la base de données source. Indispensable pour garantir la synchronisation des données. Données minimales nécessaires pour rapprocher l identité numérique avec une personne physique. Données de contact. Permet d identifier à quelle(s) population(s) (listée précédemment) appartient l identité. La définition d une population principale peut s avérer nécessaire pour les services ne gérant pas l appartenance à plusieurs populations simultanément. Affiche les structures organisationnelles auxquelles l individu est rattaché. Ces structures peuvent être de différents niveaux (établissement, direction service, composante, département, pôle, laboratoire, équipe de recherche). En conséquence, selon les besoins et les choix d implémentations, plusieurs attributs différents seront potentiellement employés. Statut d employé Information sur le statut professionnel d un employé. Exemples : type de contrat, corps/grade, date de fin de contrat. Cursus scolaire/universitaire Informations sur la scolarité de l étudiant. Exemples : inscription aux diplômes ou aux cours, état boursier, etc. Favoriser l utilisation de modèles standards La communauté de l enseignement et de la recherche a établi quelques modèles de données standards pour la gestion de comptes. Leur usage est fortement recommandé. Si les informations modélisées sont insuffisantes, il sera toujours possible d étendre le modèle. L utilisation de standards présente plusieurs intérêts. Elle permet un démarrage plus rapide et on évite les pièges qu ont connus les prédécesseurs dans le domaine. Elle facilite également la coopération entre établissements en termes de mutualisation, diffusion ou conception commune de services. Au chapitre des inconvénients, on peut noter que si le modèle du standard n est pas adapté aux services consommateurs, un travail de conversion de données intermédiaire peut s avérer nécessaire. Une majorité de services consommateurs inadaptés et inadaptables pourrait donc favoriser l usage d un modèle privé dans votre référentiel. Mais même dans cette situation extrême, pour bénéficier de services offerts par la communauté, il est fortement conseillé d être en mesure d exposer ses identités dans le format standard. Les formats standards reconnus en France pour l enseignement sont : eduperson (Internet2) : schéma LDAP pour la représentation de personnes dans l enseignement supérieur 17

18 eduorg/ SCHAC (TERENA) : schéma complémentaire à eduperson pour faciliter l échange de données au niveau Européen Supann (CRU/RENATER) [supann] : complément français à eduperson Choisir la technologie L usage d un annuaire LDAP s est aujourd hui imposé comme standard dans la communauté éducationrecherche pour constituer le référentiel de comptes utilisateurs. Ce type d annuaire est nativement conçu pour gérer des objets de type individu et offre effectivement plusieurs avantages : d excellentes performances en lecture, la possibilité d étendre ses schémas, des facilités de répartition sur plusieurs serveurs, le support par de nombreux applicatifs clients LDAP, un vaste choix d implémentations, notamment dans le monde du logiciel libre. L implémentation OpenLDAP semble aujourd hui être majoritairement déployée dans les établissements d enseignement français, mais d autres alternatives libres existent. Active Directory comme référentiel d'identités? D un point de vue technique, Microsoft Active Directory est un annuaire LDAP gérant des comptes utilisateurs. Il semble donc adapté pour réaliser la fonction de référentiel de compte. Cependant, en raison de son objectif initial (gestion de parc de machines Microsoft) et de sa nature propriétaire, il impose un certain nombre de contraintes sur le modèle et son organisation. Il est ainsi rarement choisi pour devenir le référentiel central de comptes dans les grands établissements. Il reste cependant un choix pertinent dans des petits établissements et/ou ceux utilisant beaucoup de produits spécifiquement compatibles Infrastructure technique La conception de l infrastructure technique pour supporter le service de référentiel de comptes ne présente pas de spécificité majeure par rapport à d autres applicatifs. Il est cependant nécessaire d insister sur le fait que cet élément sera central et vital pour le bon fonctionnement des autres services du Système d Information. En conséquence, il est indispensable de monter une architecture redondante permettant de résister à des défaillances éventuelles de certains composants. Il est également conseillé de disposer d un plan de reprise d activité afin de remettre rapidement ce service en fonctionnement en cas de sinistre majeur (incendie, inondation, catastrophe naturelle, etc.). 18