Evolution #92

Révision de l'export LDAP

Added by Grégory MARIGOT - TEICEE over 11 years ago. Updated about 11 years ago.

Status:Fermé Start date:03/09/2011
Priority:Normal Due date:
Assignee:Grégory MARIGOT - TEICEE % Done:

100%

Category:-
Target version:ProxyEPN 2.0
Version ProxyEPN:TEST

Description

L'alimentation d'un annuaire LDAP par l'application est à revoir :
  • Adapter les valeurs transmises à l'annuaire avec les modifications effectuées sur ProxyEPN
  • Simplifier le domaine d'application du rôle (unique) de l'usager par une liste des EPN (disparition des roles sur les GEPN)
  • Simplifier le code transmettant le mot de passe pour la fiche LDAP, celui-ci pouvant dans tous les cas être récupéré depuis les données hachées stockées dans la BdD
  • Revoir les déclenchements des synchro vers le LDAP en utilisant les hooks Propel (pre/post insert/update/delete)
  • Ajouter l'export de fiches sur les EPN dans l'annuaire
  • Redéfinir les schémas des entités LDAP utilisées (classes et attributs)
  • Améliorer le code effectuant l'export des différents objets

Related issues

related to Anomalie #69: Révision du support LDAP pour les fiches contacts Fermé 07/12/2010
related to Evolution #74: Enrichir les informations disponibles dans l'annuaire LDAP Fermé 11/29/2010
related to Evolution #80: Révision globale du code Fermé 12/17/2010
related to Evolution #93: Révision de tâches Symfony de l'application Fermé 03/10/2011

Associated revisions

Revision 384
Added by Grégory MARIGOT - TEICEE over 11 years ago

NEW #92: Nouvelles classes permettant de définir le mapping entre objets BDD et fiches LDAP.
NEW #92: Synchronisations vers le LDAP basées sur les hooks (postSave, postDelete...) plutôt que des behaviors Symfony.
NEW #93: Controles à l'utilisation de l'application sur la màj de la date d'expiration, le statut de l'usager, la politique exportée.

Revision 410
Added by Grégory MARIGOT - TEICEE over 11 years ago

NEW #92: Ajout des coordonnées (postales et téléphoniques) des usagers dans l'export LDAP

Revision 430
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #92: Ajout d'un ID de politique spécial pour l'export LDAP des comptes expirés

Revision 439
Added by Grégory MARIGOT - TEICEE about 11 years ago

FIX #92: Renforcement du filtre pour identifier les fiches lors des exports LDAP

Revision 444
Added by Grégory MARIGOT - TEICEE about 11 years ago

FIX #92: Correction de la synchro LDAP après ajout/suppression d'un role (l'ancien wrapper était encore appelé dans cette classe)

Revision 450
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #85: L'export LDAP des assignations est désactivé dans les hooks pour être lancé depuis les actions (évite de multiplier les exports sur assignation par lot).
FIX #92: La référence complète d'un EPN ne doit pas utiliser de 0 de remplissage sur l'id (cohérence avec l'usage externe : nom des box).

Revision 608
Added by Grégory MARIGOT - TEICEE over 8 years ago

FIX #92: Tâche ldap-regen bénéficiant des droits superadmin et munie d'une option de test

History

Updated by Grégory MARIGOT - TEICEE over 11 years ago

  • Status changed from Nouveau to In Progress
  • % Done changed from 0 to 20

LDAP Directory Tree

L'arborescence LDAP est définie comme suit :

dc=proxyepn,dc=org
    | o=directory
        | ou=GEPN
            | uid=EPN
            | cn=User

Le suffixe LDAP ainsi que le premier niveau (o=directory) constituent le BaseDN de l'annuaire et ne sont en rien imposés : ils sont paramétrables dans la configuration de l'application pour correspondre à la réalité du serveur LDAP utilisé.

Voici un exemple de fichier LDIF permettant la création initiale d'une base LDAP (ainsi qu'un utilisateur pour le bind) :

# Racine LDAP
dn: dc=proxyepn,dc=org
objectClass: dcObject
objectClass: organization
dc: proxyepn
o: proxyepn.org
description: ProxyEPN Project

# Annuaire des EPN
dn: o=epn-dev,dc=proxyepn,dc=org
objectClass: organization
objectClass: top
o: epn-dev
description: ProxyEPN Directory (devel)

# Administrateur de l'annuaire
dn: cn=admin,dc=proxyepn,dc=org
objectClass: organizationalRole
objectClass: simpleSecurityObject
objectClass: top
cn: admin
userPassword: {SSHA}Ne3+zfFHB95cqU+wOC1EvpfcR7wqcSlB
description: ProxyEPN Administrator

A noter qu'i ln'a pas été jugé nécessaire d'ajouter un niveau pour les EPN : ceux-ci sont au même niveau que les fiches des usagers. Celà pourra toujours être facilement modifié s'il s'avèrait utile de placer les usagers sous chaque EPN. Cependant le lien d'appartenance entre usager et EPN existe grâce à la notion de groupe.

Schémas LDAP

Seuls des schémas standards sont ici utilisés.
Certains attributs supplémentaires pourraient être renseignés si nécessaire (ex: coordonnées des GEPN). Pour d'autres champs, des attributs supplémentaires pourront être nécessaire, via une extension personnalisée des schémas (en particulier pour stocker des infos sur les EPN).

Définition des GEPN

Classe organizationalUnit
  • ou : référence fiche GEPN (ex 14001)
  • description : official_name
Classe labeledURIObject
  • labeledURI : URL du site web, du sous-domaine ?

Définition des EPN

Classe posixGroup
  • gidNumber : id de l'EPN (ex 1)
  • cn : nom de l'EPN
  • description : hosting_structure
Classe uidObject
  • uid : référence complète fiche EPN (ex 14001-1)

Définition des usagers

Classe posixAccount
  • cn : NOM Prénom (identifiant)
  • uid : identifiant de connexion
  • uidNumber : référence fiche usager (ex 14000001)
  • gidNumber : id de l'EPN de rattachement (ex 1)
  • homeDirectory : /home/identifiant
  • userPassword : mot de passe du compte
  • description : id du profil pour politique de filtrage
  • gecos : options internet du compte
Classe inetOrgPerson (hérite de organizationalPerson / person)
  • cn : cf posixAccount
  • sn : NOM
  • givenName : Prénom
  • mail : adresse email
  • uid : cf posixAccount
  • userPassword : cf posixAccount
  • description : cf posixAccount
  • carLicense : id bis du profil pour politique de filtrage
  • employeeType : role (manager / coordinator / user)
  • registeredAddress : liste des EPN sur lesquels l'usager a un rôle
  • telephoneNumber : numéro de téléphone principal
  • homePhone : numéro de téléphone secondaire
  • postalAddress : adresse
  • postalCode : code postal
  • l : ville

Updated by Grégory MARIGOT - TEICEE over 11 years ago

  • % Done changed from 20 to 80

Modifications publiées sur le svn (r384) :

Définition du mapping BdD-LDAP

De nouvelles classes permettent de définir le mapping entre les objets en BdD et l'export vers le LDAP :
  • ldapExport : Classe abstraite contenant les méthodes génériques. Le constructeur prend un objet de la BdD à exporter et une configuration LDAP. Des méthodes 'save' et 'delete' sont disponibles pour effectuer la synchronisation vers l'annuaire.
  • ldapExportGepn : Classe héritant de ldapExport spécifiant la conversion d'un StructureGroup en OrganizationalUnit
  • ldapExportEpn : Classe héritant de ldapExport spécifiant la conversion d'un Structure en posixGroup
  • ldapExportUser : Classe héritant de ldapExport spécifiant la conversion d'un sfGuardUserProfile en posixAccount
L'intérêt est d'avoir un système facilement extensible et personnalisable. Les classes filles sont très faciles à écrire et à adapter, ne contenant que le minimum d'informations pour le mapping BdD-LDAP :
  • $peer : le nom de la classe Peer de l'objet (utile pour récupérer l'objet depuis l'id ou pour la regénération de l'annuaire)
  • $rdn : le nom du champs LDAP utilisé pour établir le DN de la fiche
  • $key : le nom du champs LDAP utilisé pour retrouver un objet existant (clé unique de recherche pouvant être différente du DN si celui-ci contient une partie modifiable)
  • getPathDN() : méthode construisant le DN complet de la fiche LDAP (détermine le chemin dans l'arborescence LDAP relative au BaseDN)
  • getAttributes($action = 'new') : méthode optionnelle permettant de spécifier les champs à synchroniser en fonction de l'action (new ou mod), par défaut tous les champs sont synchronisés.
  • populate() : méthode qui effectue le mapping des données en affectant les valeurs aux champs LDAP à partir de l'objet BDD fourni.

Bien entendu des traitements spécifiques sont toujours possibles, s'il le faut en surchargeant des méthodes de la classe mère (ex pour les usagers avec la prise en compte du status pour supprimer les comptes anonymes au lieu de les enregistrer, ou le blocage de la politique de filtrage pour les comptes expirés).

Edit 13/04 (r439) : Les valeurs indiquées dans l'attribut objectClass sont systématiquement ajoutées dans le filtre de recherche généré par la méthode getFilter() en plus de la clé $key pour s'assurer qu'uniquement le bon objet pourra ainsi être récupéré.

Déclenchement des synchronisations

Propel propose des hooks sur les actions BdD des objets qui sont tout à fait adaptés :
  • StructureGroup : postUpdate et postDelete
  • Structure : postSave et postDelete
  • sfGuardUserProfile : postUpdate et postDelete
  • sfGuardUserGroupStructure : postSave et postDelete

Note : Pour les GEPN et les usagers, le déclenchement n'est fixé que sur les update, car un insert est toujours suivi d'un update pour définir la référence de l'objet (basée sur l'id autoincrémental).

Pour ne pas éparpiller le code relatif aux synchro LDAP, les hooks se contentent de simples appels à des méthodes statiques regroupées dans la classe ldapExportWrapper. Ainsi c'est dans cette dernière que se font les choix sur la configuration de l'export LDAP (en particulier voir si l'export est activé ou non).

Edit 20/04 (r444) : La classe sfGuardUserGroupStructure avait été oubliée... Elle déclenche également l'export sur un usager après modification d'un de ses rôles (assignation/destitution sur un EPN).

sfGuardUser et sfGuardUserProfile

Le choix paraissant le plus logique a été de brancher la synchro LDAP sur les hooks de l'objet sfGuardUserProfile. C'est cette extension qui renferme la majorité des données et un compte qui n'en disposerait pas ne serait pas à exporter (normalement seul le compte admin n'a aucun profil).

Avantage : il n'est plus nécessaire de désactiver la synchro au momen du sign_in ! En effet lorsqu'un utilisateur se connecte sur l'application, la date de connexion est enregistrée dans la table sf_guard_user. Auparavant celà provoquait un export inutile vers le LDAP qui avait été contourné. Ce contournement n'a maintenant plus lieu d'être.

Inconvénient : le formulaire permettant de changer un mot de passe ne touche à aucune donnée du profil. De ce fait celà ne déclenche aucune synchro... Ce problème est réglé en ajoutant dans la méthode setPassword() une récupération du profil : celui-ci se retrouve alors lié à l'objet et recevra de sa part l'action save().

Regénération complète de l'annuaire

La classe mère ldapExport dispose également d'une méthode nommée 'regen'. Utilisée sur une classe fille, elle provoque la synchro LDAP de tous les objets correspondants présents dans la BdD. Dans ce cas il est inutile de passer un objet à exporter à l'instanciation de la classe, la liste des objets sera récupérée automatiquement par un doSelect() effectué sur la classe Peer indiquée.

La classe statique ldapExportWrapper dispose aussi d'une action doRegen($type) afin de lancer la synchro en spécifiant le type d'objets à traiter (le type correspond aux classes filles, donc ici 'Gepn', 'Epn' ou 'User').

Auparavant la regénération du LDAP été rendue accessible via l'interface web (action réservée au superadmin, cf #72). Cette méthode n'est pas la plus adaptée et a été supprimée. Il est préférable d'utiliser une tâche Symfony pour exécuter ce genre d'opération (cf #93).

Updated by Grégory MARIGOT - TEICEE over 11 years ago

  • Status changed from In Progress to Résolu
  • % Done changed from 80 to 100

Modifications publiées sur le svn (r410) :

Export des coordonnées des usagers

Les fiches usagers de l'annuaire sont enrichies par l'enregistrement des coordonnées téléphoniques (principal et secondaire) et postales (adresse, code postal et ville).
Les champs LDAP ne sont présents que si les champs BdD sont renseignés.
Le helper "Proxyepn" est chargé manuellement (require_once) dans l'objet d'export des utilisateurs pour bénéficier de la conversion des numéros de téléphones au format international.

Le schéma exposé précédement a été mis à jour avec ces champs supplémentaires.

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF