aeris22’s avataraeris22’s Twitter Archive—№ 76,276

                      1. Ça fait longtemps que je n’avais pas râlé je trouve. Donc un petit thread pour changer 😂 Ce soir, on poutre LDAP 😂
                    1. …in reply to @aeris22
                      Tout le monde loue LDAP « parce que c’est intéropérable avec tout ». Sauf que. En fait non.
                  1. …in reply to @aeris22
                    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…
                1. …in reply to @aeris22
                  On peut s’authentifier de plusieurs manières. Et certainement d’encore plein d’autres que je n’ai pas imaginé.
              1. …in reply to @aeris22
                « à 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.
            1. …in reply to @aeris22
              À la bourrin : si tu es capable de t’authentifier au LDAP, alors tu es authentifié à l’application (aka le direct bind en langage LDAP).
          1. …in reply to @aeris22
            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.
        1. …in reply to @aeris22
          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.
      1. …in reply to @aeris22
        Une version un peu mixte est d’utiliser un compte authentifié « admin » pour la recherche, puis un bind DN + password.
    1. …in reply to @aeris22
      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
  1. …in reply to @aeris22
    aussi modéliser les groupes comme une organizationalUnit et des alias dedans. Ou toute autre manière que vous trouverez de modéliser ça…
    1. …in reply to @aeris22
      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.
      1. …in reply to @aeris22
        Le soft tartanpion n’a implémenté que le login « à la SGBD » quand duchmol implémente uniquement « direct bind » et trucmuch seulement « filter + bind »…
        1. …in reply to @aeris22
          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 !
          1. …in reply to @aeris22
            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
            1. …in reply to @aeris22
              peu gagné d’avance d’avoir 2 softs différents qui s’attendent à trouver exactement la même structure LDAP derrière…
              1. …in reply to @aeris22
                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 :
                1. …in reply to @aeris22
                  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… 😂