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.
![[en]](../images/en.png)
Site du projet (570 hits)-
Site de Lasso (202 hits)
![[fr]](../images/fr.png)
Démonstration en ligne (807 hits)-
Documentation administration (voir vue générale) (303 hits)
> Lire la dépêche (23 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #658554.
Run by 
Cette page a été générée par Templeet en 0.0488s (dont 0.0046 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Fédération d'identité
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é
Pour ta note : Oui c'est exactement ça .. :)
[^]Re: Fédération d'identité
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 ?
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 ?
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.