Continuing the discussion from Basic Azure AD Config:
Bonjour,
Est-il possible de mapper non plus avec l’email mais avec le “user” de l’azure AD sur le paramètrage de l’AUTH_PROVIDERS ?
Merci,
Ophélie Gorizian
Oui il faut juste connaitre le nom de cet attribut “user” dans la réponse de l’appel au endpoint userinfo Azure AD
Pour voir, notamment, dans les logs ce que répond ce endpoint vous pouvez activer teporairement le log event de debug DAUTHSC001
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Bonjour @OphelieG ,
Je ré-ouvre ce sujet suite à ton mail :
Aujourd’hui nous mappons nos utilisateurs avec l’email envoyé via l’Azure AD, nous souhaitons désormais que ce soit le nom d’utilisateur principale.
Peux-tu me donner des détails sur ce que vous souhaitez implémenter, et comment vous avez essayé de l’implémenter? As-tu consulté la section userinfo_mappings de la doc OAuth2 ?
Hello Simon,
Merci pour ton message.
Je te mets en relation avec notre admin office (je crois qu’il est déjà en contact avec Alistair) qui a fait la plupart des tests, je ne suis pas sûre qu’il ait un compte sur la communauté Simplicité.
Bonne journée,
Bonjour, Voici les réponses que nous obtenons lors de la phase login :
De ma compréhension il va rechercher les valeurs disponibles par L’openip de Microsoft à savoir :
Nous avons besoin de mapper sur l’upn de l’utilisateur qui n’est pas présent dans ces retours mais qui figure bien dans le token :
L’idée serait peut être si cela est supporté d’abandonner le userinfo mapping login:email et d’essayer de mapper via le token avec quelque chose du genre :
“jwt_issuer” : “https://sts.windows.net/8fffb097-8caf-49b1-81fe-e17224249928/”
récupéré à partir du token :
“iss”: “https://sts.windows.net/8fffb097-8caf-49b1-81fe-e17224249928/”,
Et comme mapping :
“jwt_claims_mappings” { “login”: “upn”},
qui viendrait du token :
“upn”: “de.XXXXXX.com”,
Est-ce que cela peut fonctionner ?
Merci
Comme dit précédemment le mapping configurable pour le login se fait soit sur un attribut présent dans la réponse du endpoint user info (userid_mappings), soit sur attribut (“claim”) présent dans le token JWT (jwt_claims_mappings).
Attention il faut configurer l’un ou l’autre, pas les deux
Le login ainsi récupéré doit correspondre exactement (casse comprise) au login de vos utilisateurs déclarés dans l’application.
PS: S’il y a besoin d’un traitement additionnel il y a un platform hook prévu pour implémenter ce genre de choses mais dans la plupart des cas client que je connais un simple mapping configurable suffit.