LDAP¶
Pour les règles métiers, voir le document dédié.
La configuration du ldap se fait via des variables d'environnement dont les valeurs de production sont récupérées via le manifeste stocké sur le QG.
LDAPS¶
Le LDAPS est supporté sur le port 636 sans besoin d'ajouter le certicicat CA (autorité de certification) car nous avons désactivé la vérification de l'intégrité du certificat via l'option TLS_REQCERT never. Cependant, les données transitent tout de même de manière chiffrée.
Synchronisation¶
Pour que les utilisateurs du ldap puissent utiliser l'application, ils doivent être importés dans la table utilisateur. Cette opération se fait via la commande bin/console synchroniser-ldap.
Les utilisateurs ldap stockés dans notre base contiennent l'attribut dn qui permet de les identifier dans le ldap et n'ont pas de mot de passe (cf. le fonctionnement du login).
Login¶
Puisqu'on doit d'abord rechercher l'utilisateur par son identifiant, on réutilise le système de login de base qui va chercher et au moment de valider le mot de passe sur cet utilisateur on injecte l'abstraction du ldap dans la méthode de vérification du mot de passe. Ce qui laisse la décision à la classe de l'utilisateur de savoir s'il doit vérifier le mot de passe via le ldap (si l'utilisateur vient du ldap) ou s'il utilise le mot de passe stocké en interne (pour les utilisateurs stockés en interne).
Puisque l'abstraction du ldap est instanciée à chaque processus de login (même pour les utilisateurs locaux) la connexion au ldap n'est pas effectuée à l'instanciation mais à l'utilisation (en utilisant une factory) pour éviter de bloquer le système de login si le ldap n'est pas disponible.
Debug de la connexion au serveur LDAP¶
D'abord installer ldapsearch :
Lancer une requête de récupération de la liste en fonction des informations présentes dans le QG :