Development #46533
connexion automatique des agents sur un IDP externe
0%
Description
On peut aujourd'hui exposer les boutons de connexion agent (via les IDPs d'une collectivité) uniquement aux agents.
On a la mécanique nécessaire pour déclencher la connexion automatique via l'IDP externe s'il est le seul exposé sur la page de connexion.
La connexion des agents devient donc transparente.
Il reste un souci: la mire de connexion disparaît et nous (les travailleurs EO) ne pouvons plus nous connecter au backoffice.
Ce ticket donc pour discuter des moyens pour qu'authentic reste un IDP proxy transparent pour les agents tout en nous laissant la possibilité de nous authentifier.
Demandes liées
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Je dirai de passer plutôt par un raccordement OIDC à cresson et virer le raccordement LDAP, mais je ne sais pas quelle condition on pourrait mettre pour que ça ne s'affiche que pour nous (évitons l'IP du vpn, c'est déjà assez chiant comment ça).
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Pourquoi on cache la mire de connexion au fait ? Il me semblait que le but était surtout de ne pas gêner les usagers avec un bouton uniquement pour les agents, dans l'autre sens c'est moins critique.
Mis à jour par Serghei Mihai il y a plus de 3 ans
Pour aller vers l'objectif du ticket #30960: authentic doit être complétement transparent pour les agents. Ils ouvrent leur session sur leur IDP, ils vont dans le backoffice de Publik sans action supplémentaire (le clic en plus sur un bouton).
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Ok, alors la seule possibilité est de trouver un moyen de faire la différence entre un agent de la ville et nous; est-ce qu'une plage IP serait possible pour deviner que ça vient de leurs locaux?
Mis à jour par Thomas Noël il y a plus de 3 ans
Benjamin Dauvergne a écrit :
Ok, alors la seule possibilité est de trouver un moyen de faire la différence entre un agent de la ville et nous; est-ce qu'une plage IP serait possible pour deviner que ça vient de leurs locaux?
Plutôt l'inverse, ne pas basculer quand c'est nos IP (l'IP de sortie vpn et pas mal d'autres sont connues, on peut même avoir une liste des IP "nsupdate" facilement) ?
Chercher les IP des villes, on va pas pouvoir suivre, ça va être "la cata au secours plus rien ne marche" quand ils changeront d'IP.
En alternative aux IPs, on pourrait imaginer pour nous gérer un header "X-Entrouvert: yes" ? C'est pas très compliqué à avoir en extension de navigo, et ça nous permettrait de facilement tester à la place d'un client...
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Thomas Noël a écrit :
L'idée des IPs c'était juste pour minimiser le travail dans a2 parce qu'elle est déjà exposé dans les conditions, mais à l'usage je pense que ce sera plus simple de faire les deux :En alternative aux IPs, on pourrait imaginer pour nous gérer un header "X-Entrouvert: yes" ? C'est pas très compliqué à avoir en extension de navigo, et ça nous permettrait de facilement tester à la place d'un client...
- au niveau de la condition mettre un truc genre
'X-Entrouvert' in headers(ce sera pas comme ça parce que les headers sont exposés bizarrement en WSGI) - au niveau d'haproxy ajouter le header en fonction de nos IPs.
Donc sans rien faire ça marche, si besoin on peut l'ajouter via notre navigateur.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Lié à Development #47084: donner accés aux entêtes HTTP dans les conditions d'affichage des fronts d'authentification ajouté