Principes généraux de la solution de Web Scraping Amélioré (WSA) sur la nouvelle offre Orange Bank

Dans le cadre du WSA, Orange Bank donnera aux TPPs un accès privilégié à l'Espace Client Web (qui est une SPA Angular qui effectue des appels d'API). Cet espace est disponible à l'adresse suivante : https://www.orangebank.fr/espace-client/.

L'authentification de chaque TPP s’effectue par une signature cryptographique à l'aide de son certificat QSealC. L'ouverture d'une session « pour le compte » d'un utilisateur s'effectuera à l'aide de l'identifiant du consentement obtenu sur le canal API (s'il est toujours valide). Cette solution a été envisagée suite à la demande des TPPs de ne pas demander deux fois le consentement de l'utilisateur.

A la suite de l'ouverture de la session : les APIs à utiliser seront exactement les mêmes que celles utilisées en nominal par notre Espace Client : 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 et bonnes pratiques

Orange Bank attend des TPPs qu'ils n'utilisent le canal WSA que dans les conditions convenues ensemble lors de leurs échanges de place ou des ateliers TPP-Orange Bank, à savoir :

  • En nominal : uniquement pour accéder aux informations sur les comptes qui ne sont pas des comptes de paiement.
  • En fallback (en cas d'indisponibilité de la plateforme d'API) : pour accéder aux comptes de paiement et initier des virements, en plus de l'accès aux autres comptes que ceux 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 souligner 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.

Par ailleurs, Orange Bank trace de manière détaillée tous les appels effectués par un utilisateur, qu'ils soient effectués directement par lui ou  par l’intermédiaire d’un TPP.

Prérequis techniques à la connexion en WSA 

  • Prérequis organisationnel :
    • le Web Scraping nécessitera l'usage du certificat QSealC DSP2 officiel déjà nécessaire sur le canal API de certaines banques
      • La liste des certificats QTSP actuellement reconnus par la plateforme WSA est la suivante : 
        • InfoCert (potentiellement obtenue via Luxtrust) via l'autorité :  « CN=InfoCert Qualified Electronic Signature CA 3, OID.2.5.4.97=VATIT-07945211006, OU=Qualified Trust Service Provider, O=InfoCert S.p.A., C=IT »
      • Si votre QSTP n'en fait pas parti, merci de vous rapprocher dès que possible des équipes Orange Bank (support-dsp2@orangebank.com) en précisant bien sur quelle offre (nouvelle offre ou ancienne offre) Orange Bank vous cherchez particulièrement à vous connecter et en fournissant votre certificat QSealC
  • Prérequis techniques :
    • Toutes les connexions devront être faites par un client HTTPS supportant l'extension TLS : SNI (ServerName Indication).
    • L’ensemble du site www.orangebank.fr fait l’objet d’une protection visant à lutter contre les attaques par déni de service. Dans ce cadre la fréquence d’émission de requête pour une IP source donnée est limitée.
      • les TPPs sont donc invités à continuer d’utiliser les techniques leur permettant actuellement de lever cette contrainte dans le cadre du webscraping « pre-DSP2 » (lissage des requêtes sur la journée, utilisation de plusieurs IPs sources, …)

Afin de faciliter les diagnostiques, les TPPs sont aussi invités à fournir à OrangeBank la liste des IPs sources qu’ils utilisent. Cela permettra en particulier aux équipes OrangeBank d’éviter de considérer que ces requêtes constituent une attaque.

 

Descriptif progressif des modalités de connexion par WSA

 

Etape 1 : obtention du consentement sur le canal API

 

L'accès au canal WSA s’appuie sur le consentement AISP recueilli par le TPP auprès du client sur la plateforme API.

Pour rappel : ce consentement est valable 90 jours à la suite de quoi, son autorisation devra être renouvelée via une nouvelle SCA de l'utilisateur.

L'obtention d'un consentement AISP sur le canal API est décrite ici : https://devportal-tpp.orangebank.fr/content/01-manage-consents-account-information-service

L'identifiant du consentement (nécessaire pour le WSA) est l'identifiant renvoyé par le premier appel du workflow de consentement AISP : "POST /berlingroup/v1/consents" : (champ consentId de l'objet JSON renvoyé)

La phase de SCA de l'utilisateur doit avoir été menée à son terme pour que le consentement soit valide et donc utilisable en WSA.

 

Etape 2 du WSA : obtention d'une session Web pour le compte de l'utilisateur

 

L'obtention d'une session de WSA pour le compte de l'utilisateur s'effectue en une seule requête http. 

Le TPP devra : 

  • Etablir une connexion TLS sur le FQDN www.orangebank.fr (port 443).
    Comme indiqué, le support de SNI est obligatoire pour cela.
  • Effectuer au sein de cette connexion la requête HTTPS suivante :
    POST sur https://www.orangebank.fr/portalserver/services/tpp/authenticate-as-customer/{consentId}
    Avec une payload vide. La partie {consentId} de l’URL devant être valorisée avec l'identifiant du consentement AISP obtenu sur le canal API pour le PSU concerné.
  • Le TPP devra s’authentifier au sein de cette requête au moyen d’une signature HTTP-Signature mettant en œuvre son certificat QSealC (voir encadré ci-dessous)
  • Un retour sans erreur de cette requête positionne les cookies nécessaires à l'établissement de la session.

Le client Http de simulation d'un utilisateur devra être capable de capturer (puis renvoyer dans les requêtes suivantes) l'ensemble des cookies que le serveur lui aura renvoyé (et ceci uniquement dans le cadre d'un PSU donné) :
en particulier (mais pas uniquement) le cookie JSESSIONID qui identifie à date la session HTTP initiée lors de cette étape 2.

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

Focus - Signature HTTP-Signature :

Le TPP devra ajouter à cette première requête un header « Signature » répondant à la norme HTTP-Signature pour laquelle il utilisera la clef de son certificat QSealC

Notre système WSA supportera a minima la spécification HTTP-Signature dans sa version https://tools.ietf.org/html/draft-cavage-http-signatures-09 :
On notera que, par rapport à la version https://tools.ietf.org/html/draft-cavage-http-signatures-10, le paramètre de signature « algorithm » reste pour le moment obligatoire.

Le paramètre « headers » de la signature spécifiant le contenu de la « Signature String » devra a minima contenir :

  • Le nom de header spécial « (request-target) »  (On notera que cela permet de signer l’ID de consentement AISP qui en fait parti)
  • Le nom de header http standard « Date »  (La valeur du header Date sera par ailleurs vérifiée pour limiter les possibilités de rejeu. Il est donc important qu’elle respecte le format http standard).

Le TPP est libre d’ajouter toute information qu’il jugera pertinente dans la signature.

Le paramètre KeyId de la signature devra être valorisé en suivant les préconisations de la spécification BerlinGroup 1.3 : en particulier le chapitre 12 du document 03. NextGenPSD2 Access to Account Interoperability Framework - Implementation Guidelines V1.3.4_20190705.pdf :
Serial Number of the TPP's certificate included in the "TPP-Signature-Certificate" header of this request.
It shall be formatted as follows: keyId="SN=XXX,CA=YYYYYYYYYYYYYYYY" where “XXX" is the serial number of the certificate in hexadecimal coding given in the TPP-Signature-Certificate-Header and "YYYYYYYYYYYYYYYY" is the full Distinguished Name of the Certification Authority having produced this certificate.

En complément du header Signature, et toujours sur la base des préconisations BerlinGroup, cette requête devra aussi contenir un header « TPP-Signature-Certificate » contenant son certificat QSealC au format PEM (c’est-à-dire encodé en BASE64 avec son préfixe « -----BEGIN CERTIFICATE-----») mais sans aucun retour chariot.

 

 

Etape 3 : le "Web Scraping" proprement dit

On notera que le terme "Web Scraping" est utilisé ici dans le cadre d'une définition générale.  En effet, techniquement, l'espace client Orange Bank est une application javascript (SPA) qui effectue des appels à des APIs propriétaires qui lui sont dédiées.
Il n'est donc pas nécessaire pour les TPPs de faire du Web Scraping de pages HTML à proprement parlé puisque les APIs renvoient déjà directement de la donnée structurée.
Les TPPs n'ont ainsi qu'à reproduire les appels Http de l'application Javascript pour obtenir ces données.

La session HTTP obtenue à l'étape précédente permet aux TPPs d'effectuer ces appels pour le compte du client ayant donné son consentement.

Les requêtes à effectuer sont exactement les mêmes que celles effectuées par l'application web hébergée à l'adresse https://www.orangebank.fr/espace-client/ pour les clients finaux.

Il est donc aisé, suite à une simple analyse des requêtes émises par https://www.orangebank.fr/espace-client/ de déduire les requêtes à effectuer par le simulateur HTTP effectuant le "Web Scraping".

Une session Http WSA (représentée côté simulateur Http par l'ensemble des cookies obtenus à l'étape 2) ne doit pas être stockée par le TPP plus que le temps nécessaire à l'exécution d'une série d'appels Http consécutifs 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 initialement. 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 2.

Focus - Appels et gestion des cookies :

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

  • 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.

 

 

Focus - Gestion du token CSRF en header :

Pour les rares appels HTTP qui ne s'effectueront pas via la méthode GET, un token CSRF devra être positionné en entête HTTP : cet header doit se nommer "x-bbxsrf" et devra contenir la valeur extraite du cookie BBXSRF