Réconciliation sur l'identité pivot et non le mail

[maudePremillieu]

Bonjour,

La documentation de FranceConnect demande explicitement à ce que la réconciliation d'identité se fasse sur les données de l'identité pivot et non le mail. De même, les données de l'identité pivot ne doivent pas être modifiables par l'utilisateur, contrairement au mail.
Ces critères sont indiqués dans la demande de qualification du fournisseur de service (https://docs.partenaires.franceconnect.gouv.fr/fs/devenir-fs/projet-qualification-fs/)

Or le comportement par défaut de Keycloak est exactement l'inverse : réconciliation sur le mail uniquement et non-modification du mail par l'utilisateur.

Y a-t-il un paramétrage particulier à mettre en place pour respecter les critères demandés par FranceConnect ? Je pense notamment aux mappers, faut-il configurer des mappers particuliers pour que la réconciliation ne se fasse pas sur le mail ? Ou bien peut-être un flux d'authentification ?

Si quelqu'un a réussi à respecter ces critères de réconciliation, je suis preneuse d'un peu d'aide pour y arriver de mon côté !

Merci d'avance !

[maudePremillieu]

Voici un complément sur les critères demandés par FranceConnect : https://partenaires.franceconnect.gouv.fr/monprojet/cadrage#Parcoursdereconciliation

La réconciliation de comptes est un point majeur de la phase de cadrage du projet. Elle doit être pensée astucieusement pour offrir une expérience usager la plus fluide possible.

Si le fournisseur de services dispose de comptes locaux et souhaite gérer la réconciliation entre ses données locales et celles transmises par FranceConnect, il y a deux cas de figure :

une réconciliation automatique, sans intervention de l'usager : le fournisseur de services détient les 6 champs de l’identité pivot et dans le même format. La correspondance entre les deux identités est alors instantanée et l’identité locale est taguée avec l'identifiant technique (le « sub ») fourni par FranceConnect. Cette opération est transparente pour l’usager.
une réconciliation faisant intervenir l’usager : les données de l’identité locale ne peuvent pas être rapprochées des 6 champs de l’identité pivot de FranceConnect. Dans ce cas, le fournisseur de services demande explicitement à l’usager de saisir un « secret » qui se trouve dans le compte local (ex : un numéro de permis de conduire, un numéro de sécurité sociale, un identifiant de bibliothèque, etc.).
Une fois la réconciliation réussie, le fournisseur de services stocke l’identifiant technique (le « sub ») rattaché à l’utilisateur. Cet élément permettra de le reconnaître instantanément lors de ses prochaines connexions.

Ce qu’il ne faut pas faire :

demander à l’usager de saisir son identifiant/mot de passe local. En effet, trop complexe, cette demande provoque l'abandon de l'usager.
baser la réconciliation sur l'adresse email seulement. L'adresse mail ne fait pas partie de l'identité pivot et peut être différente suivant le fournisseur d'identité utilisé par l'usager et peut également être partagée entre plusieurs usagers.

[lme-atolcd]

La réconciliation d'un compte FranceConnect avec un compte Keycloak basée sur les informations de l'identité pivot n'est pas une fonctionnalité présente dans cette extension.

Nous avons développé cette fonctionnalité de notre côté via la création d'un nouveau step qui sera utilisé dans un flow "first broker login". En gros, on a créer un nouveau flow "first broker login" utilisé uniquement par l'IDP franceconnect-particulier qui réalise les étapes suivants :

• Review Profile
• User creation or linking
  • FranceConnect Check Identite Pivot (→ le nouveau step)
  • Create User If Unique

@clement-dufaure serais-tu ok pour qu'on contribue ce step au projet ?

[Ekouyoja]

Bonjour à tous les deux,
Je suis intéressé par le développement que vous avez produit afin d'établir cette réconciliation via l'identité pivot, il m'a toujours semblé étrange que personne ne demande cette fonctionnalité auparavant qui me paraît pourtant phare dans le cas de la proposition de FranceConnect.
@lme-atolcd est-il possible pour vous de me montrer le développement que vous avez fait ?
Merci par avance

[lme-atolcd]

#134

N'hésitez pas à tester et à faire vos retours sur la PR.

[Ekouyoja]

Merci, c'est très intéressant.
J'ai pu voir que ça imposait d'avoir le lieu de naissance et le pays de naissance, chose que nous n'avons pas dans nos bases.
Je me pose également une question concernant la partie prénom, il me semble que l'on récupère l'ensemble des prénoms côté FC, cela veut dire que vous aviez également l'ensemble des prénoms dans votre base et au même format ?

[lme-atolcd]

On est plus ou moins dans le même cas. Au final, on pense que la reconciliation automatique ne sera quasiment pas utilisée : c'est très compliqué d'avoir toutes les informations de l'identité pivot en local (surtout à l'époque du RGPD qui incite fortement à n'avoir que le strict minimum sur les utilisateurs).

Et même si on a toutes les données en local, il y a de fortes chances que la comparaison avec l'identité pivot échoue : majuscule/minuscule, caractères accentués, signe de ponctuation (je pense aux tirets, mais il dois en exister d'autres), l'ordre des prénoms, etc.
Par exemple : Charles-Edouard != charles-edouard != Charles-Édouard != Charles Edouard != CHARLES-ÉDOUARD != etc.

On l'a quand même mis en place pour automatiser les cas les plus simples et pour lesquels on a les infos.

Si on met de côté la reconciliation automatique, il reste la reconciliation manuelle (avec intervention de l'utilisateur), mais cela nécessite de partager un secret entre l'utilisateur et Keycloak. La documentation FC donne comme exemple : un numéro de permis de conduire, un numéro de sécurité sociale, un identifiant de bibliothèque, etc.). Encore une fois, avec le RGPD, on évite d'avoir ce genre de données en local.

Sur l'option "reconciliation manuelle avec secret", on a réussi à faire valider par FC le fait d'avoir un secret généré côté Keycloak (et unique à chaque utilisateur). Ce secret est une chaîne aléatoire de quelques caractères que l'utilisateur peut retrouver dans sa console utilisateur (celle de Keycloak).

Sinon, dernière option qu'on n'a pas encore essayé de faire valider par FC : inciter l'utilisateur à faire le reconciliation de son compte directement depuis la console utilisateur de Keycloak. Le plus simple à déployer (que de la comm, aucun dév), mais je ne sais pas si ça passe auprès de FC. Si quelqu'un l'a déjà tenté, je suis preneur de l'info :)

[clement-dufaure]

J'ai donc fait la release 7.5.0 incluant cet authenticator en l'état, malgré les réserves évoquées ca fait une bonne base de départ. Merci pour la contribution.

[maudePremillieu]

Merci pour cette info, c'est bien ce que je soupçonnais !

De notre côté nous nous en sommes sortis finalement car nous ne stockons pas l'identité pivot dans notre Keycloak. Nous avons donc pu nous passer de cette réconciliation car nous ne disposons tout simplement pas des informations permettant de la faire.