accueilSystèmes et réseauxAnnuaires LDAP
 

Annuaires nationaux LDAP

Les annuaires LDAP à la DSI

Présentation des services d’annuaire LDAP opérés par la DSI du CNRS


La DSI, dans le cadre de l’urbanisation du SI du CNRS, a mis en place des annuaires LDAP.

Les services réalisés via ses annuaires sont

  1. Authentification
  2. Identification
  3. Gestion de certains accès applicatifs
  4. Gestion de certaines propriétés applicatives

Situation des annuaires à la DSI

La DSI opère principalement 3 groupes d’annuaires

- L’annuaire central du CNRS
- l’annuaire référentiel
- l’annuaire des comptes des Progiciels SAP

Le contexte dans lequel s’inscrivent ces annuaires est caractérisé par certains ordres de grandeur
- une forte volumétrie : environs 100 000 profils d’identification
- une fréquence de mise à jour élevée : environs 500 mises à jours quotidiennes
- des temps de réaction très court : 5 secondes pour que la modification soit répercutée dans tous les annuaires

Principes de mise en place

La mise en place et l’utilisation des annuaires sont assujetties à des principes

Contenu

Les informations métier proviennent exclusivement de Source de Données de Référence reconnues par l’établissement (Labintel et l’application de gestion RH Sirhus). ces informations ne sont pas gérées dans l’annuaire.

Pour qu’une information métier soit ajoutée, supprimée ou modifiée il n’existe pas d’autre solution que d’agir directement dans l’application de référence.

Les flux sont unidirectionnels.

Ils vont des Source de données de Référence vers les annuaires LDAP. Les données sont interprétées par un agent logiciel Dmas , appelé aussi Robot, qui va les répercuter dans les annuaires. Aucune intervention directe n’est nécessaire ni souhaitable.

Le passage par ce canal unique permet
- de respecter un corpus de règle de gestion ou de transformation pouvant être complexes
- de capter des évènements et de les transmettre

Flux de données

Temps de réaction et cercle vertueux

Le temps de réaction entre une modification dans une source de donné et sa répercussion est de l’ordre de la seconde. Cette propriété associée à l’obligation de modifier à la source, à permis d’établir un cercle vertueux de correction des informations. C’est un élément essentiel pour que l’utilisation annuaire soit comme un service aux applications, et non comme une contrainte d’architecture.

Synchronisation

Chaque annuaire est chapeauté par un agent logiciel. Ces agent logiciels communiquent entre eux via un intergiciel orienté message [1] de type JMS. Ainsi les annuaires sont en cohérence les uns avec les autres tout en conservant les spécificités qui sont les leurs.

Vue globale

Voici une vue globale de l’architecture LDAP du SI du CNRS Les trois annuaires principaux sont

  • l’Annuaire Central CNRS, annuaire historique, utilisé pour les authentifications directes LDAP et la gestion des droits Labintel
  • l’Annuaire Référentiel, annuaire d’authentification appelé à remplacer l’annuaire central et principalement utilisé par Janus
  • l’Annuaire SAP (parfois encore appelé projet), annuaire de gestion des macro accréditation d’accès aux application BFC et SIRHus.

Les composants sont

  • Les sources de données de référence
    • Labintel (qui reçoit également des données de SIRHus)
    • Le Référentiel des partenaires
  • Les annuaires et les agents logiciel en charge de leur gestion
  • Le broker JMS qui permet l’échange de messages entre agents
  • Les applications clientes
  • Le fournisseur d’identité Janus
  • Le gestionnaire d’accès IHM Ldap
  • L’application de définition de mots de passe Sésame

Cinématique

Flux principal (Labintel)

  • L’application Labintel inscrit dans une table de notification l’identifiant d’une personne modifiée dans LABINTEL (ex. Jean GABIN).
  • (1) Le robot de l’annuaire central lit périodiquement table de notification et voit que Jean GABIN a été modifié. Il récupère dans LABINTEL toutes les informations nécessaires
  • (2) Le robot assemble les informations récoltées dans LABINTEL
    • il modélise l’entrée uid=jean.gabin,ou=cnrs,ou=people,dc=cnrs,dc=fr
    • il crée l’uid qu’il stocke
    • il écrit l’entrée uid=jean.gabin,ou=cnrs,ou=people,dc=cnrs,dc=fr dans l’annuaire central
  • (3) il diffuse l’entrée uid=jean.gabin sous forme de document XML sur le topic PROD.CENTRAL.TOPIC
  • (4) Le robot référentiel lit le message en provenance de PROD.CENTRAL.TOPIC,
    • à partir des informations reçues, il modélise l’entrée selon ses règles de gestion
    • (5) il modifie l’entrée uid=jean.gabin,ou=cnrs,ou=people,dc=cnrs,dc=fr dans l’annuaire référentiel en conséquence
    • et crée le sapusername qu’il stocke
  • (6) il diffuse l’entrée uid=jean.gabin sous forme de document XML sur le topic PROD.REFERENTIAL.TOPIC
  • (7) le robot projet (appelé SAP) lit les message en provenance de PROD.REFERENTIAL.TOPIC,
    • à partir des informations reçues, il modélise l’entrée selon ses règles de gestion
    • (8) il modifie l’annuaire SAP en conséquence
  • au bout de la chaîne, les batchs SAP créent des comptes à partir du contenu de l’annuaire projet

Flux sésame (définition des mots de passe)

Le flux Sésame est le suivant

  • (A.1) suite à un échange de token, l’application Sésame réécrit le mot de passe dans l’annuaire central de l’utilisateur Jean Gabin et le note dans une table de notification dédiée
  • (A.2) le robot central consomme les enregistrements de la ttable de notification dédiée et va lire l’entrée l’entrée uid=jean.gabin,ou=cnrs,ou=people,dc=cnrs,dc=fr dans l’annuaire central
  • reprise au (3) du flux principal

Flux IHM LDAP (gestion des accès)

Le flux IHM LDAP est le suivant

  • (B.1) un utilisateur de l’IHM LDAP modifie des tags ou demande explicitement la propagation de Jean GABIN. L’IHM écrit alors l’uid dans une table de notification d’événements dédiée
  • (B.2)’ le robot central consomme les enregistrements de la table d’événements et va lire l’entrée l’entrée uid=jean.gabin,ou=cnrs,ou=people,dc=cnrs,dc=fr dans l’annuaire référentiel
  • reprise au (5) du flux principal


[1] appelé également Message Oriented Middleware, il fonctionne sur un mode asynchrone par diffusion de message


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits