Project

General

Profile

Development #39406

Fournir dans le backoffice (/manage/) des écrans de configuration de la gestion et de la fourniture des identités

Added by Paul Marillonnet over 1 year ago. Updated 12 months ago.

Status:
En cours
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
30 Jan 2020
Due date:
05 Oct 2020
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

En l'état actuel il faut passer par le /admin/ django, dont l'interface utilisateur actuelle ne correspond pas aux choix de simplification et de masquage de la complexité des écrans de configuration dans Publik.

De là à, comme discuté par courriel, voir disparaître le /admin/, je ne sais pas.
Mais, encore pour rebondir sur ces discussions, ça pourrait notamment réduire la charge de travail nécessaire de consolidation de la documentation d'Authentic.


Files

login-settings.png (162 KB) login-settings.png Frédéric Péters, 18 Apr 2020 01:49 PM
a2-reorder.png (106 KB) a2-reorder.png Frédéric Péters, 20 Apr 2020 12:05 PM
a2-add-provider.png (105 KB) a2-add-provider.png Frédéric Péters, 20 Apr 2020 12:05 PM
authentic-sp-saml.png (175 KB) authentic-sp-saml.png Serghei Mihai, 30 Oct 2020 10:28 AM
Authenticators-FC.png (152 KB) Authenticators-FC.png Serghei Mihai, 30 Oct 2020 10:35 AM
Authenticators - SAML.png (242 KB) Authenticators - SAML.png Serghei Mihai, 03 Nov 2020 12:24 PM
Authenticators - OIDC.png (271 KB) Authenticators - OIDC.png Serghei Mihai, 03 Nov 2020 12:24 PM
Authenticators-Home.png (8.67 KB) Authenticators-Home.png Serghei Mihai, 04 Nov 2020 02:20 PM

Related issues

Related to Authentic 2 - Development #5541: Add a page to manage providersNouveau19 Sep 2014

Actions
Related to Authentic 2 - Development #6648: Allow managing LDAP servers from the managerNouveau09 Mar 2015

Actions
Related to Plugin FS FranceConnect - Development #29246: Interface de configurationNouveau20 Dec 2018

Actions
Related to Authentic 2 - Development #41671: écran de configuration de la connexion par mot de passeNouveau14 Apr 2020

Actions
Related to Authentic 2 - Development #41876: pouvoir agir sur l'ordre d'affichage des blocs d'authentification sur la page de connexionFermé20 Apr 2020

Actions
Related to Gadjo - Development #47132: avoir une icône pour la gestion de l'authentificationRejeté29 Sep 2020

Actions
Related to Gadjo - Development #47902: style pour les titre des sections désactivéesSolution déployée20 Oct 2020

Actions
Related to Gadjo - Development #47901: style pour lien-bouton en titre de sectionSolution déployée20 Oct 2020

Actions
Related to Gadjo - Development #48140: ne pas afficher (optionnel) sur les cases à cocherSolution déployée30 Oct 2020

Actions
Related to Publik - Development #49198: Paramétrage poussé d'Authentic via l’interface graphiqueNouveau08 Dec 2020

Actions
Related to Authentic 2 - Development #53902: avoir une classe de base pour les modèles de gestion des moyens d'authentificationEn cours10 May 2021

Actions
Related to Authentic 2 - Development #20697: Avoir une interface de configuration en backoffice permettant de poser des configurations aujourd'hui en settingsNouveau14 Dec 2017

Actions

History

#1

Updated by Benjamin Dauvergne over 1 year ago

Ça fait un gros ticket quand même.

#2

Updated by Paul Marillonnet over 1 year ago

Je voyais vraiment ça comme un « ticket-chapeau ».

#3

Updated by Mikaël Ates over 1 year ago

Qui chapeauterait des tickets comme #5541 et #6648 ?

#4

Updated by Paul Marillonnet over 1 year ago

#5

Updated by Paul Marillonnet over 1 year ago

#6

Updated by Paul Marillonnet over 1 year ago

Mikaël Ates a écrit :

Qui chapeauterait des tickets comme #5541 et #6648 ?

Merci (je n'avais pas pensé à chercher en anglais des sous-tickets candidats préexistants).

#7

Updated by Frédéric Péters over 1 year ago

#8

Updated by Frédéric Péters over 1 year ago

  • Related to Development #41671: écran de configuration de la connexion par mot de passe added
#9

Updated by Frédéric Péters over 1 year ago

À titre d'illustration/maquette possible, sur la forme que ça pourrait prendre, pour qui voudrait avancer là-dessus, image attachée.

#10

Updated by Paul Marillonnet over 1 year ago

C'est de la balle, merci pour la maquette. Dès que j'ai bouclé la migration à django 2.2 je m'y colle.

#11

Updated by Serghei Mihai over 1 year ago

  • Related to Development #41876: pouvoir agir sur l'ordre d'affichage des blocs d'authentification sur la page de connexion added
#12

Updated by Frédéric Péters over 1 year ago

Maquette avec la fenêtre d'ajout d'un fournisseur (exemple, on peut aussi imaginer quelques champs supplémentaires/communs, genre un libellé); et maquette avec l'ordre d'affichage.

#13

Updated by Benjamin Dauvergne over 1 year ago

Il faut prendre en compte les OUs, en fait ces écrans devraient venir en dessous de chaque OU, ça ne peut pas être global.

#14

Updated by Frédéric Péters over 1 year ago

Les méthodes d'authentification viennent avant l'authentification de l'utilisateur, ces paramètres ne sont aujourd'hui pas liés à une OU, comment cela se lierait-il à une OU ?

#15

Updated by Benjamin Dauvergne over 1 year ago

À part login/mdp sur modèles toutes les autres sont liées à une OU (ldap, oidc) sauf SALM où je pense que ça fait juste n'importe quoi actuellement (des utilisateurs sans OU).

#16

Updated by Frédéric Péters over 1 year ago

Ok, mais ça indique pour moi plutôt alors qu'il faut inclure un sélecteur d'OU dans le paramétrage, parce qu'on reste sur une seule page de connexion.

Pour la partie LDAP, je ne l'imaginais pas sur cet écran. (un écran similaire, avec sans doute là aussi un a priori pour une sélection de l'OU dans le paramétrage, plutôt qu'un écran par OU).

#17

Updated by Benjamin Dauvergne over 1 year ago

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

Ok, mais ça indique pour moi plutôt alors qu'il faut inclure un sélecteur d'OU dans le paramétrage, parce qu'on reste sur une seule page de connexion.

Pour la partie LDAP, je ne l'imaginais pas sur cet écran. (un écran similaire, avec sans doute là aussi un a priori pour une sélection de l'OU dans le paramétrage, plutôt qu'un écran par OU).

Ça veut dire que plusieurs collectivités ne pourront jamais gérer leur raccordement LDAP/SAML elle même sans un cas multico, sauf à toucher à tout; j'ai toujours envisagé les OU comme le moyen de cloisonner le BO d'a2 en mode multitenant dans une même instance (et ça marche déjà pour rôles et les utilisateurs). Je trouverai dommage d'abandonner cette objectif pour les services.

Ça n'empêche pas que certains trucs resteront globaux comme :
  • la protection contre les attaque force brut login/mdp (parce qu'on a qu'un formulaire pour tout le monde)
  • les certificats RSA/DSA pour SAML ou OIDC (parce qu'on qu'un idp pour tout le monde)

La gestion des mots de passe, de la validation des mails, de l'unicité du mail ou du username, et la politique de nettoyage des comptes sont déjà par OU.

#18

Updated by Frédéric Péters over 1 year ago

veut dire que plusieurs collectivités ne pourront jamais gérer leur raccordement LDAP/SAML elle même dans un cas multico

Le même écran peut être utilisé, en affichant uniquement les raccordements liés à l'OU en question.

Je trouve utile pour l'administrateur d'avoir cette vue d'ensemble, plutôt qu'avoir à visiter n OU en se disant que peut-être la commune unetelle est reliée à un LDAP. (et je pense aussi ce cas de l'administrateur technique "global" plus commun que la délégation du paramétrage des annuaires à chacune des communes d'une interco).

#19

Updated by Benjamin Dauvergne over 1 year ago

Là ok.

#20

Updated by Paul Marillonnet over 1 year ago

  • Assignee set to Paul Marillonnet
#21

Updated by Serghei Mihai over 1 year ago

  • Assignee deleted (Paul Marillonnet)

Je vais prendre à mon retour de congés (le 10 août).

#22

Updated by Serghei Mihai about 1 year ago

  • Due date set to 14 Sep 2020
  • Assignee set to Serghei Mihai
#23

Updated by Serghei Mihai about 1 year ago

  • Due date changed from 14 Sep 2020 to 28 Sep 2020
#24

Updated by Serghei Mihai about 1 year ago

  • Due date changed from 28 Sep 2020 to 05 Oct 2020

Ça sera pour la prochaine itération.

#27

Updated by Serghei Mihai about 1 year ago

  • Related to Development #47132: avoir une icône pour la gestion de l'authentification added
#28

Updated by Serghei Mihai 12 months ago

#29

Updated by Serghei Mihai 12 months ago

#30

Updated by Serghei Mihai 12 months ago

  • Status changed from Nouveau to En cours

Branche à jour avec des tests.
Il manque la possibilité d'ordonner les blocs d'authentification.

J'ai perdu pas mal de temps à essayer de faire un widget permettant de définir le mapping entre les attributs SAML/OIDC et ceux du profil usager, sans arriver à un résultat qui me plaise. Je me laisse ça comme amélioration pour plus tard et me contente d'un champ JSON.

Une petite vidéo de l'usage (les traductions ne sont pas faites): https://perso.entrouvert.org/~smihai/authenticators.mp4

#31

Updated by Frédéric Péters 12 months ago

J'ai juste regardé la vidéo.

Je trouve que le feedback du titre grisé est suffisant, plutôt qu'aller décaler en hauteur les blocs via un (django.contrib.)message.

Utile aussi de travailler les styles pour réduire la hauteur, cf par exemple hobo qui range les scopes oidc en colonnes.

Communément il me semble qu'on ajoute plutôt du SAML en 1/ pointant une URL 2/ uploadant un fichier; je trouve curieuse l'utilisation d'un textarea. Pour l'oidc je me demande à quel point le .well-known/... est courant dans les implémentations, s'il est courant il pourrait y avoir un seul champ URL, plutôt qu'un champ par endpoint.

De manière plus générale, si une popup est plus haute que l'écran autant en faire une vraie page; mais plutôt je serais pour que l'ajout se fasse en réduisant le nombre de champs, libre ensuite d'ajuster le paramétrage. (par exemple pas besoin de lister les scopes si la valeur par défaut est ok).

~~

Je pensais aussi que côté gadjo on n'affichait plus "(optionnel)" pour les cases à cocher; et les formulaires d'ajout et de modification devraient être cohérents, là on a des astérisques à l'ajout et des (optionnel) à la modification.

#32

Updated by Serghei Mihai 12 months ago

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

Je trouve que le feedback du titre grisé est suffisant, plutôt qu'aller décaler en hauteur les blocs via un (django.contrib.)message.

Je trouvais utile d'afficher le message notamment quand on désactive un bloc qui n'est visible qu'en scrollant la page, mais le grisé devrait suffire.

Utile aussi de travailler les styles pour réduire la hauteur, cf par exemple hobo qui range les scopes oidc en colonnes.

En effet, zappé les styles, rajouté.

Communément il me semble qu'on ajoute plutôt du SAML en 1/ pointant une URL 2/ uploadant un fichier; je trouve curieuse l'utilisation d'un textarea.

J'ai fait un peu par analogie avec la gestion des SP dans l'admin, ou on pointe une URL ou un fichier mais c'est le contenu qui est important pour prendre en compte le SP.
Cela permet aussi un peu de "voir" les métadonnées. Parmi tes suggestions je préfère l'upload d'un fichier au lieu de pointer une URL car dans pas mal de cas quand nous demandons les métadonnées on nous file un fichier et non une URL.

Pour l'oidc je me demande à quel point le .well-known/... est courant dans les implémentations, s'il est courant il pourrait y avoir un seul champ URL, plutôt qu'un champ par endpoint.

J'en ai aucune idée. Peut-être les GI men en savent plus. Ici je suis parti sur un ModelForm.

De manière plus générale, si une popup est plus haute que l'écran autant en faire une vraie page; mais plutôt je serais pour que l'ajout se fasse en réduisant le nombre de champs, libre ensuite d'ajuster le paramétrage. (par exemple pas besoin de lister les scopes si la valeur par défaut est ok).

Sur un écran dont la hauteur fait 800px la popup FC s'affiche entièrement.
Idée à côté: il y aurait peut-être ici un peu de travail sur l'amélioration des libellés des scopes, reprendre ceux qui sont définis dans le backoffice client dans FC.

~~

Je pensais aussi que côté gadjo on n'affichait plus "(optionnel)" pour les cases à cocher;

Cela a été fait uniquement dans publik-base-theme: #46436, je fais un ticket pour gadjo.

et les formulaires d'ajout et de modification devraient être cohérents, là on a des astérisques à l'ajout et des (optionnel) à la modification.

en effet, zappé l'attribut css_class des formulaires.

#33

Updated by Serghei Mihai 12 months ago

  • Related to Development #48140: ne pas afficher (optionnel) sur les cases à cocher added
#34

Updated by Frédéric Péters 12 months ago

De manière plus générale, si une popup est plus haute que l'écran autant en faire une vraie page (...)

Sur un écran dont la hauteur fait 800px la popup FC s'affiche entièrement.

Je parlais de manière générale (en voyant dans ta vidéo que l'ajout SAML dépasse), surtout pour noter que réduire le nombre de champs initialement dans la popup serait je trouve une bonne idée.

#35

Updated by Serghei Mihai 12 months ago

Ok, je fais 2 formulaires séparés pour l'ajout et l'édition d'un authenticator.
Rajouté également la possibilité de changer l'ordre d'affichage.

#36

Updated by Benjamin Dauvergne 12 months ago

Il est parti beaucoup trop gros ce ticket, j'aurai préféré avoir une vision de ce qui allait être fait techniquement en dehors des mockups.

Le fait de vouloir mettre plusieurs formulaires sur une seule page rend les choses très complexes (typiquement pour les mappings ça va être galère, autant gérer ça sur plusieurs pages), je préférerai une page de visualisation, avec des informations minimales (le nom, le type, si c'est conditionné ou pas) et qui permet de gérer l'ordre et changer des petits choses via des popups comme le nom d'un bouton, un message d'intro, la condition, etc... Après pour chaque type de système d'authentification une page formulaire de création et édition, ou alors une page de visualisation plus complète avec pour chaque élément un mini-formulaire en popup (pour la condition d'affichage, à la façon des formulaires/workflow w.c.s.).

Chaque système d'authentification devrait tenir sur 2/3 lignes pas plus sur cette page d'accueil.

Aussi un stockage des settings je ne pense pas que ça faisait parti des choses dont on avait parlé les dernières fois; ça va marcher pour FranceConnect parce qu'on a jamais qu'une seule instance et puis devenir compliqué pour le reste. Je pense plutôt à quelque chose de plus simple comme un modèle de ce genre :

Ça me dérange pas qu'on introduise un stockage de settings, mais j'ai peu que si on commence à s'en servir pour un truc un peu structuré on ne s'en passe jamais et on se sente permis d'y mettre n'importe quoi.

Authenticator :
 - id
 - uuid
 - name
 - order
 - slug : slugfield
 - type : charfield = (login/password, fc)
 - data : jsonfield = (ex. pour FC) {'platform'': 'integration', 'client_id': 'xxx', 'mappings': [...]}
                      (ex. pour login/password) {'use_ou_field': False, 'accept_email_authentication': .., 'retry_timeout_factor': .. ,'retry_timeout_duration':...} (<- on est pas obligé de tout transférer des settings et exposer d'un coup c'est pour donner une idée)

Ça n'est pas plus compliqué qu'un stockage de setting mais c'est plus propre et ça permet de se débarrasser des settings.

J'ai commencé ça mettre les choses dans authentic2/apps, continuons.

Après pour la définition des pages/formulaires on repart de classes AuthenticatorType qui fournissent des URLs et des formulaires pour éditer data (à la manière des modèles passerelle).

Coté OIDC et SAML on pourra définir un modèle hérité et ne pas tout mettre dans data si ça un sens (et pour OIDC faire hériter OIDCProvider de Authenticator) pour essayer de faire converger les choses.

#38

Updated by Serghei Mihai 12 months ago

Benjamin Dauvergne a écrit :

Il est parti beaucoup trop gros ce ticket, j'aurai préféré avoir une vision de ce qui allait être fait techniquement en dehors des mockups.

Le fait de vouloir mettre plusieurs formulaires sur une seule page rend les choses très complexes (typiquement pour les mappings ça va être galère, autant gérer ça sur plusieurs pages), je préférerai une page de visualisation, avec des informations minimales (le nom, le type, si c'est conditionné ou pas) et qui permet de gérer l'ordre et changer des petits choses via des popups comme le nom d'un bouton, un message d'intro, la condition, etc... Après pour chaque type de système d'authentification une page formulaire de création et édition, ou alors une page de visualisation plus complète avec pour chaque élément un mini-formulaire en popup (pour la condition d'affichage, à la façon des formulaires/workflow w.c.s.).

Chaque système d'authentification devrait tenir sur 2/3 lignes pas plus sur cette page d'accueil.

Ok, ça serait quelque chose comme dans la capture jointe.

Ça me dérange pas qu'on introduise un stockage de settings, mais j'ai peu que si on commence à s'en servir pour un truc un peu structuré on ne s'en passe jamais et on se sente permis d'y mettre n'importe quoi.

Le but de ce stockage est de ne pas chambouler tout le fonctionnement existant qui se base sur des settings.json tapés dans les répértoires des tenants ou des variables transmises par Hobo.
Certains settings (surtout pour LoginPassword) avec des valeurs par défaut ne sont pas exposés dans le manager mais ont un impact.

J'ai commencé ça mettre les choses dans authentic2/apps, continuons.

Après pour la définition des pages/formulaires on repart de classes AuthenticatorType qui fournissent des URLs et des formulaires pour éditer data (à la manière des modèles passerelle).

Coté OIDC et SAML on pourra définir un modèle hérité et ne pas tout mettre dans data si ça un sens (et pour OIDC faire hériter OIDCProvider de Authenticator) pour essayer de faire converger les choses.

Je regarde tout ça.

#39

Updated by Pierre Cros 10 months ago

  • Related to Development #49198: Paramétrage poussé d'Authentic via l’interface graphique added
#40

Updated by Serghei Mihai 5 months ago

  • Related to Development #53902: avoir une classe de base pour les modèles de gestion des moyens d'authentification added
#41

Updated by Frédéric Péters 5 months ago

  • Related to Development #20697: Avoir une interface de configuration en backoffice permettant de poser des configurations aujourd'hui en settings added

Also available in: Atom PDF