Sortie d'Authentic 0.5

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
10
déc.
2005
Sécurité
Authentic, sous licence GNU GPL, est un fournisseur d'identité Liberty Alliance. Il permet de créer un cercle de confiance au sein duquel les échanges sont facilités et sécurisés. Il fournit le Single Sign-On (SSO), le Single Logout (SLO), l'échange d'attribut et il se paramètre aisément.

Ses principales fonctionnalités :
  • Support des protocoles ID-FF 1.2, ID-WSF et SAML 2.0
  • Support de bases d'utilisateurs variées : LDAP V3, Postgresql, MySQL
  • Proxy : Authentic peut se comporter comme un proxy, redirigeant les requêtes des fournisseurs de services vers d'autres fournisseurs d'identités.
  • Partage d'attributs : il permet le partage d'attributs d'identité en utilisant ID-WSF.

Sa compatibilité Liberty Alliance repose sur Lasso, bibliothèque certifiée par le consortium en mai 2005. Authentic implémente toutes les fonctionnalités requises par la matrice de compatibilité de Liberty Alliance.

Aller plus loin

  • # Liberty ?

    Posté par  . Évalué à -7.

    En fait de Liberty alliance il s'agit surtout d'un enième lobby des plus gros et puissants industriels de la planète ...

    Cette identification permanente, ça doit servir à protéger nos voitures des enfants incendiaires de polygames, un truc dans le genre, non ?

    Ou au contraire, en faisant un petit coquetel de DADVSI, de maitrise totale de la fin du tube (ordinateur personnel) et de matériel conçu et produit par les industriels ... Il pourrait etre possible de fermer la parenthèse ...

    Licence GPL, oui mais en fait de liberté, on s'en éloigne plutot ...

    Je préfère les projets comme freenet (http://freenet.sourceforge.net/) !
    • [^] # Re: Liberty ?

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

      Je fais partie de la boite qui développe Authentic et Lasso, je suis donc pas vraiment objectif. Mais il faut que tu comprennes comment on est venu sur Liberty. Notre boite était spécialisée en "transparence et démocratie", rien que ça, on faisait en particulier des solutions de vote en ligne. Et pour faire des solutions de vote on nous a demandé des systèmes d'authentification forte, donc pour nous c'était, attention danger, c'est potentiellement liberticide.

      Les seuls standards ouverts qu'on a trouvé et qui sont capables de donner un minimum de garanti en matière de respect de la vie privée sont ceux de Liberty Alliance.

      C'est d'ailleurs la position de l'UE qui a heureusement rejeté Passeport et dit que LA était utilisable.

      Après c'est un groupement d'indusriel qui rassemble à peu près tout le monde sauf Microsoft (ça pourrait changer), pas très excitant c'est clair, mais les standards sont ouverts. Si il y avait le moindre rapport avec les DADVSI ou un flicage quelconque, on serait parti en courant. Je t'invite à lire la FAQ de notre site, tu comprendras mieux notre position.
      • [^] # Re: Liberty ?

        Posté par  . Évalué à -9.

        et vous vous positionnez comment face à des projets comme freenet ? Qui basiquement reprennent la même idée.
        • [^] # Re: Liberty ?

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

          Je comprends pas le rapport entre freenet (réseau sur un réseau où toute action est anonyme) et un service de SSO qui permet de partager le même service d'authentification entre plusieurs applis.

          Les deux fournissent des services intéressants mais qui n'ont rien à voir.
      • [^] # Re: Liberty ?

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

        Bonjour,

        je profite de ta présence sur cette page pour te poser des questions qui sont susceptibles d'intéresser du monde ici.

        Supposons que je développe un applicatif web (en zope, php, ...). Que dois-je faire pour qu'elle puisse utiliser authentic ? En particulier :

        - je suppose que je dois rediriger la page de login vers le serveur authentic et ensuite modifier mon code d'authentification pour récupérer un certains token (header HTTP, cookie ?) de la part du client pour le reconnaitre. Dois-je utiliser un bindings vers la lib lasso (au hasard python-lasso) pour décoder ce token et verifier qu'il est valide au près d'authentic ?

        - supposons maintenant que mon appli ait un composant webmail qui attaque un serveur IMAP (+ SMTP) :
        - existe-t-il des serveurs IMAP (et SMTP) qui savent interoperer avec authentic pour reconnaitre leurs utilisateurs ?
        - que dois-je faire pour que mon webmail transfere le token d'authentification à son backend IMAP/SMTP pour que mes utilisateurs n'aient pas besoin de resaisir un login/mot de passe ?

        - enfin : quelles sont les applis libres fares qui supportent nativement une authentification des utilisateurs via authentic ?


        --
        Bon finalement, j'ai trouvé la page http://authentic.labs.libre-entreprise.org/doc/fr/authentic-(...)
        qui repond en parti à ces questions. Mais je suppose que c'est cas d'utilisations interesseront d'autres devs qui frequente ce site donc je poste quand meme ce commentaire :)
        • [^] # Re: Liberty ?

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

          C'est (toujours) très simple. Authentic est un fournisseur d'identités compatible Liberty Alliance; ça signifie qu'il s'interfacera avec d'autres applications compatibles Liberty (appelées dans le jargon "fournisseurs de service").

          Évidemment ça se corse quand on se rend compte que les applics libres avec du support Liberty, il n'y en a pas. Pour ajouter ce support, il y a des options propriétaires (et systématiquement (d'après ce que j'ai vu) en Java) ou lasso, dans le binding approprié (Python pour Zope, PHP pour PHP, c'est ridicule de l'écrire).

          Ajouter ce support, de manière un peu crade, ça a déjà été fait avec quelques applics libres (je me souviens de dotclear, spip, egroupware, squirrelmail) mais rien qui ne fut contribué en retour vu le caractère crade et envahissant de la modif. Ce n'est pas compliqué, la doc manque mais la liste lasso-devel@ fonctionne.

          Ensuite, sur l'interaction avec des serveurs IMAP, SMTP et autres, la réponse est non, les normes Liberty ne parlent de SSO que dans un contexte d'applications web (ce qui peut être imaginé c'est que l'authentification liberty se fasse sur du kerberos et que les applics non web utilisent kerberos).

          Voili voilà, j'espère que ça éclaire un peu.
        • [^] # Re: Liberty ?

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

          Le nom du projet me parait tres risque. Ma boite precedente, Oberthur Card Systems a developpe des produits sur carte a puce avec des noms en ic : authentic (authentification, comparaison d'empreinte digitales), SIMphonic (cartes GSM), etc.

          Je doute qu'ils aient oublie de reserver la marque. Et il y a clairement un conflit puisque les deux produits servent a la meme chose, l'authentification.

          Ca fait des annees que Oberthur developpe la solution d'authentification a base de authentic, donc je pense que ta boite n'a pas bien fait son travail de recherche de nom de produit.
          • [^] # Re: Liberty ?

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

            Le "travail de recherche de nom de produit" est plutôt spécifique chez nous :), je te passe les détails. Merci de nous alerter sur le produit Oberthur qu'on ne connaissait pas.

            Mais honnêtement, on s'en fout un peu. Si Oberthur souhaite nous embêter ils auront certainement la possibilité de le faire (on ne dépose jamais de nom ou de marque) mais je vois mal ce qu'ils y gagneraient : notre solution n'a rien à voir avec les cartes, nous ne visons pas du tout le même public.
            • [^] # Re: Liberty ?

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

              notre solution n'a rien à voir avec les cartes, nous ne visons pas du tout le même public.
              Mobilix ne visait pas non plus les lecteurs des BDs de nos chers amis les gaulois, et ne faisait pas exactement la même chose que les éditions d'Albert et de René.

              Mais un procès au tribunal les a fait changer d'avis. (et de nom par conqéquence)
              Alors gardons à l'esprit que tout le monde n'a pas cette ouverture (d'esprit) et qu'il faut faire attention avec ces choses là.

              (Au hasard, rapelons l'histoire du nom de mozilla firefox, qui passa ar foenyx et firebird)
              • [^] # Re: Liberty ?

                Posté par  . Évalué à 3.

                Pour info, un autre tribunal a donné raison à Orange qui avait été attaqué toujours par Messieurs Albert et René, car Monsieur (ou Madame) Orange avait utilisé (ou tenté d'utiliser) le nom Mobilix pour un produit de téléphonie mobile.

                Conclusion: en cas de problème avec Messieurs Albert et René, faites-vous racheter par Orange ;-)
                • [^] # Re: Liberty ?

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

                  Rien à voir, mais M. rené n'a rien à voir la-dedans (il est mort, malheuresement, en 1977).
                  Je me demande même si Albert, coupable de commetre de mauvaise BD sur de si bonne base, est coupable ou victime de son entourage.
    • [^] # Re: Liberty ?

      Posté par  . Évalué à 4.

      En fait de Liberty alliance il s'agit surtout d'un enième lobby des plus gros et puissants industriels de la planète ...
      Donc d'après ton raisonnement, dès qu'un grand du monde industriel et/ou informatique se lance dans un projet, il est forcément un lobbyiste méchant et malfaisant ?

      Cette identification permanente, ça doit servir à protéger nos voitures des enfants incendiaires de polygames, un truc dans le genre, non ?
      D'après ce que j'ai compris de Liberty Alliance, il s'agit d'un consortium qui a pour but de spécifier un framework pour l'utilisation de SAML 2.0. Ainsi, avec le framework, il devrait alors être possible d'utiliser une authentification unique pour se connecter sur des services de divers horizons. Le SSO te permet actuellement d'avoir une authentification unique pour te connecter sur des services du même environnement (ton université, ton entreprise...). SAML 2.0 peut te permettre d'accéder à un service d'une autre entité que la tienne en t'authentifiant sur ton système d'authentification, et cela grâce à des relations de confiance établies entre le service que tu cherches à joindre et ton système d'authentification.

      Ou au contraire, en faisant un petit coquetel de DADVSI, de maitrise totale de la fin du tube (ordinateur personnel) et de matériel conçu et produit par les industriels ... Il pourrait etre possible de fermer la parenthèse ...
      mouais, je vois pas le rapport...

      Licence GPL, oui mais en fait de liberté, on s'en éloigne plutot ...
      mouais, je ne sais pas comment tu arrives à sortir une telle réflexion. Je te rappele que Liberty Alliance est un consortium qui se charge de définir un framework pour l'utilisation de SAML2.0. Il n'y a rien d'opaque là dessous.

      Je préfère les projets comme freenet (http://freenet.sourceforge.net/) !
      je ne vois toujours pas le rapport... désolé. C'est un peu comme si tu me disais : les SSO c'est pas bien, c'est un truc de lobbyiste. Moi je préfère freenet !
  • # Fédération d'identité

    Posté par  . Évalué à 10.

    Lors des JRES 2005 qui viennent de se terminer, il y a eu un tutoriel sur les fédérations d'identité. Ils ont alors parlé de Liberty Alliance et de Shibboleth. Pour ceux qui ont participé aux JRES ou ceux qui connaissent quelqu'un qui y a participé, vous trouverez les explications dans le document des tutoriels.

    En gros, pour ceux qui ne connaissent pas, une fédération d'identité est un ensemble de systèmes permettant l'authentification des utilisateur selon leurs propres systèmes d'authentification. Par exemple, supposons deux universités A et B qui ont chacune un système d'authentification et des services web. Si un utilisateur de l'université A veut se connecter sur un service web de B, alors il doit avoir un compte dans le système d'authentification de B. Avec Shibboleth (et si j'ai bien compris Liberty Alliance), il sera authentifié sur son système d'authentification A d'origine.
    Les fédérations d'identités permettent d'établir des relations de confiance entre plusieurs entités. Par exemple, l'université B peut autoriser les étudiants de mathématiques de l'université A à accéder aux cours en ligne de mathématiques mis en place sur un service web de B. La seule information qui circule entre A et B et que l'utilisateur est authentifié, et qu'il fait partie du groupe des utilisateurs de mathématiques.
    Le système repose sur SAML2 qui permet l'échange des informations entre les différents systèmes.

    Le tutoriel Jres (n°3) : http://www.jres.org/public/ViewObj.asp?id=54

    Pour info (tiré des tutoriels papiers) :

    SAML (Security Assertion Markup Language) a été initialement conçu pour permettre entre autres la délégation d'authentification. C'est devenu un standard OASIS en 2002. Il s'agit d'un ensemble de spécifications qui définissent comment des services peuvent s'échanger des assertions de sécurité (authentification, autorisation, attributs), indépendamment des technologies utilisées par chacun de ces services.

    Liberty Alliance est un consortium d'entreprises fondé en 2001 qui a produit plusieurs spécifications sur la gestion d'identités. ID-FF (Identity Federation Framework) enrichit SAML pour permettre la fédération des comptes, la délégation d'authentification, la propagation de fin de session. ID-WSF (Identity-based Web Services Framework) offre la propagation d'attributs utilisateur, la recherche de service d'identités, etc... De nombreux produits propriétaires et plusieurs solutions open source implémentent tout ou partie des spécifications Liberty Alliance.

    Note : Il met semble avoir compris que l'ADAE a choisi Liberty Alliance pour la fédération d'identité des sites gouvernementaux. (?)
    • [^] # Re: Fédération d'identité

      Posté par  . Évalué à 4.

      Pour ta note : Oui c'est exactement ça .. :)
    • [^] # Re: Fédération d'identité

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

      Tu as tout compris, Shibboleth et Liberty ont participé conjointement à l'élaboration de SAML 2.0 et sont maintenant très proches.

      L'ADAÉ (C'est l'Agence pour le Développement de l'Administration Électronique, le bras armé de l'État en matière d'e-administration) pousse effectivement Liberty Alliance au travers de son projet mon.service-public.fr. Cela parce qu'il n'y a pas d'identifiant unique qui circule dans un système Liberty, ce que la CNIL apprécie particulièrement (et nous aussi).

      Juste sur les "plusieurs solutions open source" dans l'article que tu rapportes, j'en connais qu'une en GPL :) et une autre plus ou moins libre selon les saisons (ils ont une licence maison que je vous laisse le soin de découvrir), SourceID.

      Mais récemment j'ai vu quelqu'un de très bien chez Sun qui m'a annoncé une solution Sun en GPL pour bientôt (plutôt pour servir de test/exemple, pas un produit finalisé)
      • [^] # Ca parle à qui cette histoire de LibertyAlliance ?

        Posté par  . Évalué à 4.

        OK, ça semble hyper important de ne pas mélanger tous les identifiants des français dans une grosse base mais, entre nous, la dépêche n'est pas très grand public... En plus, au vu des commentaires, tout ceci est un peu "consanguin", non (si je comprends bien les seuls qui connaissent sont ceux de la boite qui développe Authentic) ?

        En pratique :
        - quelle position "officielle" a l'ADAE là-dessus ? Ca m'intéresse parce qu'en général ils sont plutôt pertinents.
        - y-a-t-il de bons tutoriaux en français ? Notamment la présentation du CRU aux JRES ? Ou un doc de l'ADAE ? Ou un doc d'Entr'ouvert ?

        Et enfin :
        Pourquoi de telles solutions ne sont pas "financées", voire largement poussées par l'Etat français ou la Commission Européeene s'il s'avère que ce sont les seules capables de simplifier la vie des gens en évitant le flicage ? A quand des subventions sur les logiciels libres jugés fondamentaux par l'Etat (ou un crédit d'impot comme pour les éditeurs de jeux vidéo) ?

        • [^] # Re: Ca parle à qui cette histoire de LibertyAlliance ?

          Posté par  . Évalué à 4.

          La problématique initiale à laquelle les fédérations d'identités tentent de répondre est la multitude des bases d'authentification qui existent et la multitude de services web associés. Pour accéder à tel serveur web, il faut être connu dans tel base d'authentification, pour accéder à un autre service web, il faut être connu dans une autre base. L'administration des comptes utilisateurs est alors impossible car il faudrait que chaque utilisateur ait un compte dans toutes les bases d'authentification.

          Le CRU (Comité Réseaux des Universités) a étudié les fédérations d'identités pour répondre à cette problèmatique et ainsi permettre aux étudiants/enseignants/personnels d'accéder à des services d'autres universités sans avoir à avoir de compte dans cette université. On peut par exemple penser aux réseaux WIFI, et ainsi imaginer que n'importe quel étudiant peut se connecter au WIFI dans n'importe quelle université. Ca serait beau !

          La dépêche n'est pas grand public car elle touche un domaine assez spécifique de l'administration des systèmes. Ceux qui connaissent sont ceux qui sont face à la problématique. Il n'y a rien de consanguin. Authentic n'est pas le seul produit qui réponde aux besoins. Il existe également shibboleth utilisé par le CRU ( http://federation.cru.fr/ )

          Etant donné que l'ADAE et le CRU utilisent la solution et y participent (?), on peut considérer que l'Etat y participe et le finance (par du temps de travail). Y'a pas de chèque, mais le travail fourni par les personnes est aussi précieux.
  • # De la théorie à la pratique

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

    Les commentaires montrent que le sujet "fédération d'identité" demande à être démystifié.
    La méconnaissance du sujet conduit visiblement à des amalgames ...

    La question de Champi me semble importante et la réponse un peu laconique pour une personne soucieuse de passer de la théorie à la pratique.
    Shibboleth précise clairement qu'il ne fournit pas de mécanisme SSO mais qu'il s'appuie sur CAS par exemple. Ainsi lors de la mise en oeuvre les applications sont d'abord "casifiées" pour le SSO local et Shibboleth intervient alors pour fédérer des SSO locaux.

    Quand est-il pour liberty alliance ? N'est-il pas un peu cavalier de prétendre fournir un service SSO si celui ne pourrait-être utilisé qu'avec des applications compatible liberty.
    Comment rendre les applications existantes compatibles liberty ?
    Que faire avec mon parc d'applis en PHP, Perl, Python, JAVA , ... ?
    Quelle est l'équivalent de la "casification" ?
    Comment une application casifiée s'intégre elle dans liberty alliance ?

    Avec SAML 2.0 plus personne ne doute de l'interopérabilité prochaine de liberty alliance et de Shibboleth mais comment développer aujourd'hui une application capable de s'intégrer avec l'une ou l'autre de ces technologies et comment migrer les applications existantes ?

    Les réponses a ses questions permettront sans doute de démystifier (un peu) la fédération d'identité ...
    • [^] # Re: De la théorie à la pratique

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

      Il y a différentes manières de procéder à l'intégration d'un support Liberty à une application existante, des simples et des compliquées, des appropriées à une application qui ne le sont pas à d'autres, etc.

      Il y a eu une petite doc écrite sur la création d'un fournisseur de service Liberty avec Lasso, en PHP (http://lasso.entrouvert.org/documentation/writing-a-php-sp.h(...) ).

      Une autre manière déjà testée, ça a été de passer par un module Apache,

      - le patch pour DotClear: http://www.0d.be/files/dotclear.scalpkit.diff.gz ,
      - le patch pour eGroupware http://www.0d.be/files/egroupware.scalpkit.diff.gz
      - le patch pour Roundup http://www.0d.be/files/roundup.scalpkit.diff.gz


      Le module apache en question, c'était 169 lignes de Python (module réalisé via mod_python), je n'en trouve pas une URL pour le moment, si ça t'intéresse je peux chercher.
      • [^] # Re: De la théorie à la pratique

        Posté par  . Évalué à 1.

        L'existence d'un module Apache ou d'un Reverse proxy pourrait effectivement aider. Car si on n'a rien en natif dans les serveurs d'applis ou dispositifs de portail par exemple, intégrer des systèmes variés sur un seul SSO Liberty Alliance ne doit pas être trivial.
        Si je comprends bien l'intérêt est d'avoir un maximum d'applications compatibles Liberty Alliance pour disposer d'un grand SSO global à ces applis. Simplement il faut minimiser le boulot pour les développeurs d'applications afin que celles-ci soient rendues compatibles avec Liberty Alliance.

        Soit on délègue la gestion de ses comptes à un module externe qu'on "libertifie" (par ex. un module Apache ou un reverse proxy), soit on se code à la mimine les appels aux quelques API de haut niveau fournies par exemple par LASSO. C'est bien çà ?

        Autre question que ça soulève (je bosse sur une application dont j'aimerais étudier la compatibilité avec un système Liberty Alliance, tout ceci m'a donné des idées !), quel est le rapport avec LemonLDAP dont on a déjà parlé ici ? Et existe-t-il un module Liberty Alliance pour LemonLDAP ? Je sais, c'est intéressé, mais moi je trouverais ça cool pour simplifier le portage d'applications existantes.

        Enfin, j'avais déjà regardé Liberty Alliance il y a un ou deux ans et je comprends de moins en moins le rapport avec SAML 2.0 ? Est-ce que Liberty Alliance (ID FF) est totalement compatible avec SAML ?
        En pratique vaut-il mieux faire du Liberty Alliance ou du SAML ?
        Ou alors SAML est un sous-ensemble de Liberty Alliance, (ou bien c'est le contraire, je suis dans le noir !) ?
        • [^] # Re: De la théorie à la pratique

          Posté par  . Évalué à 2.

          D'après ce que j'ai compris, il y a SAML. Mais bon, comme ce n'est qu'une spécification, ça nous fait une belle jambe d'avoir un fichier texte des spécs. Alors y'a des gens qui se sont réunis qui ont formés un consortium (Liberty Alliance) pour utiliser SAML pour faire des fédérations d'identité. Z'ont bossé un peu, fait un framework et ont développé Lasso.
          • [^] # Re: De la théorie à la pratique

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

            En fait, il y a SAML 1, normalisé par l'OASIS, ça ne définit pas suffisamment de choses, d'un côté Liberty Alliance, de l'autre Shibboleth procèdent à des extensions correspondant à leurs besoins propres.

            Plus tard arrive SAML 2, toujours normalisé par l'OASIS, qui se veut récupérer dans son giron les deux "divergences" en ajoutant ce qui manquait (il n'y avait heureusement pas d'incompatibilité de principe entre les deux).

            C'est à peu près là qu'on est; les specs Liberty sur le SSO seront maintenant plus sur la manière d'appliquer les specs SAML 2 à la réalité des membres de Liberty que sur une nouvelle extension (et probablement pareil pour Shibboleth)

            À côté de ça, Liberty a aussi défini d'autres protocoles qui ne sont pas (encore?) repris dans le giron de SAML2 (cf les specs ID-WSF).

            Sur ces specs, il y a eu des implémentations propriétaires, une implémentation "open source" (SourceID, www.sourceid.org ) et une implémentation "libre" (Lasso, lasso.entrouvert.org (qu'utilise Authentic)). Ces projets sont indépendants des différents consortiums et n'ont pas du tout été financés par eux.
  • # Communautarisme(s)

    Posté par  . Évalué à -1.

    Il est beaucoup question de sécurité et de droit dans les commentaires mais le phénomène de "communautarisation" croissante dans nos sociétés latines - influencées par la tradition anglo-saxonne - n'est pas abordé.
    Un outil tel qu'Authentic (et les autres) peut permettre à une entreprise garantir le secret professionnel, à un individu de s'assurer que ses libertés individuelles ne seront pas baffouées, mais c'est également un formidable moyen de créer de manière efficace une communauté d'intérêt communautaire, contre l'intérêt collectif.
    Bien entendu, il n'est pas question d'interdire un outil tel qu'Authentic mais je souhaiterais que ce débat soit aussi ouvert que les formats qu'Authentic utilise.

Suivre le flux des commentaires

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