Prérequis d'exploitation¶
Évolution en préparation
Cette page décrit une évolution non livrée. État au 2026-09-11, d'après les fiches
d'intégration backend/docs/integration/ (infra, connecteur, portail, application).
En bref
Le nouveau modèle d'authentification demande quatre choses à l'exploitant : un serveur d'identité central et disponible, un magasin de sessions par plateforme, des connecteurs qui savent valider un jeton central, et un portail qui sert l'annuaire des connecteurs. Cette page les résume ; l'ordre de mise en place est sur Bascule v0.1 vers v0.2.
Les composants¶
| Composant | Où | Rôle |
|---|---|---|
| Serveur d'identité, en grappe de deux nœuds | central SenSaaS | comptes, connexion, connexion unique, fédération vers l'annuaire du client, habillage de la page de connexion par client |
| Sa base de données, en haute disponibilité | central | la vraie ressource critique : deux nœuds sur une base unique ne font qu'un seul point de panne |
| Proxy inverse chiffré devant le serveur d'identité | central | la console d'administration est servie sur un nom d'hôte distinct |
| Portail | central | client d'identité et annuaire des connecteurs |
| Plateforme SenSaaS, une par environnement et par revendeur | hébergement SenSaaS ou du revendeur | répartiteur de charge, point d'entrée, plusieurs instances du backend, magasin de sessions |
| Magasin de sessions | avec la plateforme | les sessions et le verrou de renouvellement ; un nœud en version 0.2, cible : nœud principal, réplique et surveillance automatique |
| Serveur d'identité de non-production | séparé | développement et recette ; jamais de compte de test en production |
Dimensionnement de départ, d'après la fiche : deux petits nœuds pour le serveur d'identité, deux instances légères pour le backend, un nœud modeste pour le magasin de sessions, dont la mémoire est plafonnée sans éviction et le journal d'écriture activé.
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.
Serveur d'identité perdu : plus de connexion ni de renouvellement ; les sessions en cours sont servies jusqu'à l'expiration du jeton d'accès, soit 5 à 15 minutes.
Les flux réseau¶
| De | Vers | Usage |
|---|---|---|
| navigateurs | point d'entrée de la plateforme | l'application et ses appels |
| navigateurs | serveur d'identité | la page de connexion et la connexion unique |
| backend | serveur d'identité | découverte, jetons, renouvellement, clés publiques, déconnexion |
| backend | portail | l'annuaire des connecteurs |
| backend | connecteurs clients | le relais des appels de l'API v2 — flux sortant vers les sites clients |
| serveur d'identité | plateforme | déconnexion centralisée — c'est le seul flux entrant à autoriser |
| connecteurs clients | serveur d'identité | les clés publiques, à faible fréquence |
| backend | magasin de sessions | réseau privé uniquement |
Ce que le connecteur doit fournir¶
- Valider les jetons du serveur d'identité : 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 attendue, jamais de contrôle sur le client émetteur (il y en a un par déploiement) ; tolérance d'horloge d'au moins une minute ; un seul émetteur central.
- Identifier l'utilisateur par son adresse électronique vérifiée, qui détermine le rattachement aux dossiers.
- Exposer la liste des dossiers accessibles à l'utilisateur courant, par une route v2 explicite, appelée par l'application au démarrage — elle remplace l'ancienne route de synchronisation des dossiers.
- Répondre proprement : jeton absent, invalide ou expiré donne une réponse d'authentification accompagnée de son en-tête de défi (le backend renouvelle une fois et rejoue les lectures) ; dossier refusé donne un refus explicite, inchangé.
- Ne produire aucun effet de bord sur les lectures : la protection contre les requêtes forgées ne couvre que les méthodes de modification.
- Prérequis : accès sortant chiffré vers le serveur d'identité, et un certificat valide sur le nom d'hôte du connecteur.
Le connecteur reste l'unique autorité sur les dossiers : il filtre, il refuse, il expose la liste.
Ce que le portail doit fournir¶
- Devenir client d'identité, avec son habillage propre : plus de mots de passe, et connexion unique avec l'application.
- Servir l'annuaire des connecteurs de l'utilisateur connecté : la réponse ne contient que les connecteurs de l'utilisateur dont le jeton est présenté. Jamais de recherche par adresse libre — un backend ou un revendeur ne doit pas pouvoir énumérer les connecteurs d'autrui.
- Assurer le provisionnement : créer le client d'identité de chaque revendeur et l'organisation de chaque client final.
- Permettre la révocation immédiate : retirer un accès déclenche la déconnexion centrale de l'utilisateur, donc la purge de sa session sur chaque plateforme. Sans cela, la perte d'accès n'est effective qu'au renouvellement suivant.
L'annuaire est appelé une fois par connexion, doit répondre en moins de 300 ms, et son indisponibilité refuse la connexion plutôt que de dégrader silencieusement le service.
Ce que l'application doit changer¶
L'application 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 propose les boutons de connexion par compte Microsoft, Google ou Apple ;
- 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).
Secrets et configuration¶
Le backend attend : l'adresse publique de la plateforme, les paramètres du client d'identité, l'adresse du portail, celle du magasin de sessions, une clé de chiffrement des jetons au repos et une clé de signature des cookies. Chaque secret se fournit par fichier plutôt qu'en clair dans l'environnement, et la rotation est prévue semestriellement.
Pourquoi les jetons sont chiffrés au repos
Le journal d'écriture du magasin de sessions vit sur le disque de l'hébergeur — qui peut être le revendeur. Les jetons y sont donc chiffrés : lire le disque ne suffit pas à usurper une session.
Supervision¶
- un point de contrôle simple pour le répartiteur de charge, et un point de contrôle détaillé pour la supervision, qui distingue l'état du magasin de sessions de celui du serveur d'identité ;
- des journaux structurés avec identifiant de corrélation, jetons et cookies masqués ;
- une alerte sur la mémoire du magasin de sessions : saturé, il refuse les nouvelles connexions tout en servant les sessions existantes.