Sommaire
Le projet LemonLDAP::NG a été publié pour la première fois en 2005 par la Gendarmerie nationale. Il est aujourd’hui très largement déployé en France, notamment dans les administrations et collectivités territoriales. Ses grands principes sont :
- le SSO doit être faiblement intrusif dans les applications : pas d’obligation d’utiliser une bibliothèque ou un langage spécifique, prise en charge d’un maximum de protocoles, etc. ;
- le SSO ne doit pas pénaliser les performances des applications (architecture extensible, faible surcharge…) ;
- pont protocolaire : LemonLDAP::NG permet de connecter une application utilisant le protocole standard X sur une infrastructure basée sur le protocole Y ;
- et, bien sûr, la sécurité et le confort des utilisateurs.
Principales nouveautés de la version 2.0
Voici les principales nouveautés de cette nouvelle version majeure :
- meilleur fonctionnement du pont protocolaire : de nombreux tests unitaires valident le fonctionnement du SSO lors du passage d’un protocole à un autre ; par exemple, une application qui s’authentifie en SAML sur le portail WebSSO, qui lui‐même redirige en OpenID Connect sur un fournisseur d’identité externe (France Connect, Google, etc.) ;
- authentification multi‐facteur ;
- SSOaaS (SSO as a Service) ;
- un moteur de greffons permettant de créer des composants d’authentification ou toutes sortes d’applications s’intégrant au portail sans avoir à modifier le code source et ainsi mieux gérer les montées de version.
Vous pouvez consulter la liste complète des nouveautés.
Handler Node.js
Node.js est une plate‐forme très populaire pour le développement d’applications Web. La version 2.0 inclut un handler node.js en version bêta, qui permet de protéger une application Node.js par LemonLDAP, directement dans le code de l’application.
Cela permet également de rendre facilement une application compatible avec des protocoles de SSO comme SAML ou OpenID Connect. Ce handler ne gère pas encore toutes les fonctionnalités de LL::NG.
Le handler Node.js fournit également un moteur alternatif pour le SSO en tant que service.
Seconds facteurs d’authentification
LemonLDAP::NG gère désormais directement les seconds facteurs d’authentification (2FA), en particulier :
- les périphériques U2F ;
- TOTP (FreeOTP, Authy, GoogleAuthenticator…) ;
- les clefs Yubikey ;
- les appels REST à un service Web externe ;
- n’importe quelle autre commande via le module External 2F.
Greffons
LemonLDAP::NG est désormais capable de gérer des développements spécifiques sans pour autant risquer de les casser en cas de mise à jour, via un système de greffons. Quelques exemples déjà disponibles :
-
Auto Signin : permet de s’authentifier automatiquement en fonction d’une règle, par exemple une adresse IP ;
-
Brute Force Protection : permet de gérer la protection contre les attaques en force brute directement dans LemonLDAP::NG ;
-
Check State : permet de générer une page de statut pour une meilleure intégration avec des outils de supervision ;
- etc.
SSO as a Service (SSOaaS)
Le contrôle d’accès SSO fournit trois services :
- authentification globale ;
- gestion des autorisations : authentifier n’est pas suffisant, les droits d’accès doivent être examinés ;
- traçabilité :
- traces d’accès issues du SSO,
- traces des actions de l’utilisateur.
LemonLDAP::NG fournit tous ces services (à l’exception des traces des actions des utilisateurs qui doivent être générées par l’application, mais LemonLDAP::NG fournit les identifiants à enregistrer via les en‐têtes HTTP).
Les acronymes « *aaS » signifient que l’application peut piloter la couche sous‐jacente (IaaS, pour l’infrastructure ; PaaS, pour la plate‐forme…). Pour nous, le SSOaaS doit fournir la possibilité pour une application de gérer ses droits et choisir les attributs à transmettre : un fichier JSON est présent à la racine de l’application et permet de définir ces paramètres, sans avoir à manipuler la configuration centrale du WebSSO.
L’authentification SSO ne peut être réellement « *aaS » : l’application l’utilise sans la gérer, bien sûr.
LemonLDAP::NG fournit donc les fonctionnalités permettant de mettre en œuvre le SSOaaS dans ces conditions. Encore un peu rustique, cette prise en charge sera améliorée dans les prochaines mises à jour de la branche 2.0.
Serveur à Serveur
Les applications modernes utilisent des micro‐services Web. LemonLDAP::NG fournit un dispositif permettant de donner à une application un ticket qu’elle peut utiliser sur d’autres micro‐services protégés par le WebSSO pour :
- propager l’identité de l’utilisateur final ;
- permettre aux micro‐services de vérifier les droits de l’utilisateur final ;
- limiter l’accès de cette application aux seuls micro‐services autorisés dans la console d’administration LemonLDAP::NG ;
- limiter l’usage dans le temps de ce ticket (30 secondes).
L’alternative consistant à donner à l’application le ticket SSO de l’utilisateur est nettement moins sécurisée : l’application obtiendrait ainsi tous les droits de l’utilisateur pendant tout le temps de sa session.
La solution apportée par LemonLDAP::NG est une alternative à OAuth2, moins intrusive : le micro‐service n’a pas besoin de valider le jeton d’accès, ce jeton est consommé directement par un handler qui retransmet ensuite l’identité de l’utilisateur via des en‐têtes HTTP.
Fédération Renater
LemonLDAP::NG est désormais compatible nativement avec le système de fédération de Renater, permettant de rendre son déploiement plus facile dans l’éducation, les universités, les laboratoires et le secteur public utilisant la fédération de Renater.
Manager
Différentiel des configurations
Cette nouvelle fonctionnalité permet d’afficher directement dans le Manager la différence entre deux versions de la configuration et donc d’identifier plus facilement les paramètres qui ont été modifiés.
Gestion des ACL pour les protocoles CAS, SAML et OpenID Connect
Il est désormais possible de définir des listes de contrôle d’accès (ACL) pour des applications reliées par CAS, SAML et OpenID Connect. Ces règles peuvent être également utilisées pour afficher ou non l’icône des applications dans le menu.
Autres
- explorateur de sessions : possibilité de trier les sessions par date de création et de modification ;
- journaux : possibilité de gérer les journaux séparément (traces techniques et traces des utilisateurs) :
- journaux du serveur (Apache uniquement) ;
- journal système (syslog) ;
- Log4Perl (compatible Log4J) ;
-
Sentry (à utiliser de préférence avec Dispatch) ;
- Dispatch : permet de tracer séparément en fonction du niveau d’alerte.
Portail
Rafraîchissement de la session
Il est à présent possible pour l’utilisateur de rafraîchir sa session sans avoir besoin de se déconnecter, utile dans le cas de l’ajout à un nouveau groupe apportant de nouvelles applications sur le portail.
Autres
- sélection de la langue avant la connexion ;
- nouvelles langues : vietnamien, arabe et italien, en plus de l’anglais et du français ;
- gestion du changement de logo du portail sans modifier le thème ;
- passage du portail sur Bootstrap 4.
Contributeurs
Les contributeurs suivants ont participé à cette nouvelle version :
- développeurs principaux : Xavier Guimard, Christophe Maudoux et Clément Oudot ;
- organisations (sponsors et bêta‐testeurs) : la Gendarmerie nationale, Worteks, Orange, Huma Num, Campus Condorcet, Agirc‐Arrco et Urgences Santé Québec ;
- communauté (ouvertures de tickets, tests et correctifs) : Valérie Bauche, David Coutadeur, Frédéric Massot, Mathieu Lecompte‐Melançon, Nicolas Chauvet, Mathieu Parent, Rick Jongbloed, Jérémy Kespite, Philippe Baye, Pasi Karkkainen, Julian Layen, Quentin Jabœuf, Stéphane Liabat, Emmanuel Lesouef, François‐Xavier Deltombe, Iheb Khemissi, Jean‐Charles Rogez, Nicolas Dutertre, Maxime de Roucy, pit pit, Carl R., Dave Conroy, Paul Curie, Dejan Sanader, Jean‐François Vincent, Anthony Roussel, Xavier Bachelot, Lulandco, Cédric Liard, Frédéric Pégé, Jonathan Swaelens et Michael Goldfinger.
