Sortie de LemonLDAP::NG 2.0

Posté par (page perso) . Édité par yadd, ZeroHeure, Trollnad Dump, Xavier Teyssier, Davy Defaud, paucur et M5oul. Modéré par Xavier Teyssier. Licence CC by-sa.
33
6
déc.
2018
Sécurité

LemonLDAP::NG est un logiciel libre d’authentification unique pour applications Web (WebSSO), de contrôle d’accès et de fédération d’identités, écrit en Perl et publié sous licence GPL. Cette nouvelle version majeure apporte de grands changements au logiciel comme le prise en charge de Node.js, des seconds facteurs d’authentification (OTP, U2F, Yubikey…), un mécanisme de greffons, la protection de micro‐services et bien d’autres qui seront développés dans la suite de cet article.
logo LemonLDAP::NG

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.

interface utilisateur LemonLDAP::NG

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.

Aller plus loin

  • # Du libre financé pour des services publics!

    Posté par (page perso) . Évalué à 10 (+10/-0).

    Du libre pour tous, suite à un gros besoin de l'état. C'est finalement le parcours de rêve pour ce projet!

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Hum, en fait, ça sert à quoi?

    Posté par . Évalué à 3 (+2/-1).

    Je suis désolé, mais je n'ai pas compris l'usage de ce logiciel et, malgré tout, j'ai l'impression qu'il pourrait me permettre de résoudre un de mes problèmes au taf: gérer facilement les comptes utilisateurs.
    Bon, je sais que c'est plus ou moins l'utilité de LDAP (je n'ai eu il y a quelques années qu'une formation sur AD, qui semble être une surcouche de LDAP, et je n'ai jamais eu l'occasion de manipuler du vrai LDAP) et justement, c'est là ou je ne comprend pas.

    Ce logiciel ajoute quoi à LDAP? Une interface facile à utiliser (facile restant à définir, la ligne de commande ne me fais que rarement peur)? Une possibilité de versionner facilement la config (j'ai cru lire qu'il est maintenant plus facile de faire un diff… pourquoi maintenant, et pas avant?)?

    • [^] # Re: Hum, en fait, ça sert à quoi?

      Posté par . Évalué à 6 (+6/-0).

      Je cite la première ligne : "LemonLDAP::NG est un logiciel libre d’authentification unique pour applications Web (WebSSO), de contrôle d’accès et de fédération d’identités".
      Donc, pour faire simple, ce logiciel ajoute la possibilité de faire du SSO (Single Sign On) sur des applications "web" (ex : intranet…) sur la base d'un annuaire (ex : LDAP) qui lui contiendra les comptes et les accréditations.

  • # SSO as a Service (SSOaaS)

    Posté par (page perso) . Évalué à 1 (+0/-0).

    Bonjour,

    je n'ais trop compris ce qu'apporte LemonLDAP::NG 2 par rapport à un couple IdP <-> Agent pour serveur web plus classique.

    Comme par exemple un IdP OpenID Connect (LemonLDAP::NG, keycloak, …) et le module apache mod_openidc (idem avec SAML en le module shibboleth,…) qui en 5 lignes de configurations dans le fichier ( https://github.com/zmartzone/mod_auth_openidc#quickstart-with-a-generic-openid-connect-provider ) apache permets de sécuriser un site ou une API tout en mettant à disposition des claims à l'application et aussi de gérer les droits d'accès ( https://github.com/zmartzone/mod_auth_openidc/wiki/Authorization ).

    • [^] # Re: SSO as a Service (SSOaaS)

      Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 07/12/18 à 14:57.

      Bonjour Mathieu,

      en effet OpenID connect apporte à peu près la même fonctionnalité, à ceci près qu'il faut en effet déployer un agent sur le client et le configurer (tu as ici la doc dédié à LemonLDAP::NG : https://github.com/zmartzone/mod_auth_openidc/wiki/LemonLDAP::NG).

      Mais mod_auth_openidc n'est par exemple disponible que pour Apache, pas Nginx. D'autre part, OpenID Connect exige que le client soit déclaré au niveau du serveur pour obtenir en particulier un client_id et un client_secret. Avec le mode SSOaaS de LL::NG, pas de déclaration nécessaire dans le serveur. Enfin OpenID Connect impose l'utilisation de scope et de claims, avec validation du consentement de l'utilisateur, ce qui est plutôt une bonne chose mais pas forcément souhaité dans le déploiement de micro services.

      • [^] # Re: SSO as a Service (SSOaaS)

        Posté par . Évalué à 2 (+0/-0).

        Mais mod_auth_openidc n'est par exemple disponible que pour Apache, pas Nginx

        Tiens, d'ailleurs, puisqu'on en parle : ça donne quoi LemonLDAP avec autre chose qu'Apache? Nginx c'est bon? Traefik? Caddy? Y'a des retours d'expérience sur ce type de choses?

        • [^] # Re: SSO as a Service (SSOaaS)

          Posté par (page perso) . Évalué à 2 (+0/-0).

          Tiens, d'ailleurs, puisqu'on en parle : ça donne quoi LemonLDAP avec autre chose qu'Apache? Nginx c'est bon? Traefik? Caddy? Y'a des retours d'expérience sur ce type de choses?

          LemonLDAP::NG est compatible Apache, Nginx et tout serveur Plack. C'est désormais Nginx qui est recommandé, car le support de mod_perl dans Apache 2.4 ne permet pas d'avoir des performances correctes.

      • [^] # Re: SSO as a Service (SSOaaS)

        Posté par (page perso) . Évalué à 1 (+0/-0).

        merci pour le retour.

        OpenID Connect exige que le client soit déclaré au niveau du serveur pour obtenir en particulier un client_id et un client_secret.

        Comment le serveur sait-il que la demande est ou non légitime et que ce n'est pas une application faisant par exemple du phishing ?

        Enfin OpenID Connect impose l'utilisation de scope et de claims

        Il est tout à fait possible de faire une demande d'autorisation sans scope et de ne retourner aucun claims (et donc de ne faire que de l'authentification). Mais c'est plutôt dommage si l'application doit faire du contrôle d'accès derrière.

        avec validation du consentement de l'utilisateur

        Toutes les solutions que je connais permet de bypasser cette étape au besoin

        pas forcément souhaité dans le déploiement de micro services.

        Je ne suis absolument pas un spécialiste en micro service, mais n'utiliserions nous pas simplement les jetons en Bearer (access_token ou id_token). Jetons issuent d'une authentification utilisateur préalable (avec éventuellement un consentement :)) ou d'une authentification en grant_type=client_credential pour les "non humains" puis propagation des jetons de services en services (exemple de conf de sécurisation de ressource avec mon cher mod_auth_openidc https://github.com/zmartzone/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server) ?

        Mais mod_auth_openidc n'est par exemple disponible que pour Apache, pas Nginx

        Pour ngnix il y a https://github.com/zmartzone/lua-resty-openidc (lui aussi certifié)

        Désolé, j'ai beaucoup de questions et interrogations, mais c'est un sujet qui m’intéresse beaucoup.

        • [^] # Re: SSO as a Service (SSOaaS)

          Posté par (page perso) . Évalué à 2 (+0/-0).

          Comment le serveur sait-il que la demande est ou non légitime et que ce n'est pas une application faisant par exemple du phishing ?

          Un paramètre permet de lister les hôtes de confiance (vers qui une redirection est autorisée). On peut autoriser tout un sous-domaine par exemple.

          Il est tout à fait possible de faire une demande d'autorisation sans scope et de ne retourner aucun claims (et donc de ne faire que de l'authentification). Mais c'est plutôt dommage si l'application doit faire du contrôle d'accès derrière.

          Pour être précis, le scope "openid" est obligatoire, sinon tu fais du OAuth2 et pas du OpenID Connect. Et donc l'utilisateur doit accepter ce scope.

          Toutes les solutions que je connais permet de bypasser cette étape au besoin

          En effet, LL::NG le permet aussi, mais c'est contraire au protocole.

          Je ne suis absolument pas un spécialiste en micro service, mais n'utiliserions nous pas simplement les jetons en Bearer (access_token ou id_token). Jetons issuent d'une authentification utilisateur préalable (avec éventuellement un consentement :)) ou d'une authentification en grant_type=client_credential pour les "non humains" puis propagation des jetons de services en services (exemple de conf de sécurisation de ressource avec mon cher mod_auth_openidc https://github.com/zmartzone/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server) ?

          Attention, un ID Token est un JWT qui n'a pas vocation à être utilisé en authentification Bearer, c'est l'access token qui est prévu pour ça. Pour être bref, oui OpenID Connect peut marcher pour protéger applications et API, mais ce n'est pas la seule solution et elle nécessite que les applications et API implémentent le protocole.

          Pour ngnix il y a https://github.com/zmartzone/lua-resty-openidc (lui aussi certifié)

          Merci, je ne connaissais pas.

      • [^] # Re: SSO as a Service (SSOaaS)

        Posté par (page perso) . Évalué à 1 (+0/-0).

        Complément au POST du dessus …

        qu'il faut en effet déployer un agent sur le client

        Oui. Dans LemonLDAP::NG 2, si j'ai bien compris, c'est du FastCGI ? c'est donc bien exécute aussi coté serveur web ? Il est aussi possible de mettre ton apache en reverse proxy de ton application et de propager les claims via, par exemple, les headers (comme Lemon, si j'ai bien suivis).

        • [^] # Re: SSO as a Service (SSOaaS)

          Posté par (page perso) . Évalué à 2 (+1/-0).

          Ça dépend du serveur web :

          Protéger un vhost

          Si tu veux protéger un vhost gérer par Apache, tu as juste un handler Perl à ajouter à la conf du vhost (en plus du mod Perl à activer) :
          PerlHeaderParserHandler Lemonldap::NG::Handler::ApacheMP2

          Pour Nginx tu passes par FastCGI pour accéder à un process Lemonldap::NG.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.