Produits Entr'ouvert » Authentic 2

i.e. ça revient à dire qu’un client OIDC peut aussi être un client d’API.

Pour moi maintenant qu'on a des clients d'API explicites, ce mélange des genres n'a plus lieu d'être.

Thomas Noël a écrit :

Pour moi maintenant qu'on a des clients d'API explicites, ce mélange des genres n'a plus lieu d'être.

Aucun souci à décider de ça, simplement en l’état du code actuel, retirer l’accès à l’API aux clients OIDC et créer des clients d’API à la place va casser des choses, car les hooks spécifiques à l’API appelée par un client OIDC ne seront plus exécutés : https://git.entrouvert.org/authentic.git/tree/src/authentic2_idp_oidc/apps.py

Edit: et des choses plus spécifiques encore dans le plugin GLC.

Paul Marillonnet a écrit :

Aucun souci à décider de ça, simplement en l’état du code actuel, retirer l’accès à l’API aux clients OIDC et créer des clients d’API à la place va casser des choses, car les hooks spécifiques à l’API appelée par un client OIDC ne seront plus exécutés : https://git.entrouvert.org/authentic.git/tree/src/authentic2_idp_oidc/apps.py

Edit: et des choses plus spécifiques encore dans le plugin GLC.

Donc une idée de plan pour ne pas casser l’existant :
· ajouter une FK de client OIDC associé au modèle de client d’API, avec les modifications d’interface adéquates dans /manage/api-clients/,

· faire que les hooks OIDC, qui s’exécutaient jusque là si

hasattr(request.user, 'oidc_client')

isinstance(request.user, APIClient) and request.user.oidc_client is not None

· écrire une migration qui :
(1) pour chaque OIDCClient tel que OIDCClient.has_api_access := True, crée le client d’API associé
(2) retire cette colonne OIDCClient.has_api_access.

Moi ça m'irait qu'il ne soit rien fait dans une précipitation que je trouve inutile ici. Déjà le ticket #71820 pour moi aurait du être refusé, qu'on n'emcombre pas ces interfaces avec cette partie legacy bizarre.

Je vais parler sans trop savoir : pas moyen de faire une migration qui prend les comptes oidc et les envoie dans des APIClientUser ? Puis qui supprime l'existance complète de l'accès aux API via les comptes OIDC ?

Thomas Noël a écrit :

Je vais parler sans trop savoir : pas moyen de faire une migration qui prend les comptes oidc et les envoie dans des APIClientUser ? Puis qui supprime l'existance complète de l'accès aux API via les comptes OIDC ?

Je ne sais pas trop si on pourrait alors conserver les deux cas différents :
· l’appelant est un client d’API, on se contente de retourner les données inchangées ;
· l’appelant est par ailleurs un client OIDC, il faut modifier les données (notamment dans le cas où celles-ci concernent les usagers, changer l’uuid en sub pour prévenir le croisement des données entre clients etc.).

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

Moi ça m'irait qu'il ne soit rien fait dans une précipitation que je trouve inutile ici. Déjà le ticket #71820 pour moi aurait du être refusé, qu'on n'emcombre pas ces interfaces avec cette partie legacy bizarre.

J’ai passé #71820 en considérant que ce n’est pas legacy dans la mesure où, actuellement, configurer un client d’API pour une entité qui est aussi un client OIDC vis-à-vis d’authentic ne fonctionnera pas, il y aura une variation irréconciliable entre les données servies au SSO et celles obtenues via l’API.

J’ai l’impression qu’il n’y a pas consensus ici parce que le plan de #71823-4 est un peu vague, je vais taper quelques lignes et prendre quelque captures d’écran pour que ça prenne une allure plus concrète, ensuite on verra si on poursuit comme ça ou pas.

C'est l'idée même de mélanger API et OIDC qui ne devrait pas apparaitre dans les interfaces, pour moi. (j'entends qu'il y a du legacy, que ça amène des changements de comportements etc. et là-dessus je n'ai aucun problème à ce que ça reste limité à /admin/).

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

(j'entends qu'il y a du legacy, que ça amène des changements de comportements etc. et là-dessus je n'ai aucun problème à ce que ça reste limité à /admin/).

Perso pas dingue de la situation actuelle où seuls les clients qui ont accès à l’/admin/ au petit bonheur la chance peuvent faire une config client OIDC entièrement fonctionnelle d’eux-mêmes, et où ceux qui jouent le jeu de s’emparer des écrans de /manage/ récemment ajoutés se heurtent à des lacunes de ce côté là.

C'est l'idée même de mélanger API et OIDC qui ne devrait pas apparaitre dans les interfaces, pour moi.

J’entends l’argument, je suis à cours d’idées de proposition qui iraient dans ce sens. Pour moi il y a la nécessité :
· pour les clients OIDC d’accéder à l’API,
· pour l’API a2 de savoir qu’il faut interposer le système de pseudonymat propre à OIDC sur les données renvoyées lorsque c’est un client OIDC qui appelle.
Ce mélange intrinsèque va forcément se répercuter dans les interfaces, je ne vois pas comment il pourrait en être autrement. Je suis preneur d’idées qui pourraient me détromper.

une config client OIDC entièrement fonctionnelle d’eux-mêmes

Mais pour moi une config client OIDC entièrement fonctionnelle existe déjà, sans avoir à y mélanger des bouts d'API.

J'entends (maintenant) que quand je parle de "config client OIDC" je parle juste d'un service OIDC relié à authentic pour faire du SSO, et que tu entends quelque chose d'autre, des trucs d'API pour lesquels je ne sais pas faire la part des choses entre ce qui serait quelque chose officiel OIDC et quelque chose qui a pu être un "bricolage" spécifique Authentic à un moment.

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

une config client OIDC entièrement fonctionnelle d’eux-mêmes

Mais pour moi une config client OIDC entièrement fonctionnelle existe déjà, sans avoir à y mélanger des bouts d'API.

J'entends (maintenant) que quand je parle de "config client OIDC" je parle juste d'un service OIDC relié à authentic pour faire du SSO, et que tu entends quelque chose d'autre, des trucs d'API pour lesquels je ne sais pas faire la part des choses entre ce qui serait quelque chose officiel OIDC et quelque chose qui a pu être un "bricolage" spécifique Authentic à un moment.

Non, tu as raison, c’est moi qui imaginais ce flag has_api_access nécessaire à l’accès à l’endpoint UserInfo (et dans le cas où il aurait été à False ça aurait voulu dire "ce client ne reçoit que des infos de l’idtoken, il n’est pas autorisé à interroger le fournisseur OIDC indépendamment des séquences de connexion de l’usager"), je viens de vérifier et ce n’est pas le cas, mes excuses.

En fait ce flag n’est utilisé que pour nos bricolages pas du tout officiels OIDC. Je vais revert #71820.