Produits Entr'ouvert » Authentic 2

Ça fait un gros ticket quand même.

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

Qui chapeauterait des tickets comme #5541 et #6648 ?

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).

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

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

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 ?

À 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).

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).

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.

• 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.

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).

Là ok.

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.

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.

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.