Bonjour,
Cela fait longtemps que j'entends parler de LDAP mais sans jamais vraiment bien comprendre.
J'aimerais une fois pour toute me simplifier la vie et que mon mail (bongo), mon blog (dotclear) et mon jabber (ejabberd) partage le même login/password sur mon serveur Ubuntu.
Je pense que pour ce genre de choses, LDAP est le plus approprié mais peut-être que je me trompe.
Avez-vous des ressources genre "LDAP pour les nuls" à me conseiller ?
Histoire que les choses soient encore plus facile pour moi, je me demandais s'il existait de bons front-ends graphiques pour administrer un serveur LDAP distant (soit un front-end web, soit une appli qui se connecte via internet donc).
Dernière question que je me pose : j'ai l'impression que dans cet usage relativement simple, LDAP ne gêrera donc que l'authentification. Tout ce qui est des privilèges et du compte lui-même sera gêrée par l'application elle-même. (en gros, si je n'ai pas créé le compte "ploum" dans dotclear, même si l'utilisateur ploum existe dans LDAP, je ne pourrais pas me logguer). Mais j'avoue que ça me semble très fumeux, je n'ai pas les idées précises. Est-ce que c'est bien ça ? Est-ce que c'est un choix ? Si c'est un choix, quelles sont les avantages/désavantages des différentes solutions ?
Un grand merci pour vos retours. Je dois avouer que je suis un peu paumé car je pense que mon use-case est très simple (centraliser l'identification et rien de plus) mais ce que je trouve comme doc me parle directement de racine, root machin chouette avec notation cryptique, identification sur 15 réseaux distribués, etc...
Je considérerais une solution comme un succès si changer mon password dans Jabber le change aussi dans dotclear et Bongo. Tout simplement :-)
Cela fait longtemps que j'entends parler de LDAP mais sans jamais vraiment bien comprendre.
J'aimerais une fois pour toute me simplifier la vie et que mon mail (bongo), mon blog (dotclear) et mon jabber (ejabberd) partage le même login/password sur mon serveur Ubuntu.
Je pense que pour ce genre de choses, LDAP est le plus approprié mais peut-être que je me trompe.
Avez-vous des ressources genre "LDAP pour les nuls" à me conseiller ?
Histoire que les choses soient encore plus facile pour moi, je me demandais s'il existait de bons front-ends graphiques pour administrer un serveur LDAP distant (soit un front-end web, soit une appli qui se connecte via internet donc).
Dernière question que je me pose : j'ai l'impression que dans cet usage relativement simple, LDAP ne gêrera donc que l'authentification. Tout ce qui est des privilèges et du compte lui-même sera gêrée par l'application elle-même. (en gros, si je n'ai pas créé le compte "ploum" dans dotclear, même si l'utilisateur ploum existe dans LDAP, je ne pourrais pas me logguer). Mais j'avoue que ça me semble très fumeux, je n'ai pas les idées précises. Est-ce que c'est bien ça ? Est-ce que c'est un choix ? Si c'est un choix, quelles sont les avantages/désavantages des différentes solutions ?
Un grand merci pour vos retours. Je dois avouer que je suis un peu paumé car je pense que mon use-case est très simple (centraliser l'identification et rien de plus) mais ce que je trouve comme doc me parle directement de racine, root machin chouette avec notation cryptique, identification sur 15 réseaux distribués, etc...
Je considérerais une solution comme un succès si changer mon password dans Jabber le change aussi dans dotclear et Bongo. Tout simplement :-)
> Lire le journal (35 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #920410.
Run by 
Cette page a été générée par Templeet en 0.0433s (dont 0.004 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
LDAP ou SGBDR ?
Aujourd'hui, j'ai un système d'authentification et de gestion des paramètres de mes applications serveurs qui utilise principalement une base de données relationnelle (PostgreSQL pour ne pas la citer).
Dans ces applications, j'ai mon serveur SMTP, IMAP, FTP, et je suis en train de regarder pour migrer ce qui est utilisé par Apache pour y mettre dedans aussi (au moins la gestion des comptes). Et puis si c'est la folie, ptêtre l'authentification des comptes locaux (via pam_sql) \o/
Maintenant que j'ai mis pas mal de choses dans cette BD, je me demande quels avantages j'aurais eu à choisir un serveur LDAP pour stocker ça à la place ?
J'ai pas vraiment rencontré de limitations avec les *mod_sql que j'ai utilisé jusqu'à présent, à part deux fonctionnalités (mais j'ai pas encore vraiment regardé non plus), à savoir :
* faire du virtual hosting avec Apache : ya un module LDAP [1] pour ça je crois, je sais pas si il y a l'équivalent en SQL ;
* gérer des carnets d'adresses : bon, j'avoue que c'est ça au départ qui m'a fait intéressé à LDAP :-)
Pour les applications serveurs que j'utilise (je dis pas si c'est généralisé), j'ai trouvé à chaque fois un équivalent SQL à LDAP...
Après, je me doute fort que pour des applications qui utilisent complètement LDAP, ça va coincer. Mais lesquelles ?
D'une manière générale, ma question reste donc ouverte (recopitage de la question d'au dessus) : "quels avantages j'aurais eu à choisir un serveur LDAP pour stocker ça à la place ?"
[1] : http://modvhostldap.alioth.debian.org/
[^]Re: LDAP ou SGBDR ?
quelques avantages :
1/ sécurité : la plupart du temps, quand tu veux vérifier un login/mdp :
* en SQL, c'est le même compte utilisateur SQL qui va faire une recherche dans ta table utilisateurs avec le login et le mot de passe. Donc si ton site est compromis, et que quelqu'un arrive à récupérer ce fameux compte ou faire une recherche en l'utilisant, par exemple via une injection SQL, il peut lire tous les mots de passe de ta base
* en LDAP, ce n'est pas une recherche qui est faite mais une authentification, directement en utilisant le login et le mot de passe (ou le DN et le mot de passe). Donc aucun compte n'a besoin de pourvoir lire les mots de passe. Donc ceux-ci sont mieux protégés.
2/ performance : les principes de modèle arborescent LDAP permettent d'effectuer des recherches significativement plus rapides. Je ne sais pas pourquoi. Mais on le lit de partout.
3/ intéropérabilité : même si comme tu dis les modules SQL existent de partout, il est plus facile de faire un module LDAP que SQL : moins de paramétrage nécessaire car des schémas standards d'utilisateurs/groupes/... existent, protocole identique quel que soit le vendeur, etc.