Plateforme mutualisée et prérequis

Évolution en préparation

Cette page décrit une évolution non livrée. État au 2026-10-11, d'après la configuration Keycloak de référence de SenSaaS, les fiches d'intégration du backend et la décision du 2026-10-11 sur le backend mutualisé.

En bref

Toute l'infrastructure de l'authentification est mutualisée et exploitée par SenSaaS : plateforme d'authentification, backend de la webapp, magasin de sessions, API centrale. Un revendeur n'héberge rien et n'administre rien de cette infrastructure. Il reste au site du client un connecteur v2 à jour, qui sait joindre la plateforme d'authentification.

Ce que SenSaaS exploite

Composant	Rôle
Plateforme d'authentification (Keycloak), `ident.sensaas.fr`	comptes, connexion, connexion unique, passkeys, double authentification, organisations des revendeurs et des clients
Sa base de données	la vraie ressource critique : sauvegardée chaque jour, restauration testée
Plateforme de recette `ident.dev.sensaas.fr`	développement et recette ; jamais de compte de test en production
Backend de la webapp, mutualisé	plusieurs instances : connexion, session, relais des appels vers les connecteurs
Magasin de sessions	les sessions et le verrou de renouvellement ; jetons chiffrés au repos
API centrale	l'annuaire des connecteurs de chaque utilisateur, la gestion des comptes depuis le portail
Portail	gestion des organisations et des utilisateurs par les revendeurs

Installation, haute disponibilité, sauvegardes, mises à jour, rotation des secrets et supervision de ces composants sont à la charge de SenSaaS.

Ce que coûte la perte de chaque composant

Magasin de sessions perdu : quelques indisponibilités passagères, puis reprise grâce au journal ; au pire, tout le monde se reconnecte. Aucune donnée métier n'est en jeu.

Plateforme d'authentification perdue : plus de connexion ni de renouvellement ; les sessions en cours sont servies jusqu'à l'expiration du jeton d'accès, soit 15 minutes au plus. Les connexions directes aux connecteurs, elles, continuent de fonctionner.

Ce qui reste au site du client

Prérequis	Pourquoi	État
un connecteur v2 à jour	il valide les jetons de la plateforme, en plus de sa connexion directe	livré le 2026-10-02 - voir Migrer un connecteur v1 vers la v2
HTTPS sortant vers `ident.sensaas.fr`	le connecteur télécharge les clés publiques de la plateforme au premier jeton, puis les garde sur disque	à vérifier sur le pare-feu du site
des utilisateurs du connecteur avec la même adresse électronique que leur compte SenSaaS	l'adresse vérifiée relie l'utilisateur à ses dossiers ; sinon 403 `AUTH.UTILISATEUR_INCONNU`	inchangé : voir Utilisateurs

Aucun autre réglage d'authentification n'est demandé sur le connecteur : l'émetteur, l'audience et les applications autorisées sont fixés dans le connecteur lui-même.

Ce que le connecteur fournit déjà

Validation des jetons de la plateforme : signature vérifiée avec ses clés publiques mises en cache, donc aucun appel réseau par requête ; contrôle de l'audience, du type de jeton, de l'application d'origine et du rôle d'accès.
Identification de l'utilisateur par son adresse électronique vérifiée.
Liste des dossiers accessibles à l'utilisateur connecté, par la route v2 GET /v2/sage/dossiers : voir Sage, infrastructure.
Réponses distinctes : jeton absent, invalide ou expiré donne une réponse d'authentification ; utilisateur inconnu ou inactif donne un refus 403, sans boucle de renouvellement.

Le connecteur reste l'unique autorité sur les dossiers : il filtre, il refuse, il expose la liste.

Les flux réseau

De	Vers	Usage
navigateurs	webapp SenSaaS	la webapp et ses appels
navigateurs	plateforme d'authentification	la page de connexion et la connexion unique
backend SenSaaS	connecteurs des clients	le relais des appels de l'API v2
connecteurs des clients	plateforme d'authentification	les clés publiques, à faible fréquence

Les autres flux (backend vers plateforme, annuaire, magasin de sessions, déconnexion centralisée) restent internes à l'infrastructure de SenSaaS.

Ce que la webapp change

La webapp ne manipule plus aucun jeton : elle est authentifiée par un cookie de session, et ses appels partent vers la même origine.

au démarrage, elle demande qui est connecté ; si personne, elle redirige vers la connexion en mémorisant la page d'origine ;
elle affiche un écran de choix du connecteur quand plusieurs sont rattachés ;
elle envoie un en-tête d'identification sur toute requête modifiante - sans lui, la requête est refusée ;
elle distingue "session finie" (redirection vers la connexion) d'"indisponibilité passagère" (courte nouvelle tentative, sans déconnecter).