Cette note a été partagée par mail en février à l'ensemble des acteurs identifiés par l'AFEPAME et repartagée suite à l'activation de l'authentification forte sur l'espace client Groupama aux TPP qui n'ont pas adapté leurs connecteurs.

Afin de faciliter la prise de connaissance de ce document, la voici ci-dessous en libre accès.

Principes généraux de la solution de Web Scraping Amélioré (WSA) sur l’ancienne offre Groupama

Pour les clients anciennement "Groupama Banque" (que l'on appelle "Ancienne Offre") : le Web Scraping Amélioré sera le mode d'accès nominal pour les TPPs (il n'y a pas d'API).

Dans le cadre du WSA, Orange Bank donnera aux aux TPPs un accès privilégié à l'Espace Client Web de Groupama. Cet espace est disponible à l'adresse suivante :  https://espaceclient.groupama.fr/.

L'authentification de chaque TPP sera effectuée par TLS MA à l'aide du certificat QWAC (pour cela l'Espace Client Web de Groupama sera ré-exposé techniquement sur un nom de domaine spécifique).

L'ouverture d'une session pour le compte d'un utilisateur sera identique à la version actuellement en production : elle nécessitera le login/mot de passe de l'utilisateur.

L'activation du Web Scraping Amélioré permettra de désactiver l'envoi de l'OTP SMS que nous allons mettre en place pour être conforme à la DSP2 sur l'accès web de nos clients.
A la suite de l'ouverture de la session, les requêtes à effectuer seront identiques à celles nécessaires sur l'espace client nominal (les serveurs applicatifs sous-jacents étant exactement les mêmes) : il est donc possible de les rétro-engineerer dès à présent.

Pour toute difficulté ou discussion d’optimisation envisageable, les TPPs peuvent adresser leurs demandes ou suggestions à l’adresse générique consacrée : support-dsp2@orangebank.com.

Conditions d'utilisation

Orange Bank attend des TPPS qu'ils n'utilisent le canal WSA que dans les conditions pour lesquelles il a été mis en place :

  • En nominal : pour accéder aux informations sur l'ensemble des comptes de paiement de l'utilisateur ou pour initier des virements pour le compte de l'utilisateur, depuis son/ses compte(s) de paiement.

En particulier, il est entendu que ce canal n'a pas vocation à permettre d'ajouter ou de modifier des bénéficiaires de confiance, dans le prolongement des recommandations de l'EBA en matière d'écriture de bénéficiaires de confiance. Il est en effet souligné que, dans son implémentation, Orange Bank a retenu la solution d’assimilation de tout bénéficiaire enregistré par le client (avec RIB) à un bénéficiaire de confiance.

On notera qu'Orange Bank trace de manière détaillée tous les appels effectués pour le compte d'un utilisateur (qu'ils soient effectués par l'utilisateur lui-même ou via un TPP).

Prérequis techniques à la connexion en WSA : 

  • Prérequis organisationnel :
  • Prérequis techniques :
    • Toutes les connexions devront être faites en authentification mutuelle TLS pour lesquels le TPP devra utiliser son certificat QWAC.
    • Toutes les connexions devront être faites par un client HTTPs supportant l'extension TLS : SNI (ServerName Indication).

Etape préliminaire : obtention du login / mot de passe de l'utilisateur 

L'accès au canal WSA nécessite que l'utilisateur ait consenti en connaissance de cause à fournir son login/mot de passe au TPP, autorisant ainsi ce dernier à avoir accès aux informations relatives à ses comptes de paiement

Etape 1 du Web Scraping : obtention d'une session Web pour le compte de l'utilisateur

L'obtention d'une session de WSA pour le compte de l'utilisateur nécessite de simuler le workflow complet de connexion réel d'un utilisateur avec deux spécificités :

  • Impact TPP : l'affichage et la saisie du mot de passe doit s'effectuer via un nom de domaine dédié permettant d'authentifier le TPP via TLS MA (le serveur appelé par ces requêtes restant le même que pour les utilisateurs finaux derrière ce nom de domaine).
  • Adaptation du workflow de connexion pour les TPPs : dans le cadre de cet accès TPP, l'OTP-SMS normalement envoyé au client pour finaliser sa connexion ne sera pas envoyé, le TPP obtiendra directement l'accès.

Voici la liste des requêtes HTTP que le TPP devra simuler pour dérouler cette connexion :

  • Accéder à l'url https://espaceclient.groupama.fr/ (en GET) et suivre l'ensemble des redirections techniques automatiques qui s'appliquent à ce domaine (espaceclient.groupama.fr) en gérant l'ensemble des cookies émis par le serveur (pour les renvoyer ensuite).
  • La dernière redirection pointe vers le domaine authentification.groupama.fr : elle ne doit pas être suivie tel quelle par les TPPs :
  • A la suite de ces appels, le formulaire de login est renvoyé : 
    • Ce formulaire contient deux champs de saisie : username et password
      ainsi que des champs techniques non visibles sur l'interface utilisateur.
    • Le TPP devra renseigner les champs username et password tel que le ferait un utilisateur. :
      Pour des raisons de sécurité (entre autres, pour déjouer des logiciels "keylogger"), ce formulaire impose que ce mot de passe soit encodé : les TPPs doivent donc s'assurer d'encoder ce mot de passe tel que le code source de la page HTML le ferait. (le comportement actuel est décrit plus bas).
  • Simuler la soumission de ce formulaire après avoir renseigné les champs username et password (encodé comme décrit précédemment) avec les codes d’accès du PSU concerné.
    Cette soumission (hors cas d'erreur) aura pour effet de générer plusieurs redirections techniques automatiques qui atterriront au final sur la page d'accueil du site espaceclient.groupama.fr en mode connecté (sous l'identité de l'utilisateur final)

Encodage du mot de passe :

Voici des éléments permettant de faciliter la reproduction de l'algorithme d'encodage du mot de passe tel qu'il existe au moment de la rédaction de cette documentation

  • Chaque chiffre du mot de passe est encodé par une lettre, avec une combinatoire changeant à chaque connexion.
  • Le "clavier virtuel" (tableau HTML d'identifiant "keypad") généré par le code javascript de la page est porteur de cette combinatoire : chaque case représentant un chiffre et permettant de saisir la lettre associée.
  • Le code javascript générant ce clavier virtuel en question est actuellement présent ici : https://authentification.groupama.fr/cas/js/commons/manageKeyBoard.js et son comportement facilement reproduisible.

Comme indiqué plus bas, le client Http de simulation devra être capable de capturer (puis renvoyer dans les requêtes suivantes) l'ensemble des cookies HTTP que chaque serveur (c'est à dire pour chaque FQDN différent) lui aura renvoyé (mais ceci uniquement dans le cadre d'un PSU donné) : attention, les cookies sont associés aux différents domaines et sous-domaines, leur sémantique standard devra donc être respectée.

Dans notre système, cette session est associée à la double identité du client et du TPP et donne accès uniquement aux données du client exactement comme s'il s'agissait du client lui-même.

Etape 2 : le "Web Scraping" proprement dit

La session HTTP obtenue à l'étape précédente permet aux TPPs de parcourir l'espace Client sous l'identité du client ayant donné son consentement (sous la forme de la communication de ses codes d’accès).

Mis à part l'étape de connexion décrite précédemment (dont le but est d’authentifier le TPP afin de ne pas envoyer d'OTP-SMS à l'utilisateur), une fois redirigé vers Espace Client en mode connecté, le TPP a accès à exactement la même application Web que l'utilisateur final dans le cadre des écrans d’accès aux comptes de paiement. L'analyse de https://espaceclient.groupama.fr/  permettra donc de déduire facilement les requêtes à effectuer par le simulateur HTTP de "Web Scraping".

Une session Http WSA (représentée côté simulateur http par l'ensemble des cookies obtenus à l'étape 1) ne doit pas être stockée par le TPP plus que le temps nécessaire à l'exécution d'une série consécutive d'appels Http lui permettant d'obtenir les informations recherchées au moment précis des appels. . Les cookies doivent être utilisés pour les seuls besoins des finalités de l’aboutissement des requêtes de data prévues. Une fois ces appels accomplis et réussis, les données de connexions devront être supprimées. En cas de nouveau besoin de connexion, une nouvelle session pourra facilement être obtenue en suivant à nouveau l'étape 1

Pour information :

Voici quelques informations pour faciliter l'analyse et la reproduction des requêtes effectuées par notre application web :

Gestion des cookies : 

  • le client HTTP simulant les appels HTTP, devra être capable de renvoyer l'ensemble des cookies que le serveur lui aura renvoyé (en particulier le nom de ces cookies pourra être amené à évoluer dans le futur)
  • En cas d'évolution des cookies, il est entendu qu'Orange Bank restera à disposition pour permettre et faciliter la connexion.