Aller au contenu

ADR-0020 — Propagation du couloir en inter-app par contexte signé (jamais en-tête libre)

Date : 2026-06-17 Catégorie : A (convention de sécurité transverse) Décideur : Lead architecte DYNORS Statut : Proposée (décision ouverte D16 — à figer au scénario intermédiaire) S'appuie sur : [[0008-secret-transit-sly-par-app]], [[0017-couloir-lane-unite-execution-explicite]], [[0018-exposition-hors-prod-sly-edge-chemin]] Sources : étude §Partie 7 Q21 ; dynors-platform/selebeyone/src/main/java/com/dynors/sly/filter/SlyForwardSigningFilter.java, SlyTransitHkdf.java

Contexte

Hors-prod, si l'on veut router l'inter-app (SLY Bus) par couloir, l'identifiant de couloir doit transiter de service à service. Un simple en-tête X-Sly-Lane fourni librement par l'appelant permettrait à un client de cibler un couloir non autorisé (franchissement d'isolation). Le Bus dispose déjà d'une signature de transit HMAC (SlyForwardSigningFilter + SlyTransitHkdf, ADR-0008).

Décision (proposée)

  1. L'en-tête libre est exclu. Un lane_code inter-app n'est accepté que s'il est : injecté par un composant de confiance (InterAppCallService), inclus dans la signature HMAC de transit, vérifié par le Bus, contrôlé contre (route, tenant, projet, environnement), non modifiable par un navigateur/ client externe, journalisé et propagé dans les traces distribuées.
  2. Option retenue : contexte signé (Option C). En-têtes X-Dynors-Environment + X-Dynors-Lane inclus dans le HKDF/signature de transit, vérifiés par le Bus. À comparer formellement avec :
  3. Option A — couloir dans le hostname interne (sly-int-rc1.internal.dynors.com/{app}/api/...) : isolation par hôte, mais multiplie hôtes/certs internes.
  4. Option B — couloir dans le chemin interne (sly.internal.dynors.com/int/rc1/{app}/api/...) : un seul hôte, mais contexte non signé par défaut, vigilance collisions.
  5. Distinguer trois plans (ne pas mélanger) : routage navigateur = Edge (ADR-0018) ; routage backend = Bus ; propagation du contexte env+couloir = contexte signé.

Conséquences

Positif : impossible de cibler un couloir non autorisé depuis un client ; cohérent avec ADR-0008 ; découplé de l'URL. Coût : étendre le HKDF/signature et la vérification Bus aux champs env+lane ; faire évoluer InterAppCallService pour injecter le contexte ; tests de non-franchissement.

Composants impactés : SlyForwardSigningFilter, SlyTransitHkdf, InterAppCallService, dynors-interapp-client, traçage.

Alternatives considérées

  • X-Sly-Lane non signé → écartée (franchissement d'isolation).
  • Option A (hostname interne) / Option B (chemin interne) → à comparer ; A coûteuse en certs, B sans signature native.
  • Pas de couloir en inter-app hors-prod (couloirs uniquement navigateur) → option de repli valable au scénario minimal : l'inter-app reste mono-cible par environnement tant que le besoin de couloirs inter-app n'est pas avéré.

Plan d'exécution

Différé au scénario intermédiaire (déclencheur : besoin avéré de router l'inter-app par couloir, ex. campagnes RC croisées). 1. Comparer A/B/C avec PoC. 2. Étendre signature + vérification. 3. Tests de non-franchissement. 4. Acter (passage Proposée → Acceptée).

Suivi

Succès : aucun couloir inter-app sélectionnable via en-tête non signé ; contexte env+lane présent dans la signature et les traces ; tests de franchissement au rouge sans le secret.