07:01 <discord_afpy> <lythari59> <debnet> Antoine le GOAT.
07:01 <discord_afpy> <lythari59> => Jme dit souvent ça. 😅
07:06 <entwanne> Vous allez me rendre chèvre 🐐
07:26 <debnet> Dites les gens, j'ai un problème à vous soumettre. Sur mon projet Django professionnel, j'ai eu une demande d'un gros client qui voudrait que la création de comptes ne passe plus par nous mais par leur système d'authentification interne car ils ont énormément de collaborateurs et ils ne veulent pas qu'ils aient un login/mot de passe à retenir alors qu'ils ont un SSO en interne. Du coup je dois réfléchir à la possibilité d'intégrer ça
07:26 <debnet> dans mon application tout à conservant l'authentification standard pour tous mes autres clients, et idéalement il faudrait que la création de ces comptes n'ouvre pas un accès administrateur à mon application (actuellement les comptes sont créés par nous et on envoie un lien d'activation par mail). Vous avez des idées pour mettre en place ce genre de fonctionnalité ?
07:26 <alain_afpy> WARNING !!! YAKAFOKON DETECTED !!!!
07:26 <debnet> Chut Alain.
07:27 <ChOcO-Bn> debnet: c'est quel SSO ?
07:27 <ChOcO-Bn> j'avais un middleware LDAP pour l'authentification il y a encore quelques mois (mais maintenant c'est l'auth django qui est devenu le point d'entrée, donc plus besoin de ldap)
07:31 <debnet> @ChOcO-Bn Justement je ne sais pas, je crois qu'ils ont un truc maison. Ils me disent qu'ils s'adapteront mais j'aimerais bien faire un truc cadré et standard.
07:32 <debnet> Du coup je suis un peu perdu je dois admettre, je ne sais pas quel bout le prendre.
07:34 <debnet> J'avais pensé à OAuth2 mais je suis un merde en authent et j'ai toujours eu du mal à comprendre ce truc.
07:35 <ChOcO-Bn> oauth2 il y a un middleware, on l'a implémenté il y a peu
07:35 <asyd> openid connect me parait suffisant (c'est un subset d'oauth2)
07:35 <ChOcO-Bn> django-oauth-toolkit==2.4.0 ca doit etre ca
07:35 <debnet> Ouais c'est ce que j'ai commencé à regarder.
07:35 <discord_afpy> <bronxae> Surtout si eux peuvent l’aménager de leur côté 👍
07:36 <debnet> En fait là où je comprends pas, c'est que je ne serai pas le auth provider, du coup comment je peux accepter des comptes qui viennent d'ailleurs ?
07:36 <debnet> Et est-ce que je peux les contraindre d'une certaine manière ?
07:37 <debnet> Genre les forcer à être ajoutés à un groupe ou une équipe, avec des permissions spécifiques.
07:37 <debnet> OpenID ça m'a l'air chouette sur le principe.
07:38 <entwanne> J'irais vers OpenID aussi, après s'ils ont un truc complètement maison avec un protocole maison, ben va falloir implémenter le dit protocole (redirections, token, validation, création de comptes) et c'est chiant
07:38 <asyd> avec openid tu peux très bien ne gérer que l'authentification, et garder donc l'authorisation chez toi, ou faire un mix des deux
07:39 <entwanne> <debnet> Et est-ce que je peux les contraindre d'une certaine manière ?
07:39 <entwanne> Oui, après la manière de faire dépendra de la lib que tu utiliseras pour.
07:40 <debnet> Si vous avez des pistes, je suis preneur. Je voudrais le minimum d'effort de notre côté, car forcément cet aspect ne sera que peu facturé.
07:40 <debnet> Si on ne peut avoir à gérer que l'autorisation, ça me va bien.
07:41 <debnet> Je ne connais pas du tout OpenID par contre, ça a l'air relou à mettre en place quand je vois la doc de OAuth Toolkit.
07:43 <asyd> la doc me faire dire que c'est plutot pour faire provider que consumer
07:45 <debnet> Il existe des outils pour tester tout ce bordel ? Genre avec un provider fictif connecté à notre application ?
07:50 <entwanne> J'ai un fake SSO de test que je m'étais codé si ça peut t'être utile https://wyz.fr/3J-2C
07:53 <debnet> Ça c'est intéressant, merci. Côté consumer je dois mettre quoi en place du coup ? Je vois qu'il y a des échanges de clés et tout.
07:53 <discord_afpy> <bronxae> Je suis pas sûre de comprendre la question, mais dans OAUth il y a une notion de "scope" qui permet de récupérer de l'information au passage. Par exemple, tu te connectes sur 9Gag avec ton compte LinkedIn, tu es connecté et en plus ça rappartie ton nom et ton avatar. Si le provider peut s'adapter, il peut t'envoyer par exemple une liste de rôles pour l'user, qu'ensuite toi tu traduis en groupes ou permissions
07:56 <discord_afpy> <bronxae> Le truc de l'OAuth c'est que c'était censé être un standard, tu coup je sais plus quel GAFAM se sont mis autour d'une table, ont décidé d'un truc en commun...et de chacun avoir leur spécificités. Je le vois comme le terme "REST" : tout le monde dit que son API est RESTful, alors que personne ne suit pile le standard de REST, tout le monde fait un peu à sa sauce
07:56 <discord_afpy> <bronxae> Comme SCRUM
07:56 <discord_afpy> <bronxae> Du moins c'était comme ça la dernière fois que j'ai mis les doigts dedans
07:58 <asyd> disons que les claims de base sont assez limité oui, par exemple y a pas de claim pour roles/groupes (et je trouve ça très con)
07:58 <debnet> bronxae: Le truc c'est que ce genre de demande va sans doute se reproduire. Dans les faits, tous les comptes créés sur notre application ont les mêmes droits, peu importe la provenance, mais j'aimerais qu'à la réception d'un token (?) je sache la provenance pour associer le compte à une équipe dédiée.
07:58 <entwanne> Côté consumer tu rediriges vers l'authorization_endpoint (/login dans mon exemple) en fournissant une redirect_uri à toi et un state que tu génères, le client sera ensuite redirigé vers cette redirect_uri avec en paramètre le même state et un code, puis tu peux utiliser ce code pour appeler l'API token_endpoint (/token) et récupérer un token jwt contenant les infos de ton utilisateur. Mais normalement tout ça devrait être
07:58 <entwanne> géré par la lib que tu trouveras
07:59 <debnet> entwanne: Tu avais utilisé quoi dans tes souvenirs ?
07:59 <debnet> Car ton bout de code là c'est un micro provider c'est ça ?
08:01 <entwanne> Ouais le code là c'est juste un provider de test. Pour le consumer c'était une implémentation maison (parce que basé sur un truc maison existant dans la codebase), mais je ne recommande pas. Je me dis que ce serait fou qu'il n'existe rien dans l'écosystème django pour ça
08:01 <alain_afpy> :loudspeaker: Appel à volontaires pour la PyConFR 2024 ! - https://discuss.afpy.org/t/appel-a-volontaires-pour-la-pyconfr-2024/2302
08:02 <asyd> https://mozilla-django-oidc.readthedocs.io/en/stable/installation.html#quick-start
08:03 <debnet> @entwanne J'imagine, mais j'ai l'impression qu'il y a beaucoup de limitations dans les librairies dont j'ai regardé la doc.
08:04 <debnet> La plupart des implémentations ont l'air d'être pour Django <= 4
08:04 <debnet> Typiquement le lien d'asyd c'est un truc qui n'a pas été mis à jour depuis 2021, c'est compatible uniquement avec Django 2.
08:04 <asyd> hmm 3 aussi d'après la doc
08:05 <asyd> mais oui je trouve ça surprenant que ça soit si peu a jour
08:05 <debnet> Ouais enfin bon on est à Django 5.1.1.
08:05 <entwanne> Ah. Ben après si tu dois l'implémenter maison ça n'a rien d'insurmontable : génération d'un state, redirection dans un sens, gestion de la redirection dans l'autre sens et appel API pour récupérer un token
08:05 <entwanne> Je m'étais basé sur cette doc pour mon implem https://developers.google.com/identity/openid-connect/openid-connect?hl=fr#python
08:05 <asyd> ah oui 5 en effet
08:06 <debnet> @entwanne Le truc que je comprends pas, c'est qu'il faut bien côté consumer "accepter" qu'on se connecte via un token mais en préciser les sources non ?
08:06 <debnet> Ou c'est openbar ?
08:06 <debnet> En fait je pense que j'ai du mal à comprendre la cinématique.
08:07 <debnet> Je vois bien le principe de double poignée de main, mais c'est niveau implémentation que je comprends pas.
08:07 <asyd> on parle bien que d'appels pour humain au fait ?
08:07 <debnet> Ouais, globalement mon client veut intégrer notre outil dans son extranet où tous ses utilisateurs sont connectés en permanence.
08:08 <entwanne> c'est plus ou moins openbar oui, tu fais confiance au fournisseur pour te renvoyer un email de compte valide chez lui, et t'as différents mécanismes (state + signature pour vérifier que tout va bien). Mais après le login final se situe de ton côté, donc tu peux ajouter toutes les limitations que tu veux
08:08 <debnet> Notre outil est un gros monolithe centralisé, les clients s'y connectent habituellement directement avec un login/mot de passe qu'ils choisissent quand on leur envoie un lien de création.
08:09 <debnet> @entwanne Ce que je veux dire, c'est que si j'implémente ça, n'importe quel SSO peut se connecter à mon appli? J'imagine que nous mais où est la restriction d'accès?
08:09 <debnet> s/que nous/que non
08:10 <entwanne> Ah ben non parce que c'est toi qui choisis vers quel SSO tu rediriges
08:10 <debnet> @entwanne Ah alors là va y avoir un soucis alors, car j'ai besoin d'un truc agnostique si un autre client vient me voir avec le même genre de demande.
08:11 <debnet> Ce qui arrivera d'ailleurs.
08:11 <asyd> tu peux faire un truc aussi simple que regarder l'IP source, si IP du client = login par le SSO associé au dit client
08:11 <debnet> Ca a l'air d'être infernal.
08:12 <entwanne> Ben dans tous les cas il faudra que tu conserves les infos concernant le SSO, mon provider est minimal mais pour un vrai truc tu as besoin d'envoyer un client_id et un client_secret aussi, ces infos dépendent du SSO
08:13 <debnet> Ah ça me parle ça, j'ai vu un truc comme ça dans django-oauth-toolkit.
08:13 <entwanne> Je sais que chez nous on fait ça par rapport à l'email de l'utilisateur : on a un formulaire de connexion dédié au SSO dans lequel on demande à l'utilisateur d'entrer uniquement son adresse email
08:15 <entwanne> à partir de l'email on identifie le nom de domaine et on regarde en DB si on a une configuration SSO (URL openid, client id, client secret) associée à ce domaine, et si c'est le cas on redirige vers l'url de login du sso en indiquant l'email et les infos nécessaires, puis ça fait la tambouille côté sso
08:15 <entwanne> si aucun sso n'est référencé chez nous associé à ce domaine, il ne se passe rien
08:15 <debnet> La configuration SSO est côté consumer ou provider ?
08:15 <debnet> Consumer j'imagine.
08:15 <debnet> C'est une solution maison ?
08:15 <entwanne> les deux je pense
08:16 <debnet> C'est d'un compliqué ce truc en vrai, ou alors c'est moi qui suis une merde ?
08:16 <entwanne> oui là c'est maison, mais le protocole openid est standard
08:17 <entwanne> mais tous les cas peuvent être un peu différents, nous on a un formulaire de connexion unique pour tous nos clients sur notre dashboard. Si tu as un dashboard / un formulaire de connexion par client, tu n'as pas besoin de tel mécanisme qui cherche à identifier quel SSO utiliser
08:19 <entwanne> le principe de base est assez simple je trouve (un aller-retour + un appel), c'est plus les conditions concernant ton environnement autour qui sont compliquées (est-ce que tu dois gérer plusieurs SSO, comment tu identifies quel SSO, comment tu veux gérer les comptes utilisateurs connectés via SSO)
08:22 <debnet> Ouais c'est exactement ça, tu mets le doigt sur mes problèmes.
08:22 <debnet> Ce que tu as mis entre parenthèses, c'est là où je pèche.
08:24 <entwanne> ouais, là-dessus y a pas de réponse universelle
08:29 <asyd> debnet: y a potentiellement plus simple sinon, a base de reverse proxy et d'IP dédiée
08:30 <debnet> C'est à dire ?
08:31 <asyd> si tu peux avoir une IP dédiée au client, tu peux mettre un proxy devant qui va se charger de faire l'auth (je parle toujours d'openid connect)
08:31 <asyd> auquel cas django n'aurait qu'a utiliser le bearer token
08:35 <debnet> Ah ouais non ça n'arrivera pas ça, le client n'a pas d'IP dédiée.
08:58 <asyd> je parle de toi
08:58 <asyd> ah oui pardon
09:25 <Mindiell> debnet: j'ai utilisé Keycloak pour ça.
09:25 <Mindiell> voir ici : https://collecte-pro.gouv.fr/presentation/
09:26 <Mindiell> si tu cliques sur Connexion, il te redirige vers une page d'authent keycloak qui te permet de sélectionner un moyen d'authentificaiton différent (là, c'est la CC, les ministères sociaux ou Cerbère (un truc des ministères)
09:26 <Mindiell> ils gèrent donc chacun leurs comptes, mais tout est centralisé
09:26 <Mindiell> et je peux créer des comptes directement dessus depuis mon djnago
09:27 <Mindiell> et, effectivement, tu gères les droits donnés aux profils depuis le keycloak, et il les transfère vers django où tu décides donc qui à droit à quoi
09:27 <Mindiell> l'intérêt c'est qu'ensuite, c'est tout à base de Keycloak et donc tu peux y connecter qui tu veux.
09:29 <Mindiell> s'pus moi qui le gère, mais le code est là : https://github.com/SocialGouv/collecte-pro
09:30 <debnet> Ouais mais du coup il faut un service intermédiaire.
09:30 <debnet> En l'occurrence ce keycloak.
09:30 <debnet> Qu'il faut bien faire tourner quelque part.
09:31 <Mindiell> ah oui, chez toi, tu as la main
09:31 <Mindiell> C'est un petit truc en java. Il est plutôt modulable, c'est pas mal fait sincèrement.
09:32 <Mindiell> non j'ai pas fait de Java, il se module via des ajouts de fichiers et cie.
09:33 <debnet> Là je vois que dans django-allauth y a la possibilité d'ajouter des serveurs OpenID Connect personnalisés.
09:33 <debnet> Ca pourrait répondre à mon besoin je pense.
09:41 <alain_afpy> Nouveautés de Python 3.13 - https://docs.python.org/3.13/whatsnew/3.13.html
09:54 <discord_afpy> <chadys> django-allauth c'est un peu la ref pour ces problématiques à ma connaissance.
09:54 <discord_afpy> <chadys> Et oui l'authentification c'est toujours une tannée sans nom à mettre en place avec un paquet de concepts à appréhender au début.
09:54 <discord_afpy> <chadys> Perso j'ai mis les mains dans du openLDAP et du ActiveDirectory et c'était bien relou alors même qu'il y a toutes les libs qu'il faut. Mais une fois que tu as la recette ça prend beaucoup moins de temps.
09:54 <discord_afpy> <chadys> Et pas de soucis en Django pour avoir plusieurs Backend en parallèle, il les test un à un. Donc en soit, si tu as pas trop trop de clients, tu peux même te passer de routage SSO intelligent et juste ajouter les backends dédiés au fur et à mesure dans l'ordre de priorité qui semble logique. Tant qu'il trouve pas d'user, il testera le backend suivant (ce qui évidemment n'est pas une stratégie viable si tu as 50 endpoint de SSO)
09:54 <discord_afpy> <chadys> https://docs.djangoproject.com/en/5.1/topics/auth/customizing/#specifying-authentication-backends
09:55 <discord_afpy> <chadys> je vois que ça parle de bar du vendredi soir dans le CR, ça m'intéresse 😄
09:56 <entwanne> Ouais faut que je m'occupe de réserver ça, c'est histoire de donner un lieu de rendez-vous pour les gens qui arriveraient là sans savoir trop quoi faire
09:56 <alain_afpy> WARNING !!! YAKAFOKON DETECTED !!!!
09:56 <entwanne> alain_afpy: Ben t'as qu'à le faire toi
09:56 <alain_afpy> entwanne: c'est une première...
10:00 <debnet> @chadys : la tannée c'est que j'ai l'impression de faire quelque chose d'inédit. Toute la documentation que je trouve parle d'être son propre provider mais jamais d'être un consumer répondant à plusieurs providers non officiels pour lesquels il me faudrait une configuration dédiée.
10:00 <debnet> Alors que de mon point de vue ça ne me paraît pas si incongru.
10:04 <Mindiell> jdcjdr, mais Keycloak est fait pour ça ;o)
11:19 <debnet> Je voulais utiliser ça: https://openidconnect.net/
11:19 <debnet> Mais on peut pas changer le redirect_uri pour tester.
11:19 <debnet> C'est un peu nul.
11:20 <debnet> Ou alors je comprends pas.
12:56 <debnet> Ah ouais allauth ça a l'air magique.
12:57 <entwanne> inch'allauth
13:25 <debnet> :')
13:32 <misc> ah ah
14:46 <discord_afpy> <melcore> entwanne, tu veux pas écrire ma conf sur l'humour en python ?
14:47 <entwanne> Non mais je veux bien profiter de ton slot pour faire la 2ème partie de ma conf :D
14:55 <asyd> debnet: hesite pas si jamais tu veux une petite demo d'openid connect au fait
15:38 <entwanne> j'essaie de faire un exemple plus complet d'interaction producer-consumer aussi
17:22 <entwanne> debnet: Voilà l'exemple plus complet en question https://gist.github.com/entwanne/816af177ebe2b6211f14c2b165102559
19:21 <debnet> entwanne: waaa tu t'es fait chier, merci. Je veux utiliser ton provider pour tester ma solution côté consumer.
19:21 <debnet> Vais*
19:29 <entwanne> ouais c'est précisément pour ça que je l'avais codé à la base :D
19:33 <debnet> entwanne: J'ai utilisé le truc d'Okto pour tester, et ça avait l'air de fonctionner.
19:34 <debnet> C'est juste qu'avec django-authall je dois cliquer sur un bouton côté consumer pour déclencher l'authentification.
19:34 <debnet> Je me demande si y a moyen de bypasser cette étape.
19:40 <misc> en injectant du js dans le template pour cliquer
19:40 <misc> (c'est comme ça qu'on faisait avec le blog de Fedora avant)
19:47 <debnet> @misc C'est d'une tristesse sans nom mais je garde la technique en tête. x)
20:06 <discord_afpy> <guyzmal> Hello 👋
20:50 <debnet> He be ça a été vite la négociation concernant la PEP 760.
20:59 <alain_afpy> Covoiturage retour pycon - https://discuss.afpy.org/t/covoiturage-retour-pycon/2303