Sortie de LemonLDAP::NG 1.3

Posté par  . Édité par ZeroHeure, Benoît Sibaud, claudex et palm123. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes : aucune
17
3
nov.
2013
Sécurité

La version 1.3 de LemonLDAP::NG vient de sortir. Outre les quelques corrections de bogues, cette nouvelle version apporte son lot de nouveautés parmi lesquelles :

  • configuration de l'utilisation d'un annuaire AD plus aisée : un module AD hérite du module LDAP ;
  • nouveaux supports d'authentification externes : Mozilla Persona (BrowserID), WebID, Facebook, Google.

LemonLDAP::NG est une infrastructure d'authentification unique distribuée, c'est-à-dire qu'elle permet de s'authentifier une seule fois pour différentes applications web. Ce qui la distingue des autres solutions open-source est la gestion centralisée des droits. Elle se présente sous la forme d'une suite logicielle libre reposant sur le serveur web Apache. Depuis plusieurs années, elle implémente également plusieurs systèmes de fédération d'identité tels SAML/Shiboleth, CAS, OpenID, Twitter (OAuth2) et peut même servir de proxy entre ces protocoles. Hautement personnalisable, c'est la solution de très loin la plus utilisée dans l'administration française avec plusieurs centaines de milliers d'utilisateurs (gendarmerie, police, justice, douane, finances, culture,…).

La première version de LemonLDAP date de 2003, écrite par Éric German. Remplacé par LemonLDAP::NG en 2007, réécriture complète intégrant la gestion des droits, le projet continue de se développer.

Aller plus loin

  • # Perl

    Posté par  (site web personnel) . Évalué à 4.

    A noter que c'est programmé en Perl et, au vu des quelques fichiers que j'ai parcouru, cela me semble du Perl propre et particulièrement lisible.

    Question, vous utilisez quelle moulinette pour générer la doc car il me semble clair que les commentaires sont loin d'être idiot et in-structuré ;-)

  • # En comparaison de CAS, et sur quels Use Case?

    Posté par  (site web personnel) . Évalué à 3.

    Petites questions si des gens ont joué avec les outils SSO traînent par là:

    1) Comment se situe LemonLDAP par rapport à CAS (que je connais) qui semble proche sur la logique (différence, atouts/faiblesses).

    2) CAS (et semble t'il LemondDAP) fonctionne sur la logique j'essaye de m'authentifier sur un site, celui me redirige sur un autre site qui possède un champ login/pwd, puis, je suis redirigé vers le site initial. Désormais, je suis connu dans les sites géré par le SSO.

    Quel outils pour faire du SSO pour 2 use-case différents:
    a) Les champs login/pwd sont directement sur le site initial, ils sont envoyé en ajax sur le système SSO. Sans rediriger l'utilisateur sur un autre site.

    b) Faire du SSO en supportant l'auth basic d'apache. Pour authentifier des utilisateurs à des services avec par exemple des URL https://login:password@monservice.com . Ce genre de chose serait possible avec le mod Apache "qui va bien". Vous connaissez quelque chose?

    • [^] # Re: En comparaison de CAS, et sur quels Use Case?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Bonjour,

      je vais essayer de répondre aux différentes questions :

      1) CAS est avant tout un protocole (http://www.jasig.org/cas/protocol), c'est aussi un logiciel implémentant ce protocole. LemonLDAP::NG implémente également ce protocole. Côté logiciel, LemonLDAP::NG a de nombreux avantages sur CAS, comme le support de nombreux moyens d'authentifications, de la politique des mots de passe LDAP, du contrôle d'accès, etc.

      2) C'est en effet le principe. Dans le fonctionnement standard de LemonLDAP::NG toutefois, la transmission de l'identifiant se fait par en-tête HTTP vers l'application, alors que CAS nécessite d'intégrer un bibliothèque cliente (on parle de cassification).

      a) C'est moins simple car le système SSO doit positionner un cookie. LemonLDAP::NG propose toutefois un WebService permettant de le faire.

      b) C'est standard, LemonLDAP::NG possède un mode d'authentification Apache, et également un Handler AuthBasic permettant de le faire pour certaines applications en particulier.

      • [^] # Re: En comparaison de CAS, et sur quels Use Case?

        Posté par  (site web personnel) . Évalué à 1.

        Merci pour ta réponse.

        CAS, je connais (le logiciel qui implémente le protocole disons). LemonLdap a donc l'air plus complet, et offre plus de possibilité si par exemple l'application n'est pas "casifiable" (appli proprio par exemple).

        a) Pour le Webservice, tu parles donc du mode "Soap Admin Session"?… J'avoue que j'étais totalement passé a coté en regardant le site. C'est donc au site qui implémente le client Soap d'écrire le cookie. Et cela marchera tant que les différents sites à "SSOiser" sont dans le même domaine.

        b) Ca c'est bon.

        • [^] # Re: En comparaison de CAS, et sur quels Use Case?

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Oui, il y a une fonction SOAP getCookies qui permet de faire ça, activable dans le backend de sessions SOAP:

          ##@method SOAP::Data getCookies(string user,string password, string sessionid)
# Called in SOAP context, returns cookies in an array.
# This subroutine works only for portals working with user and password
#@param user uid
#@param password password
#@param sessionid optional session identifier
#@return session => { error => code , cookies => { cookieName1 => value ,... } }

Suivre le flux des commentaires

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