Project

General

Profile

Development #60488

auth_oidc : strategie appairage sub -> email

Added by Paul Marillonnet 5 months ago. Updated 5 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11 Jan 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Dans #60476 je suis parti dans une fausse piste en proposant cette solution, qui ne s’applique pas à ce ticket là si mais qui reste néanmoins une fonctionnalité intéressante (et cadrée par les spécs OIDC).
Aussi, ce serait le dual de ce qu’on a déjà dans la partie fournisseur OIDC, à savoir la fourniture de l’email dans le sub (POLICY_EMAIL).


Files

History

#1

Updated by Paul Marillonnet 5 months ago

#2

Updated by Paul Marillonnet 5 months ago

  • Status changed from Solution proposée to Nouveau

Deux choses à éclaircir, après discussion dans le salon tech :
· il s’agit donc d’un sub que l’usager peut potentiellement modifier côté fournisseur OIDC ;
· on doit aussi sans doute tenir compte de la configuration de gestion de la casse des adresses de courriel dans a2 lors de la réception du sub.

#3

Updated by Benjamin Dauvergne 5 months ago

Paul Marillonnet a écrit :

Deux choses à éclaircir, après discussion dans le salon tech :
· il s’agit donc d’un sub que l’usager peut potentiellement modifier côté fournisseur OIDC

Clairement ce mode est un cas exceptionnel à n'utiliser que pour l'authentification d'agents ou externes, pas les usagers, c'est trop casse gueule pour eux.

· on doit aussi sans doute tenir compte de la configuration de gestion de la casse des adresses de courriel dans a2 lors de la réception du sub.

Oui à prendre en compte dans le code de recherche de l'utilisateur, il faut juste changer email en email__iexact dans ton code.

Il y a aussi l'OU cible que tu ne prends pas en compte.

#4

Updated by Thomas Noël 5 months ago

Benjamin Dauvergne a écrit :

Paul Marillonnet a écrit :

Deux choses à éclaircir, après discussion dans le salon tech :
· il s’agit donc d’un sub que l’usager peut potentiellement modifier côté fournisseur OIDC

Clairement ce mode est un cas exceptionnel à n'utiliser que pour l'authentification d'agents ou externes, pas les usagers, c'est trop casse gueule pour eux.

Comme j'aime bien poivrer les discussions, on a un exemple récent d'une ville qui change l'email de tous ses agents.

Ceci pour dire que ce patch est quand même bien théorique, cette fonctionnalité, jamais on ne va l'utiliser :)

Also available in: Atom PDF