Dot.Blog

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

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 !