Comment une banque européenne a mis en place son système d'authentification forte conforme à la directive PSD2 en s'appuyant sur sa propre infrastructure d'identité
Comment une banque européenne a bâti son authentification forte pour la PSD2 à partir de son propre référentiel d’identités
Une banque qui entreprend d'ajouter une authentification client forte s'attend généralement à ce que la partie difficile soit l'authentification elle-même : quels facteurs combiner, quelle application déployer, comment franchir les obstacles réglementaires. La question la plus difficile se situe souvent une étape avant. Où résident réellement les identités des utilisateurs, et est-il possible de s'authentifier aujourd'hui, même de manière limitée, contre ces identités ?
Nous avons travaillé avec une banque privée en Europe qui est venue nous voir pour authentification forte du client, une ASCA dans le langage de la DSP2, pour les clients utilisant sa banque en ligne. L'exigence était claire, dictée par le régulateur et sur site par nécessité. Ce qui est devenu clair en y regardant de plus près, c'est que le projet était plus vaste que la demande initiale. La banque avait pris de l'avance sur de nombreux homologues du même segment, et la portée n'a cessé de s'élargir au fur et à mesure de l'avancement des travaux.
Où résidaient réellement les identités des utilisateurs
Les clients de la banque n'avaient pas de répertoire propre. Leurs identités n'existaient qu'à l'intérieur de la solution e-banking précédente, conservées dans sa base de données, où elles s'étaient accumulées au fil des années. C'est une situation courante, et elle fonctionne bien au quotidien. Elle commence à montrer ses limites lorsque vous devez appliquer une couche d'authentification cohérente devant ces utilisateurs, c'est là qu'intervient l'authentification forte du client.
La modernisation de l'authentification a donc commencé une étape plus tôt, en dotant ces identités d'un répertoire qui leur est propre. Nous avons mis en place une solution sur site OpenLDAP pour les clients de la banque et a migré leurs identités de la base de données e-banking précédente vers celle-ci. Les comptes qui n'avaient jamais existé qu'à l'intérieur de l'application pouvaient désormais être gérés de manière centralisée par le biais de WebADM, notre console IAM principale qui fournit l'administration de répertoire basée sur le web, exécute OpenOTP et le fournisseur d'identité sur site, et fédère les sources d'identité sur site et dans le cloud.
Pourquoi la couche d'identité a dû rester sur site
Pour une banque, l'emplacement des données d'authentification n'est pas une préférence de déploiement, c'est une partie de la surface de contrôle. Ici, l'annuaire, le serveur d'authentification et les politiques d'accès fonctionnent tous sur site, à l'intérieur de l'environnement propre à la banque, sans que rien concernant l'authentification client n'en sorte. Nous avons déployé WebADM et OpenOTP (notre serveur d'authentification multifacteur) en tant que cluster haute disponibilité, frontal par deux proxys inversés qui n'exposent que les services destinés aux utilisateurs finaux vers l'extérieur, et nous avons construit le tout sur des environnements distincts de pré-production (UAT) et de production afin que les modifications puissent être validées avant d'atteindre l'accès client en direct.
Ce que l'authentification forte PSD2 exige, au-delà d'un deuxième facteur
La banque a formulé son besoin en termes d'authentification forte du client(AFC).En pratique, l'ACS est plus qu'une deuxième invite à la connexion : elle définit comment les facteurs d'authentification sont combinés et, pour une banque, s'étend à l'autorisation des paiements elle-même. Nous avons d'abord livré une authentification forte comme base : un fournisseur d'identité sur site soutenu par WebADM et OpenOTP, fournissant MFA (authentification multi-facteurs) pour les clients de la banque en ligne. Dans un contexte d'open banking, cependant, l'authentification doit être distinguée du consentement du client : la connexion vérifie l'identité de l'utilisateur, tandis que le consentement à accéder aux données du compte ou à initier des paiements doit être recueilli par le biais du flux PSD2/Open Banking applicable.
Sécuriser le paiement lui-même, pas seulement la connexion
L'authentification de connexion répond à une question : est-ce la bonne personne ? La DSP2 pose une deuxième question au moment du paiement : cette personne a-t-elle approuvé cette transaction spécifique, pour ce montant, auprès de ce bénéficiaire ?
C'est l'approbation de transaction, et c'est là que le champ d'application s'est à nouveau élargi. Nous l'avons mis en œuvre de sorte que, lorsqu'un paiement est initié, la transaction est présentée à l'utilisateur dans l'application mobile pour une validation explicite, avec les détails du paiement clairement affichés avant qu'il ne puisse procéder.
Le facteur d'authentification n'est donc plus utilisé uniquement pour prouver son identité à l'entrée. Il sert également à confirmer une opération spécifique, liée cryptographiquement et contextuellement à la transaction en cours d'approbation.
Intégration avec le système d'Open Banking et les paiements interbancaires déjà en place
Une banque ne mène pas l'authentification en vase clos. L'authentification forte et l'approbation des transactions devaient s'intégrer dans deux systèmes déjà en place : le système d'Open Banking utilisé pour les services en ligne et d'open banking de la banque, et le fournisseur national sur lequel la banque s'appuie pour les paiements interbancaires.
Aucun des deux systèmes ne serait remplacé pour convenir à un fournisseur d'authentification, et aucun des deux ne fournissait de point d'intégration prêt à l'emploi pour le flux d'approbation requis. Nous avons donc développé un middleware personnalisé pour acheminer le contexte de paiement vers la validation et pour connecter les flux d'authentification et d'approbation de transaction aux deux systèmes.
La demande concernait l'authentification forte des clients. Y répondre correctement impliquait de doter les identités d'une couche d'authentification dédiée, de maintenir cette couche sur site, d'étendre l'authentification au-delà de la connexion pour inclure l'approbation des paiements, et d'écrire le code d'intégration nécessaire pour fonctionner avec les systèmes existants plutôt que de les contourner.
Oui. Lorsque les identités des utilisateurs existent uniquement à l'intérieur d'une application, elles peuvent d'abord être migrées vers un répertoire dédié sur site, afin qu'elles puissent être gérées et que des stratégies d'authentification leur soient appliquées, avant l'ajout de l'authentification multifacteur (MFA).
Non. Au-delà de l'authentification lors de la connexion, le SCA s'immisce dans les paiements par le biais de l'approbation des transactions, où l'utilisateur valide la transaction spécifique, le montant et le bénéficiaire sur une application mobile avant qu'elle ne puisse être effectuée.
Oui. L'annuaire, le serveur d'authentification et les politiques d'accès peuvent tous fonctionner sur site, à l'intérieur de l'environnement propre de la banque, déployés sous forme de cluster à haute disponibilité.
Oui, RCDevs est un fournisseur européen et OpenOTP peut être entièrement déployé sur site, toutes les données d'identité, les politiques d'authentification, les flux d'approbation des transactions et les journaux restant au sein de l'environnement propre à la banque. Il n'y a aucune dépendance vis-à-vis d'un cloud non européen, et les données d'authentification des clients ne transitent pas par l'environnement du fournisseur.
Lorsqu'un paiement est initié, les détails de la transaction, y compris le montant et le bénéficiaire, sont affichés dans l'application mobile du client pour une validation explicite avant que le paiement puisse être effectué. Cela lie le facteur d'authentification à l'opération spécifique en cours d'approbation, ce que la liaison dynamique de la DSP2 exige.
Pas nécessairement. En l'absence d'Active Directory, les identités peuvent être gérées dans un serveur OpenLDAP sur site, administré par WebADM. RCDevs propose également son propre serveur d'annuaire pour les environnements ne disposant d'aucun annuaire d'utilisateurs existant.
