Solution retenue

Après quelques heures de recherche, j'ai fini par retenir la solution "eID Applet SDK". La solution repose sur une applet java, elle impose donc aux utilisateurs d'avoir installé une machine virtuelle java (jdk). En outre, le navigateur doit être configuré pour interpréter le code JavaScript. Ces contraintes non-fonctionnelles ne sont pas vraiment un handicap. Java est portable sur tous les types de navigateurs et sur la plupart des systèmes d'exploitation (MS, Unix, MaxOs et une majorité des mobiles qui sortent sur le marché aujourd'hui). Le langage JavaScript est activé sur la plupart des navigateurs.

Le principe de cette solution est simple. Du côté du client, le navigateur lance l'exécution d'une applet grâce à un code JavaScript. Cette applet lit la carte d'identité électronique puis les envoie à un composant hébergé sur le serveur web. L'architecture proposée avec cette applet nécessite donc un composant dynamique hébergé sur le serveur. La technologie utilisée pour réaliser ce composant est interchangeable grâce au protocole utilisé par l'applet pour communiquer avec le serveur. Il est donc possible utiliser le langage souhaité pour le composant serveur, à condition de respecter les spécifications du protocole. A titre de preuve de concept, le source du sdk comprend notamment une solution qui illustre la manière d'intégrer cette applet java à une solution asp.net : AppletService. Cette solution n'est rien d'autre que le composant serveur nécessaire au bon fonctionnement de l'applet (composant client).

Intégration de la solution

La solution est proposée avec un fichier README qui explique succinctement les étapes. Néanmoins, quelques adaptations ont été nécessaires pour rendre cette intégration possible.
Comme énoncé dans la présentation de l'architecture, l'applet envoie les informations lues à un service hébergé sur l'hôte. Naturellement, on voudrait que le service stocke l'information reçue dans une session de navigation qui permettrait à l'affichage de la page de résultat d'aller récupérer les informations stockées dans cette session. Par défaut, asp.net gère les sessions en créant un cookie qui contient l'identifiant de session et le retourne au navigateur pendant une visite. En lisant le cookie adéquat, asp.net sait donc identifier si une requête a une session associée ou s'il faut en créer une nouvelle. Le problème est que l'applet et la page qui la contient ne partage pas leurs cookies pendant une navigation. Il est donc impossible dans l'état de partager les sessions qu'ils instancient chacun, par défaut. La méthode proposée ci-dessous permet d'outre passer cette lacune en étendant le mécanisme de résolution des identifiants de session.

  1. Réaliser un checkout de la solution sur l'ordinateur qui héberge le site web (le code est hébergé sur un dépôt subversion).

svn checkout http://eid-applet.googlecode.com/svn/trunk/eid-applet-aspx eid-applet-read-only

  1. ajouter une référence au projet importé, dans le projet web qui doit l'héberger.
  2. une page de résultat "AuthnResult.aspx" affichera des données stockées en sessions:
<table>
    <tr>
        <th>
            Name
        </th>
        <td>
            <%=Session["Identity.Name"]%>
        </td>
    </tr>
    <tr>
        <th>
            First name
        </th>
        <td>
            <%=Session["Identity.FirstName"]%>
        </td>
    </tr>
    <tr>
        <th>
            Date of birth
        </th>
        <td>
            <%=Session["Identity.DateOfBirth"]%>
        </td>
    </tr>
</table>
  1. Le code ci-dessous permet d'exécuter la lecture la carte dès le chargement d'une page (ex. ReadDatas.aspx).
<script type="text/javascript" src="https://www.java.com/js/deployJava.js"></script>
<script type="text/javascript">
    var attributes = {
        code: 'be.fedict.eid.applet.Applet.class',
        archive: 'eid-applet-package.jar',
        width: 400,
        height: 300
    };
    var parameters = {
        TargetPage: 'AuthnResult.aspx',
        AppletService: 'applet-service.aspx?sid=<%= Session.SessionID %>',
        BackgroundColor: '#ffffff'
    };
    var version = '1.6';
    deployJava.runApplet(attributes, parameters, version);
</script>
  1. # l'attribut "archive" pointe vers l'applet qui doit être chargée dans le navigateur (c'est un lien relatif vers le fichier à télécharger sur l'hôte).
  2. # le paramètre "TargetPage" pointe vers la page qui s'affichera après exécution de l'applet. il s'agit ici de la page définie dans le point précédent.
  3. # le paramètre "AppletService" pointe vers le service auquel l'applet communiquera les informations d'identification.
  4. Dans le point précédent, j'ajoute un paramètre à la requête vers le service (sid), il s'agit de l'identifiant de session de la page qui héberge l'applet. le serveur peut relancer la session adéquate grâce à cet identifiant et ne pas en créer une nouvelle, propre à l'applet. Pour que cela fonctionne, il faut étendre le gestionnaire d'identifiants proposé par défaut:
namespace AppletService
{
    class CustomSessionManagerId : SessionIDManager, ISessionIDManager
    {
        public new string GetSessionID(HttpContext context)
        {
            if (!string.IsNullOrEmpty(context.Request.QueryString["sid"]))
                return context.Request.QueryString["sid"];
            else return base.GetSessionID(context);
        }
    }
}

Cette classe vérifie si un paramètre "sid" est donné en paramètre à une requête requête. Le cas échéant, cet identifiant est retourné et permettra à IIS de charger la session associée. Dans le cas contraire, le comportement par défaut est exécuté.

Pour imposer ce comportement au site web, il faut déclarer ce nouveau gestionnaire de session, en le déclarant dans le fichier web.config, dans l'élément <system.web> :

<sessionState sessionIDManagerType="AppletService.CustomSessionManagerId, AppletService" />
  1. Dans ce fichier web.config, il reste à déclarer les services auxquels l'applet va s'adresser (composants serveur).
<httpHandlers>
   <add path="/applet-service.aspx" verb="*" type="Be.FedICT.EID.Applet.Service.AppletService, AppletService" validate="true"/>
   <add path="/applet-authn-service.aspx" verb="*" type="Be.FedICT.EID.Applet.Service.AuthnAppletService, AppletService" validate="true"/>
</httpHandlers>

Le premier handler "applet-service.aspx" pointe vers un service qui permet la lecture des données sur la carte (AppletService), c'est le seul testé. Le second handler "applet-authn-service.aspx" pointe vers un service qui permet l'authentification d'une personne grâce à sa carte d'identité (AuthnAppletService).

Note. Le fichier README ne préconise pas l'usage de l'extension ".aspx" aux handlers, je préfère le faire par convention car on a pas toujours la main sur la configuration iis d'un serveur et parfois seule certaines extensions sont exécutées par les handlers asp.net (ex. .aspx, .asmx par défaut. contre-ex. .gif, .html par défaut). De ce fait, certaines configuration empêche l'exécution d'un fichier sans extension autorisée.

En principe, l'exemple proposé ci-dessus doit permettre d'afficher trois informations d'une carte d'identité électornique en suivant le scénario suivant:

  1. charger la page "ReadDatas.aspx"
  2. l'applet, dont elle ordonne l'exécution chez l'utilisateur, envoie les informations lues au service applet-service.aspx
  3. le service applet-service.aspx sauvegarde les données en session
  4. l'applet redirige l'utilisateur vers la page "AuthnResult.aspx"
  5. la page "AuthnResult.aspx" lit des données collectées en session pour les afficher à l'utilisateur.

Conclusion

J'ai mis du temps avant de trouver la librairie adéquate, je trouve que le sujet est encore trop émaillé sur la toile. Cependant, mes recherches ont pu me mener en deux jours à conclure qu'il est aujourd'hui possible de lire une carte d'identité électronique de manière portable et interopérable, de manière interactive et efficace.

Conclusion personnelle

Toute cette facilité de mise en place mène à se poser des questions d'éthiques. Quand je vois des services du gouvernement se proposer comme parti tiers d'authentification auprès d'applications de gestion, afin de permettre à des utilisateur de s'identifier avec la carte d'identité, je me demande où s'arrête encore la vie privée si tout est lié à cette carte. Imaginez les opportunités!!! Elles sont telles qu'on peut craindre à court terme qu'elles priment sur une bonne gouvernance de la vie privée...

Téléchargements relatifs