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
- Site du projet (12 clics)
- Site de Lasso (3 clics)
- Démonstration en ligne (7 clics)
- Documentation administration (voir vue générale) (5 clics)
# Liberty ?
Posté par Nurachi . Évalué à -7.
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 Cros Pierre (site web personnel) . Évalué à 10.
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 jijin . Évalué à -9.
[^] # Re: Liberty ?
Posté par Olivier Grisel (site web personnel) . Évalué à 10.
Les deux fournissent des services intéressants mais qui n'ont rien à voir.
[^] # Re: Liberty ?
Posté par Olivier Grisel (site web personnel) . Évalué à 3.
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 Frédéric Péters (site web personnel) . Évalué à 6.
É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 Philippe F (site web personnel) . Évalué à 6.
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 Cros Pierre (site web personnel) . Évalué à 1.
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 chtitux (site web personnel) . Évalué à 2.
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 Matthieu . Évalué à 3.
Conclusion: en cas de problème avec Messieurs Albert et René, faites-vous racheter par Orange ;-)
[^] # Re: Liberty ?
Posté par Rin Jin (site web personnel) . Évalué à 3.
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 Matthieu . Évalué à 4.
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 Matthieu . Évalué à 10.
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 Julien Wajsberg . Évalué à 4.
[^] # Re: Fédération d'identité
Posté par Cros Pierre (site web personnel) . Évalué à 4.
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 Hawaii Five-O . Évalué à 4.
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 Matthieu . Évalué à 4.
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 newca (site web personnel) . Évalué à 3.
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 Frédéric Péters (site web personnel) . Évalué à 2.
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 Hawaii Five-O . Évalué à 1.
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 Matthieu . Évalué à 2.
[^] # Re: De la théorie à la pratique
Posté par Frédéric Péters (site web personnel) . Évalué à 1.
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 Franck Hanot . Évalué à -1.
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.