richer integration with auth providers (at least oidc)

[albanm]

Maintien de la synchronisation des identités

Pour l'instant les infos sont récupérées à la création de compte et c'est tout. Il faut:

• récupérer un refreshToken à la création du compte au travers du fournisseur d'identité
• utiliser ce refreshToken soit à chaque refresh de notre session soit à interval régulier pour vérifier que l'identité distante existe encore et éventuellement récupérer des infos fraiches
• supprimer le lien vers le fournisseur d'identité du compte si l'identité distante n'existe plus

Paramètres pour contrôler un lien plus fort avec les identités distantes

Sur les infos de l'identité distante du compte on peut ajouter quelques éléments. Par exemple:

• grantAccess=orga/dep/role, permet de rendre explicite le fait que cette identité distante est la source de l'appartenance du compte à une orga (le user créé son compte avec un SSO privé et cette connexion lui donne implicitement des permissions)
• principal=boolean, permet de préciser que cette identité distante est la source principale de vérité pour ce compte

Ces éléments sont ajoutés à la création de compte en fonction des paramètres du fournisseur d'identité

Ces informations permettent d'implémenter quelques règles:

• si une identité distante avec grandAccess disparait alors l'appartenance à l'orga disparait aussi
• si une identité distante a principal=true alors les infos du compte issues de cette identité sont en lecture seule dans SD et elles sont récupérées à chaque utilisation du refreshToken
• si une identité distante a principal=true alors le compte ne peut pas avoir de mot de passe local dans SD et ne peut pas se rattacher à d'autres identités distantes sur d'autres fournisseurs

Déclarer un fournisseur d'identité comme principal

Peut se faire soit de manière globale sur l'instance SD soit sur une configuration de site secondaire.

Quand un fournisseur d'identité est principal

• les scénarios de création de compte, login par password, gestion d'orga, etc sont désactivés ou passés en lecture seule selon les cas
• la mire d'authentif redirige immédiatement vers ce fournisseur
• tous les comptes créés ont ce fournisseur marqué comme principal (donc infos en lecture seule, pas de possibilité de password local, etc)

Remarques

On est ici sur des scénarios de fédération avancée d'identité, mais de la fédération quand même (les infos existent en base dans les 2 système et sont synchronisés). Il peut y avoir des scénarios ou les synchronisations ne se font pas en temps réel. Il faut voir quelle garantie on sera capable d'apporter en tenant compte des durées de vie des jetons, etc. À noter que de toute façon avec la persistance de la session côté client dans des jwt, on a déjà de l'asynchronisme là dessus et pas de garantie forte sur la prise en compte instantanée des changements même sans interop avec un fournisseur d'identité.

Je pense que l'intégration keycloak peut être couverte entièrement sous le chapeau oidc sans (ou avec peu de) spécificité, ça signifie quelque chose de plus réutilisable et basé sur un protocole plutôt qu'un interop en dur.