Sortie de Lasso 0.6.5

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes : aucune
0
23
mar.
2006
Sécurité
Lasso est la première implémentation sous licence GNU GPL permettant d'intégrer le Single Sign On (SSO voir seconde partie) et les spécifications Liberty Alliance dans une application.
Elle permet notamment de :
  • Sécuriser les accès aux applications sur tous les réseaux, publics et privés
  • Simplifier l'accès aux applications par l'utilisation des technologies Single Sign On
  • Garantir le respect de la vie privée des utilisateurs grâce à Liberty Alliance.

Contrairement aux autres implémentations de Liberty Alliance, Lasso n'est pas une plate-forme Java / J2EE. Le travail d'intégration s'en trouve facilité. Un site existant peut l'intégrer en quelques jours de développement, sans remettre en cause son architecture.
Lasso est une bibliothèque écrite en C. Elle fonctionne sur GNU/Linux (et fait partie en particulier de la distribution Debian), Windows et UNIX. Elle s'interface avec les langages C, C++, ColdFusion, Java, PHP, Perl et Python. Elle repose sur des bibliothèques XML performantes (libxml2, XMLSec) ce qui lui permet de supporter des montées en charge importantes.

La version 0.6.5 apporte son lot de nouveautés. La compatibilité avec les versions précédentes a été assurée aussi bien pour l'API que pour l'ABI, tous les utilisateurs sont donc encouragés à passer à cette nouvelle version.
Elle comprend un support des fonctionnalités ID-WSF essentielles (Interaction service, signature des messages) et implémente 70 % du protocole SAML 2.0 (Web SSO et Single Logout). La version 0.6.5 affine également la détection des erreurs, supporte SWIG 1.3.28 et améliore plus généralement la qualité des bindings et la gestion de quelques cas particuliers.

À propos : Entr'ouvert est spécialisée dans les solutions libres de E-administration et d'identification numérique. Elle fait partie du réseau Libre-entreprise, réseau de sociétés de service en logiciel libre, dans lequel les entreprises fonctionnent de manière démocratique. Tiré de fr.wikipedia.org :

Web Single Sign On (Web-SSO) est un principe permettant aux utilisateurs d'applications web de ne pas s'authentifier séparément sur chaque application : les applications vérifient que l'utilisateur a déjà été authentifié précédemment.

Comme ces dispositifs sont généralement basés sur des cookies, on ne peut généralement pas véhiculer les authentifications en dehors d'un domaine DNS. Pour résoudre ce problème, plusieurs sociétés se sont associés pour définir des mécanismes d'interopérabilité entre Web-SSO et ont créé le projet Liberty Alliance.

Aller plus loin

  • # Je comprends pas...

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

    //Lasso n'est pas une plate-forme Java / J2EE. Le travail d'intégration s'en trouve facilité. Un site existant peut l'intégrer en quelques jours de développement, sans remettre en cause son architecture.//
    Je comprends pas trop pourquoi cette phrase :)

    http://about.me/straumat

    • [^] # Re: Je comprends pas...

      Posté par  . Évalué à 1.

      C'est bien plus facile de binder une blibliothèque C à du perl/php/cequetuveux qu'un truc JAVA ou même C++.

      • [^] # Re: Je comprends pas...

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

        Beh alors, on a pas la même notion de ce qu'est le SSO... pour moi, tu dois justement être indépendant de la technologie utilisée ! j'utilise du SSO et c'est transparent (webservices, post http, cookies), c'est complètement nul de faire des choses aussi couplées !
        Dans le cas que tu cites, un changement de technologies SSO t'oblige à réécrire tes applications ???

        http://about.me/straumat

        • [^] # Re: Je comprends pas...

          Posté par  . Évalué à 2.

          Je peux me tromper, mais il faut bien que ton application "cause SSO", d'une manière ou d'une autre ? Peux tu m'expliquer comment tu réalises l'authentification si ton appli ne "cause pas SSO" ?
          Libre à toi de faire le boulot toi même en php par exemple ... mais bon si une lib avec de bon bind est disponible, y a pas photo, je réinvente pas la roue ...

          Caeies.

          • [^] # Re: Je comprends pas...

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

            comme je comprends SSO, il s'agit au pire d'un token et d'un ensemble d'informations. Pourquoi le lier à un langage, n'importe quel langage peut récupérer les informations et les traiter comme il veut.

            http://about.me/straumat

            • [^] # Re: Je comprends pas...

              Posté par  . Évalué à 8.

              il s'agit au pire d'un token et d'un ensemble d'informations

              Bien sur, et pour que ton appli supporte le SSO, tu fais comment, tu recompiles ton code avec l'option -sso et "pouf" ca marche tout seul? Comment recuperes-tu le token et les informations associees a ton token? Ben oui, faut du code. Et c'est la que vient le petit bidule qu'on vient de te presenter...

              Comme on est pas sous MultiDeskOs, malheureux que nous somme, on a pas la fonction "getSSO" ecrit dans le super language qui fonctionne pour tout les langages et tout les CPUs existant.

              Il y a donc une equipe qui a ecrit une seule fois une lib qui manipule tout comme il faut, et apres fournit les bindings pour que cette meme lib soit utilisable a partir d'autres langages (Finalement on est pas loin du MultiDeskOs).

    • [^] # Re: Je comprends pas...

      Posté par  . Évalué à 2.

      Si tu écris ta plateforme SSO en Java, et que tu n'as que des serveur Apache/PHP et IIS/perl/CGI, tu vas être obligé d'installer une machine virtuelle Java ce qui est dommage en terme de ressources, de causer avec, ce qui n'est pas si facile (JNI).

      Là, si tu veux faire du PHP tu installes le module sous PHP, et du perl tu installes le module sous Perl, et ça va marcher.

      @+

      • [^] # Re: Je comprends pas...

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

        On a pas la même notion du SSO.. je dois me tromper mais je ne vois pas pkoi tes applications doivent communiquer directement avec le langage ? c'est fou quand même de lier des choses comme ça !

        Les applications et les SSO devient extrêmement couplés alors que le but du SSO et quand même de découpler l'authentification des différentes applications.

        http://about.me/straumat

        • [^] # Re: Je comprends pas...

          Posté par  . Évalué à 4.

          remplace SSO par HTTP dans ta phrase, et tu comprendras vite l'intérêt d'avoir une libsso facilement "bindable", histoire de pouvoir implémenter des clients et des serveurs SSO dans le langage de ton choix.

          Just my 0.02¤

          • [^] # Re: Je comprends pas...

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

            C'est juste que je ne comprends pas pouquoi le SSO soit être lié à un langage. Dans toutes les solutions sur j'ai vu comme JOSSO (sur lequel j'ai fait un article http://jroller.com/page/jonaslive?entry=setting_up_josso_in_(...) on peut faire du SSO peu importe la techno et tu peux changer de serveurs sans reprogrammenr ton client !

            http://about.me/straumat

            • [^] # Re: Je comprends pas...

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

              D'après la documentation de Josso[1], pour l'utiliser dans une application de PHP, il y a non seulement du code mais aussi un gros changement d'architecture système, obligation de passer par un système de reverse-proxy qui routera toutes les demandes par un serveur Java derrière.

              Certains développeurs PHP préféreront avoir une extension à leur langage que de devoir passer par Java. Et c'est valable aussi pour les développeurs Python, Perl, etc.

              Après, concernant les spécifications des échanges inter-serveurs permettant le SSO, on peut soit implémenter du spécifique soit du standard. Et comme standard de SSO multi-domaines, je ne connais que Liberty Alliance.

              À noter que SourceID[2] propose une implémentation Java de Liberty Alliance sous une licence propre à eux mais qui à une première lecture est libre.

              Et pour terminer, il serait possible d'utiliser les bindings Java de Lasso pour implémenter un système comme Josso. Ça n'apporterait même que du bon, un système simple à mettre en place pour les développeurs Java qui en plus respecterait les standards Liberty.



              [1] http://www.josso.org/php-howto.html
              [2] http://www.sourceid.org

              [Disclaimer: je suis un des développeurs de Lasso, mais ce n'est pas moi qui ai posté la brève ni mis le commentaire sur J2EE]

    • [^] # Re: Je comprends pas...

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


      Je comprends pas trop pourquoi cette phrase :)

      On serait dans le monde commercial, je parlerai de FUD. Heureusement, on est sur LinuxFr.
      Et moi non plus, je ne comprend pas cette phrase. Parce que les web services, l'interopérabilité et tout ça, ça fait un bout de temps que ça existe.

  • # Identity management

    Posté par  . Évalué à 2.

    Est-ce que quelqu'un connait une solution "d'identity management" libre ?
    Je cherche une solution permettant de faire du "Provisioning/Deprovisioning", "Password Synchronization",
    "Self-Service Password Reset" et un workflow pour les demandes d'accès...

    Le single sign-on n'est pas essentiel...

    http://en.wikipedia.org/wiki/Identity_management

  • # Serveur CAS

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

    Tiens c'est marrant j'viens de décrocher un job ou je dois faire fonctionner eprints[1] avec un server CAS [2] pour récupérer le login de l'utilisateur et récuperer ses infos sur un serveur LDAP[3]. A priori tout ça c'est du logiciel libre déjà, même si c'était pas forcément gnu gpl certes.

    Pour se qui est de l'implémentation, CAS (écrit en java) laisse le client faire comme bon lui semble et il existe tout une panoplie de client dans plein de langages, et j'ai même trouvé un module perl apache::authcas qui devrait bien m'aider, d'autant qu'eprints est écrit en perl.

    [1] http://www.eprints.org/
    [2] http://www.yale.edu/tp/auth/cas20.html
    [3] http://fr.wikipedia.org/wiki/LDAP

    • [^] # Re: Serveur CAS

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

      Un lien plus récent et plus funky pour CAS :
      http://www.ja-sig.org/products/cas/index.html

      CAS qui l'air de rien et sans FUD aucun est devenu une solution mature et efficace pour implémenter sans frais un WEB SSO local.
      La "cassification" des applications consiste simplement à déléguer l'authentification au serveur CAS centralisé et avec les bilbiothèques fournies c'est trés simple et propre quelque soit le language utilisé.
      Dans le cas d'applications JAVA il est même possible de "cassifier" l'application sans la modifier en agissant uniquement au niveau du filtre de servlet.

  • # SSO ? Pas convaincu...

    Posté par  . Évalué à 1.

    Il faudra que je creuse pour comprendre comment cela fonctionne concrètement, mais le SSO m'a l'air d'être un concept assez fumeux... De ce que j'en édite (merci Scite), la plupart des applications libres qui s'appuient sur LAMP intègrent leur propre authentification à l'intérieur de la Base. Pour accepter le SSO, il faudra donc forcément les modifier... Du moment que les navigateurs intègrent des gestionnaires de mots de passe, le "concept SSO" me paraît déjà être intégré à leur niveau. Pourquoi le délocaliser dans les applications ? Des couples user/password différents par application permettent de limiter la casse en cas de compromission. Je fais davantage confiance aux identités multiples qu'à l'identité unique et tiens à rester le seul qui garde la maîtrise du puzzle final.

    • [^] # Re: SSO ? Pas convaincu...

      Posté par  . Évalué à 2.

      Il faut vraiment avoir une très faible connaissance de la sécurité pour débiner des conneries pareilles (ou être militaire ?). Plus les utilisateurs ont de comptes et plus on trouve de Post-It ou mots de passe triviaux !

      • [^] # Re: SSO ? Pas convaincu...

        Posté par  . Évalué à 1.

        Pas forcément. Avec un bon générateur et un .bon gestionnaire de mots de passe toujours sous la main le problème est différent. Surtout si on prend le temps de sensibiliser et de responsabiliser les utilisateurs vis à vis de la sécurité.

        Je n'adhère pas plus à l'esprit du SSO qu'au "passport" de Microsoft : initiatives techniquement louables, mais intrinsèquement liberticides.

        Une identité on peut la subir ou l'assumer. Ceci devrait répondre à ta question, qui n'en était pas une. Ce qui ne fait pas nécessairement de moi un adepte du STO (Single Think On).

        • [^] # Re: SSO ? Pas convaincu...

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

          Il ne faudrait pas non plus tout mettre dans un même sac.
          Aucune technologie n'est liberticide ni dangereuse en soit. Ce qui importe davantage, c'est l'usage qui en est fait.
          Or, pour la plupart des entreprises, mettre en place des solutions centralisés se heurtent davantage aux "petits chefs" et à leurs rétentions d'informations qu'à des problèmes vraiment technique.
          Dès qu'une nouvelle technologie apparaît à l'horizon, les dinosaures font tout pour freiner sa mise en application, au lieu de chercher à s'adapter.
          Pour finir donc, les mises en place de SSO (et WSSO) concerne surtout des entreprises avec leurs employés et il n'est pas du tout impertinent de vouloir conserver une seule et même identité pour chaque employé.
          En outre, ce genre de mises en place (Passport compris, dans une autre approche) n'est imposée (et encore, il y a normalement des discussions avec les représentants du personnel) qu'aux membres de l'entrprise en question : on est bien loin de Big Brother.

    • [^] # Re: SSO ? Pas convaincu...

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

      Dans le même genre que le navigateur pour gérer les identités sans modifier les applications il y a aussi le reverse proxy SSO VultureNG : http://vulture.open-source.fr.

Suivre le flux des commentaires

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