Migration vers ProConnect #19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
En 2 phases : - effacement du token coté frontend - finalisation de la déconnexion coté backend
- ajouts des routes pesonnalisées OIDC pour les redirections vers le front-end - modification de certaines portions de `mozilla-django-oidc` avec une vue custom
Ainsi que sa configuration et la modification des routes pour permettre à la fois l'utilisation de ProConnect et d'Inclusion-Connect
En 2 étapes déjà gérées, mais cette fois-ci en véfifiant l'état du paramètre `state` passé par ProConnect (sécurité).
Dans la configuration précédente, seule l'identification par OIDC était possible. Mais la partie admin de Django à besoin de l'identification par "modéle" (qui est celle par défaut). Les deux oexistent sereinement maintenant.
Même si on n'en fait encore rien, le point de récupération de la donnée est identifié dans le code.
Résidu des tests, maintenant l'absence d'e-mail doit lever une exception.
On peut encore choisir entre Inclusion Connect et ProConnect via la var-env OIDC_AUTH_BACKEND (par défaut `proconnect`)
ggounot
requested changes
Oct 23, 2024
There was a problem hiding this comment.
Sacré travail. C'est propre et très bien documenté. Chapeau !
Petit soucis cependant :
Après avoir fait une recherche, je me connecte avec Pro Connect.
Mon URL passée par par le paramètre next est : /recherche?city=75112&cl=Paris (75)&l=Rue de Lyon 75012 Paris&lat=48.849221&lon=2.370927
À la fin du processus d'identification, je suis redirigé vers : /recherche?city=75112
Il y a donc perte de paramètres de l'URL.
En revanche, quand je me connecte à partir d'une page service avec seulement l'ID de la recherche dans l'URL : /services/bimbamjob-jlgu-titre-professionnel-?searchId=194805 je suis bien redirigé vers cette exacte URL.
ikarius
force-pushed
the
pro-connect-migration
branch
2 times, most recently
from
6cb5cfe to
963688e
Compare
Moyen détourné de reporter la responsabilité de la validité des subs fournis vers ProConnect (ce qui est présentement le cas).
L'affichage vers Inclusion Connect est toujours possible.
ikarius
force-pushed
the
pro-connect-migration
branch
2 times, most recently
from
656ab6e to
3568862
Compare
ggounot
reviewed
Oct 24, 2024
ikarius
force-pushed
the
pro-connect-migration
branch
2 times, most recently
from
a1b2961 to
f962869
Compare
ikarius
force-pushed
the
pro-connect-migration
branch
from
842f064 to
84b1099
Compare
ggounot
reviewed
Oct 25, 2024
ikarius
force-pushed
the
pro-connect-migration
branch
from
84b1099 to
a323054
Compare
ikarius
force-pushed
the
pro-connect-migration
branch
from
a323054 to
1ac6063
Compare
|
Je viens de marquer les deux dernières correction de typos comme terminées. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ℹ️ PR créée à partir des PR originales gip-inclusion/dora-back#325 et gip-inclusion/dora-front#460 suite à la création du monorepo.
Backend migration ProConnect
Cette PR ajoute la couche technique OIDC nécessaire à une connexion à ProConnect (PC).
La couche de connexion Inclusion-Connect (IC) reste en place comme solution de repli en cas de problèmes lors du déploiement de PC.
Utilisation de mozilla-django-oidc
La quasi-totalité du flow OIDC est géré par la librairie
mozilla-django-oidcchoisie pour sa simplicité et parce que déjà utilisée par d'autres startups de l'écosystème beta.gouv.Son code est simple, lisible et peut-être facilement assimilé et étendu au besoin (ce qui est notre cas).
La mise en oeuvre de
mozilla-django-oidcest essentiellement déclarative :la plupart des actions, endpoints, callbacks .. sont configurables via de simple `settings Django.
Pour les aspects :
- création et récupération d'utilisateur,
- personnalisation des interactions : SAFIR, SIRET ...
- déconnexion
certaines portions de la librairie ont dues être enrobées ou étendues pour ajouter ces fonctionnalités.
Configuration de Django pour PC :
Voir tous les paramètres Django préfixés
OIDC_, ainsi que :-
LOGIN_REDIRECT_URL-
LOGOUT_REDIRECT_URL: pour les 2 étapes de déconnexion,-
OIDC_CALLBACK_CLASS: pour le gestionnaire d'identification personnalisé.Description des particularités DORA / PC
Connexion au frontend
Pour la connectique IC, certaines parties du flow OIDC sont implémentées coté frontend (appels initiaux, callbacks).
Pour PC, tout est centralisé au niveau du backend.
Une fois le flow OIDC terminé, un token DRF est transmis à la partie frontend pour être stocké sous forme d'entrée
localStorage(même mécanisme que pour la connexion actuelle avec IC).Ce mécanisme devra être revu, ou au moins renforcé une fois IC complètement décommissionné.
Ajouts d'étapes intermédiaires dans le flow OIDC
oidc/oidc_logged_inAprès le callback d'identification OIDC pour permettre :
- de gérer correctement la redirection en cas de
next_url,- de passer le token DRF au frontend.
oidc/oidc_pre_logoutUne déconnexion complète avec PC nécessite 2 étapes, dans l'ordre :
Mal gérer cette phase mène à des états de connexion instables et dans certains cas des problèmes de redirections infinies.
Adaptation de certaines fonctions OIDC
Essentiellement représentées par des vues Django et le gestionnaire d'identification.
Vue
CustomLogoutViewEnrobe la vue de déconnexion de
mozilla-django-oidcpour permettre les deux étapes :Vue
CustomAuthorizationCallbackViewPermet essentiellement de bien gérer le paramètre
next_urlet d'effectuer correctement la redirection entre backend et frontend après une identification réussie.Gestionnaire
OIDCAuthenticationBackendLa création d'un gestionnaire d'identification personnalisé est nécessaire pour plusieurs raisons.
D'abord à cause d'un problème (?) d'implémentation par PC lors du retour du token JWT.
Le type de contenu de la réponse n'est pas celui attendu, et un reformatage du token est nécessaire pour éviter une erreur de traitement (voir
get_user_info).Ensuite les traditionnelles étapes de création ou de récupération d'un utilisateur existant après une identification réussie doivent être améliorés pour :
subOIDC en base (pour l'instant pas utilisé).Voir les méthodes :
get_user,update_user,create_user,get_user_info: pour le reformatage du token.Frontend migration ProConnect
Cette PR n'est pas prête pour la production car elle contient les accès aux 2 systèmes d'identification (IC et PC).
Assez peu de choses sur la partie frontend, la plupart des actions du flow OIDC étant effectuées coté backend.