Development #67875
interface ajout d'un SSO SAML, difficultés de compréhension
0%
Description
Dans la nouvelle interface d'ajout d'un fournisseur SAML, on a quelques champs un peu difficile à comprendre. Que faut-il indiquer, à quoi servent-ils, etc.
- « Domaine : Domaine à associer à l’utilisateur, utilisé lors de l’affectation d’un identifiant. » . C'est une notion qui n'est ni dans SAML ni dans Authentic... de quoi s'agit-il ? Par défaut c'est "saml" qui est proposé. La phrase d'aide parle de « l’affectation d’un identifiant » ce qui obscurcit encore le truc :)
- « Politique de format du NameID : Le format du NameID à demander. ». C'est un simple input, il faudrait proposer un exemple au moins, pour comprendre ce qui est attendu.
- « Politique du NameID autorisant la création : » sauf que c'est une case à cocher... à quoi sert-elle ? On attendrait plutôt un verbe ici, pour savoir s'il faut faire ou pas "quelque chose", en fonction que la case est cochée ou pas.
Voilà, ce ticket juste pour mieux comprendre et si possible proposer de meilleurs textes ou traductions.
Fichiers
Révisions associées
authenticators: allow splitting configuration form (#67875)
Historique
Mis à jour par Paul Marillonnet il y a plus d'un an
Thomas Noël a écrit :
Dans la nouvelle interface d'ajout d'un fournisseur SAML, on a quelques champs un peu difficile à comprendre. Que faut-il indiquer, à quoi servent-ils, etc.
Oui, on a fait le choix de traduire alors qu’on utilisait jusque là les termes anglais du settings.json.
- « Domaine : Domaine à associer à l’utilisateur, utilisé lors de l’affectation d’un identifiant. » . C'est une notion qui n'est ni dans SAML ni dans Authentic... de quoi s'agit-il ? Par défaut c'est "saml" qui est proposé. La phrase d'aide parle de « l’affectation d’un identifiant » ce qui obscurcit encore le truc :)
C’est le "realm", il est notamment utilisé dans le username template, pour générer des username du genre <NameID>@<realm>.
- « Politique de format du NameID : Le format du NameID à demander. ». C'est un simple input, il faudrait proposer un exemple au moins, pour comprendre ce qui est attendu.
Là je pense qu’il faudrait un choix parmi "persistent", "temporaire (transient)" et "non spécifié". En l’état je pense que le comportement par défaut dans l’authn SAML du BO reste le même que lorsque ce format n’était pas spécifié dans le settings.json, à savoir un format persistent par défaut.
- « Politique du NameID autorisant la création : » sauf que c'est une case à cocher... à quoi sert-elle ? On attendrait plutôt un verbe ici, pour savoir s'il faut faire ou pas "quelque chose", en fonction que la case est cochée ou pas.
C’est une option un peu obscure de SAML pour permettre au SP de préciser que l’IdP ne doit pas créer de NameID pour l’usager qui se connecte s’il ne lui en connait pas déjà un. Si aucun NameID n’est connu alors le SSO échoue. Les exemples d’application dans les spécs SAML ne sont pas clairs. Je ne nous connais pas de raccordements où cette option serait à False, je pense qu’on pourrait retirer cette option de l’UI.
Mis à jour par Valentin Deniaud il y a plus d'un an
- Assigné à changé de Paul Marillonnet à Valentin Deniaud
Je vais m'occuper des ajustements proposés par Paul.
Mis à jour par Valentin Deniaud il y a plus d'un an
- Fichier 0001-authenticators-add-advanced-setup-view-67875.patch 0001-authenticators-add-advanced-setup-view-67875.patch ajouté
- Tracker changé de Support à Development
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Valentin Deniaud a écrit :
Je vais m'occuper des ajustements proposés par Paul.
Et en fait pas du tout, j'ai fait un tour sur le SaaS et la majorité des ces paramètres ne sont jamais modifiés, d'autres seulement à un endroit¹.
Il ne faut donc simplement pas les afficher dans la plupart des cas, pour ça je découpe le formulaire de configuration actuel en deux, la deuxième partie étant cachée dans sous un menu « Configuration avancée » accessible depuis la page d'édition classique.
¹ Les très rares endroits où un paramètre « avancé » est modifié peuvent être problématiques, car on risque de ne jamais aller consulter la page en question.
Actuellement la description affiche des champs spécifiés explicitement, s'ils sont non vides : description_fields = ['show_condition', 'metadata_url', 'metadata_path', 'metadata', 'provision'], liste déterminée arbitrairement selon un critère d'utilité.
On pourrait à la place avoir un fonctionnement automatique, c'est à dire afficher les champs qui ont une valeur différente de celle par défaut. À ce moment là un champ « avancé » modifié sautera aux yeux.
J'ajoute un patch pour faire ça ?
Mis à jour par Frédéric Péters il y a plus d'un an
¹ Les très rares endroits où un paramètre « avancé » est modifié peuvent être problématiques, car on risque de ne jamais aller consulter la page en question.
L'idée serait alors d'utiliser des onglets et l'onglet "Avancé" serait sur ce cas précis marqué d'une pastille pour indiquer qu'il y a quelque chose dedans.
afficher les champs qui ont une valeur différente de celle par défaut
J'ajoute un patch pour faire ça ?
Mais oui ça peut aider dès maintenant de faire ça.
Mis à jour par Valentin Deniaud il y a plus d'un an
Frédéric Péters a écrit :
L'idée serait alors d'utiliser des onglets et l'onglet "Avancé" serait sur ce cas précis marqué d'une pastille pour indiquer qu'il y a quelque chose dedans.
Ce n'est pas bizarre d'avoir un onglet "Avancé" tout blanc dans 99% des cas ? Ou on y mettrait aussi le bouton pour accéder à ces réglages ?
Mis à jour par Frédéric Péters il y a plus d'un an
Ce n'est pas bizarre d'avoir un onglet "Avancé" tout blanc dans 99% des cas ?
J'ai mal expliqué; je réfléchissais ainsi : la question d'afficher les trucs vient du fait qu'il y a le "formulaire de configuration actuel en deux" et de là "risque de ne jamais aller consulter la page en question"; la page en question étant la page "configuration avancé".
De là, je défaisais cette séparation du formulaire de configuration en deux pages distinctes, et réunies sur une seule page, avec des onglets, le fait qu'une configuration avancée soit posée serait visible par la pastille sur l'onglet. Et "risque de ne jamais aller consulter la page en question" n'existe plus vu qu'on est sur un seul écran de configuration.
Ensuite, si on arrive à un moment à ne rien avoir comme option qui mérite d'exister, très bien, on arrive aussi ainsi à éliminer le "risque de ne jamais aller consulter la page en question".
Mis à jour par Valentin Deniaud il y a plus d'un an
- Statut changé de Solution proposée à En cours
Compris, il s'agit de découper le formulaire en onglets. J'avais la tête dans les onglets de la page de présentation en oubliant qu'ils n'existent même pas encore (#67025).
Mis à jour par Frédéric Péters il y a plus d'un an
Note que ça me va d'avoir ça plus tard, que la solution actuelle + uniquement afficher les paramètres avancés configurés, voire ne pas les afficher et accepter le "risque de ne jamais aller consulter la page en question", ça me va aussi.
Mis à jour par Valentin Deniaud il y a plus d'un an
- Fichier 0001-auth_saml-clarify-some-parameters-67875.patch 0001-auth_saml-clarify-some-parameters-67875.patch ajouté
- Fichier 0002-authenticators-allow-splitting-configuration-form-67.patch 0002-authenticators-allow-splitting-configuration-form-67.patch ajouté
- Statut changé de En cours à Solution proposée
Revoici avec des onglets pour le formulaire (autant partir direct là dessus pour éviter d'avoir à défaire plus tard).
Mis à jour par Valentin Deniaud il y a plus d'un an
- Fichier avancé.png avancé.png ajouté
- Fichier général.png général.png ajouté
Mis à jour par Paul Marillonnet il y a plus d'un an
Valentin Deniaud a écrit :
Revoici avec des onglets pour le formulaire (autant partir direct là dessus pour éviter d'avoir à défaire plus tard).
Testé en local, relu. C’est top. Le découpage entre conf générale et avancée est nickel pour moi. Je vais vérifier avec l’auteur du ticket que cette nouvelle interface lui convient, et on pourra valider ensuite.
Mis à jour par Thomas Noël il y a plus d'un an
Paul Marillonnet a écrit :
Valentin Deniaud a écrit :
Revoici avec des onglets pour le formulaire (autant partir direct là dessus pour éviter d'avoir à défaire plus tard).
Testé en local, relu. C’est top. Le découpage entre conf générale et avancée est nickel pour moi. Je vais vérifier avec l’auteur du ticket que cette nouvelle interface lui convient, et on pourra valider ensuite.
J'aurais envoyé durée de vie ainsi que timeout des métadonnées dans la configuration avancée (je n'ai absolument jamais joué avec ça).
Aussi sur les copies d'écran les champs paraissent petit, surtout "condition" ou "chemin d'accès", y'a pas moyen de tous les passer en 100% de largeur ?
Pour le reste, oui, c'est cool top.
Mis à jour par Valentin Deniaud il y a plus d'un an
- Fichier 0001-auth_saml-clarify-some-parameters-67875.patch 0001-auth_saml-clarify-some-parameters-67875.patch ajouté
- Fichier 0002-authenticators-allow-splitting-configuration-form-67.patch 0002-authenticators-allow-splitting-configuration-form-67.patch ajouté
Thomas Noël a écrit :
J'aurais envoyé durée de vie ainsi que timeout des métadonnées dans la configuration avancée (je n'ai absolument jamais joué avec ça).
Déplacé (avec en plus un bout qui masque les champs si l'URL des métadonnées n'est pas renseignée).
Aussi sur les copies d'écran les champs paraissent petit, surtout "condition" ou "chemin d'accès", y'a pas moyen de tous les passer en 100% de largeur ?
Bien vu, tous les champs sont à 100% de largeur dans a2 mais là le CSS passait à côté à cause du form.as_p, changé en form|with_template et ça roule à nouveau.
Mikaël Ates a écrit :
Provisionner -> Approvisionner.
C'est sûrement plus français mais pas moins bizarre, je préfère carrément mettre le help_text à la place du libellé (Créer l’utilisateur si son identifiant n’existe pas déjà : oui/non).
Mis à jour par Thomas Noël il y a plus d'un an
- Statut changé de Solution proposée à Solution validée
Create user if their username does not already exists
Ok l'anglais et moi, mais c'est pas plutôt "its username" ?
Le reste me semble ok, je valide donc, parce que ça sera au pire bien traduit :)
Mis à jour par Valentin Deniaud il y a plus d'un an
Thomas Noël a écrit :
Ok l'anglais et moi, mais c'est pas plutôt "its username" ?
Je ne crois pas, le its ça se réfère à une chose pas à une personne, alors que le their se réfère à une personne de manière non genrée.
Mis à jour par Valentin Deniaud il y a plus d'un an
- Statut changé de Solution validée à Résolu (à déployer)
commit fb981b6a88776fe960585feebefb53b558dbca6b
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date: Tue Aug 16 16:57:02 2022 +0200
authenticators: allow splitting configuration form (#67875)
commit 6f9368a09a47b5d5dd3dddffae962778a651acb6
Author: Valentin Deniaud <vdeniaud@entrouvert.com>
Date: Mon Aug 22 11:27:40 2022 +0200
auth_saml: clarify some parameters (#67875)Mis à jour par Transition automatique il y a plus d'un an
- Statut changé de Résolu (à déployer) à Solution déployée
auth_saml: clarify some parameters (#67875)