Mapping userinfo avec AUTH_PROVIDERS avec Keycloak

je veux alimenter des attributs de l’objet user en utilisant le mapping du paramètre système AUTH_PROVIDERS.

j’ai suivi votre doc et donc déclaré :
“userinfo_mappings”: {
“login”: “preferred_username”,
“firstname”: “given_name”,
“lastname”: “family_name”,
“email”: “email”,
“direction”: { “field”: “usr_direction”},
“service”: { “field”: “usr_service”}}

le mapping ne fonctionne pas pour direction et service alors que je récupère bien les valeurs : j’ai mis des traces dans le postLoadGrant du PlatformHooks pour vérifier

  • Il faut que ces 2 champs usr_direction et usr_service appartiennent à l’objet User et pas à un héritier car le mapping se fait directement avec l’objet User (instance session_User) auquel on peut ajouter des champs
  • Ne s’appellent-ils pas plutôt crb_service et crb_direction ?
  • Il devrait y avoir dans les logs du style “Can’t map field usr_direction in object User” s’il ne trouve pas le champ.

Et pour les avoir directement dans les paramètres de session getGrant().getParameter("CRB_DIRECTION"), on peut également mettre :

"direction": { "field": "crb_direction", "param": "CRB_DIRECTION" },
"service": { "field": "crb_service", "param": "CRB_SERVICE" },

Ce serait bien de faire le test de votre côté, pour voir si ces mappings de UserInfo fonctionnent également dans votre contexte.

les attributs usr_direction et usr_service appartiennent bien à l’objet user.
quand tu dis “l’objet User (instance session_User)” tu parles de quel objet ?
dans le mapping, “field” correspond au nom de l’attribut de l’objet user c’est bien ça ?

je n’ai pas de message Cant’map dans les logs

je récupère bien les valeurs de direction et service dans userinfo

Merci pour ces infos,

S’il n’y a pas d’erreur dans les logs c’est donc que les champs sont bien reconnus dans le mapping.
Mais je ne comprends pourquoi ils ne s’enregistrent pas ensuite… je vais refaire des tests.

Vous êtes en quelle version 5.1 ?
(on dirait le thème V5 sur la copie d’écran qui n’a pas encore été livré en 5.0)

je viens juste de déployer le thème …
suis en 5.0.23

le mapping fonctionne pour
“login”: “preferred_username”,
“firstname”: “given_name”,
“lastname”: “family_name”,
“email”: “email”,

pas pour
“direction”: { “field”: “usr_direction”,“param”: “CRB_DIRECTION”},
“service”: { “field”: “usr_service”,“param”: “CRB_SERVICE”},
“rne”: { “field”: “usr_rne”,“param”: “RNE”},
“titre”: { “field”: “usr_title”, “transform”: { “M.”:“MR”, “Mme”:“MRS”, “Mlle”:“MS” }}

Ok, ce thème devrait encore évoluer car il sort des ateliers et les CSS c’est toujours un peu compliqué, mais il est livré qu’à partir de la pre-release 5.1 qui sort cette semaine… comment a-t-il pu se retrouver en 5.0 ? @david @Etienne il a été backporté la semaine dernière en 5.0 ?

De mon côté, je regarde le pb de userinfo_mappings dans le contexte Keycloak.

non, ça vient de nous. c’est notre thème CRB que nous avons fait évoluer.

j’ai aussi des questions sur la synchro de groupes. j’ouvre un autre ticket ?

Oui, c’est mieux.

Pour le thème ok, ça me rassure, mais il ressemble bcp au nouveau qui va bientôt sortir :

on est toujours en avance en Bretagne ;)

1 Like

Pour avancer sur les tests d’intégration, il faut voir comment sont paramétrés vos mappers dans Keycloak pour les attributs étendus du User (rne, service, …).

Votre façon d’ajouter des attributs ne doit pas être bien parsé par Simplicité (car ils peuvent remonter dans les user-info, claims, token…) suivant le paramétrage du ClientId.

Par exemple :

j’attends les éléments de kevin mais d’après mes logs dans le platformhook, userinfo est bien alimenté

Ok un petite évolution sera poussée pour regarder dans les userinfos en plus du token.

je viens de tester et je récupère bien tous les éléments mappés.

la petite évolution est validée

1 Like

Super, les tests avaient été fait en mettant ces attributs au niveau du token dans Keycloak, mais effectivement c’est plus propre de les remonter dans le payload des user-infos.