Dot.Blog

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

BYOD, CYOD, MAM, MDM, MIM vive les unités mobiles !

[new:30/09/2013]Dans la continuité des billets consacrés au développement cross-plateforme il est important de se questionner sur la gestion des smartphones et tablettes en entreprise. Le BYOD et le CYOD sont-ils des réponses aux besoins conjoints des entreprises et de leurs salariés ? Quels sont les possibilités, les risques et les solutions ? Qu’est-ce que le MDM, le MAM et le MIM ?Plus...

Les pièges de la classe Random

[new: 14/06/2010] Générer des nombres aléatoires avec un ordinateur est déjà en soit ambigu : un PC est une machine déterministe (heureusement pour les développeurs et les utilisateurs !) ce qui lui interdit l’accès à la génération de suites aléatoires aux sens mathématique et statistique. Toutefois il s’agit d’un besoin courant et .NET propose bien entendu une réponse avec la classe Random. Plus...

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 !

Patterns & Practices : les guides de bonnes pratiques à connaître par coeur !

Dans la jungle du Framework et de tous ses projets satellites qui sortent au rythme d'une rafale d'AK47 comment un pauvre développeur isolé peut-il intégrer et digérer en quelques heures (en plus de son travail quotidien) des centaines, voire des milliers d'années-homme de librairies, technologies, outils et langages produits par Microsoft ?

C'est une véritable question. Dans mon propre travail de conseil je m'oblige à une réserve de 30% de mon temps uniquement dédié à la veille technologique, c'est à dire qu'un tiers de mon temps n'est jamais vendu, je me le réserve pour apprendre, un luxe indispensable mais coûteux en chiffre d'affaire potentiel perdu. De plus c'est un mode de fonctionnement que seul un dirigeant d'entreprise ou un indépendant peut s'offrir. Et malgré ce privilège tous les jours je mesure l'étendue de mon ignorance sur certains aspects du Framework avec la désagréable impression que plus je rame plus la côte s'éloigne ... Je suis certain de n'être pas le seul à ressentir cette sensation !

Il y a ceux qui ont d'emblée choisi de se spécialiser. Ils connaissent tout ou presque de Windows Forms, de WPF, ou de Silverlight mais ignore tout des dizaines d'autres éléments du Framework. Impasse sur ASP.NET, Ajax, MVC, Entity Framework, etc, etc. Chacun fait alors son petit marché n'ayant au final qu'une vue très restreinte sur le Framework, et, de fait, loupant souvent d'excellentes choses. Hélas une journée n'a que 24h, et pour avoir essayer par tous les moyens de contourner sans succès cette terrible réalité, je peux affirmer que travailler, même beaucoup, même trop, n'est pas forcément la solution. Seule Zenon d'Elée arrivait dans son paradoxe à faire gagner une tortue face à Achille ! Quand l'adversaire est en supériorité, la force brute est inutile, il faut ruser...

Microsoft a conscience de ce problème. Qu'il s'agisse des petites vidéo "how do I", des multiples conférences qui se tiennent régulièrement, de la documentation très fournie de MSDN, de l'excellent magazine MSDN toujours riche d'articles de haute tenue technique, et de bien d'autres actions en faveur de la diffusion de la connaissance sur ses produits, Microsoft fait beaucoup pour nous aider à appréhender l'étendue de sa gamme.

Si cet effort louable est important, on peut toujours en réclamer plus. Par exemple une certaine décentralisation de toutes ces informations fait que peu de gens connaissent tous les "points d'entrée" utiles de ces informations. Gageons que Microsoft en a aussi conscience et que des efforts supplémentaires seront réalisés pour aider le développeur "à s'y retrouver dans les informations qui permettent de s'y retrouver" dans les produits...

Patterns & Practices

Tout cela pour vous parler aujourd'hui des Patterns & Practices. Il s'agit d'un ensemble de recommandations et de code mis à disposition gratuitement sur CodePlex. Bien connaître ces "patrons et pratiques" peut vous aider à mieux tirer partie du Framework sans pour autant y consacrer vos nuits.

Pour obtenir la liste de tous les projets gravitant autour de ce concept de "patterns & practices" allez sur CodePlex et chercher cette expression. Vous pouvez aussi directement accéder à tous les projets pertinents par le tag du même nom (colonne de droite sur CodePlex).

Les projets clé

Il est bien entendu très difficile de créer un ordre de priorité dans tous les projets "patterns & practices", selon ce que vous développez, l'urgence de regarder tel ou tel projet sera plus ou moins grande. Mais je vais tenter une petite sélection de ceux qui, à mon sens, sont à connaître absolument.

App Arch Guide 2.0 Knowledge base

http://www.codeplex.com/AppArch 

Ce projet initié par JD Meier, Jason Taylor et Prashant Bansode regroupe de nombreux documents et vidéos dont le but est d'expliquer "How to put the legos together", ce dont je parlais plus haut : savoir comment utiliser correctement toutes les briques de constructions du Framework pour en faire quelque chose.

The purpose of the Application Architecture Guide 2.0 is to improve your effectiveness building applications on the Microsoft platform. The primary audience is solution architects and developer leads. The guide will provide design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.

Ce projet est certainement le premier point d'entrée que vous devez connaître. Sa vision globale de l'architecture des applications vous aidera à prendre de meilleures décisions.

Application Architecture Guide 2.0 (le livre)

http://www.codeplex.com/AppArchGuide

Ce guide fournit des guides architecturaux pour la création d'applications .NET. Les principaux types d'applications sont étudiés et de nombreuses solutions sont proposées.

Le livre complète la "App Arch Guide 2.0 Knowledge base" décrite ci-dessus.

Enterprise Library

http://www.codeplex.com/entlib

http://msdn.microsoft.com/fr-fr/library/cc467894(en-us).aspx

L'Enterprise Library est une collection de blocs applicatifs qui ont été conçus pour assister le développeur dans son travail. Il s'agit de code mais d'une certaine façon ce code constitue un guide des bonnes pratiques.

Le code source est fourni avec une documentation. EL peut être utilisé tel quel ou bien modifié ou étendu.

Constitué de plusieurs "blocs", EL est une vraie mine d'or. Gestion du caching, cryptographie, accès aux données, gestion des exceptions, logging, sécurité, des solutions pratiques, génériques et éprouvées sont apportées à chacun de ses sujets.

Un "must have" donc. (et surtout un "must understand" !).

Web Client Software Factory

http://www.codeplex.com/websf

le WCSF fournit un ensemble de directives pour les architectes et les développeurs d'applications Web. La factory inclue des exemples, du code réutilisable et un ensemble de guidlines pour automatiser les tâches clé du développement sous Visual Studio. Pour ceux qui connaissaient, WCSF remplace UIP (User Interface Process Application Block). WCSF supporte bien entendu les nouveautés du Framework comme ASP.NET, Ajax ou Workflow Foundation.

A connaître dès lors qu'on veut développer des applications Web...

Composite WPF and Silverlight

http://www.codeplex.com/CompositeWPF

Ce bloc des patterns & practices fait partie du top 5 à connaître et maîtriser. Il intègre code et guidelines nécessaires à la mise en place d'architectures suivant les best practices pour les projets de type WPF et Silverlight. Tout est bon, il faut absolument le connaître !

A noter: ce projet est aussi connu sous le nom de "Prism" (info primordiale surtout pour faire le cador à la machine à café :-) ).

Smart Client Guidance

http://www.codeplex.com/smartclient

http://msdn.microsoft.com/en-us/library/aa480482.aspx

Le Smart Client Software Factory (SCSF) est une autre guide essentiel. Guidelines et code forment un ensemble de composants réutilisables sous Windows Forms autant que WPF ou ASP.NET pour mettre en place une architecture de client intelligents composites.

Je n'ai pas eu encore le temps de plonger dans ce guide, mais du survol que j'en ai fait, il faut très certainement le regarder de plus près, les solutions proposées semblent tout aussi indispensables à connaître que les autres guides de la série "patterns & practices".

Unity

http://www.codeplex.com/unity

Encore un guide que je n'ai pas eu le temps de lire... Les longues soirées d'hiver sont un mythe : il fait nuit plus tôt mais les journées ne comptent toujours pas plus de 24h, cette expression est donc une escroquerie ! :-)

The Unity Application Block (Unity) is a lightweight extensible dependency injection container with support for constructor, property, and method call injection.

Dit comme ça, c'est un peu confus... pour tout savoir le mieux c'est de lire (le conseil vaut pour moi aussi) !

WCF Security Guidance

http://www.codeplex.com/WCFSecurity

La mise en place de services via WCF peut se faire de façon très naïve... ou de façon professionnelle, c'est à dire en gérant correctement la sécurité ! Ce guide fait le tour de la question et propose des guidelines autant que du code pour mieux sécuriser les applications communiquantes et gérer correctement les authentifications, les autorisations et toutes ces choses indispensables pour des applications mises en production.

Web Service Software Factory

http://www.codeplex.com/servicefactory

Il s'agit d'une collection d'outils, de patterns, de code source et de guidelines destinés à vous aider à construire des Web services WCF et ASMX rapidement mais en garantissant la meilleure fiabilité possible.

Indispensable comme le reste...

Guidance Explorer

http://www.codeplex.com/guidanceExplorer

Voici peut être un moyen de s'y retrouver un peu mieux parmi toutes les guidelines ! le Guidance Explorer, comme son nom l'indique, est un outil d'exploration des guidelines. Une fois installé il se met à jour via le Web.

Centralisant bon nombre de guides et simplifiant l'accès à l'information, Guidance Explorer est l'une des premières choses à installer à côté de Visual Studio !

MS Health Common User Interface

http://www.codeplex.com/mscui

C'est un peu l'ovni de cette liste et même un vrai ovni à part entière dans tout le Framework et les guidelines. On se demande pourquoi Microsoft a investi dans cette branche très spécialisée plutôt qu'une autre. Le MSCUI est en effet un ensemble de guidelines, de code et de composants permettant de réaliser des application orientées médical. Composants WCF, Silverlight ou autres, c'est un ensemble incroyable quantitativement et qualitativement. Ayant été l'un des pioniers de l'informatique médicale en France avec la gamme de logiciel Hippocrate je connais particulièrement bien la question et j'ai été bluffé par ce que propose MS avec MSCUI. Avec cet outil un bon développeur peut assez rapidement mettre en place des solutions tout à fait honorables capables de concurrencer les principaux logiciels médicaux du marché...

Si le médical n'est pas votre branche, MSCUI ne vous intéressera que peu dans la pratique, mais regardez tout de même comment cela est fait et comment les composants se présentent, ergonomiquement et fonctionnellement c'est un beau travail.

Conclusion

Si ce tour d'horizon n'est pas exhaustif il contient malgré tout le top des guidelines et outils à connaître pour développer sereinement des solutions basées sur des patterns éprouvées. Ne pas réinventer la roue, mettre rapidement en place la bonne architecture d'un projet c'est déjà s'assurer à 50% de sa réussite.

Si les soirées d'hiver ne comportent pas plus d'heures que celles d'été, la froidure incite moins à sortir et à flâner qu'en août, profitez-en pour rester au chaud en vous plongeant dans les Patterns & Practices !

N'oubliez pas ce vieux proverbe qui nous vient du fond des âges :

"L'hiver, qui bouquine Patterns & Practice,
 l'été, produit du code qui glisse !"

Et Stay Tuned !

Debug ou Cracking ? Des outils .NET à la frange des deux mondes...

Un debugger comme celui de Visual Studio n'est que rarement comparé à un outil de cracking pour la bonne raison que son utilisation s'effectue systématiquement (ou presque) sur des applications en cours de développement / maintenance, impliquant que l'opérateur du debug a le droit d'accéder aux sources. Mais comment catégoriser les outils qui suivent ?

Les trois outils dont je vais vous parler aujourd'hui se situent tous à la limite entre debugging et cracking, non pas forcément par la volonté de leur concepteur mais bien par leur nature. Il s'agit en fait d'applications autonomes capable de percer les secrets d'applications .NET en cours de fonctionnement (2 outils sur les 3 pour être précis, l'un est un visualisateur pour VS).

Outils de debug très intéressants ne nécessitant pas forcément l'installation de VS sur la machine, ces applications sont des compagnons à mettre dans votre boîte à outils. Utilitaires autonomes pouvant être utilisés par n'importe qui, l'existence même de ces outils ouvre la voie à un cracking autrement plus simple que l'utilisation d'outils comparables pour Win32. La haute cohérence de .NET et sa "lisibilité" rendant l'opération moins ardue.

Anges ou Démons ?

Les objets n'ont pas d'âme (si tant est que les êtres vivants en aient une) mais surtout ils n'ont pas de conscience. De tels outils ne peuvent donc être taxés en eux-mêmes d'être "diaboliques". C'est l'Homme qui appuie sur la gâchette que l'on juge et condamne, non les particules de poudre et l'amorce ayant permis à la balle de sortir de l'arme... A vous d'en faire bonne usage donc. Le plus important étant même de savoir que de tels outils existent pour éventuellement réfléchir, pour des applications sensibles, à comment rendre inopérantes des attaques qui utiliseraient cette approche.

Les outils

Crack.NET

Ecrit par Josh Smith, cet outil est un "logiciel de débogage et de scripting qui vous donne accès à l'intérieur de toute application .NET desktop" (d'après la traduction de la présentation de l'auteur). Une fois lancé l'utilitaire permet de choisir l'application .NET à cracker (selon les termes mêmes du bouton de lancement). Visualiser la mémoire, traverser les grappes d'objets, il est ainsi possible de tracer l'état de l'application "victime". Imaginons un mot de passe de connexion à une base de données ou à un Service Web, même si l'exécutable est obfusqué, même si les valeurs sont cryptées sur disque, il devient possible de lire ces dernières en clair une fois en mémoire de l'application.

On flirte avec la limite cracking / debugging, mais encore une fois l'intention coupable ou non est du ressort de la conscience de l'utilisateur de l'outil.

Un outil à posséder donc.

http://joshsmithonwpf.wordpress.com/cracknet/

Mole

Mole est un outil un peu différent, c'est un visualisateur pour Visual Studio qui permet de plonger dans les arborescences d'objets, de visualiser les valeurs mais aussi de les modifier.

En tant qu'outil pour VS la frontière du cracking s'éloigne, celle du debugging étant plus clairement visible.

"Mole a été conçu pour permettre au développeur non seulement d'afficher des objets ou des données, mais aussi de percer et visualiser les propriétés de ces objets, puis de les modifier. Mole permet un nombre illimité d'objets et de sous-objets en cours d'inspection. Quand Mole trouve un objet IEnumerable, les données peuvent être visualisées dans une DataGridView ou dans une grille de propriétés. Mole gère facilement les collections qui contiennent plusieurs types de données. Mole permet aussi au développeur de voir les champs non publics de tous les objets. Vous pouvez apprendre beaucoup sur le framework. NET en inspectant ainsi les données de vos applications."

http://karlshifflett.wordpress.com/mole-for-visual-studio/

Snoop

"Snoop est un utilitaire conçu pour simplifier le débogage visuel des applications WPF à l'exécution."

Un peu comme Crack.NET il s'agit ici d'un utilitaire autonome permettant d'inspecter une application WPF lors de son exécution. Cela peut s'avérer très utile en debug, mais peu présenter certains risques entre de mauvaises mains...

 

En tout cas, si vous développez des applications WPF, il faut avoir Snoop, il peut fournir une aide appréciable en plus du debug sous VS.

http://blois.us/Snoop/

Conclusion

Objets inanimés avez-vous une âme ? Questionnait Lamartine. Les objets numériques qu'il n'a pas connus n'en ont ni plus ni moins que les objets physiques en tout cas. Cracker ou debugger, c'est à vous de voir avec votre conscience, mais dans tous les cas, il est important de connaître l'existence de tels outils qui peuvent s'avérer bien pratiques dans certaines circonstances.

Stay Tuned !

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 !