Produits Entr'ouvert » Authentic 2

Dans la branche, une copie assez conforme de ce qui existe dans le plugin, copie testée elle aussi. Je vais voir s’il est judicieux de rajouter des tests.

Et bien sûr il y a tout un pan du problème qui m’avait échappé : la synchro des usagers modifiés se fait entre un fournisseur et un rp oidc, il ne faut pas renvoyer les attributs usager bruts de fonderie, mais tenir compte de la configuration des mappings de claim entre ces deux entités OIDC.

Dans le plugin GL on se simplifiait la tâche car le mapping était connu, les modifications tenant compte de cette config avaient lieu en dur dans le code.
Ici c’est plus complexe, il va falloir détecter que l’appelant de l’/api/users/?modified__gt=… est par ailleurs un client oidc pour authentic, et parvenir à la substitution des attributs en claims conformément à la configuration de ce client.

Tâche non triviale, j’ai quelques idées mais aucune arrêtée pour l’instant. Peut-être un paramètre de qs supplémentaire dans cette api pour passer le slug du client oidc appelant ?
Je revois ma copie.

il va falloir détecter que l’appelant de l’/api/users/?modified__gt=… est par ailleurs un client oidc pour authentic, et parvenir à la substitution des attributs en claims conformément à la configuration de ce client.

Le script appelle /api/users/?... qui est une API standard d'authentic, le propos ici est que le script de synchro du dépôt authentic2-gnm fonctionne parce qu'en face l'/api/users/? n'est en fait pas l'API standard d'authentic mais une API modifiée par authentic2-cut ?

(je ne capte pas)

Frédéric Péters a écrit :

il va falloir détecter que l’appelant de l’/api/users/?modified__gt=… est par ailleurs un client oidc pour authentic, et parvenir à la substitution des attributs en claims conformément à la configuration de ce client.

Le script appelle /api/users/?... qui est une API standard d'authentic, le propos ici est que le script de synchro du dépôt authentic2-gnm fonctionne parce qu'en face l'/api/users/? n'est en fait pas l'API standard d'authentic mais une API modifiée par authentic2-cut ?

Oui voilà, il y a ce fameux hook planqué dans un coin, qui change complètement le sérialiseur et donc le contenu de la réponse : https://git.entrouvert.org/authentic2-cut.git/tree/src/authentic2_cut/apps.py#n290
Ici dans ce hook on sait à quoi ressemble la configuration de mapping de claims GL -> Toodego (par exemple on sait qu’on peut placer directement le contenu de user.last_name dans family_name, ligne 322), mais dans le cas général il faut inspecter cette configuration et résoudre les claims usager par usager.

Paul Marillonnet a écrit :

Frédéric Péters a écrit :

il va falloir détecter que l’appelant de l’/api/users/?modified__gt=… est par ailleurs un client oidc pour authentic, et parvenir à la substitution des attributs en claims conformément à la configuration de ce client.

Le script appelle /api/users/?... qui est une API standard d'authentic, le propos ici est que le script de synchro du dépôt authentic2-gnm fonctionne parce qu'en face l'/api/users/? n'est en fait pas l'API standard d'authentic mais une API modifiée par authentic2-cut ?

Oui voilà, il y a ce fameux hook planqué dans un coin, qui change complètement le sérialiseur et donc le contenu de la réponse : https://git.entrouvert.org/authentic2-cut.git/tree/src/authentic2_cut/apps.py#n290
Ici dans ce hook on sait à quoi ressemble la configuration de mapping de claims GL -> Toodego (par exemple on sait qu’on peut placer directement le contenu de user.last_name dans family_name, ligne 322), mais dans le cas général il faut inspecter cette configuration et résoudre les claims usager par usager.

J’ai créé #65877 pour cette partie, sinon on ne va pas s’en sortir.

Paul Marillonnet a écrit :

Ok pour virer l’option '--delta' et se baser sur des champs spécifiques de modèles.
Par contre pour virer le code de la commande, je n’arrive pas à trouver un parallèle avec sync-ldap-users (où la méthode du backend appelée, i.e. get_users, est générique et ne se restreint pas à des fins de synchronisation). Ici à vouloir sortir le code de la commande on se retrouve avec du code très spécifique dans le modèle, spécifique car propre à la synchro, qui plus est seulement lorsque le fournisseur oidc distant est un authentic.

Si tu veux implémenter SCIM au passage vas y :) en attendant on aura du code spécifique à une API spécifique d'authentic dans authentic oui, on vivra avec ça.

Un exemple de patche pour illustrer mon propos. Je pourrais encore déplacer les bouts spécifiques aux appels à /api/users/?modified_gt=… et /api/synchronization/ dans authentic2_auth_oidc.utils, mais ça va pas simplifier l’affaire déjà plutôt convoluée.

Mon souci c'est d'avoir la logique dans un seul endroit et pas éparpillé dans des commandes et à terme de faire disparaître ces commandes pour avoir un système de cron unique et pas une nouvelle commande à chaque fois.

Pour ma part je préfère infiniment la première version du patche, et peut-être que j’ai mal interprété les modifications demandées dans la relecture, mais si tu me confirmes que c’est bien la piste envisagée je vais quand même continuer (en remaniant un peu les tests, et en trouver une manière de logguer correctement l’affaire, pour l’instant dans le patche c’est du bricolage).

Disons que je ne vois pas de difficulté technique à mettre le code exactement identique ailleurs que dans la commande, si tu en vois dis moi, je ne vois qu'une objection de forme sur le fait que ce soit spécifique à un cas d'usage Publik/authentic.

C'est rouge, je regarde dès que c'est vert.

Paul Marillonnet a écrit :

Ok, donc la version avec le code dans une méthode du modèle. J’avais commencé à réfléchir à une façon dont les logs de la méthode pourraient arriver sur stdout quand celle-ci détecte qu’elle a été appelée par la commande, mais ça donne un peu n’importe quoi dans le code. Finalement une version où ce qui est dans la commande arrive sur stdout, et les logs de la méthode passent comme ailleurs dans le logging.getLogger(__name__).

Faut rien inventer pour la sortie, utilise logging partout et adapte la configuration du handler et du logger en fonction de 'verbose'. Il me semble que Valentin a fait ça dans une autre commande, à regarder.

sync-ldap-users, log_ldap_to_console, etc.

Frédéric Péters a écrit :

sync-ldap-users, log_ldap_to_console, etc.

Ah oui ok je n’avais pas compris que c’était de la mécanique de prévention de doublon dans les logs de commande de synchro ldap dont Benj parlait. Je vais proposer quelque chose qui va dans ce sens.

Benjamin Dauvergne a écrit :

Ça synchronise sur l'email et pas sur le sub, ça ne me parait ce qui est souhaitable pour un raccordement en général, je ne sais pas trop pourquoi Fred a choisi de synchroniser sur l'email (en cas de changement d'email la synchro est perdue et le service ne verra pas le changement jusqu'à la prochaine connexion).

Ok, je revois ça pour synchroniser sur le sub.

Paul Marillonnet a écrit :

Voilà, on se base sur le sub lorsque celui-ci est fourni.

Il faut virer complètement la synchro sur l'email, la synchro ne doit pas créer de nouvelles liaisons, du tout, ça n'apporte rien et ça nous a causé des soucis par le passé. La synchronisation n'est là que pour que les gens puissent éditer leur profil sans se préoccuper de sa propagation.

Automatic expiration