Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Blocage IE avec écran multitouch sous Silverlight

Voici un cas intéressant dont je viens de trouver la solution et que je m’empresse de vous communiquer…

Les écrans multitouch ne sont pas encore légion, sauf chez quelques geeks, dont je suis. Ainsi, pour tester dans un mode proche de la réalité les applications Phone 7 en cours de développement (et faute de téléphones de ce type disponible sur le marché pour l’instant) j’ai acquis un écran 22 pouces IIYama multitouch T2250MTS. C’est très sympa, pas très cher et ça marche vraiment bien de base avec Windows 7 sans installer aucun driver (c’est à dire que Windows 7 possède déjà le fameux driver et que brancher l’USB de l’écran sur le PC suffit sans aucun pilote extérieur ni CD d’installation, c’est beau le progrès !).

L’écran est même fourni avec un stylet qui se cache dans le bas de son boitier, ce qui évite les traces de gros doigts graisseux sur l’écran ! :-)

Bref, tout cela fonctionne à merveille et du premier coup. Quand on arrive sur des zones de saisie et qu’on touche l’écran il y a même un petit symbole de clavier qui apparait pour permettre d’ouvrir un grand clavier virtuel, voire le module de reconnaissance d’écriture. On voit que Windows 7 a été conçu pour investir les Tablet PC… Vraiment cool. Seul bémol, sur un écran vertical manipuler les applis avec les doigts à bout de bras c’est vite crevant… Mais ce n’est pas pour cela que j’ai acheté l’écran, c’est pour utiliser l’émulateur de Phone 7 en mode multitouch (car tester une appli pour téléphone touch avec la souris c’est le meilleur moyen de foirer le design, les doigts sont plus gros et moins précis, il faut y penser à la conception !).

Vous allez me dire c’est quoi le rapport avec Silverlight et Internet Explorer ?

C’est tout simple.

Plantage avec Silverlight ?

Silverlight gère le multitouch. Au moment où internet exploreur se lance et affiche l’application quand je suis en  debug (sous VS ou Blend) je ne sais pas trop quel niveau de sécurité IE reconnaît (en tout cas pas Intranet local car j’ai abaisser toutes les sécurités à ce niveau et cela n’a rien changé) mais à l’activation du plugin Silverlight IE 8 s’arrête, comme planté.

Impossible de s’en sortir. Il faut aller le shooter depuis les processus de Windows ou bien stopper le debug sous VS ce qui a le même effet.

Sécurité cachée !

Et là, l’oeil averti du chasseur de bug voit passer à toute vitesse comme une petite fenêtre cachée sous IE qui, hélas puisqu’on vient de flinguer IE, disparait sans qu’on puisse la lire…

Il y a donc une question qui est posée, en modal, ce qui bloque IE 8. Il “suffit” donc d’accéder à ce dialogue.

Je n’ai pas réussi. Et si on minimise IE pour que ça ne soit plus qu’un petit carré minuscule, on ne voit pas derrière la fenêtre du dialogue… Elle ne vient donc que quand IE est shooté. Bug…

Problème numéro 1: Identifier cette fichue fenêtre.

Ca passe tellement vite que c’est illisible bien entendu.

Ruse : Utiliser l’enregistreur d’écran livré avec Expression Encoder 3 et enregistrer la vidéo du bug pour faire ensuite un arrêt sur image et lire le texte du dialogue…

Ca ne marche pas au premier essai car ça va vraiment vite. Il faut ruser encore plus en modifiant les réglages d’enregistrement de la vidéo, notamment en passant à 100 images secondes et un débit d’au moins 20.000/s.

Là, on finit par choper sur la vidéo un “fantôme” du dialogue plus ou moins opaque selon la chance qu’on a. Mais on l’a eu ! Et que lit-on ?

“Un site Web veut ouvrir un contenu Web en utilisant ce programme sur votre ordinateur” et en dessous : Nom: Composant de saisie tactile ou avec sty…, Editeur: Microsoft Windows.

Le nom du composant n’est pas complet mais on a compris de ce quoi il s’agit. Silverlight, le plugin, au moment du chargement (car la première instruction de l’appli n’est pas encore atteinte, ce que prouve le debugger) doit forcément inspecter la machine pour savoir s’il y a de la vidéo, du son, et tous les périphériques ou facilités utilisées par le plugin. Parmi celles-ci se trouve vraisemblablement le multitouch et la gestion du stylet.

C’est à ce moment que le fameux dialogue est activé pour me demander si je donne le droit ou non à ce module de s’activer. Normalement on dispose sur ce genre de dialogue d’une case à cocher permettant d’indiquer si on souhaite ne plus voir la question.

Hélas, comme IE 8 semble avoir un léger bug, ce fichu dialogue est totalement incessible, on le voit à peine quand on shoote l’application. Et encore faut-il la ruse de la vidéo pour lire de quoi il s’agit.

Comment autoriser l’application bloquante ?

Second problème alors : comment autoriser le programme en question (la gestion du stylet) alors même que le dialogue et sa case à cocher ne sont pas accessibles ?

Réponse : en plongeant dans les arcanes de la gestion de sécurité de IE 8…

Et là, ce n’est pas de la tarte… J’aime bien IE, mais ce n’est pas d’une grande limpidité dès qu’on aborde ce genre de question.

Je vous fait grâce des multiples recherches sur le Web pour arriver à trouver une réponse utilisable. Que je vais maintenant vous exposer car ça peut servir ! (et pas seulement avec un écran multitouch, je suppose que le bug du dialogue doit se voir dans d’autres cas).

Pour faire simple, IE range dans la registry la liste des programmes ayant des droits faibles ainsi que la règle d’élévation de droit qui doit être appliquée. Comment certaines applications arrivent dans cette première liste, c’est un mystère que je n’ai pas essayé d’éclaircir, ce genre de plomberie en informatique me donnant rapidement la nausée. Donc, il existe dans la registry une première liste, elle se trouve là :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\

C’est une liste d’ID, donc de GUID. Il faut la balayer pour lire les clés qui correspondent afin de localiser le programme dont on veut changer les droits. (La registry doit être ouverte en mode administrateur cela va sans dire).

Pour ce qui est du stylet, j’ai fini par trouver le coupable, c’est le programme “wisptis.exe” qui se trouve dans %SystemRoot%\System32. Les clés d’un ID sont AppName, le nom de l’appli, ici celui de l’exe (ce qui ne simplifie pas la recherche vu à quel point le nom n’est pas parlant), AppPath, le chemin que je viens d’indiquer et enfin Policy, un DWord codant l’autorisation.

Vous trouverez des explications ici : http://www.hotline-pc.org/mode-protege.html#

Une fois l’application localisée dans cette première liste on a la moitié de la solution. Changer la Policy à ce niveau ne semble pas avoir d’effet (immédiat en tout cas).

Il faut savoir qu’en réalité, pour l’utilisateur courant, IE stocke une seconde liste, similaire, dans une autre clé de la registry :

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy

L’astuce consiste donc à créer une nouvelle clé dans cette liste en utilisant le GUID repéré dans la première liste puis de recréer à la main les clés, dont Policy à laquelle on donne une valeur dépendant de ce qu’on cherche à obtenir. Pour la gestion du stylet j’ai mis 3, qui semble donner le maximum de droits.

Je reviens sous VS, je lance mon appli SL, et là, Ô magie… mon appli s’affiche et IE ne pose plus l’infamante question cachée…

Et ça marche !

Problème résolu. Comme on ne peut pas dire que la solution est évidente, je pense que la partagée ici sera un jour utile à quelqu’un.

Visiteur qui tombera au hasard d’une recherche Bing ou Google sur cette page et qui gagnera quelques heures de ton précieux temps, n’hésite pas à me laisser un message, ça fait toujours plaisir ! Quant aux fidèles lecteurs de Dot.Blog, le jour “J” j’espère que vous vous rappellerez que ce billet existe !

Et pour d’autres infos le mieux c’est : Stay Tuned !

Une dernière info : Le multitouch de l'écran utilise une barrière infrarouge visiblement, c'est à dire que les doigts ou le stylet coupe une grille infrarouge invisible. Ca marche vraiment bien. Sauf qu'en cette époque estivale, les mouches arrivent ! Et dans ma campagne elles ne sont pas en retard ! Hélas quand une mouche se pose sur l'écran : elle clique ! Ce qui fiche un beau bazard parfois ! Prévoyez ainsi avec l'achat d'un écran de ce type un désinsecteur électrique qui grillera tous ces nuisibles qui prennent votre écran pour un tarmark ! Je sais ça fait un peu rire comme truc... mais le geek n'a pas que des aventures palpitantes, il doit aussi combattre, outre les bugs, les mouches et autres diptères !

Fichiers PFX de signature de projet Visual Studio / objet déjà existant après migration Windows 7

Vous l'avez compris, l'entrée de blog d'aujourd'hui ne parle pas de Silverlight ni d'autres sujets technologiques passionnants mais d'un problème très ennuyeux intervenant après la migration sous Windows 7. Cela concerne les projets signés numériquement sous Visual Studio, ceux possédant un fichier PFX donc.

Une fois cette migration effectuée, tout semble tellement bien marcher que vous lancer fièrement Visual Studio sans vous douter du complot sournois qui se trame contre vous et qui se révèlera au moment où vous tenterez d'ouvrir une solution contenant des projets signés... Vous allez me dire, l'attente est courte. En effet, il est rare d'ouvrir VS juste pour le plaisir de le regarder, assez rapidement, même pour les plus lents d'entre nous, on finit par faire Fichier / Ouvrir (les plus créatifs préférant Fichier / Nouveau, mais ce n'est pas le sujet du jour).

A ce moment là, tous les projets signés déclenchent une importation du fichier PFX (même si vous êtes toujours sur la même machine et que rien n'a changé, n'oubliez pas que cette machine vient de migrer de Vista à 7 !). Comme vous êtes un développeur honnête, vous connaissez bien entendu les mots de passe des fichiers PFX de vos projets. Donc pas de problème vous tapez le mot de passe. Bang ! Erreur "l'objet existe déjà" (Object already exists). Et pour peu que votre solution contienne des dizaines de projets, ce qui est mon cas assez fréquemment, vous allez boucler sur cette séquence pour tous les fichiers PFX. A la fin vous pourrez travailler sur votre solution, mais à toute tentative de compilation vous vous reprendrez la même séquence : importation de la clé, demande de mot de passe, échec pour cause d'objet existant, etc pour chaque projet signé.

C'est un peu gênant... Mais il existe une raison et une solution !

La raison, en tout cas pour ce que j'en ai vu, c'est que la migration vers W7 modifie les droits du répertoire dans lequel sont cachés les clés importées. Pourquoi ? Je n'en sais rien et pour l'instant je n'ai rien trouvé sur le Web à ce sujet.

En tout cas, le problème étant identifié, il existe une solution : changer les droits et s'approprier le dit répertoire. Ca peut être plus compliqué que prévu, en tout cas j'ai galéré un peu (j'avoue franchement ne pas avoir un niveau d'expert en matière de gestion de sécurité sous Windows). En effet il faut déjà trouver le répertoire en question. (roulements de tambours) c'est... c'est... C:\Users\All Users\Microsoft\Crypto\RSA

Maintenant que faire... Clic droit sur le répertoire (dont l'image possède un petit verrou d'ailleurs, verrou qui disparaitra en fin de manip), onglet sécurité et on essaye de s'approprier tout ça. Ca plantouille car Windows répond qu'on n'a pas les droits sur xxxx (à remplacer par le nom imbuvable de chaque fichier de ce répertoire, justement ceux posant problème).

Bref, il faut y aller à la main. On entre dans le répetoire et on fait un clic droit / sécurité sur chaque fichier. Certains laissent voir la page Sécurité immédiatement. Laissez tomber. Mais un certain nombre d'autres fichiers affichent un message vous indiquant que vous n'avez pas le droit de voir l'onglet Sécurité ! Heureusement Windows vous permet de vous les approprier, donc d'en devenir le propriétaire (au passage je vois mal l'intérêt d'interdire un truc en proposant de l'autoriser, je vous l'ai dit, je ne suis pas un expert en Sécurité Windows !). C'est ce que j'ai fait pour chaque fichier. En fin de manip j'ai recommencé la modification des droits sur le répertoire lui-même, et là c'est passé. Plus de petit verrou affiché dans le symbole dossier.

Et immédiatement, Visual Studio ne redemande plus l'importation des clés. Ca remarche. Ouf !

Je suis convaincu que je m'y suis pris comme un pied pour régler le problème (il doit y avoir plus simple et plus propre que de devenir propriétaire de chaque fichier un par un), en tout cas ça règle bien le problème qui avait été bien identifié : problème de droits sur le répertoire des clés.

Pour l'instant c'est la seule surprise que j'ai eu en migrant cette machine de Vista à Windows 7. Le reste marche très bien et on ne perd rien ce qui est très appréciable (comme j'aurai aimé que cette option de migration sans douleur existe sur les anciennes versions de Windows !).

J'espère que le récit de cette mésaventure (et surtout sa solution) évitera à certains de perdre quelques heures... Si oui, n'hésitez pas à me le dire, ça fait toujours plaisir de savoir qu'un billet a été utile !

Et sir parmi vous il y en a qui sont plus doués que moi niveau sécurité Windows, qu'ils n'hésitent pas à indiquer la "bonne" manip pour arriver au résultat je modifierai en conséquence le présent billet...

Dans tous les cas, Stay Tuned !

Security Essentials enfin disponible ! (un anti virus gratuit)

Il y a un bon moment déjà (nov 2008) je vous parlais dans le billet "Morro .. Vache ? (ou les nuits blanches d'Avast, McAfee et Symantec)" du projet de Microsoft de rendre sa solution de sécurité One Care gratuite, notamment la partie anti-virus. En juin 2009 je vous annonçais (dans le billet "Microsoft Security Essentials en bêta") que la solution Security Essentials était passée en phase béta, mais uniquement aux USA.

Désormais vous aussi vous pouvez utiliser Security Essentials gratuitement ! Simplement en vous rendant sur le site de Security Essentials et en téléchargeant le logiciel. Il existe des versions localisées (en Français entre autres) et l'installation s'effectue en un clin d'oeil. Après le téléchargement des mises à jour et un balayage rapide de vos disques, SE va s'occuper de tous les virus, malwares et autres spywares qui veulent saboter votre PC.

Comparativement à la meilleure solution gratuite alternative utilisée jusqu'à maintenant, Avast, Security Essentials est moins gourmand, plus efficace, mais en revanche s'occupe de moins de choses. Par exemple Avast utilise 7 processus différents pour le mail, les sites web filtrés (anti pub), etc. Lorsqu'on utilise S.E. on ne dispose plus de ces petits avantages qu'on retrouvent soit avec des logiciels gratuits supplémentaires, soit en configurant correctement son PC et son browser !

Personnellement j'ai opté pour cette dernière approche suivant le principe que toute solution de sécurité fiable se doit d'être simple avant d'être sophistiquée... Ainsi, en paramétrant correctement IE8 et le pare-feu de Windows, sans parler bien entendu du paramétrage de la box internet, on arrive à une sécurité certainement aussi totale qu'avec 50 logiciels ultra sophistiqués...

Dans tous les cas, avec Security Essentials, Microsoft s'invite dans le petit monde des anti virus gratuits. Nul doute que la surenchère que cela va imposer à ses concurrents va mettre un coup de pied dans la foumilière un peu trop tranquille qu'était devenu ce marché des anti-virus !

Sortez couvert !

(et Stay Tuned, cela va sans dire :-) )

Microsoft Security Essentials en bêta

Dans un billet de novembre (Morro .. Vache ? (ou les nuits blanches d'Avast, McAfee et Symantec)) je vous parlais de la venue prochaine d'une solution anti-virus gratuite de Microsoft issue de One Care dont la commercialisation s'est arrêtée il y a quelques jours.

On connaît maintenant le nom de cette solution "Microsoft Security Essentials". Pourquoi "essentials", parce qu'il ne s'agit pas d'une usine à gaz intégrant plusieurs outils mais d'un anti-virus / anti-malware simplifié pour pouvoir tourner sur toutes les plateformes notamment les netbooks tellement en vogue ces temps-ci.

Du notebook à la station de travail sous Windows 7, "MSE" semble miser sur une faible consommation mémoire et ressources CPU tout en offrant ... l'essentiel : une protection temps réelle (bouclier) et par scan à la demande contre les virus et autres logiciels malveillants.

Totalement gratuit, MSE se pose en concurrent direct d'Avast personal ou d'autres produits de même type. MSE ne contient qu'un anti-virus car Windows propose déjà un Firewall depuis longtemps. Les concurrents de Microsoft ont en tout cas des soucis à se faire ! 

MSE devrait être diffusé en bêta dès demain, 23 juin depuis le site Microsoft Connect. [EDIT 1/7: Calmons notre joie, il semblerait en réalité que la bêta ne soit disponible dans un premier temps qu'aux US. Rien de neuf pour l'instant sur Microsoft Connect France ni sur le portail de securité US. Attendons encore un peu...]

La page d'accueil de MSE

Identity for .NET Application - la gestion des identités sous .NET

L'une des conférences qui m'a le plus marqué durant les TechEd tient tout autant de la qualité de son speaker qu'à son contenu, trop souvent négligé par les développeurs.

ARC204 - Identify for .NET Application : A Technology overview

La gestion des identités se limite dans 95% des cas à un simple "login", un coupe "nom d'utilisateur / mot de passe" géré par l'application ou la base de données. C'est le cas de la majorité des applications de bureau mais aussi des sites internet.
Simple à mettre en oeuvre, cette solution est malheureusement assez inefficace, voire dangereuse puisque grâce à elle le fishing a pu prendre l'essor qu'on lui connaît...

Une conférence passionnante sur un sujet difficile

David Chappell s'est ainsi attaqué à un sujet difficile, la sécurité informatique, et ce dans les conditions les pires pour un conférencier : un sujet uniquement verbal, sans jolie démo ni code. Parler de technique brute, de façon intelligente et sans endormir l'auditoire dont 80% au minimum n'est pas anglophone de naissance... Un sacré challenge parfaitement relevé par David. Ne pas s'ennuyer une minute sur un tel sujet réclame du speakler un pouvoir de conviction et un charisme certain. Un coup de chapeau à David donc.

Mais David n'a pas fait que bien parler, il a aussi, et surtout, fait un exposé clair sur la gestion des identité et ce que le framework pouvait nous proposer pour aller plus loin que le simple "login".

Login vs Identité

Le login ne permet qu'une seule chose côté application : s'assurer que l'utilisateur .. connaît le login ! Trop d'informaticiens font un amalgame dangereux en déduisant un peut vite que cela connaître le login signifie connaître l'utilisateur. Le vol de login, qu'il s'agisse du fishing sur internet ou bien par d'autres moyens, est d'une simplicité déconcertante et s'appuie justement sur cette erreur de raisonnement des informaticiens : l'utilisateur connaît le login, c'est donc bien la même personne.

Erreur, grave erreur.

Ce qu'une application sécurisée doit connaître c'est l'identité de l'utilisateur. Et une identité n'est pas un login facilement utilisable par d'autres personnes.

De l'utilité de connaître l'identité d'un utilisateur

Connaître l'identité de l'utilisateur permet à l'application de s'adapter, notamment de trois façons :

  • L'autentification (je sais que c'est Oliver qui est devant son clavier et non par Albert)
  • La gestion des autorisations (Olivier peut accéder à la comptabilité, Albert ne peut qu'accéder aux fiches clients)
  • La personnalisation (Olivier préfère telle présentation des informations, Albert une autre)

Personnalités multiples

Nous sommes tous finalement atteint de ce syndrôme... Nous fournissons des identités différentes selon le contexte. Le plus souvent seul notre nom d'utilisateur est communiqué, parfois d'autres informations (nom réel, adresse postale, ...). Ainsi, votre fiche sur un site de vente contiendra votre adresse facturation et celle de livraison, alors que votre fiche sur un site communautaire contiendra la liste de vos hobbys, le nom de votre chat, etc...

Une identité ?

Une identité n'est donc finalement qu'un ensemble d'information concernant "quelque chose". Car les humains ne sont pas les seuls à posséder une identité, des programmes, des ordinateurs, des périphériques, des entreprises, etc, peuvent posséder une identité, donc un ensemble d'informations permettant de les identifier de façon fiable.

Token

Une identité peut ainsi être vue comme un ensemble de token. Un token est un ensemble d'octets, une suite d'information sur l'identité en question. Le token représente 1 ou plusieurs  "claims". je n'ai pas encore trouvé d'équivalent français convaincant... mot à mot un "claim" et une "réclamation". Dans le contexte il s'agit d'une information particulière qui peut être demandée (réclamée) sur l'identité en question.

Format de Token

Les tokens peuvent suivre n'importe quel formalisme. Par exemple il peut s'agir de tickets Kerberos. C'est un format intéressant mais il est figé et ne supporte pas les extensions.

Un autre format classique c'est le couple username/password. On a vu ses limites plus haut.

Enfin on peut utiliser un formalisme plus ouvert et plus puissant pour représenter les tokens : Security Assertion Markup Language, ou SAML.

SAML

SAML suit le formalisme XML, sa première vocation est d'être utilisé dans un contexte Web mais il est parfaitement utilisable sous Windows ou d'autres plateformes. S'agissant d'un format ouvert basé sur XML il peut servir à véhiculer n'importe quel "claim" et peut ainsi servir de base à un véritable système de gestion des identité standardisé.

Identity Provider

Un fournisseur d'identité est une autorité qui produit des claims sur des identités.

Par exemple, qui peut mieux que l'employeur certifier que untel est bien salarié de l'entreprise. Dans ce cas l'employeur est un fournisseur d'identité qui peut fournir des "claims" tels que : nom, adresse, numéro de sécurité sociale, etc.

Mais très souvent, et notamment sur internet, nous sommes tous notre propre fournisseur d'identity ! Nous nous créons des fiches, des comptes, fournissons des informations sur notre personne sous notre seule autorité.

On conçoit bien que si être son propre founisseur d'identity est particuluièrement pratique, cela ne permet en aucun cas à l'application qui se trouve en face de savoir réellement qui nous sommes. Rien ne m'interdit d'ouvrir un compte sur un forum de discussion au nom de Peter Pan ou de mon voisin. Personne ne peut le vérifier.

Il est donc nécessaire dans certains cas d'utiliser un fournisseur d'identité fiable et surtout reconnu comme tel par l'application qui doit vérifier l''identité des utilisateurs.

Deux catégories d'applications

Il existe deux catégories d'applications vis à vis de la gestion des identités :

  • Celles qui sont "domain based" (basées sur domaine), ce sont les plus courantes. Elle peuvent gérer les tokens dans un format fixe, par exemple les applications Windows qui accèptent les tickets Kerberos.
  • Celles qui sont "claim bases" (basées sur des "claims"). Elles peuvent potentiellement accepter plusieurs formats de token, par exemple une application Windows qui accèpte les claims en SAML.

Ces dernières applications représentent le futur.

La notion de forêt

Une forêt d'application est un ensemble de logiciels fonctionnant dans un "éco-système" donné. Une forêt définit un scope (une porté) pour les identificateurs (ID scope). Dans une forêt il n'y a généralement qu'un seul ID P (Identity Provider). Toutes les applications d'une forêt peuvent accéder aux et comprendre les mêmes tokens.

Pour les applications "domain bases" (basées sur un domaine), l'IDP peut être Active Directory Domain Service (AD). Il utilise les tickets Kerberos.

Les applications "claim based" (basées sur des "claims"), peuvent utiliser Active Directory Federation Service (ADFS). Les tokens sont en format SAML.

Technologie ouverte

Il faut insister sur le fait que ADFS n'est qu'un cas d'utilisation de SAML, c'est une implémentation de Microsoft mais la technologie elle-même peut être utilisée par d'autres éditeurs sur d'autres plateformes. ADFS est ainsi supporté par IBM, Oracle et bien d'autres.

La fédération

ADFS offre la notion de fédération c'est à dire la possibilité à des intervenants de se reconnaître mutuellement comme IDP valable et sincères. Cela permet à un utilisateur connu dans la forêt F1 d'accéder à des services offerts dans la forêt F2 avec une seule et même identité. On évite ainsi le maintien couteux et générateur d'erreur de multiples fiches d'identités dans plusieurs systèmes.

L'un des grands intérêts de ADFS est, par sa structure et son langage support (SAML) de pouvoir traverser aussi les frontières du matériel et des OS. Ainsi, un utilisateur identifié dans une forêt données (par exemple son domaine dans son entreprise) peut fort bien accéder à un service internet hébergé sur d'autres machines dans une autre forêt d'applications. ADFS est conçu pour facilité ce cas de figure puisque sa vocation première est le Web.

Le mécanisme

Sans entrer dans le détail des mécanismes en jeu ni jalonner ce billet de captures écran des slides de David, voici quelques clés pour comprendre les mécanismes en jeu.

Dans la vision classique, celle du simple login, c'est l'utilisateur qui envoit à l'application son couple nom/mot de passe. Ce couple peut être volé de différentes façons et l'application cible ne peut au mieux être sûr que d'une seule chose : le couple existe et est reconnu. Mais en aucun cas l'identité de l'utilisateur ne peut être certifiée.

Dans la vision "claim based", la nature des échanges est très différentes. En effet, c'est l'application qui réclame certains claims, ceux dont elle a besoin pour identifier l'utilisateur et c'est l'IDP, le fournisseur d'identité qui transmet, via le client, les token SAML (cryptés) à l'application. Dans ce schéma les tokens ne peuvent pas être volés et réutilisés car ils sont cryptés de façon différente à chaque fois. De plus, en eux même ils n'offrent pas forcément d'informations utiles hors de leur contexte (l'identité complète de l'utilisateur).

Une application par login devra stocker toutes les informations de l'utilisateur, par exemple ses préférences d'affichage, son adresse postale, etc. Dans une application 'claim based', l'application protégée réclamera le token "adresse postale" ou d'autres informations qui sont centralisée chez le fournisseur d'identité (IDP).

Cardspace

Sous .NET l'une des applications des mécanisme "claim based" est Cardspace. Son nom provient du fait que le logiciel se présente sous la forme de cartes (une image choisie par l'utilisateur) qui contiennent différentes informations. Cette gestion simple permet aux utilisateurs de gérer leurs différentes identités de façon convivial sans connaître les principes sous-jacents.

Cardspace fonctionne de base comme un IDP privé : l'utilisateur est son propre fournisseur d'identité. Toutefois Cardspace fonctionne aussi dans le cadre de fournisseurs d'identité externes ce qui rend cette solution très souple.

Cardspace peut utiliser de multiples IDP, la technologie n'est pas limitée à .NET, Vista ni même à Microsoft.

Conçu d'abord pour les applications Internet, Cardspace autorise toutes les utilisations. En mode 'single ID scope' (porté des ID simple) il permet d'accéder aux appliactions d'une forêt donnée. En mode cross scope il utilise la fédération et peut ainsi permettre l'accès à des applications de plusieurs forêts différentes.

La version 2.0 de ADFS intègrera des IDP managés.

Synchronisation des identités

Les informations d'une identité sont souvent réparties dans plusieurs endroits. Maintenir la synchronisation entre toutes les informations d'une même identité est une tâche complexes.

Pour simplifier cette gestion Microsoft propose ILM (Identity Lifecycle Manager - Gestionnaire de cycle de vie des identités). ILM peut être programmé en VB ou C# et contient des règles de gestion. Il peut être utilisé au sein d'une même organisation ou bien entre plusieurs organisations. Les sources de données peuvent être très différentes et être gérées simultanément (données sous SQL Server, sous SAP, application mainframe IBM, etc).

Les choses se compliquent forcément. Mais comme conclue David : certes cela n'est pas le plus simple, mais le problème lui-même n'est pas très simple non plus...

Conclusion

Les développeurs doivent s'intéresser de plus près à la gestion des identités car la fiabilité de leurs applications en dépend.

Il est en effet important aujourd'hui et encore plus demain de concevoir des applications acceptant des ID de scopes différents autant que de fonder la gestion des identités sur le modèle "claim based" en utilisant ADFS pour le cross-scope et Cardspace pour internet notamment.

Un papier de Microsoft peut aussi être lu sur le sujet : Digital Identity for .NET Applications: A Technology Overview.

A bientôt pour un nouveau billet .. Stay tuned !