Aller au contenu

PD-238 — Revue de plan d'implémentation & code contracts

1. Synthèse exécutive

Verdict global : RÉSERVE

Nombre d'écarts identifiés par catégorie : - Ambiguïté : 2 - Incohérence : 3 - Composant manquant : 0 - Risque : 2 - Dépendance : 1 - Violation invariant : 1

2. Écarts détaillés

ECT-01

  • Catégorie : Incohérence
  • Localisation : Plan §3.4 (Guards), Spec §2 (Rate limiting endpoints MFA)
  • Description : Le plan applique MfaRateLimitGuard sur POST /auth/reauth, alors que la spec limite le rate limiting aux endpoints MFA (/user/mfa/*). Cela ajoute une contrainte non spécifiée.
  • Sévérité : Majeur
  • Recommandation : Aligner explicitement la portée du rate limiting avec la spec (soit étendre la spec, soit retirer du plan).

ECT-02

  • Catégorie : Incohérence
  • Localisation : Plan §3.3 (Guards), Code contracts — controllers.MfaManagementController (OidcJwtAuthGuard)
  • Description : Le plan mentionne JwtAuthGuard alors que les code contracts imposent OidcJwtAuthGuard. L’auth guard effectif n’est pas cohérent entre plan et code contracts.
  • Sévérité : Mineur
  • Recommandation : Uniformiser la désignation du guard (plan et code contracts).

ECT-03

  • Catégorie : Incohérence
  • Localisation : Plan §3.2 (verifyTotp: userId, code), Code contracts — KeycloakAdminService.verifyAndActivateTotp(code, sessionId)
  • Description : Le plan ne prévoit pas de sessionId pour la vérification TOTP, alors que le code contract l’exige comme paramètre clé pour l’API Keycloak. Le flux de données est incomplet.
  • Sévérité : Majeur
  • Recommandation : Aligner plan et code contracts sur les paramètres requis pour la vérification TOTP.

ECT-04

  • Catégorie : Ambiguïté
  • Localisation : Plan §3.2 (Mapping userId → keycloakUserId), Spec INV-238-02
  • Description : Le plan mentionne un mapping userId → keycloakUserId mais ne définit pas la source d’autorité ni le mécanisme (claim, table de correspondance, lookup Keycloak). Risque d’accès croisé non contrôlé.
  • Sévérité : Majeur
  • Recommandation : Spécifier la source unique de vérité et la méthode de mapping.

ECT-05

  • Catégorie : Risque
  • Localisation : Plan §3.6 (Rate limit par userId), Spec INV-238-11
  • Description : Le rate limiting est défini par userId. Si un attaquant obtient un JWT valide, il peut contourner la protection par rotation d’identités (multi comptes) — le plan ne prévoit pas de protection additionnelle (IP/device) ni de justification d’alignement avec la “global policy”.
  • Sévérité : Mineur
  • Recommandation : Justifier l’alignement avec la politique globale ou expliciter les dimensions de rate limit attendues.

ECT-06

  • Catégorie : Dépendance
  • Localisation : Plan §5 (Dépendances externes), §8 (Risques), Code contracts — KeycloakAdminService
  • Description : La dépendance Keycloak Admin API est critique, mais le plan n’explicite pas les versions, scopes ou permissions nécessaires du service account. Risque de blocage à l’exécution.
  • Sévérité : Majeur
  • Recommandation : Documenter les permissions minimales et la version cible de l’API Keycloak.

ECT-07

  • Catégorie : Ambiguïté
  • Localisation : Plan §3.7 (DTOs), Spec INV-238-03
  • Description : MfaStatusDto.method est défini comme 'TOTP' | null alors que la spec impose method = TOTP (seule valeur supportée). Le cas null n’est pas contractuellement défini.
  • Sévérité : Mineur
  • Recommandation : Clarifier la valeur attendue lorsque MFA est désactivé, ou aligner sur la spec.

ECT-08

  • Catégorie : Violation invariant
  • Localisation : Code contracts — MfaManagementController.responses (401 pour verifyTotp), Spec ERR-238-TOTP-INVALID
  • Description : La spec impose ERR-238-TOTP-INVALID (400) pour code invalide. Les code contracts ne listent pas explicitement le 400 pour verifyTotp dans le tableau de réponses (seulement 200/401/429). Risque de non-conformité d’erreur.
  • Sévérité : Majeur
  • Recommandation : Aligner les réponses verifyTotp sur l’erreur 400 contractuelle.

3. Points forts

  • Architecture modulaire claire (controller/service/guard/dto/errors).
  • Mapping détaillé vers Keycloak Admin API.
  • Code contracts structurés et traçables aux invariants clés.

4. Recommandations générales

  • Verrouiller la cohérence plan ↔ code contracts (guards, paramètres, erreurs).
  • Documenter explicitement les hypothèses de mapping identité et la source d’autorité.
  • Harmoniser la portée du rate limiting avec la spec et la politique globale.