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). -- benjamin