ProxyEPN

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

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

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.