1. Premiers contacts avec Windows CardSpace (WCS)

Auteur : Philippe Beraux, MCS, Microsoft France
Janvier 2007 - Cet article est paru dans le magazine Programmez!

Microsoft Windows CardSpace (WCS), anciennement connu sous le nom de code « InfoCard », constitue un sous-système Windows sécurisé pour créer des relations avec des sites Web et services en ligne consommateur d’identité. WCS propose une approche cohérente pour :

• Des sites et/ou des services Web de façon à 1) exprimer leur(s) exigence(s) en termes d’informations personnelles sur votre identité (fournisseur(s) d’identité de confiance recevables dans le contexte de la transaction courant, format(s) de jetons de sécurité accepté(s) comme preuve d’une identification et authentification réussie auprès desdits fournisseurs, informations nécessaires sur votre identité à fournir par lesdits fournisseurs de façon à prendre des décisions d’autorisation) et 2) exposer leur politique d’utilisation de ces informations personnelles.

• Vous permettre 1) de vérifier de façon sûre et digne de confiance l’identité du site ou service accédé, 2) de prendre connaissance de la politique d’utilisation des informations personnelles divulguées, 3) de décider, en toute connaissance de cause et de façon déterministe, de poursuivre ou non, sur ces bases, la transaction courante engagée avec le site ou service Web.

• Vous permettre de gérer vos diverses informations d’identité (multiples identités, multiples  formats, multiples fournisseurs d’identités, etc.) à l’aide de cartes d’information virtuelles.

  Une carte d’information virtuelle ne représente pas un jeton de sécurité. Fondée sur la métaphore des cartes du monde réel (carte national d’identité, permis de conduire, carte bancaire, carte de membre d’un club, carte de fidélité, etc.), une carte d’information personnelle matérialise une relation avec un fournisseur d’identité indépendamment de la technologie de sécurité sous-jacente et des mécanismes d’identification et d’authentification supportés per le fournisseur de sécurité. Une carte d’information virtuelle contient des métadonnées pour l’obtention d’un jeton de sécurité auprès du fournisseur d’identité (adresse du fournisseur d’identité, format(s) de jetons de sécurité supporté(s), type d’informations personnelles supporté, mécanisme d’authentification, etc.).

  WCS permet de créer des identités auto-déclarées via un fournisseur d’identité local intégré au travers de cartes d’information personnelles ; ces dernières peuvent alors remplacer le besoin de mémoriser un couple nom d’’utilisateur/mot de passe. D’autres transactions peuvent exiger une identité certifiée par un fournisseur d’identité de confiance dans la transaction, comme une banque ou une administration. Ceci suppose que le fournisseur d’identité émette vis-vis de cette identité une carte d’information gérée (par ce dernier).

• Vous permettre de 1) passer en revue vos informations personnelles potentiellement communiquées sur la base de l’identité choisie au travers de la sélection d’une carte d’information virtuelle 2) consentir à divulguer effectivement ces informations au site ou service Web dans le cadre de la transaction.

Lorsqu’un site ou un service Web supportant CardSpace souhaite obtenir des informations personnelles sur vous-même, l’affichage bascule sur un autre bureau Windows et l’interface WCS affiche alors l’identité du site ou du service accédé, ici sts.labs.live.com.

Après votre validation de l’identité du site ou du service accédé et votre consentement à poursuivre la transaction en optant pour l’« envoi » d’une carte d’information à ce dernier, l’ensemble de vos identités que vous avez stocké sous forme de cartes d’information virtuelles (personnelles ou gérées). Seules les cartes répondant aux exigences exprimées dans la transaction courante par le site ou le service Web peuvent être sélectionnées.

Vous disposez alors de la latitude de choisir la carte (identité) à utiliser dans la transaction courante et WCS entre en contact avec le fournisseur d’identité concerné (local ou distant) de façon à obtenir un jeton de sécurité émis et signé numériquement par ce dernier qui contient l’ensemble des informations personnelles exigées par le site ou service Web. Ceci requiert de vous identifier et authentifier auprès du fournisseur d’identité conformément au mécanisme précisé dans la carte. Par ailleurs, seules les informations personnelles exigées sont présentes dans le jeton résultant (besoin d’en connaître) et ce, même si le fournisseur d’identité dispose potentiellement d’informations additionnelles sur vous-même.

WCS permet de stoker de façon sécuriser les diverses identités numériques (auto-déclarées et/ou certifiées) d’une personne et fournit, à ce titre, une interface unifiée et cohérente pour choisir l'identité à exposer pour une transaction particulière au niveau d’un site ou d’un service Web. WCS peut remplacer via l’usage de la cryptographie les couples nom d’utilisateurs et mots de passe que vous utiliser pour vous enregistrer et vous connecter auprès de sites et de services Web.
WCS constitue une composante du Framework .NET 3.0 à venir, et aujourd’hui disponible pour les environnements Windows XP SP2 et Windows Server 2003 SP1 et R2 au travers la pre-release Community Technology Preview (CTP) de juillet 2006. Cette dernière peut être téléchargée depuis l’adresse Internet https://msdn.microsoft.com/fr-fr/netframework/bb902784.aspx#eze . Son utilisation avec Internet Explorer requiert la version 7.0 de ce dernier aujourd’hui disponible en Release Candidate 1 (RC1) à l’adresse Internet https://www.microsoft.com/windows/ie/downloads/default.mspx . Windows Vista, la prochaine version de Windows, intègre par défaut le sélecteur WCS.

Ainsi, rapidement décrit, le système Windows CardSpace (WCS) représente l’implémentation Microsoft de la notion de sélecteur d’identité, pièce centrale d’un effort partagé au niveau de l’industrie pour constituer un méta-système d’identité, à savoir une couche d’identité unifiée, sécurisée et interopérable pour l’Internet.

1.1 Vers un éco-système de confiance

Kim Cameron, architecte Identité au sein de Microsoft, a entrepris, au travers de son blog http://www.identityblog.com , le projet, il y a maintenant plus de deux ans, de développer et partager une compréhension formelle des dynamiques amenant des systèmes d’identités numériques à rencontrer le succès ou, au contraire à échouer et ce, dans différents contextes. Les larges discussions qui s’en sont suivi avec l’industrie, les associations de défenses des libertés individuelles, etc. ont conduits à établir un consensus autour de 7 lois de l’identité qui sont discutées dans le livre-blanc « The Laws of Identity » (http://www.identityblog.com/?page_id=354 ). Peu importe la façon dont une organisation positionne un système d’identité, si ce dernier viole ces lois, il est fort probable que celui-ci échouera d’une façon ou d’une autre. L’échec sera peut être du à une faille de sécurité permettant le vol d’identité ou plus simplement, les utilisateurs potentiels rejetteront le système parce qu’ils ne se sentent pas en confiance avec.

Pourquoi irais-je donner mes identifiants ? Divulguer des détails sur mon identité et ma personne ? Quel(s) usage(s) va-t-il en être fait ? Sont autant de questions que tout utilisateur est amené à se poser lorsqu’il doit communiquer des informations personnelles et ce dernier ne comprends pas toujours pourquoi il doit faire tout cela. L’adhésion et par la même la confiance placée dans un système d’identité ne se décrète pas, elle se mérite !

Prise dans leur ensemble, ces lois définissent un méta-système d’identité unifié qui offre à l’Internet la couche Identité qui de façon évidente lui fait défaut. La résolution d’un tel problème est bénéfique à tous.

Un méta-système d’identité (système de systèmes d’identité) constitue une architecture interopérable pour l’identité numérique qui présume que les sujets (ou personnes) disposent de plusieurs identités numériques basées sur de multiples technologies/protocoles, implémentations et fournisseurs sous-jacents.

Une telle approche permet non seulement aux personnes d’être en contrôle, au travers d’un sélecteur d’identité, de leurs identités et de l’usage qui en est fait, mais également aux organisations de pouvoir continuer à utiliser et bénéficier de leur investissements existants en termes d’infrastructure d’identité, de choisir la technologie d’identité qui leur est la mieux appropriée, et de plus facilement migrer d’anciennes technologies vers de nouvelles technologies sans pour autant sacrifier l’interopérabilité avec les autres.

Le livre-blanc « The Identity Metasystem » (http://www.identityblog.com/?page_id=355 ) en partant des conclusions et du large consensus des lois de l’identité présente une architecture ouverte et interopérable pour construire un tel méta-système et décrit comment participer à ce méta-système d’identité qui part nature n’appartient et n’est contrôlé par personne.

Différentes parties participent dans le méta-système de différentes façons. Les trois rôles au sein du méta-système sont :

1. Sujets – Des exemples de sujets sont des internautes pour des sites de commerce en ligne, des usagers particulier et/ou professionnel pour l’administration électronique, etc.

   Comme dans le monde réel, un sujet peut disposer dans le monde numérique de plusieurs identités numériques (quelles soient omni ou mono directionnelles) qui sont utilisables ou non dans le contexte courant d’une transaction.

   L’identité numérique d’un sujet se traduit par un ensemble d’informations personnelles exprimé sous forme d’une collection de « claims », déclarations faites sur quelqu’un/quelque chose par quelqu’un/quelque chose qui caractérisent le sujet. Autrement dit, ce que vous dites sur vous-mêmes ou ce que d’autres disent sur vous. Dans les deux cas, ceci suppose une relation établie avec un fournisseur d’identité : local ou tiers (distant) ;

2. Fournisseurs d’identité qui émet les identités numériques – Par exemple, les sites de commerces en ligne peuvent émettre des identités à leurs clients, les gouvernements peuvent émettre des identités à leurs citoyens, les banques peuvent émettre des identités permettant le paiement, et les utilisateurs peuvent utiliser des identités autoproclamées dans les contextes où cela est acceptable comme l’inscription sur tels ou tels sites Web.

   Comme précédemment suggéré, ses diverses identités se traduisent sous forme de jetons de sécurité émis et signés par les fournisseurs d’identité. Ils constituent, de la part du fournisseur d’identité, une preuve d’une authentification réussie et contiennent la collection de « claims » exigés par le consommateur d’identité ;

3. Consommateurs d’identité qui requièrent des identités – Par exemple, un site Web qui utilise des identités gérées lui-même ou par d’autres entités de confiance ;

Le méta-système d’identité contribue à établir au global un écosystème de confiance avec, au centre, le sélecteur d’identité. Le livre-blanc « Design Rationale behind the Identity Metasystem Architecture » (http://www.identityblog.com/wp-content/resources/design_rationale.pdf ) aborde plus en détail les décisions de conception et leur rôle au sein d’un méta-système d’identité. Windows CardSpace (WCS) est l’implémentation Microsoft d’un tel sélecteur d’identité.

Comme nous l’avons vu en introduction, le sélecteur d’identité permet à l’utilisateur :

1. De s’assurer de l’identité du site ou service Web (fournisseur de service) accédé,
2. De sélectionner dans le contexte courant de la transaction son identité (et par la même le fournisseur d’identité de son choix),
3. De la communiquer après son consentement explicite au fournisseur de service accédé.

Le méta-système d’identité :

• Repositionne les identités numériques d’un sujet sous son contrôle direct et explicite,

• Offre une expérience utilisateur prévisible, cohérente et reconductible quels que soient les fournisseurs d’identité et de service impliqués dans le contexte de la transaction courante,

• Élimine les couteuses intégrations pas toujours des plus ergonomiques et cohérentes tant au niveau fournisseur d'identité que consommateur d’identité fournisseur de service. Ces dernières années, beaucoup de technologies et protocoles d’identité ont vu le jour. LID, SXIP, Liberty Alliance, Microsoft Passport/Windows Live ID, Yadis, SAML ne constituent que quelques exemples,

• Est agnostique en termes de jetons de sécurité et de « claims ». Seule la transaction en cours et les décisions de l’utilisateur pilote ces éléments dans le cadre de la transaction courante.

Il convient de noter que, dans de nombreux cas, les participants dans le méta-système jouent plus d’un rôle. Ainsi, même si les consommateurs d’identité potentiels ne sont pas forcément prompt à laisser « quelqu’un d’autre », en l’occurrence un fournisseur d’identité*,* potentiellement au milieu de leur relation avec un utilisateur, les consommateurs d’identité peuvent jouer également le rôle de fournisseurs d’identité qui pourra servir à ce titre de service de jetons de sécurité d’autorisation. Par ailleurs, les choses évoluent à présent avec le besoin croissant de mécanismes d’authentification forte et de dispositif anti-hameçonnage/vol d’identité. Les statistiques proposées sur le site de l’Anti-Phishing Working Group à l’adresse Internet http://www.antiphishing.org sont édifiants. Les consommateurs d’identité, sont aujourd’hui beaucoup plus intéressés par ce genre de chose qu’il y a encore 2 ou 3 ans.

De plus, le méta-système offre l’opportunité d’établir de nouvelles relations entre partenaires jusque là impossibles si les orientations technologiques des uns et des autres (fournisseur d’identité vs. Consommateur d’identité fournisseur de service) n’étaient pas compatibles.  A ce titre, l’ensemble des problématiques adressées par le sélecteur d’identité (au sein d’un écosystème de confiance), en permettant aux utilisateurs de gérer leurs propres identités (quelles soient omni ou mon directionnelles), et les problèmes que rencontre la fédération d’identité sont dans l’ensemble orthogonaux. 

Le méta-système d’identité n’est pas positionnée contre tel ou tel protocole de fédération, mais au contraire supprime les frictions qui peuvent exister et résout des problématiques connexes et complémentaires. Il s’agit donc d’une approche orthogonale.
La meilleure preuve en est la démonstration réalisée par Ping Identity au Burton Catalyst 2006 : « A SAML federation supporting InfoCards » (http://www.identityblog.com/?p=527 et http://www.identityblog.com/?p=471 )

1.2 Interactions CardSpace et protocoles

L’architecture des services Web fournit au méta-système d’identité et à CardSpace 1) une pile standard au travers des spécifications/protocoles WS-Security, WS-Trust, WS-SecurityPolicy, et WS-MetadataExchange et 2) l’enveloppe.

WS-Security permet de véhiculer un jeton de sécurité. Un tel jeton peut être obtenu auprès d’un service de jetons de sécurité (Security Token Service ou STS) exposé par le fournisseur d’identité à travers le protocole WS-Trust. WS-SecurityPolicy permet à un service Web consommateur d’identité d’exprimer un politique de sécurité et WS-MetadataExchange de la  consommer dynamiquement.

Le méta-système d’identité correspond à un simple profil de ces spécifications.  Ce profil est décrit dans le document « A Technical Reference for InfoCard v1.0 in Windows » (https://download.microsoft.com/download/5/4/0/54091e0b-464c-4961-a934-d47f91b66228/infocard-techref-beta2-published.pdf ) et son complément « A Guide to Integrating with InfoCard v1.0 » (https://download.microsoft.com/download/6/c/3/6c3c2ba2-e5f0-4fe3-be7f-c5dcb86af6de/infocard-guide-beta2-published.pdf )

La très large adoption des standards de la pile WS-* fait qu’il est très facile de participer au méta-système d’identité quelque soit le ou les rôles souhaités, la plateforme ou la technologie utilisée. La suite de cet article consacré à l’expérimentation par la pratique de WCS en offre l’illustration.

Dans le cadre d’une transaction avec un site Web depuis un butineur comme Internet Explorer, il est noter que le méta-système ne repose pas directement sur la pile WS-*. Le modèle d’interaction adopté est décrit dans le document «  A Guide to Supporting InfoCard v1.0 Within Web Applications and Browsers » (http://www.identityblog.com/?page_id=412 ).

1.3 Démarrer aujourd’hui avec Windows CardSpace

Les présentations étant ainsi faites, si vous souhaitez expérimenter CardSpace aujourd’hui et découvrir concrètement le potentiel du méta-système d’identité, le site communautaire CardSpace à l’adresse Internet http://cardspace.netfx3.com permet d’être au fait de l’ensemble des choses relatives à l’« univers » CardSpace. Au côté des références techniques proposées sur le site MSDN CardSpace à l’adresse https://msdn2.microsoft.com/en-us/netframework/aa663320.aspx , ce site propose notamment de très nombreux exemples de code et outils associés pour explorer le développement Windows CardSpace (WCS) à proprement parlé avec le Framework .NET 3.0, qu’il s’agisse de sites Web avec ASP.NET 2.0, de services Web ou de services de jetons de sécurité avec Windows Communication Foundation (WCF), de « provisioning » utilisateur avec génération de cartes via Windows Workflow Foundation (WF).

En première approche, les deux tutoriels « Introduction to CardSpace with Internet Explorer » (http://cardspace.netfx3.com/files/folders/samples-july-ctp/entry4898.aspx ) et « Windows CardSpace and Web Services » (http://cardspace.netfx3.com/files/folders/samples-july-ctp/entry5269.aspx ) basés sur la Community Technology Preview (CTP) de juillet 2006 du Framework .NET 30 offrent une vue d’ensemble sur les deux axes de mise en œuvre de CardSpace, en l’occurrence l’utilisation d’un sélecteur d’identité vis-à-vis de l’accès identifié et authentifié à un site ou service Web consommateur d’identité.

Des exemples complémentaires sont proposés pour aborder des aspects connexes du développement WCS comme le déchiffrement de jetons de sécurité au niveau d’un consommateur d’identité, la mise en œuvre d’un service de jetons de sécurité élémentaire ou encore la création de cartes d’information pour tel ou tel compte pour un fournisseur d’identité, etc.

En termes de ressources complémentaires pour cette exploration, il convient de noter la présence en ligne du bac à sable CardSpace à l’adresse http://sandbox.netfx3.com   conçu pour démontrer l’utilisation de WCS. Comme la plupart des sites sur la toile aujourd’hui, ce site permet de s’identifier et de s’authentifier à l’aide du couple nom/mot de passe. Ceci étant, ce site supporte également l’utilisation de WCS dans ce cadre. Ainsi, ce site permet 1) de créer (provisioning) un compte utilisateur sur la base d’une carte d’information personnelle 2) lier une ou plusieurs cartes d’information à ce compte utilisateur et 3) « se signer » avec l’une de ces cartes d’information sur ce site.

Toujours au registre des fournisseurs d’identité, le site expérimental Microsoft Live Labs Security Token Service à l’adresse Internet https://livelabs.com/ offre la possibilité de déporter les fonctions d’authentification sur ce dernier qu’il s’agisse pour un utilisateur de « se signer » sur un site ou un service Web ou, de façon corolaire, pour un site ou un service Web d’authentifier un utilisateur. Dans le premier cas, l’utilisateur peut s’enregistrer sur ce site et utiliser par la suite la carte d‘information délivrée pour s’authentifier sur un site ou un service participant au méta-système d’identité. Dans le second cas, un site ou un service Web peut s’enregistrer auprès de ce service de jetons de sécurité de façon à utiliser les jetons de sécurité émis par ce dernier.

De façon à poursuivre cette exploration dans un contexte d’interopérabilité, le tutoriel à l’adresse http://www.identityblog.com/?page_id=430 et le code source associé (http://www.identityblog.com/wp-content/resources/simple-infocard-demo/simple-infocard-demo-v2.zip) illustre la mise en œuvre d’un site Web PHP 5 consommateur d’identité dans le méta-système d’identité. Le consommateur d’identité peut être testé directement à l’adresse Internet https://www.identityblog.com/wp-login.php . La société Ping Identity propose, de son côté, un fournisseur d’identité écrit en Java à l’adresse http://www.pingidentity.com/.

Si WCS constitue l’implémentation Microsoft du sélecteur d’identité, d’autres sélecteurs d’identité à destination de la plateforme Windows ou d’autres plateformes commencent à voir le jour qu’il s’agisse du prototype Java pour FireFox à l’adresse http://xmldap.org/relyingparty/ ou du projet Open Source Identity Selector (OSIS) annoncé lors de la conférence Harvard/Berkman Identity Mashup en juin dernier. Les détails de ce projet OpenSource sont précisés à l’adresse Internet http://osis.netmesh.org/wiki/Main_Page.

Le méta-système d’identité prend forme. Que le bigbang de l’identité commence ! 

1.4 Pour aller plus loin

• Liens sur les ressources MSDN Windows CardSpace (https://msdn2.microsoft.com/en-us/netframework/aa663320.aspx) – Articles et documentations techniques sur Windows CardSpace.

• Liens sur les ressources de la section CardSpace du site communauté netFx3 (http://cardspace.netfx3.com ) – Présentations, tutoriels, exemples de code et outils sur Windows CardSpace.

• Vidéo « InfoCard Explained » (https://channel9.msdn.com/showpost.aspx?postid=181080) – Vidéo Channel9 avec une explication des exemples d’utilisation de Windows CardSpace.

• Weblog Identité de Kim Cameron (http://www.identityblog.com ) – information from Microsoft's architect for identity. Ce site permet par ailleurs une identification et authentification avec Windows CardSpace ou tout autre sélecteur d’identité.

• Weblog  d’Andy Harjanto (https://blogs.msdn.com/andyhar ) – Information sur le développement d’applications avec CardSpace.

• Weblog de Garrett Serack « CardSpace and more... » (https://blogs.msdn.com/garretts) – Information du responsable Communauté CardSpace sur la conception et le développement avec CardSpace.

• Weblog de Vittorio Bertocci « Vibro.net »  (https://blogs.msdn.com/vbertocci) – Information d’un architecte Longhorn Server sur la conception et le développement avec CardSpace.

• Weblog de Nigel Watling « Security and identity for developers » (https://blogs.msdn.com/nigelwa ) – Information d’un architecte Longhorn Server sur la conception et le développement avec CardSpace.