Project

General

Profile

Bug #28215

permettre le filtrage des frontends d'authentification à exposer à l'usager

Added by Serghei Mihai about 1 year ago. Updated 12 days ago.

Status:
Solution proposée
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
21 Nov 2018
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Le(s) filtre(s) serai-en-t une expression python/django à placer dans les settings du tenant.

0001-misc-add-support-for-request-based-enable-conditions.patch View (10.5 KB) Serghei Mihai, 22 Nov 2018 03:50 PM

0002-misc-add-support-for-request-based-enable-conditions.patch View (11.7 KB) Serghei Mihai, 01 Feb 2019 04:43 PM

0001-auth-let-LoginPassowrd-frontend-handle-registration-.patch View (2.29 KB) Serghei Mihai, 01 Feb 2019 04:43 PM

0001-misc-add-support-for-enable-conditions-on-authentica.patch View (12.4 KB) Serghei Mihai, 03 Dec 2019 06:16 PM


Related issues

Related to Authentic 2 - Development #30960: Permetttre de faire d'authentic un IdP proxy transparent Nouveau 27 Feb 2019 31 May 2019
Related to Authentic 2 - Bug #31259: présenter les IDP OpenidConnect dans des blocks à part sur la page de login Solution déployée 11 Mar 2019
Related to Authentic 2 - Development #31218: registration: permettre au frontend LoginPassword de gérer la création du cmpte Solution déployée 08 Mar 2019

History

#3 Updated by Serghei Mihai about 1 year ago

Basé sur la branche du ticket #14475 (renommage des classes et modules d'authentification).

Il manque pas mal de tests et peut-être que la terminologie n'est pas la meilleure, mais l'idée est de pouvoir une simple expression pythonique pour activer chaque frontend d'authentification.
Il manque encore des tests: wip.

#4 Updated by Frédéric Péters about 1 year ago

À reculer un peu,

  • on aurait des conditions "wants_frontoffice" / "wants_backoffice"
  • genre une configuration pourrait être : FranceConnect:wants_frontoffice, KeyCloak:wants_backoffice.
    • l'usager arrive, les filtres sont joués, reste une seule méthode, l'autorun de #28216 est lancé, etc.

Mais, la situation GNM est différente, il y a une seule méthode, "oidc", mais celle-ci en cache deux (oidc vers GLC, oidc vers GLC/agents). Résultat cette mécanique de filtre ne peut pas y fonctionner.

(c'est un commentaire que j'ai fait dans les notes "bilan J1" du pad, sans doute j'aurais du la mettre en avant).

Selon moi, on a besoin d'une découpe supplémentaire, un module d'authentification (OIDC, FC, etc.) doit pouvoir exposer plusieurs frontends(?), et c'est à ce niveau que pourrait alors se jouer le filtrage de ce ticket.

  • OIDC (module d'authent)
    • explode
    • → frontends : OIDC[usagers], OIDC[agents]
    • filtre des frontends
    • → OIDC[agents]
      • un seul → autorun

#5 Updated by Benjamin Dauvergne about 1 year ago

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

À reculer un peu,

  • on aurait des conditions "wants_frontoffice" / "wants_backoffice"
  • genre une configuration pourrait être : FranceConnect:wants_frontoffice, KeyCloak:wants_backoffice.
    • l'usager arrive, les filtres sont joués, reste une seule méthode, l'autorun de #28216 est lancé, etc.

Mais, la situation GNM est différente, il y a une seule méthode, "oidc", mais celle-ci en cache deux (oidc vers GLC, oidc vers GLC/agents). Résultat cette mécanique de filtre ne peut pas y fonctionner.

Si parce que pour le frontend OIDC, chaque fournisseur OIDC représente une méthode différente.

(c'est un commentaire que j'ai fait dans les notes "bilan J1" du pad, sans doute j'aurais du la mettre en avant).

Selon moi, on a besoin d'une découpe supplémentaire, un module d'authentification (OIDC, FC, etc.) doit pouvoir exposer plusieurs frontends(?), et c'est à ce niveau que pourrait alors se jouer le filtrage de ce ticket.

  • OIDC (module d'authent)
    • explode
    • → frontends : OIDC[usagers], OIDC[agents]
    • filtre des frontends
    • → OIDC[agents]
      • un seul → autorun

Dans mon plan initial ce n'est pas la vue login() qui décide de lancer autorun, mais le frontend il faut pour cela deux méthodes (can_autorun() puis autorun()) ou bien prévoir qu'autorun retourne possiblement None.

Donc dans un fonctionnement avec None:
  • GNM -> un seul frontend = OIDC
  • appel à OIDCFrontend.autorun()
    • sélection d'au moins deux fournisseurs : autorun() retourne None
    • sélection d'un seul fournisseur : autorun() retourne HttpRedirect

Au passage il faut passer à autorun tout un tas de paramètre reçus par login, comme le nonce, next_url, etc..

#6 Updated by Frédéric Péters about 1 year ago

Si parce que pour le frontend OIDC, chaque fournisseur OIDC représente une méthode différente.

C'est peut-être un problème de vocabulaire mais il me semble que c'est ma proposition aussi, et qu'elle ne correspond pas à la série de patchs en cours de développement, #14475 change juste des noms, on reste avec OIDC = 1 Frontend^WAuthenticator, et ce ticket, il itère sur ces objets, pas un objet "méthode d'authentification" dessous.

#7 Updated by Serghei Mihai about 1 year ago

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

Si parce que pour le frontend OIDC, chaque fournisseur OIDC représente une méthode différente.

C'est peut-être un problème de vocabulaire mais il me semble que c'est ma proposition aussi.

Oui. Je revois mon idée pour prendre en compte ce cas d'usage.

#8 Updated by Benjamin Dauvergne about 1 year ago

Si on introduit maintenant un changement de structure avec des AuthMethod il faut passer sur authentic2-auth-fc aussi et peut-être d'autres modules externes, je préfèrerai que ce soit fait une fois ces modules externes réintégrés dans authnetic.

#9 Updated by Benjamin Dauvergne about 1 year ago

  • Status changed from Solution proposée to Nouveau

#10 Updated by Frédéric Péters about 1 year ago

(peut-être que tout ceci devrait être dans authentic, pas authentik)

À redéfinir le fonctionnement des frontends/méthodes d'authentification il faut peut-être inclure dans la réflexion également la partie "inscription" (qui aujourd'hui mélange un truc un peu en dur pour l'inscription locale/email et un mécanique "accumulation de blocs de frontends" simulaire à la page de login).

#11 Updated by Benjamin Dauvergne about 1 year ago

  • Project changed from Authentik to Authentic 2

Œuf corse.

#12 Updated by Serghei Mihai 11 months ago

Patch en plus pour ne pas mettre en dur le formulaire de création de compte sur la page d'enregistrement.

Je ne suis pas sûr de l'approche d'appeler l'autorun directement depuis le vue login j'aimerais qu'on puisse aussi laisser la main à l'usager de choisir son moyen d'authentification.
Je pense notamment au cas de 3 frontends: login/mdp, FranceConnect et un IDP dédié uniquement aux agents. Pour l'agent on peut souhaiter de jouer l'autorun immédiatement, mais l'usager doit pouvoir choisir.

Concernant la problèmatique des multiples fournisseurs OIDC je vois la possibilité de pouvoir les filtrer dans la condition d'affichage, genre: request.session.get('is_agent', False) and providers.filter(slug="idp-agents")

#13 Updated by Frédéric Péters 10 months ago

Concernant la problèmatique des multiples fournisseurs OIDC je vois la possibilité de pouvoir les filtrer dans la condition d'affichage, genre: request.session.get('is_agent', False) and providers.filter(slug="idp-agents")

Je trouve vraiment dommage de garder cette association "1 module d'authentification = 1 pavé de connexion", qui oblige derrière à inventer une notion de sous-pavé (un fournisseur oidc), qui fait que tu parles déjà de devoir dupliquer une mécanique de conditions. Je ne fais que me répéter.

#14 Updated by Mikaël Ates 10 months ago

  • Related to Development #30960: Permetttre de faire d'authentic un IdP proxy transparent added

#16 Updated by Serghei Mihai 19 days ago

  • Related to Bug #31259: présenter les IDP OpenidConnect dans des blocks à part sur la page de login added

#17 Updated by Serghei Mihai 19 days ago

  • Related to Development #31218: registration: permettre au frontend LoginPassword de gérer la création du cmpte added

#18 Updated by Serghei Mihai 12 days ago

En reprenant le principe de plus haut, avec possibilité de filtrer aussi les idp OIDC.

#19 Updated by Frédéric Péters 12 days ago

    A2_AUTH_PASSWORD_ENABLE_CONDITION=Setting(default=None, definition='Filters',
                                              names=('FRONTEND ENABLE CONDITION',)),

Je lis le code de app_settings et names me semble être un attribut permettant d'aller chercher, si le paramètre demandé n'existe pas, le paramètre sous un autre nom. Et ici, sous le nom "FRONTEND ENABLE CONDITION", avec des espaces, ça me semble farfelu.

                return eval(condition, context)

Discussion de fond, je serais pour éviter le Python tapable partout, que se passe par une condition Django. (mais je pense qu'il n'y aura pas accord sur ce commentaire, ne te lance surtout pas là-dedans tout de suite).

            except Exception, e:

Pensons à Python 3, Exception as e.

            providers = self.eval_enable_condition(app_settings.IDP_ENABLE_CONDITION, request,
                                                   providers=providers)

mais self.eval_enable_condition retourne un booléen. (?)

Ici, et dans l'autre, côté SAML, où on passe idps=idps, je ne pige pas trop le sens de l'affaire, pourquoi on ferait une comparaison sur base de la liste des IdP possibles. Alors ça s'éclaire en lisant le test, providers.filter(name='My IDP'), mais pour moi c'est retourner à mon commentaire 13 ci-dessus, un partage bizarre d'une même mécanique pour faire deux choses :

  • pour une méthode d'authentification comme le mot de passe avoir une condition qui retourne un booléen.
  • pour une méthode d'authentification comme oidc/saml, avoir une condition qui n'en est pas une qui est plutôt une expression filtrant une liste.

Pas fan du tout il y a dix mois, pas fan du tout aujourd'hui.

Très concrètement, pour mon usage GNM, j'aurais aimé pouvoir :

"A2_AUTH_MODULES_CONDITIONS": {
  "password": "request|is_for_backoffice",
  "oidc/glc": "not request|is_for_backoffice" 
}

ou dans la version précédente avec deux GLC,

"A2_AUTH_MODULES_CONDITIONS": {
  "oidc/glc-agents": "request|is_for_backoffice",
  "oidc/glc": "not request|is_for_backoffice" 
}

Ailleurs, pour un Chambéry,

"A2_AUTH_MODULES_CONDITIONS": {
  "password": "not request|is_for_backoffice",
  "franceconnect": "not request|is_for_backoffice",
  "saml/adfs": "request|is_for_backoffice" 
}

(et j'en reste ici à des settings, idéalement j'aimerais la condition portée par l'objet OIDCProvider, etc.)

Also available in: Atom PDF