Bonsoir,

Le lundi 09 septembre 2013 à 17:58 +0200, Emmanuel Thierry a écrit :

> Le 9 sept. 2013 à 16:54, Simon Boche a écrit :
>
> >
> > En ce qui concerne cette solution, je verrais bien un serveur LDAP
> > pour gérer les adhérents ainsi que toutes les informations
> > nécessaires pour la gestion de leurs services.

Aïe, à chaque fois que je lis LDAP, ya « usine à gaz » qui s'affiche
dans ma tête. J'ai ré-étudié récemment la problématique
d'authentification/autorisation, et j'avoue toujours avoir du mal à
m'enlever cette idée de la tête… même si je ne vois pas de solution
aussi « complète » à côté.

> > L'avantage de cette solution c'est la centralisation en un seul
> > endroit de toutes les informations concernant un adhérent,

Ça sa doit coller à pas mal d'autres solutions d'authentification que
LDAP.

> > avec en
> > plus des solutions existantes et éprouvées pour la mise en place
> > d'un serveur de secours, l'interconnexion avec d'autres services
> > (genre ssh ou bien les mails), l'authentification sécurisée (en
> > passant par Kerberos)...

Rhaaa, Kerberos… Là, je vois la centrale atomique à gaz !(!)

> > De plus, je dispose déjà d'une biblio assez
> > importante sur cette solution (et au passage je vais très
> > certainement la déployer sur mon propre serveur).

Bon, je comprends que si tu connais, tu aimes bien.

> Attention avec le LDAP, c'est beaucoup moins hackable que du SQL. Et
> ça n'a d'avantage que sur les bases avec beaucoup de lookups, ce que
> vous n'aurez pas à Griffon.

C'est clair que pour les perfs, on s'en fou un peu.

> Le SQL te permettra plus facilement des schémas custom, des requêtes
> custom, etc. Le LDAP te contraint en terme d'accès et d'utilisation
> des données.

Oui, mais il y a toujours des avantages et des désavantages à la
souplesse versus un truc bien défini/rodé.

> Moi-même je fonctionne avec un LDAP et je regrette d'avoir choisi
> ça...

Ah ouai ? T'as des exemples concrets de problèmes ?

Perso, après avoir vraiment bien regardé comment différents protocoles
pouvaient interagir ensemble, je n'arrive pas à trouver une solution
« globale » satisfaisante. En fait, je suis parti de ce dont on aura
besoin en tant qu'opérateur pour l'authentification, afin de voir quel
protocole/logiciel répond à nos besoins :

      * Pour se connecter aux machines en local (pour les interventions
        physiques), je suppose que PAM peut se brancher à un paquet de
        trucs, donc pas trop de problèmes. Prévoir un fallback en cas de
        problème réseau, quand même…

      * Pour l'authentification SSH, là c'est un peu plus galère : on
        peut utiliser PAM aussi, mais si on veut faire autre chose que
        du mot de passe, genre de clés asymétriques, il faut utiliser
        autre chose, à ma connaissance. Là, LDAP est moyen branlé pour
        (même si les attributs existent en non-standard à priori),
        RADIUS aussi, mais avec un OpenSSH récent on peut lancer un hook
        pour lui sortir de l'équivalent à authorized_keys, qu'on peut
        chopper d'où on veut (c-à-d même d'un fichier qu'on pourrait
        synchro « à la main » sur les machines, si on voulait faire
        « simple »).

      * Pour de la collecte, on aura sûrement à mettre en place un
        serveur RADIUS ; c'est ce que parlent les équipements réseau.
        FreeRADIUS est pas mal, et peut parler SQL derrière, ou LDAP,
        mais ça a l'air moins bien intégré.

      * Pour faire de l'accounting (OK, c'est pas lié directement à
        l'authentification), bah, ya que RADIUS, je ne crois pas que
        LDAP fasse vraiment.

      * Pour l'authentification DHCP(v6), car ça serait pas mal de
        préparer un peu le futur, et qu'on aura peut-être des méthodes
        d'accès autre que du PPP-like (i.e. basé sur RADIUS seulement),
        où un serveur DHCP sera utilisé, genre sur du Wifi, il faut
        pouvoir brancher le serveur DHCP sur une « base ». Il y a un
        plugin LDAP à l'ISC DHCP, et un patch non-officiel pour du SQL,
        mais rien pour RADIUS. Pour l'IPv6, si on ne veut pas que les
        gens le configurent à la main, c'est _obligé_ d'avoir du DHCPv6.
        Et sur du PPP ; c'est vraiment un peu galère à mettre en place
        (i.e. j'ai encore réellement essayé, mais vu les discussions, ça
        a pas l'air d'être de la tarte).

Et bien sûr, faire marcher tout ça ensemble veut dire qu'on sera à peu
près obligé de stocker les mots de passe en clair… (je vous laisse vous
moquer des « grands » qui le font, mais c'est réellement impossible avec
le spaghetti de protocoles à supporter). C'est un autre truc limitant de
LDAP : ça n'est qu'une base, et les infos dedans sont « en clair », même
si ça peut bien sûr être un mdp hashé. Et bien sûr, si on veut faire
moderne avec du SCRAM (RFC 5802) pour les mdp (j'ai pas compris comment
LDAP pouvait supporter ça avec SASL et comment ils interagissent, vu que
ça a l'air théoriquement supporté…) ou des courbes elliptiques
(ECDSA/ECDH) pour les clés asymétriques, ça sera avec des patchs plus ou
moins expérimentaux, voire qu'il faudra qu'on écrive…

Le plus chiant, et qui sera encore un autre « limiteur », c'est de voir
par quel protocole on va _modifier_ la base ; car autant lire les infos
avec un traducteur LDAP/RADIUS/DHCP, ça se fait, autant les écrire…

Bref, si quelqu'un a une idée pour tout ça… C'est pour ça que le SQL ça
me tente pas mal comme (plus petit ?…) dénominateur commun. Mais ça se
discute, vu la gueule du module SQL de LDAP (il m'a fait un peu peur).