Affichage des articles dont le libellé est Liberty Alliance. Afficher tous les articles
Affichage des articles dont le libellé est Liberty Alliance. Afficher tous les articles

mercredi 5 mars 2008

La gestion de l'identité sur Internet

Dans le billet précédent, nous avons tenté d'expliquer la gestion de l'identité en entreprise (interne au SI). Le présent billet a pour objectif d'expliquer cette gestion de l'identité sur Internet. Dès lors, deux visions s'affrontent :
  • la vision de l'identité fédérée par les entreprises,
  • la vision utilisateur (user-centric)
Vision de l'identité fédérée par les entreprises :
Dans le cadre de cette vision, l'architecture de service que nous avons décrite pour la gestion de l'identité en entreprise reste valable mais doit être interprétée quelque peu différemment :

Dans ce contexte, l'objectif est d'exposer des services sur Internet à des internautes et de leur offrir la possibilité de naviguer en SSO. Dès lors, les différentes fonctions doivent être interprétées comme suit :
  • le référentiel d'identités qui stocke la liste des identités autorisées à accéder à des services,
  • gestion des habilitations : ce module permet au internautes de souscrire à différents services en ligne ; il fonctionne généralement comme un self-service et embarque rarement des notions de workflow,
  • provisioning : ce module permet de créer les comptes sur des systèmes cibles après inscription à un nouveau service,
  • contrôle d'accès : permet d'authentifier un utilisateur et lui permet de naviguer en SSO entre plusieurs services souscrits,
  • fédération : ce module permet de fédérer des services inter-entreprises afin d'offrir une navigation fluidifiée à l'utilisateur (pas de nécessite de plusieurs authentifications, pas de nécessité de re-saisie de données personnelles). Ce type de fédération est associé aux protocoles Liberty Alliance, SAML, WS-*
  • Audit : ce module permet de tracer ce qui est effectué dans les autres modules et d'effectuer un reporting adéquat
Dès lors que la fédération est mise en œuvre sur ce type de vision (Liberty Alliance, SAML, WS-*), elle nécessite de mettre en œuvre des accords juridiques entre les entreprises ainsi que des contrats d'interface pour que cela fonctionne bien tant au niveau business que technique.

La vision utilisateur (user-centric) :
L'objectif de cette vision est de donner la main à l'utilisateur de sorte qu'il n'y ait pas besoin d'accords entre les entreprises au préalable. L'architecture précédemment décrite n'a pas d'utilité vu de l'utilisateur mais peut exister pour autant pour les services exposés par les entreprises.

Dans cette vision utilisateur, l'idée est que l'utilisateur est complètement maître de son identité (ou ses identités), peut choisir de les stocker chez l'Identity Provider de son choix, de partager les informations relatives à son identité vers qui il veut.

Cette vision s'appuie sur des protocoles de type OpenID ou CardSpace. A noter que le premier nécessite de faire opérer un Identity Provider alors que le second s'appuie sur le stockage de vos cartes d'identité sur votre poste de travail.

Nous détaillerons dans un prochain billet le fonctionnement de ces protocoles.

lundi 7 janvier 2008

L'approche limité des standards ?

Les standards énoncés ne doivent pas être mélangés de façon encore à faire croire que cela est complexe.
- Liberty Alliance (ID-FF 1.2) et SAML ont convergé pour donner naissance à SAML 2.0. Désormais, depuis 2005, on ne devrait plus dire (n'en déplaise à Sun), je fais de la fédération d'identités compatible Liberty mais plutôt SAML 2.0. Rappelons que Liberty Alliance a laissé le soin à l'OASIS de faire évoluer SAML si cela s'avérait nécessaire, Liberty se focalisant sur les couches WSF et SIS (nous reviendrons sur ces dernières dans un billet ultérieur).
- dans l'article énoncé, il est mélangé sécurité des web services et fédération des identités dès lors qu'on parle des protocoles liés à WS-*. Il est vrai que vu la complexité de la pile WS-*, on peut se demander si une simple protection HTTPs n'est pas suffisante (mais là encore cela dépendra de l'architecture mise en oeuvre et du niveau de sécurité souhaité). Si l'on veut faire de la fédération d'identité, on sera amener à utiliser WS-federation (et donc WS-*) ce qui revient potentiellement à faire des choses très complexes. Le fait que WS-* soit porté par Microsoft et fourni dans ADFS sera certainement un frein pour WS-Federation (alors qu'il devrait l'être moins pour le reste de la pile WS-*)
- OpenID provient du monde open source et avait pour but au départ de fournir une fonction de SSO aux internautes navigant sur le web. OpenID a la particularité de donner à l'utilisateur la possibilité de se définir de multiples identités de façon à se garantir une certaine anonymité. Le fait que certains acteurs comme Orange mette en oeuvre OpenID en garantissant la véracité des données fournies détourne OpenID de son modèle original.

Il est clair qu'au délà de la complexité technique de mise en oeuvre :
- il existe des complexités organisationnelles et juridiques de mise en oeuvre,
- les éditeurs ne veulent pas rester dans le carcan d'un protocole et préférent fournir des solutions fonctionnant comme des hubs multi-protocoles.

Dans tous les cas, il est clair que l'apport de ces standards est une vraie avancée dans le monde de l'identité et que demain verra la mise en oeuvre de nombreux projets de ce type car la fédération d'identités est le futur de la gestion des identités du fait que les systèmes d'informations s'ouvrent de plus en plus sur Internet.