Sortie de Lemonldap::NG 0.9

Posté par . Modéré par Nÿco.
Tags : aucun
0
10
mar.
2008
Sécurité
Lemonldap::NG est un système de protection des sites web de type Web-SSO. La nouvelle version est sortie il y a quelques jours.

Principale innovation : l'intégration d'un portail d'authentification compatible Liberty-Alliance. Cette composante « service provider » permet à un utilisateur de se trouver authentifié sur le service protégé par Lemonldap::NG tout en étant authentifié auprès d'un fournisseur d'identité de son choix. Au menu également quelques corrections de bugs et de nombreuses améliorations des API.

Dernière nouvelle enfin et pas des moindres, Lemonldap::NG est désormais intégré à Debian (la version 0.9 passera de « unstable » à « testing » dans quelques jours). Une des principales caractéristiques de Lemonldap::NG est sa capacité à gérer les autorisations de manière centralisée. En effet, beaucoup de SSO sont utilisés pour véhiculer les authentifications, mais le contrôle des droits reste effectué sur chaque serveur. Avec Lemonldap::NG, l'interface web d'administration permet de visualiser tous les sites protégés et d'y administrer le contrôle d'accès.
La méthode retenue est un contrôle par expression régulière PCRE sur les URL auquel on associe un calcul sur les attributs LDAP (membre d'un groupe ou plus complexe). On peut toutefois continuer à gérer les droits localement sur tout ou partie des sites protégés.

Conçu sur une architecture très modulaire, Lemonldap::NG a été retenu par le projet FederID comme composant WebSSO.
Les autres éléments de ce projet sont l'annuaire Interldap et la bibliothèque Liberty-Alliance Lasso. Le principe retenu est de créer une interopérabilité entre systèmes d'authentification Web-SSO ou autres.
Cette solution d'interopérabilité est particulièrement étudiée par l'administration.

Aller plus loin

  • # Liberty Alliance

    Posté par (page perso) . Évalué à 3.

    Le support Liberty Alliance est en effet une fonctionnalité intéressante, apportée grâce au projet FederID.

    En effet, une application Web peut être facilement transformée pour venir s'inscrire dans le WebSSO de LemonLDAP::NG : il suffit qu'elle récupère l'identifiant de l'utilisateur (et d'autres informations si nécessaires) dans les en-têtes HTTP au lieu de présenter le formulaire d'authentification. Coût d'intégration : très faible.

    Faire du Liberty Alliance est plus complexe : l'application doit pouvoir dialoguer avec un fournisseur d'identités en utilisant des assertions SAML. La bibliothèque Lasso[1] (utilisée dans les différents composants de FederID, dont LemonLDAP::NG), permet de réaliser cette intégration, mais prend plus de temps (et nécessite plus de connaissances).

    L'idée ici est de transformer LemonLDAP::NG en fournisseur de service (donc vu comme une application client vis à vis d'un fournisseur d'identités), qui saura créer automatiquement une session SSO sur les applications qu'il protège déjà : c'est donc une solution très simple d'intégrer une application Web dans un cercle de confiance Liberty Alliance.

    [1] http://lasso.entrouvert.org/
    • [^] # Re: Liberty Alliance

      Posté par (page perso) . Évalué à 2.

      Je suis pas spécialiste des applications webs, mais par exemple, si je prends un forum php classique ( genre punbb ), il faut quand même gerer la base de compte quelque part, et donc tu te retrouves à quand même dupliquer la base des comptes et à devoir désactiver des fonctionnalités comme le changement de mot de passe, etc.

      Donc j'irais pas dire que c'est facile de transformer une appli, ou alors, il faut rajouter "c'est facile de transformer sans se soucier du reste et sans avoir peur de faire un truc pas trés propre".
      • [^] # Re: Liberty Alliance

        Posté par . Évalué à 2.

        Je suis un des développeurs de Lasso et je suis justement en train d'écrire un kit simple pour "libertyser" des applications PHP à partir du binding
        PHP de lasso (qui est nouveau lui aussi) . Il est tout à fait possible de se passer complètement de la base utilisateur locale si l'application ne demande pas une customisation trop importante i.e s'il faut
        juste stocker un email et un pseudo l'IdP peut s'en charger et le fournir à chaque login dans l'assertion SAML. Il suffit ensuite de le stocker
        dans le cookie de session. Ça supprime tout le code de session utilisateur. Ça suppose de prévoir SAML 2.0 comme unique technique d'authentification
        dés le départ ce qui est je l'avoue rarement le cas. Même s'il faut stocker un peu de parmétrage (recevoir les email d'info, afficher les pages avec
        le thème xyz, etc...) ça permet de limiter les informations critiques stocker en permanence localement comme les emails ou des numéros de CB. Le site
        peut se procurer ces informations (on dit des attributs dans le jargon liberty) au coup par coups avec autorisation explicite de l'utilisateur chez
        un fournisseur d'attributs.

Suivre le flux des commentaires

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