Development #30960
Mis à jour par Mikaël Ates il y a environ 5 ans
C'est à la fois un ticket pour une fonctionnalité précise et un ticket chapeau.
Ce ticket est un doublon de https://dev.entrouvert.org/issues/27447 mais ce dernier est difficile à exploiter.
L'objectif est ici de rester dans une description « non-technique » donc de modifier cette description pour ajuster le plan, puis de suivre son déroulement.
L'objectif est, sur un authentic proxy (à la fois FI et FS, SAML ou OIDC), de pouvoir rediriger automatiquement sur un FI en fonction de l'URL de destination sur le FS.
Cas d'usage : Sur un authentic de Publik, pouvoir rediriger automatiquement vers un FI tiers agents lorsque l'on accède à une URL de backoffice Publik, vers un FI tiers usagers lorsque l'on accède à une URL de frontoffice Publik.
Plusieurs axes de développement semble se dégager.
h3. Filtrer les sources à afficher à l'utilisateur
https://dev.entrouvert.org/issues/28215
Plus que les frontends, c'est bien les sources qu'il faut pouvoir filtrer, par exemple un FI OIDC du front OIDC.
h3. h3.. Lorsqu'il n'y qu'une source et quelle est remote par redirection, renvoyer dessus.
Il s'agit de :
https://dev.entrouvert.org/issues/28216
h3. Appliquer le filtrage selon la provenance (« hint »).
Une fois le mécanisme de filtrage possible, il faut ici avoir une méthode pour définir des filtres basés sur la provenance. On parle ici de « hint » qui est l'indication de la provenance par le FS.
De https://dev.entrouvert.org/issues/27447 :
<pre>
dans l'IdP
associer les modes d'authentification à des OU, ça existe déjà pour LDAP et pour OIDC mais pas pour SAML et surtout pas pour le mode base login/mdp,
attention aux modes probables ou déjà existant pouvant être attachés à plusieurs OU: OIDC par défaut est attaché à une OU en particulier, mais si on désigner un claim ou_slug alors il acceptera de créer des utilisateurs dans plusieurs OUs sans lien avec l'attribut OIDCProvider.ou, je ne sais pas si c'est bien ou mal, en tout cas ça casse la simplicitié initiale, un IdP = une OU ; idem LDAP on pourrait prévoir dans le futur de reproduire les OUs LDAP vers des OUs authentic
filtrer les OUs en fonction des hints et en déterminer les modes d'authentification actifs,
pouvoir récupérer le hint au niveau des feuilles de style de la page de login (une bête classe login-hint-{{ login_hint }} pour chaque login_hint après un str.split())
pouvoir injecter du contenu en page de login via un template différent venu de combo (taper sur /login/{{ login_hint }} plutôt que /login/ lors de la récupération du thème, comme ça on peut raconter des chose différentes aux agents)
</pre>
Je ne trouve pas de ticket relatif à cela.
h3. Adapter les modules publik pour indiquer la destination.
Il s'agit d'un ticket Publik mais je pointe cela ici pour la réalisation du cas d'usage.
De https://dev.entrouvert.org/issues/27447 :
<pre>
dans nos services (les briques Publik) pour émettre ces "hints", pour les agents on voit à peu près comment (sur un accès à /backoffice/ ou à un combo désigné "portail agent" émettre un login_hint=agent ou en SAML <eo:login_hint>agent</eo:login_htin> et mapper ça vers une ou des OUs agent, concernée )
</pre>
Je ne trouve pas de ticket relatif à cela.
Ce ticket est un doublon de https://dev.entrouvert.org/issues/27447 mais ce dernier est difficile à exploiter.
L'objectif est ici de rester dans une description « non-technique » donc de modifier cette description pour ajuster le plan, puis de suivre son déroulement.
L'objectif est, sur un authentic proxy (à la fois FI et FS, SAML ou OIDC), de pouvoir rediriger automatiquement sur un FI en fonction de l'URL de destination sur le FS.
Cas d'usage : Sur un authentic de Publik, pouvoir rediriger automatiquement vers un FI tiers agents lorsque l'on accède à une URL de backoffice Publik, vers un FI tiers usagers lorsque l'on accède à une URL de frontoffice Publik.
Plusieurs axes de développement semble se dégager.
h3. Filtrer les sources à afficher à l'utilisateur
https://dev.entrouvert.org/issues/28215
Plus que les frontends, c'est bien les sources qu'il faut pouvoir filtrer, par exemple un FI OIDC du front OIDC.
h3. h3.. Lorsqu'il n'y qu'une source et quelle est remote par redirection, renvoyer dessus.
Il s'agit de :
https://dev.entrouvert.org/issues/28216
h3. Appliquer le filtrage selon la provenance (« hint »).
Une fois le mécanisme de filtrage possible, il faut ici avoir une méthode pour définir des filtres basés sur la provenance. On parle ici de « hint » qui est l'indication de la provenance par le FS.
De https://dev.entrouvert.org/issues/27447 :
<pre>
dans l'IdP
associer les modes d'authentification à des OU, ça existe déjà pour LDAP et pour OIDC mais pas pour SAML et surtout pas pour le mode base login/mdp,
attention aux modes probables ou déjà existant pouvant être attachés à plusieurs OU: OIDC par défaut est attaché à une OU en particulier, mais si on désigner un claim ou_slug alors il acceptera de créer des utilisateurs dans plusieurs OUs sans lien avec l'attribut OIDCProvider.ou, je ne sais pas si c'est bien ou mal, en tout cas ça casse la simplicitié initiale, un IdP = une OU ; idem LDAP on pourrait prévoir dans le futur de reproduire les OUs LDAP vers des OUs authentic
filtrer les OUs en fonction des hints et en déterminer les modes d'authentification actifs,
pouvoir récupérer le hint au niveau des feuilles de style de la page de login (une bête classe login-hint-{{ login_hint }} pour chaque login_hint après un str.split())
pouvoir injecter du contenu en page de login via un template différent venu de combo (taper sur /login/{{ login_hint }} plutôt que /login/ lors de la récupération du thème, comme ça on peut raconter des chose différentes aux agents)
</pre>
Je ne trouve pas de ticket relatif à cela.
h3. Adapter les modules publik pour indiquer la destination.
Il s'agit d'un ticket Publik mais je pointe cela ici pour la réalisation du cas d'usage.
De https://dev.entrouvert.org/issues/27447 :
<pre>
dans nos services (les briques Publik) pour émettre ces "hints", pour les agents on voit à peu près comment (sur un accès à /backoffice/ ou à un combo désigné "portail agent" émettre un login_hint=agent ou en SAML <eo:login_hint>agent</eo:login_htin> et mapper ça vers une ou des OUs agent, concernée )
</pre>
Je ne trouve pas de ticket relatif à cela.