ProxyEPN

Modifications publiées sur le svn (r295) :

En étant connecté en admin, il est possible de lancer la regénération de l'annuaire LDAP via /user/ldapRegen
Cette action commence par traiter la liste des GEPN, puis la liste de tous les contacts (sauf les anonymisés) se trouvant dans la base de données EpnAdmin. Pour chaque objet, l'entité correspondant dans l'annuaire sera sauvegardée avec les valeurs venant de la BdD. Si l'annuaire contient toujours les fiches, alors elles seront modifiées, sinon ajoutées.

Mais...
Il n'est actuellement pas possible de regénérer entièrement l'annuaire Ldap : le mot de passe ne peut être récupéré depuis la base de données pour alimenter la fiche du Ldap (y compris en recopiant la forme cryptée).

Dans la BdD EpnAdmin, les mots de passe sont stockés en SSHA1, soit du SHA1 + grain de sel. De l'autre côté OpenLdap sait aussi stocker les mots de passe en SSHA1, mais cette méthode à le défaut de ne pas être standart... Et nous tombons dans le cas de non-interoperabilité :

• EpnAdmin utilise le salt en préfixe avant de crypter en SHA1
• OpenLdap utilise le salt en suffixe

Il devient donc impossible de convertir les mots de passe cryptés d'EpnAdmin vers OpenLdap, et bien entendu impossible de revenir à la forme en clair.

Conclusion : la génération totale du Ldap, mot de passe compris, ne serait possible qu'à condition d'utiliser un algo de stockage des mots de passe compatible entre les 2 applications.

Plan de modification du stockage des mots de passe :

• Dans un premier temps, récupérer les mots de passe depuis l'annuaire LDAP, sous leur forme cryptée par l'algorithme MD5, pour les affecter dans la BDD EpnAdmin. En renseignant l'algoryhtme et en supprimant le grain de sel, l'applicatif EpnAdmin devrait pouvoir les utiliser.

• Une fois que la BDD et l'annuaire partagent les mots de passe dans cet algorithme commun, il devient possible de mettre en place une regénération complète de l'annuaire LDAP à partir de la BDD (pourra être tester avec la migration en version 1.1.3, celle-ci contenant de nombreuses modifications sur le contenu de l'annuaire)

• Par la suite, si le stockage en MD5 n'est pas le choix préféré, un autre algorithme est envisageable, y compris le SSHA1 à condition de modifier la méthode dans EpnAdmin pour utiliser le grain de sel en suffixe. Dans ce cas, tout nouveau mot de passe (ou modification) utilisera ce nouvel algo. Les anciens resteront en md5 mais la cohabitation ne devrait pas gêner puisque les algo sont toujours spécifié pour chaque mot de passe stocké.

Modifications publiées sur le svn (r301) :

Les méthodes setPassword() et checkPassword() de l'objet sfGuardUser ont été surchargées pour appliquer un algorithme de cryptage des mots de passe en SSHA1 qui soit compatible avec celui utilisé par OpenLdap (salt en suffixe).

Grâce à ceci, il est possible de garder l'algorithme SSHA1 tout en ayant des mots de passe stockés dans la BDD EpnAdmin directement exportables vers les fiches LDAP. Les fonctions d'export LDAP ont été adaptées en conséquence.

Par contre, tous les mots de passe déjà enregistrés dans la base ne sont plus exploitables. Ils seront écrasés par leurs versions MD5 récupérées depuis l'annuaire LDAP.