Intégration SSO — récupération des droits géographiques

Principe

Le token OIDC reçu par l'API VegLab ne contient pas les droits : il porte seulement une référence, à savoir l' URL d'un endpoint de la source (façon OIDC Distributed Claims). VegLab appelle cet endpoint une fois par connexion pour récupérer les contraintes spatiales (communes, départements, etc.) et les persiste dans l'entité UserRight.

L'appel à l'endpoint de la source est authentifié par le token que la source a elle-même émis lors de l'authentification. La source valide donc ses propres tokens (aucune logique de validation spécifique à écrire de son côté) et en déduit l'utilisateur de façon prouvée — il n'y a ni secret partagé, ni e-mail déclaratif dans cet appel.

Le point clé : où VegLab trouve-t-il le token de la source ?

VegLab ne reçoit jamais le token de la source : le front se connecte à Keycloak et reçoit un token Keycloak (audience veglab-web). C'est Keycloak qui, en tant que broker OIDC, a obtenu et stocké le token de la source pendant le login (option storeToken de l'IdP).

VegLab récupère ce token stocké via l' endpoint broker token de Keycloak, en présentant le token Keycloak de l'utilisateur (celui qu'il a déjà en main, le Bearer de la requête entrante) :

Où {alias} est l'alias de l'IdP Keycloak (configuré côté VegLab dans le claim_map, pas codé en dur). Keycloak vérifie le token Keycloak, contrôle que l'utilisateur possède le rôle client broker → read-token, rafraîchit le token de la source si nécessaire, puis le restitue.

Séquence complète d'un login

Garanties et garde-fous (côté VegLab)

• Once-per-login: la synchronisation s'exécute une seule fois par session, repérée via le claim sid (UserRightSynchronizer::synchronize()), bien que le firewall soit stateless.

• Allowlist anti-SSRF: l'URL extraite du claim n'est appelée que si son hôte figure dans VEGLAB_USER_RIGHTS_ALLOWED_HOSTS.

• Fail-closed: si le token de la source ne peut être récupéré (rôle read-token manquant, absence de token stocké, endpoint injoignable…), l'authentification est refusée — on ne laisse pas entrer un utilisateur sans les droits qu'on est censé faire respecter.

• Découplage: aucun nom de système externe n'apparaît dans le code ; l'alias du broker et la correspondance claim → (type, role) sont en configuration (config/services.yaml, app.user_rights.claim_map).

Prérequis de configuration Keycloak (realm veglab)

Sur l'IdP source (alias lobelia) :

• storeToken: true — sans quoi Keycloak jette le token de la source et l'endpoint broker token ne renvoie rien.

• addReadTokenRoleOnCreate: true — accorde le rôle broker/read-token aux nouveaux utilisateurs brokerés. Les utilisateurs déjà existants doivent se voir attribuer ce rôle manuellement.

• Le scope du token émis par la source doit autoriser l'endpoint des droits.