Ça fait longtemps que je n’avais pas râlé je trouve. Donc un petit thread pour changer 😂
Ce soir, on poutre LDAP 😂

Tout le monde loue LDAP « parce que c’est intéropérable avec tout ». Sauf que. En fait non.

LDAP n’est pas plus normalisé pour faire de l’authentification que ne l’est MySQL ou PostgreSQL. Oui on peut, mais faut tout faire à la main…

On peut s’authentifier de plusieurs manières. Et certainement d’encore plein d’autres que je n’ai pas imaginé.

« à l’ancienne », ie un compte admin utilisé pour accéder aux données utilisateurs, et on vérifier le login une fois le hash du mot de passe obtenu. Comme on le ferait naturellement avec un SGBD conventionnel donc.

À la bourrin : si tu es capable de t’authentifier au LDAP, alors tu es authentifié à l’application (aka le direct bind en langage LDAP).

Ici c’est LDAP qui gère le mécanisme d’authentification, par exemple la comparaison des hashs. Ça vous évite de réimplémenter son mécanisme côté applicatif.

Un peu plus fin : on commence par faire une requête anonyme à partir du username pour obtenir le DN de l’entrée LDAP associée à l’utilisateur. Ensuite, on bind au LDAP avec DN + password. C’est filter + bind.

Une version un peu mixte est d’utiliser un compte authentifié « admin » pour la recherche, puis un bind DN + password.

On peut raffiner le bordel avec de la gestion de groupe, en interrogeant le LDAP pour savoir si un utilisateur est dans tel ou tel groupe. Sauf que rien n’est normalisé pour définir ce qu’est un groupe…
Certains utiliseront un groupOfNames, d’autres un groupOfUniqNames. On peut aussi modéliser les groupes comme une organizationalUnit et des alias dedans.
Ou toute autre manière que vous trouverez de modéliser ça…

Côté logiciel, chacun vient avec ses prérequis. Et tout le monde n’implémente pas forcément toutes les manières de faire.
Le pire étant la gestion des groupes, personne ne faisant la même chose que son voisin.

Le soft tartanpion n’a implémenté que le login « à la SGBD » quand duchmol implémente uniquement « direct bind » et trucmuch seulement « filter + bind »…

Machin n’aura pas d’option de bind admin pour le « filter + bind » et réclamera un accès anonyme donc. Mais pas Truc qui aura tout implémenter en mode authentifié… mais ne gérera peut-être pas les groupes !

Bilan : oui, en théorie LDAP est compatible avec tout. Autant que l’est MySQL ou PostgreSQL. Ni plus, ni moins.
C’est juste « mieux compatible » parce que des usages plus ou moins communs sont apparus. Mais les petites subtilités d’implémentation font qu’il est généralement assez peu gagné d’avance d’avoir 2 softs différents qui s’attendent à trouver exactement la même structure LDAP derrière…

Si vous avez un LDAP avec accès anonyme et sans nécessité de gestion des groupes, vous êtes dans le cas le plus confortable. C’est généralement implémenté partout (direct-bind ou filter+bind).
Si vous avez désactivez le bind anonyme ou que vous voulez une gestion des groupes : bon… courage…
La probabilité que ça tombe en marche tout seul est loin d’être proche de 1, et vous pouvez déjà commencer à acheter des tubes d’aspirines… 😂

Follow

@aeris On peut également parler des idées grandioses de certaines implémentations... Comme OpenLDAP qui a décidé qu'un simple fichier de configuration, c'était trop simple à utiliser et qui a décidé de stocker sa configuration dans OpenLDAP lui-même (le fameux cn=config). Histoire de bien montrer aux gens qu'ils peuvent aller se faire mettre 🤬

Sign in to participate in the conversation
Mastodon

Generalistic and moderated instance. All opinions are welcome, but hate speeches are prohibited. Users who don't respect rules will be silenced or suspended, depending on the violation severity.