Actualités

[08/12/2014] Lancement du « Symfony Expertise Center » by SensioLabs and Smile

SensioLabs, éditeur du framework open source Symfony et Smile annoncent un partenariat exclusif et créent le « Symfony Expertise Center » pour répondre aux demandes d'expertise sur Symfony.

[04/12/2014] Smile Maroc participe aux Assises de l'AUSIM, le rendez-vous des DSI au Maroc

Smile Maroc est partenaire de l’événement « Les Assises de l'AUSIM », sous le thème de la "Transformation digitale" à Marrakech du 03 au 05 décembre 2014.

[24/11/2014] De nouveaux locaux pour Smile Lille, Lyon et Marseille !

Trois agences de Smile ont déménagé ces deux dernières semaines. De nouveaux locaux plus spacieux ont été investit pour accompagner la croissance et le développement de ces agences Lilloise, Lyonnaise et Marseillaise.

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

Identité numérique, authentification unique et fédération des identités sur Internet, où en est-on et où va-t-on?

Identité numérique, authentification unique et fédération des identités sont des problèmatiques importantes du web2.0. Aujourd'hui certaines normes et technologies comme OpenID, OAuth, OpenSocial y répondent déjà ou promettent d'y répondre. Qu'en est il exactement?

 

Avec le boom du web2.0, les sites où on peut interagir moyennant une authentification se multiplient. Pour l'utilisateur, un inconvénient majeur est qu'il doit alors gérer une multitude de comptes et de mots passe, c'est la problématique de l'authentification unique.
En corollaire, pour la jeune startup qui ambitionne d'être le Facebook de demain, la rébarbative phase de création d'un compte fait fuir la moitié de nouveaux utilisateurs potentiels. En effet, pour éviter la création de faux comptes par des robots, on doit en passer par la réponse à un e-mail et également par la validation d'un captcha.
Si d'autre part, j'ai déjà créé un profil sur ma plateforme de blog, quel dommage que je doive aussi re-créer un pofil sur Facebook; il s'agit cette fois d'une problématique de fédération des identités.
Enfin, impossible aujoud'hui par exemple de partager des bookmarks Del.icio.us avec des contacts directement issus du carnet d'adresse d'un réseau social d'amis ou de contacts professionnels; cette dernière problématique est celle de l' échange d'attributs d'identité entre applications web.

Par ailleurs, les portails d'entreprise sont-ils eux aussi confrontés à ces problématiques et ont-ils à y répondre de la même façon? Certes l'intérêt est moindre car on peut forcer les employés d'une société à utiliser des mots de passes différents pour utiliser des logiciels obligatoires. Néanmoins on voit dans les entreprise une pression croissante pour plus d'ergonomie et de sécurité vers une authentification unique dont le fer de lance ouvert actuel est CAS.
Oui mais dans ce cas, est-il encore judicieux de mettre en place l'infrastructure d'un serveur CAS qui ne saura pas faire le lien entre votre identité sur GMail par exemple et votre webmail d'entreprise? Se cantonner à CAS, c'est aussi se couper un peu d'une intégration avec la sur-enchère de services en ligne au rabais voire gratuits (business model de la pub) qui se battent pour attirer de nouveau clients.
Le manque d'interopérabilité actuel de l'identité numérique, de fédération d'identité ou de protocole d'échanges d'attributs sont des facteurs de protectionnisme et un frein à la fois à la mise en concurrence et à la creation de synergies des services en ligne qui pourraient pourtant aboutir à une meilleur offre tant au niveau des loisirs que de l'entreprise. Faisons alors un tour d'horizon des solutions existantes et de celles qui se profilent.

l'émergence de standards d'authentification unique (SSO) sur le web: OpenID

 

Pour ce qui est d'utiliser des comptes et mots de passes spécifiques à chaque site, une solution standard existe déjà, il s'agit d'OpenID. En effet, cette norme énumère un certain nombre de règles que doit respecter tout serveur tierce jouant le rôle de serveur d'authentification unique et que peuvent alors consulter autant de sites web qui le souhaitent. Ainsi un site web - soit FaceBookKiller.com - peut externaliser la phase d'authentification, c'est à dire laisser un serveur OpenID valider ou l'invalider l'existence d'un compte pour le couple login/mot de passe saisi par l'utilisateur; c'est le principe du 'tiers de confiance'.
Ainsi, lorsque l'utilisateur doit s'authentifier sur notre site FaceBookKiller.com, on lui demande simplement son login OpenID (il s'agit en fait d'une URL ou d'un bout d'URL). Grâce à lui, on retrouve le fameux serveur OpenID qui va gérer la phase d'authentification. On redirige donc l'utilisateur dessus. De là, plusieurs scénario sont possibles:

  1. Si l'utilisateur est encore loggué sur ce serveur OpenID, alors:
    1. Si l'utilisateur a déjà dit qu'il autorisait spécifiquement FaceBookKiller.com à consulter notre profil OpenID et dans ces cas l'utilisateur est renvoyé sur notre site comme étant authentifié sans même qu'il s'aperçoive de cet l'allé-retour presque instantané.
    2. Si l'utilisateur s'était déjà loggué sur OpenID par exemple le matin pour consulter ses mails en lignes, mais n'a jamais visité FaceBookKiller.com auparavant. Dans ce cas, on lui demande expressément s'il autorise FaceBookKiller.com à consulter ensuite son profil OpenID. En cas d'accord, l'utilisateur est bien renvoyé loggué sur notre site FaceBookKiller.com.
  2. Si l'utilisateur n'a pas de compte OpenID, on l'enjoint alors à en créer un sur une page personnalisée du serveur OpenID qui explique bien que c'est pour utiliser FaceBookKiller.com. Bien évidemment, dans ce cas de la toute première utilisation d'OpenID, l'utilisateur doit bien valider un captcha et répondre à un mail pour valider son compte.
  3. Si l'utilisateur a bien un compte OpenID mais qu'il n'est plus loggué, alors on lui demande de saisir son mot de passe. L'utilisateur le fera volontiers car il reconnaît alors son portail OpenID d'authentification unique. Lorsque le mot de passe est saisi et validé par le serveur OpenID, l'utilisateur est redirigé sur notre site FaceBookKiller.com. Plus précisément, l'utilisateur est redirigé sur l'URL que nous avions spécifié avec, en plus, en paramètre d'URL, un jeton qui certifie qu'il y a bien eu authentification par OpenID et qui est valide le temps d'une session. Dans ce cas, on sait que l'utilisateur est loggué et on interroge alors à nouveau le serveur OpenID en utilisant le jeton fourni pour connaître le login de cet utilisateur. A nouveau, plusieurs scénarios sont possibles:
    1. Ou notre utilisateur existe bien dans notre référentiel d'utilisateur propre à notre site. Dans ce cas, pas de problème, on laisse l'utilisateur continuer. Généralement, on lui ajoute aussi un cookie qui permettra de se rappeler que l'utilisateur est loggué sur notre site. Et si ce cookie est à vie longue, si l'utilisateur revient dans quelques jours sans avoir fait de logout explicite, alors il sera aussi reconnu directement sans même appeler de serveur OpenID.
    2. Dans où l'utilisateur est inconnu au bataillon, on souhaite généralement créer un compte dans notre réféntiel local pour rattacher d'autres informations à cet utilisateur.
      1. Généralement, on créer donc un compte à la volée et on laisse l'utilisateur continuer à naviguer sur notre site.
      2. Mais parfois hélas, on a besoin de plus d'informations, par exemple l'email de l'utilisateur. On tente alors dans un premier temps d'interroger le serveur OpenID pour voir s'il n'a pas des informations complémentaire à nous fournir, c'est le protocole "simple registration" qui étend OpenID et que peut supporter ou non une serveur OpenID. Dans le cas où celui-ci est incapable de transmettre cette information, alors on doit bien demander à l'utilisateur de saisir ces informations complémentaires pour compléter son profil sur notre site.

 

Ces explications détaillées peuvent laisser croire à un système complexe. Il n'en est rien. Mettons les choses au plus simple: si l'utilisateur s'est connecté récemment à votre site et que vous lui aviez laissé un cookie, alors il est reconnu immédiatement. Sil l'utilisateur s'est déjà connecté à OpenID récemment pour utiliser un autre site, il n'aura qu'à cliquer dans une seule case pour autorisé l'authentification de FaceBookKiller.com par OpenID, même s'il n'est jamais venu sur votre site. Comparez ceci avec le long processus de création d'un compte avec captcha et envoi d'email et vous comprenez pourquoi OpenID est une révolution d'ergonomie.

Outre le bénéfice évident pour l'utilisateur, les développeur de tout FaceBookKiller.com connaissent aussi des avantages considérables:

  • Ils n'ont pas à gérer d'envoi d'email de création de compte dans toute les langues imaginables.
  • Ils n'ont pas à gérer de captcha eux-mêmes (ou pire subir les assauts incessant des spammers s'il ne le font pas)
  • OpenID mutualise la lutte contre les faux comptes de spam
  • certains serveur OpenID gèrent eux-mêmes l'authentification via HTTPS avec un certificat signé. Là encore gain important quand on connaît le prix d'un certificat SSL.
  • selon la technologie adopté, l'intégration d'OpenID peut être triviale, en utilisant ce plugin Rails, j'ai moi même intégré OpenID à un site en 2 heures chrono avec en prime fusion avec un référentiel d'utilisateurs existant.

Tout ça ne ressemblerait pas à CAS?

Vous avez vu juste: le principe du serveur tierce à qui on délègue l'authentification ressemble énormément à CAS. Les différences sont:
Inconvénients:

  • OpenID ne sait pas se connecter un un annuaire existant comme Ldap ou autre comme sait le faire CAS. OpenID sait juste éventuellement géré un profil basique (simple registration). Dans le cas ou ça ne suffit pas, chaque application doit ensuite consulter son propre référentiel d'utilisateurs qu'elle synchronise éventuellement en utilisant OpenID. Remarque, de toute façon, en général, les applications qui l'authentifient avec CAS ont néanmoins elles aussi besoin de se connecter directement à ces référentiels. L'avantage de CAS ici est donc faible.
  • Il n'existe pas de bonne implémentation stable et open source de serveur OpenID. Vous pouvez monter votre propre serveur OpenID mais alors vous devez encore le faire seul. Heureusement, il existe une myriade de serveurs OpenID qui fournissent le service d'authentification gratuitement et de façon fiable, par exemple MyOpenID.

Avantages:

  • OpenID permet en partie une fédération des identités en un seul et même référentiel (URL unique par utilisateur). CAS lui suppose une unicité du référentiel d'utilisateurs à son échelle, mais ne donne aucun moyen d'y parvenir. Généralement, CAS n'intéragit qu'avec un référentiel localement unique, un annuaire Ldap par exemple.
  • OpenID permet à une multitude de serveurs de jouer le rôle de serveur d'authentification. C'est donc un système plus ouvert qui répond en même temps aux problématiques de montée en charge par sa décentralisation.
  • OpenID est accessible de n'importe où par n'importe qui.
  • OpenID peut dans une certaine mesure servir en partie de référentiel unique d'utilisateurs grâce à son extension "simple registration".
  • la plupart des serveurs OpenID sont déjà internationalisés.
  • certains serveurs OpenID comme MyOpenID peuvent déjà gérer eux-même la création de compte utilisateur (envois d'email, captcha) de façon personnalisable en fonction du site cible.
  • pas d'infrastructure CAS à gérer des serveurs OpenID gratuit et fiable existent déjà.

Et la sécurité avec OpenID?

OpenID ouvre quelques failles de sécurité en même temps qu'il en referme d'autres, au final rien de si terrible. Le risque numéro 1 bien sûr, c'est que quelqu'un s'empare de votre unique mot de passe et vous vole tous vos services en lignes. A cause de ceci, il est par exemple exclu qu'une banque en ligne passe par OpenID. Dans une entreprise, on peut soit éviter OpenID pour les applications les plus critiques - celles qui vont vraiment motiver des pirates à passer du temps à essayer de vous voler les clées - ou passer par OpenID mais interdire à vos services l'accès par une IP externe.

Une technique pour vous voler votre OpenID: le spoofing qui consiste à vous faire croire que vous aller vous authentifier sur votre portail OpenID alors qu'il s'agit d'une page imitée qui n'a d'autre but que de vous voler votre mot de passe. D'une part dans un futur assez proche, les navigateurs sauront détecter - et vous signaler ces tentatives d'usurpations. D'autre part, dès aujourd'hui, on peut lutter efficacement contre le spoofing en présentant une image personnalisée que l'on a retrouvé grâce à un cookie à vie longue, l'absence d'image inciterait l'utilisateur à vérifier que l'URL sur laquelle il a été redirigé est bien la bonne. C'est par exemple la solution adoptée par Yahoo sur son système d'authentification similaire à OpenID.

Enfin, halte à l'hypocrisie, ne pas avoir de login/mot de passe unique, c'est presque à coup sûr laisser l'utilisateur utiliser des mots de passe similaires, voire les mêmes ou encore évoluant de façon prévisible sur tous les sites qu'il consulte afin de soulager sa mémoire. Avec ce mécanisme actuel, il suffit de faire un site web2.0 populaire pour voler à coup sûr de très nombreux services en ligne. Au moins avec OpenID, on ne saisit pas son mot de passe n'importe où sur n'importe quel site aussi piratable soit-il!

Par ailleurs, signalons que certains serveurs OpenID gèrent le HTTPS. Cela évite donc qu'un intermédiaire puisse intercepter le couple login/mot de passe, et ce indépendamment du fait que notre site soit lui en HTTPS. Bien sûr, pour une application critique on choisira du HTTPS de bout en bout.

Autres atouts d'OpenID:

  • au moment d'autoriser un site à s'authentifier avec son OpenID, l'utilisateur peut décider de d'associer à ce site un profil spécifique dont les informations personnelles peuvent différer d'une application à une autre.
  • l'URL de login utilisée comme OpenID peut servir de page d'information sur l'utilisateur s'il le souhaite. Dans ce cas, OpenID spécifie même un mécanisme dit de délégation. Ainsi, l'utilisateur peut simplement utiliser par exemple l'URL de son blog comme OpenID dès lors qu'à cette page on trouve 2 petites balise HTML spécifique qu'il aura pris soin d'insérer et qui vont permettre à un serveur OpenID dédier de traiter la phase de login.

Interopérabilité des identités numériques entre sites!

Comme on l'a vu, OpenID propose une fonctionnalité minimale de fédération des identités numérique autour d'une unique URL. Cependant, comme on l'a vu, la plupart des sites ont et auront besoin d'enrichir ce référentiel utilisateurs par d'autres paramètres, par exemple une liste d'amis dans un réseau social. Se posent donc d'autres problématiques d'interopérabilité de ces données indépendamment de la problématique d'authentification unique.

OpenSocial

 

API publique standard très récemment lancé par Google, OpenSocial est une des réponse à ce problème. Open Social spécifie un cadre - une API - que doivent respecter les sites sociaux afin que tout développeur puisse y déposer une mini-application qui reconnaitrait l'utilisateur loggué et des paramètres classiques des réseaux sociaux, tels que la liste d'amis. Ainsi le réseau social se comporte en portail d'applications de type Google Gadget ou Google Mashup ou encore totalement libre pourvu qu'elle implémente l'API javascript d'OpenSocial. A la différence des portlets, il s'agit ici d'intégration coté client avec l'avantage que les serveurs peuvent être hétérogènes mais l'inconvénient de ne pas supporter l'accessibilité au sens W3C.

Grâce à son initiative, Google va donc favoriser l'éco-système des solutions de 'social networking' en aidant les développeurs à n'écrire une application qu'une seule fois et qui pourra néanmoins être déployée et utile dans différents contextes de réseaux sociaux. C'est le même "write one, run anywhere" de Java qui avait en sont temps démultiplié l'offre de logiciels open source. Une approche très différente de l'existant là où par exemple Facebook exigeait qu'on se plie à leur API propriétaire pour écrire une mini-application sociale qui puisse exister dans leur portail et ainsi rendre captif ses partenaires avec ses utilisateurs eux aussi captifs.

Pour autant, Open Social ne résout aucun des autres problèmes. En effet, on peut utiliser OpenSocial indépendamment d'OpenID et dans ce cas la fédération des identités n'est qu'une douce illusion. Et quand bien même le référentiel d'utilisateurs est OpenID, quand on récupère une liste d'amis, rien ne nous permet d'établir un parallèle entre ces utilisateurs et leur éventuel compte dans d'autres réseaux sociaux !

OpenID2 et OAuth

Pour aller plus loin, il faudrait établir des protocoles standards d'échange d'attributs liés à l'identité entre applications. C'est tout l'objet d' OpenID 2.0 qui vient justemment d'être finalisée et de OAuth. C'est aussi à cause de ce besoin que les grands noms de l'Internet que sont par exemple Google ou Yahoo ont mis en place leurs propres solutions similaires à OpenID (Google Auth Sub et BBAuth ) mais qui possèdent déjà de telles fonctionnalités. C'est ainsi que, par exemple, une application Google Mashup faite par n'importe qui, peut - si on l'autorise - interagir avec votre calendrier GCalendar.

Google a annoncé récemment qu'il comptait se rapprocher de OAuth quant à ses protocoles d'échange pour OpenSocial alors même qu'il a aussi annoncé récemment que Google Blogger allait lui utiliser permettre l'utilisation d'OpenID pour les commentaires.

Le Futur d'Open ID

Après une phase de croissance fulgurante de 7% de croissance par mois des sites utilisant OpenID, la croissance est redescendue à 5% par mois.

 

En fait, tout va surtout désormais dépendre de ce que décident les acteurs majeurs de l'Internet. Certain supporters se sont défaussés comme Digg, qui n'offre toujours pas ce système de login en dépit de ses annonces. Au contraire, OpenID a reçu le support net de Microsoft (mis en échec avec sa fonctionnalité MS Passeport), de Google Blogger, d'AOL, d'Orange, de Wikipedia, de LiveJournal...

 

Dès aujourd'hui, 160 Millions de comptes sont des comptes OpenID même si leur utilisateurs ne le savent pas toujours (c'est le cas pour Orange et AOL).

Le problème est qu'OpenID ne s'utilise pas comme un système de login classique. En effet, l'utilisateur doit d'abord donner son identifiant ou URL OpenID. En effet il ne doit pas écrire son mot de passe sur le serveur non sécurisé. Ceci est un peu déconcertant au début car il habitué à donner son couple login/mot de passe dans un seul et même formulaire. Bien sûr, quand le service à utiliser est hébergé sur le même domaine que le serveur OpenID (comme à AOL, Orange ou LiveJournal), l'utilisateur ne s'en rend même pas compte.

Cependant, il est probable que les navigateurs gèrent l'authentification OpenID nativement, comme par exemple avec le plugin SeatBelt pour Firefox fait par Verisign. l'OS Leopard d'Apple intègre lui toutes les bibliothèques OpenID nativement.

Dès lors que les utilisateurs seront totalement familiarisés avec le système, gageons qu'OpenID aura acquis un statut de standard incontournable.

Quelle qu'en soit l'issue, on peut dorénavant affirmer sans réserve qu' OpenID est une véritable aubaine pour tout site grand public nécessitant la création de comptes utilisateurs. Et ceci d'autant plus pour les sites au business model dit 'opportuniste' qui doivent conquérir leur utilisateurs et qu'un processus de login ne doit pas faire fuir. A la clé, également, une bonne économie en coût de développement.

Pour ce qui est des portails d'entreprises, comme il faudra sans doute que l'entreprise implémente elle-même le serveur OpenID (si elle ne fait pas confiance aux fournisseurs externes), la conclusion est donc mitigée à cette heure.

Dans ce cas, on a clairement plus de travail à effectuer que mettre en place un serveur CAS, c'est pourtant parfois intéressant pour des raisons d'ouverture vers l'extérieur ou de scalabilité; Orange et AOL viennent de nous le prouver. Il faudra sans doute néanmoins attendre l'avènement de fournisseurs OpenID ayant pignon sur rue voire des responsabilités contractuelles pour que la solution devienne le standard de facto en entreprise si c'est cette solution qui s'impose.

Enfin, tordons le coup à cette idée qu'il existerait toujours deux sphères bien distinctes, l'une publique et l'autre d'entreprise qui ne serait pas interoperables. Ainsi, on a récemment vu la solution de gestion documentaire d'entreprise Alfresco s'associer à Facebook pour fournir un réseau social de partage de documents concurrents de solutions propriétaires au coût comparativement exorbitant car il incluait le support de l'infrastructure de réseau social alors qu'Alfresco la mutualise avec Facebook. De plus, selon une étude de McKinsey 37% des entreprises interrogés pensent à mettre en place de telles solutions collaboratives... Une autre étude de Yankee Group affirme elle que 54% des employés affirment qu'ils seraient plus productif avec des outils web2.0 issus de la sphère privé plutôt que leurs outils d'entreprises...

Raphael Valyi
picto

Commentaires

Soyez la premiere personne à ajouter un commentaire sur cet article.
Ecrire un nouveau commentaire