LemonLDAP::NG est une réécriture de la version initiale LemonLDAP, qui n'est aujourd'hui plus maintenue. Eric German, leader historique de la communauté, est à présent impliqué sur un nouveau projet, LemonID, que nous vous invitons à découvrir.
Cette version est normalement la dernière avant la 1.0 qui se concentrera sur la refonte de la configuration (utilisation de XML, exhaustivité des paramètres de configuration dans la console d'administration Web, etc.). Elle apporte toutefois un lot conséquent de corrections et d'améliorations, telles qu'un menu des applications autorisées, un explorateur de session, et des paquetages pour les systèmes basés sur Debian et RedHat.
Cette version est également importante en terme de sécurité car elle corrige quelques failles de Cross Site Scripting (XSS) et ajoute un contrôle plus fort sur les URL de redirection. LemonLDAP::NG permet de déployer trois types d'architectures de WebSSO :
- Un système de mandataire inverse (reverse-proxy) qui concentre en un point unique le portail d'authentification et les agents de contrôles. L'utilisateur n'accède alors jamais directement aux applications mais utilise toujours le mandataire.
- Un système de délégation, où les agents de contrôles sont déployés au plus près des applications. Dans ce cas l'utilisateur accède directement aux applications, dont les agents interagissent avec le portail d'authentification pour valider les sessions.
- Un système mixte, mélangeant le mandataire inverse et la délégation.
Voici quelques détails supplémentaires sur les principales fonctionnalités du produit :
- Indépendance des mécanismes d'authentification et de recherche des données de l'utilisateur : la phase d'authentification permet de valider la création de la session WebSSO, elle peut être effectuée sur un annuaire LDAP, par certificat SSL, par Liberty Alliance, par CAS, par Kerberos ou tout autre méthode d'authentification disponible dans Apache2. La phase de recherche des données correspond elle à la récupération des informations propres à l'utilisateur (nom, mail, etc.) qui serviront d'une part à valider les règles d'accès, et d'autre part à approvisionner les applications protégées. Cette phase ne peut à l'heure actuelle être opérée que sur un annuaire LDAP (l'ajout d'autres méthodes est prévu dans les futures versions).
- Utilisation des Web-Services (SOAP) : il est possible d'activer les Web-Services pour s'authentifier (et donc créer la session SSO correspondante), consulter et modifier les sessions existantes, consulter et modifier la configuration.
- Portail d'authentification : il permet de s'authentifier lorsque l'on est redirigé depuis des applications protégées, mais propose également un module de menu dynamique des applications (seules les applications autorisées sont affichées à l'utilisateur) et un module changement de mot de passe. L'affiche de ces modules est également dynamique, et peut permettre par exemple de ne proposer le changement de mot de passe qu'à une certain profil d'utilisateurs.
- Interface d'administration graphique : LemonLDAP::NG fournit par défaut un Manager qui permet d'éditer à travers une page Web la configuration générale du WebSSO ainsi que les droits d'accès et les en-têtes spécifiques à chaque application protégée. Cette nouvelle version propose également un explorateur de sessions, offrant une vue hiérarchique des sessions (par identifiant ou adresse IP), et affichant le contenu de chacune d'elles. Cette interface peut être protégée directement par le WebSSO.
- Choix des backends de session et de configuration : les sessions peuvent être stockées comme fichiers, dans une base MySQL, par SOAP ou dans memcached. La configuration peut être stockée comme fichier, dans une base MySQL ou par SOAP. Ce choix permet de mettre en place très rapidement des solution de haute-disponibilité. En cas de configuration stockée sur un système distant, un mécanisme de cache permet de limiter le transfert des données sur le réseau.
- Agents et applications compatibles : un certain nombre d'applications sont déjà compatibles avec LemonLDAP::NG, en particulier GLPI, Sympa, Dokuwiki, ... Mais des agents sont également disponibles, en particulier une valve pour Tomcat permettant le SSO sur les application J2EE délégant leur sécurité au conteneur de servlets (par exemple le CMS Lutece, probe, etc.). De plus, toutes les applications Web utilisant des protections Apache (par exemple par htaccess) sont nativement compatibles (c'est le cas de Nagios). Enfin, la nouvelle version de LemonLDAP::NG peut à présent mettre le mot de passe de l'utilisateur en session, ce qui permet par exemple le SSO sur des applications protégées par HTTP Basic (en particulier le fameux Outlook Web Access).
- Pages de statuts et scripts de supervision : une page de statut est à présent disponible (équivalent au mod-status d'Apache), permettant de réaliser simplement des graphiques avec des outils de supervision (un script pour MRTG est fourni dans les exemples).
- Politique des mots de passe : LemonLDAP::NG est compatible avec la politique des mots de passe des annuaires LDAP qui suivent le draft de la RFC. C'est le cas d'OpenLDAP avec l'overlay policy. Cela permet à l'utilisateur de savoir que son compte est bloqué ou expiré, et de changer son mot de passe en respectant les critères fixés dans l'annuaire (taille minimale, présence dans l'historique, etc.)
Cette version fait donc état de la grande maturité du produit et des nombreuses fonctionnalités offertes. Toute la communauté reste à l'écoute des utilisateurs pour répondre aux questions et enrichir le logiciel selon leurs besoins. Toutes les contributions sont également les bienvenues.
Aller plus loin
- Site officiel (36 clics)
- Téléchargement (6 clics)
- Captures d'écran (9 clics)
- Projet sur la forge OW2 (5 clics)
# Si j'ai bien compris...
Posté par Aefron . Évalué à 2.
> De plus, toutes les applications Web utilisant des protections Apache (par exemple par htaccess) sont nativement compatibles
Donc, si j'ai bien compris, ça permet (outre le SSO) d'unifier les méthodes d'identification web, quelles qu'elles soient entre LemonLDAP::NG et le serveur sur lequel on souhaite s'authentifier ? Par exemple, forcer l'utilisation d'un certificat de smartcard pour accéder à un service à la base "protégé" par htaccess... Intéressant.
D'autant que suis justement en train de me repencher sur LDAP - j'avais arrêté de le tester il y a un moment en me disant que le faible nombre d'utilisateurs que j'ai inhibait ses bénéfices, mais en fait, vu le nombre de machines que je finis par avoir avec les conteneurs OpenVZ/Vserver, j'ai maintenant dans l'idée de m'en servir comme base de données que mon CFengine maître utiliserait pour personnaliser les fichiers qu'il exporte aux clients, en faisant gaffe à gérer le cas d'indisponibilité du LDAP, et afin de répartir les données dans le réseau sans forcément les dupliquer à leur définition.
Par exemple, savoir sur quelles machines tourne quoi et à partir desquelles autres elles peuvent être jointes est utile pour configurer iptables sur les routeurs, pour configurer les serveurs, _et_ pour configurer les clients - or tant que le CFengine maître est le seul à connaître toutes ces données, rangées proprement dans une base de données LDAP, les ACL LDAP ne deviennent pas trop un enfer (par rapport à si je déléguais la recherche aux clients CFEngine)...
... pour ce qui est des ACL CFEngine, ie les "grant" du cfservd.conf, je pense "simplement" essayer de les fabriquer à partir des FDQN des hôtes (en créant autant de répertoires exportés que d'hôtes, et où seront personnalisés des fichiers de conf génériques, en fonction de certaines classes, assignées dans l'annuraire), et de LDAP...
Je n'ai pas encore trop réfléchi à comment bénéficier, au passage, de LDAP pour les authentifications (vu que ce n'est pas mon but initial), mais j'ai dans l'idée que je n'aurai pas trop de mal à trouver une place dans cet ensemble à LemonLDAP, entre autres.
[^] # Re: Si j'ai bien compris...
Posté par KPTN (site web personnel, Mastodon) . Évalué à 2.
Cela sort toutefois du cadre de LemonLDAP::NG qui est dédié aux applications Web, et donc comme cité en début de commentaire, permet de centraliser l'authentification et les règles d'accès aux applications protégées.
[^] # Re: Si j'ai bien compris...
Posté par Aefron . Évalué à 2.
J'imagine que je vais devoir modifier le schéma pour ajouter les infos dont j'ai besoin, et c'est ce qui me fait un peu peur (pas beaucoup d'expérience LDAP)... mais j'en ai un peu marre de définir mes variables et classes CFEngine dans des fichiers textes, et j'ai de plus en plus besoin de quelque chose comme un annuaire (a priori, ça me paraît plus adapté qu'un MySQL ou assimilé)...
Par contre, pas grand monde n'a l'air de faire ça (en tout cas, avec CFEngine... Puppet inclue de quoi gérer une conf centralisée dans LDAP ; mais trop de choses me gênent par ailleurs dans Puppet)...
> Cela sort toutefois du cadre de LemonLDAP::NG
Certes : LemonLDAP::NG est néanmoins une raison de plus de me repencher sur LDAP... et je dois avouer que son concept est séduisant.
# Oh non! Pas XML!
Posté par FantastIX . Évalué à 6.
Par contre, le simple fait d'utiliser XML pour les fichiers de configuration me donne de l'urticaire. Je vois de plus en plus de projets adopter XML en tant que support de données. Et la modification de ces données à la main est un vrai cauchemar pour monsieur-tout-le-monde.
D'après ce que j'ai constaté la plupart du temps et tel que je l'ai vu mis en oeuvre:
* XML n'est pas intuitif.
* XML n'est pas lisible facilement pour un humain.
* XML n'est pas convivial.
* XML possède trop de contraintes syntaxiques pour des choses simples (des commentaires, par exemple, via l'utilisation de sections CDATA et autres...)
Comparé à de simples fichiers INI, par exemple, ou d'autres types de fichiers texte, XML est totalement indigeste. XML est adapté à l'échange de données entre machines (c.-à-d. là où l'humain n'est pas sensé intervenir), pas au stockage, surtout si les données doivent être modifiées par l'humain et c'est souvent le cas.
Les exemples que j'ai sous la main pour illustrer mon opinion sont les fichiers de configuration de eINIT, de Xfont, de Hal... Je ne remets évidemment pas en cause tout ce beau projet. Je mets simplement l'accent sur le fait qu'il est préférable de ne choisir XML que s'il est inévitable.
[^] # Re: Oh non! Pas XML!
Posté par Henry-Nicolas Tourneur (site web personnel) . Évalué à 1.
XML is like violence : if it doesn't work, use more.
Ceci dit je trouve que xml n'est pas si si inbuvable (question de point de vue) que ça et je suppose que les config en xml facilitent le chargement de la configuration dans le logiciel.
[^] # Re: Oh non! Pas XML!
Posté par KPTN (site web personnel, Mastodon) . Évalué à 1.
On peut imaginer conserver sans problème un mode de stockage de configuration en fichier plat, comme c'est le cas actuellement.
[^] # Re: Oh non! Pas XML!
Posté par BAud (site web personnel) . Évalué à 1.
[^] # Re: Oh non! Pas XML!
Posté par Xavier Guimard . Évalué à 2.
XML va être utilisé en arrière-plan dans Lemonldap::NG : la configuration se fait par une interface web facile à manipuler. Actuellement, la configuration est stockée dans des fichier texte ou des champs SQL mais n'est pas du tout intuitive pour certains champs. Actuellement seul un petit XML doit être édité à la main pour l'affichage du menu, mais tout ça va rejoindre l'interface web de management.
@+
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.