eIDAS: mise en œuvre des composants STORK v1

La commission européenne doit établir cette année pour eIDAS (electronic Identification and Trust Services) les normes et protocoles de la fédération des identités (FI) continentale. Ce travail ne part pas d’une page blanche puisque e-Sens et le projet STORK  (Secure idenTity acrOss boRders linKed) préparent déjà le terrain depuis 2008.

Je souhaiterais revenir sur la première version du projet STORK et revisiter les fondamentaux. Nous découvrirons dans un prochain article les évolutions de STORK v2.

les composants de STORK v1

Globalement STORK repose sur SAML v2 au niveau des protocoles et des composants. Mais il en introduit aussi de nouveaux.

Dans une FI (fédération des identités) basée sur SAML, le dialogue s’établit uniquement entre le Service Provider (SP) et l’Identity Provider (IdP).

Mais STORK introduit deux autres composants:

• PEPS (Pan European Proxy Service) une passerelle d’échange entre les composants que nous décrirons plus loin
• AP (Attribute Provider) un fournisseur de données personnelles, qui est hérité de Liberty Alliance

Pan European Proxy Service

Pourquoi introduire une passerelle ?

1. Pour faire communiquer les différentes  implémentations des IdP nationaux sans que chacun n’embarque la spécificité des 18 autres.
    
2. Rendre compatibles l'approche centralisée comme avec SAML ou OpenI et répartie avec des logiciels clients dédiés.

Par exemple, certaines implémentations imposent un lecteur de carte, un pilote et un agent dédié, qui vont communiquer avec une infrastructure serveur. On parle alors de MiddleWare. Le PEPS est un composant ouvert, soit vers l’application (SP), on parlera de S-PEPS, soit vers le système d’identification nationale (IdP), on parlera alors de C-PEPS (C=Country).

S-PEPS et C-PEPS communiquent par un protocole commun et permettent les adaptations vers les applications et source d’identité ainsi que les moyens d’authentification. Chaque PEPS aura une spécialisation entre une application et un pays.

Pour les architectures reposant sur un MiddleWare, le PEPS permet une adaptation au client dédié sous la forme d’un V-IDP. En fait une exposition du client dédié sur une infrastructure commune.

Attribute Provider

Le fournisseur de données (AP) est une obligation dans le cadre de la mise en œuvre de la directive sur la gestion des données personnelles. En effet SAML v2 ne dispose pas de mécanisme permettant un consentement des utilisateurs sur l’utilisation de leurs informations, comme on le trouve dans oAuth.

les flux entre les composants

Voici une vision globale des composants et le sens des échanges dans une séquence d’authentification partant d’une application (SP), d’un autre PEPS ou d’un V-IdP (Virtual IDP qui est le pilote universel pour les applications liées à des systèmes d’authentification).

Nous proposons une mise en œuvre reposant sur le kit STORK 1.2.1 qui livre les composants binaires suivants:

• SP.war une application permettant de créer une requête d’authentification SAML v2 et recevoir une réponse
• PEPS.war la passerelle reliant les autres composants
• IdP.war le fournisseur d’identité et d’authentification
• AP.war le fournisseur de données personnelles

Ce kit est ancien mais STORK v2 n’a pas encore livré de binaires permettant cette mise en œuvre. Nous verrons plus loin que certains composants resteront inchangés.

la plate-forme de test

Dans notre mise en œuvre le SP du pays CA (Country A) est installé sur une machine dédiée (bzrm.spopoff.com). Les autres composants du pays CB (Country B) sont installés sur une autre machine (openam.bzrm.spopoff.com).

Le point essentiel et délicat de l’installation réside dans la déclaration des informations permettant à chacun de joindre l’autre. A la différence de SAML qui possède un système de méta données pour normaliser ces informations, STORK v1 utilise de nombreux fichiers xml dans lesquels il faut déclarer les URL des services et les certificats de signature.

Il est évident que le nombre de jointures de STORK est bien plus important que pour SAML (du fait du plus grand nombre de composant), mais la manière de le mettre en œuvre (dans cette version) est un risque. De plus, STORK est principalement orienté vers une communication entre les états membres (Country = Member State) et ne garantit pas un fonctionnement optimum au sein d’un même état. Cela me semble aussi être une restriction forte. Si le système fonctionne entre la France et l’Allemagne alors pourquoi pas dans l’Hexagone ?

Néanmoins une fois reglé l’obstacle de la configuration, le système est opérationnel pour une démonstration.

la démonstration à tester par vous même

Connectez-vous sur l’URL http://bzrm.spopoff.com:81/SP.
Choisissez CA comme pays d’origine de l’application et CB comme pays de l’identité.
Sélectionnez les attributs que vous souhaitez obtenir.
Validez le formulaire, puis le formulaire suivant qui met en évidence la requête SAML. Il faut imaginer que c’est l’application qui prendra en charge ce paramétrage.

Une première page est soumise au consentement de l’utilisateur avec le choix d’attribut du SP, dont certains peuvent être optionnels.

Une page d’authentification (xavi / creus) suivie d’une page de consentement sur les données transmises.

Enfin une page de résultat exposant la requête SAML.

capture du flux HTML

Il est possible de suivre tout le dialogue du flux au travers du navigateur comme dans cette capture. A la différence de SAML qui laisse passer une partie des échanges directement de SP à IdP.

On retrouve le cheminement du premier schéma :

• Les deux premières lignes correspondent à la fabrication de la requête, donc l’origine de la flèche 1.
• La troisième ligne à l’appel au S-PEPS.
• La quatrième ligne est le lien en S-PEPS et C-PEPS (ColleagueRequest), flèche 2.
• La cinquième ligne correspond au consentement sur le choix d’attribut, sixième et septième l’authentification (boucle flèche 2 et 3).
• La huitième ligne à la réponse de l’IdP.
• La Neuvième ligne au consentement sur les valeurs d’attribut (flèche 4 et 5).
• Puis le transfert vers le SP à travers le ColleagueResponse (de C-PEPS vers S-PEPS).

Pendant tous ces échanges, des assertions SAML signées par chacun des composants portent les principales informations, comme par exemple cet extrait de l’assertion de réussite remontée au SP.

conclusions

STORK étend les capacités de SAML en intégrant des interfaces vers de nouveaux composants.

Pour autant, la version 1 semble figée dans un scénario extrêmement simple, par rapport à la capacité de SAML (pas de singleLogout, pas de réactivation de l’authentification, pas d’approche IdP initated).

STORK ne pouvait-t-il pas hériter des années d’expériences des grandes communautés SAML, comme celle des universités américaines InCommon, ou en Europe eduGain ? Ces communautés universitaires sont de bons exemples d’initiatives citoyennes pour gérer des problématiques d’identité et d’accès.

La forte dépendance de l’élément PEPS entre un SP et un IdP nécessite de monter une combinaison importante de PEPS, ce qui va poser des problèmes d’administration des plates-formes de fédération.

• En particulier comment va se dérouler la déclaration des SP et leur intégration dans les PEPS ? Un module de Version Control semble répondre à ce problème, nous reviendrons dessus dans le prochain sujet.
• Chaque fournisseur d’application devra-t-il faire une déclaration auprès de chaque pays ?
• Aurait-il la charge d’une partie du PEPS ?
• Comment se passera le renouvellement des certificats ?
• Plus généralement combien faudra-t-il de plate-forme de PEPS en Europe, gérées par qui ?

Certaines de ces questions trouvent déjà une réponse dans la version 2 du projet STORK.

Stéphane