Aller au contenu

PD-238 — Confrontation Gate AMBIGUITY (v1)

1. Synthese

  • Ecarts ChatGPT valides : 4/8
  • Ecarts partiels : ⅜
  • Ecarts rejetes : ⅛
  • Ecarts manques identifies : 2

2. Analyse des ecarts ChatGPT

ECT-01 — Rate limiting sur /auth/reauth

  • Verdict : PARTIEL
  • Analyse : ChatGPT signale une incoherence entre le plan (qui applique MfaRateLimitGuard sur POST /auth/reauth) et la spec qui limite le rate limiting aux endpoints /user/mfa/*. Cependant, l'analyse est incomplete :
  • La spec INV-238-11 mentionne "endpoints MFA DOIVENT etre soumis au rate limiting global"
  • L'endpoint /auth/reauth est fonctionnellement lie aux operations MFA sensibles (prerequis pour disable/regenerate)
  • Les code contracts (ligne 416-417) confirment MfaRateLimitGuard sur /auth/reauth
  • L'inclusion de reauth dans le rate limiting MFA est une decision d'architecture coherente pour prevenir le brute force sur le mot de passe
  • Severite ajustee : Mineur (au lieu de Majeur)
  • Recommandation ajustee : Clarifier dans la spec que le rate limiting MFA s'applique egalement a /auth/reauth pour justifier cette extension. Ce n'est pas une violation mais une extension de portee non documentee.

ECT-02 — JwtAuthGuard vs OidcJwtAuthGuard

  • Verdict : VALIDE
  • Analyse : L'ecart est reel et correctement identifie :
  • Plan section 3.3 (ligne 97-101) : JwtAuthGuard
  • Code contracts (lignes 337, 344, 355, etc.) : OidcJwtAuthGuard
  • Cette incoherence terminologique peut creer de la confusion lors de l'implementation
  • Le guard effectif doit etre OidcJwtAuthGuard car le systeme utilise les claims OIDC (spec H-238-02)
  • Recommandation : Uniformiser vers OidcJwtAuthGuard dans le plan pour coherence avec les code contracts.

ECT-03 — sessionId manquant pour verifyTotp

  • Verdict : VALIDE
  • Analyse : L'ecart est significatif et bien identifie :
  • Plan section 3.2 (ligne 84) : verifyTotp(userId: string, code: string) - 2 parametres
  • Code contracts KeycloakAdminService.verifyAndActivateTotp (lignes 210-217) : (keycloakUserId, code, sessionId) - 3 parametres
  • Le sessionId provient de TotpInitResult.sessionId (ligne 47 code contracts)
  • Sans ce parametre, l'API Keycloak ne peut pas associer le code a la session d'initialisation
  • Le plan ne documente pas le flux de gestion du sessionId entre init et verify
  • Recommandation : Ajouter dans le plan la gestion du sessionId : stockage temporaire (cache/session) apres init, passage a verify, nettoyage apres activation.

ECT-04 — Mapping userId vers keycloakUserId non defini

  • Verdict : VALIDE
  • Analyse : L'ecart est reel et critique pour la securite :
  • Plan section 3.2 (ligne 77) mentionne "Mapping userId local → keycloakUserId" sans definir le mecanisme
  • Spec INV-238-02 impose qu'un utilisateur ne peut acceder qu'a son propre MFA
  • Le code contracts ne definit pas non plus la source d'autorite pour ce mapping
  • Options possibles non explicitees : claim sub du JWT OIDC, table de correspondance User.keycloakId, lookup Keycloak Admin API
  • Risque : si le mapping est incorrect, violation de INV-238-02 (acces croise)
  • Recommandation : Specifier dans le plan que le keycloakUserId est extrait du claim sub du token OIDC (coherent avec H-238-02) ou documenter le mecanisme de lookup via UserRepository.

ECT-05 — Rate limiting par userId insuffisant

  • Verdict : PARTIEL
  • Analyse : L'ecart est partiellement valide mais la severite et l'analyse sont discutables :
  • Le plan definit correctement le rate limit par userId (10 req/min) alignant sur les specs
  • La spec INV-238-11 parle de "rate limiting global" sans definir les dimensions (IP, device, etc.)
  • Le scenario d'attaque "multi-comptes" suppose que l'attaquant possede plusieurs comptes valides, ce qui est un risque different
  • La spec H-238-04 confirme que "le rate limiting global est actif sur /user/mfa/*"
  • Severite confirmee : Mineur
  • Recommandation ajustee : Documenter dans les risques du plan que le rate limit par userId est la politique choisie, conformement a la politique globale backend. L'ajout de rate limit par IP est hors perimetre PD-238.

ECT-06 — Permissions Keycloak Admin API non documentees

  • Verdict : VALIDE
  • Analyse : L'ecart est reel et impactant :
  • Plan section 5 liste les dependances externes mais pas les permissions Keycloak
  • Plan section 7 mappe les operations vers l'API Keycloak mais sans mentionner les scopes requis
  • Plan section 8 (risques) mentionne "Keycloak Admin API indisponible" mais pas les permissions insuffisantes
  • Code contracts KeycloakAdminConfig (lignes 527-544) definit le client ID/secret mais pas les roles/scopes requis
  • Les operations (GET credentials, POST otp/init, DELETE credential, etc.) necessitent des permissions specifiques
  • Recommandation : Ajouter dans la section 6 (Configuration) les permissions minimales du service account Keycloak : manage-users scope, ou roles specifiques par realm.

ECT-07 — MfaStatusDto.method null vs TOTP

  • Verdict : PARTIEL
  • Analyse : L'ecart est partiellement valide mais l'interpretation de ChatGPT est incorrecte :
  • Spec INV-238-03 : "method DOIT valoir TOTP (seule valeur supportee dans PD-238)"
  • Plan section 3.7 : method: 'TOTP' | null
  • Code contracts MfaStatusDto (lignes 91-94) : type: "'TOTP' | null"
  • L'intention est claire : quand MFA est desactive (enabled: false), method vaut null
  • La spec dit que TOTP est la seule valeur supportee quand MFA est actif, pas que method ne peut jamais etre null
  • La spec section 3 definit method avec "Type de MFA configure" impliquant null si non configure
  • Severite ajustee : Mineur (coherent avec ChatGPT)
  • Recommandation ajustee : Clarifier dans la spec que method = TOTP quand enabled = true, et method = null quand enabled = false. Ceci est implicite mais meriterait d'etre explicite.

ECT-08 — Reponse 400 manquante pour verifyTotp

  • Verdict : REJETE
  • Analyse : L'ecart signale par ChatGPT est un faux positif :
  • ChatGPT affirme que les code contracts ne listent pas 400 pour verifyTotp
  • Or, code contracts ligne 373-374 : 400: "ERR-238-TOTP-INVALID"
  • Les responses listees sont : 200, 400, 401, 429 (lignes 370-375)
  • Ceci est parfaitement aligne avec la spec ERR-238-TOTP-INVALID (HTTP 400)
  • ChatGPT a mal lu ou interprete les code contracts
  • Recommandation : Aucune action requise. L'ecart n'existe pas.

3. Ecarts manques

ECT-M01 — Absence de circuit breaker dans les code contracts

  • Categorie : Risque
  • Localisation : Plan section 8 (Risques) vs Code contracts KeycloakAdminService
  • Description : Le plan mentionne "Circuit breaker + retry" comme mitigation pour l'indisponibilite de Keycloak Admin API (section 8, ligne 285). Cependant, les code contracts KeycloakAdminService ne definissent pas :
  • Les parametres du circuit breaker (threshold, timeout, half-open)
  • La strategie de retry (nombre de tentatives, backoff)
  • Le comportement en cas de circuit ouvert (erreur specifique) Cette omission peut mener a une implementation incomplete ou inconsistante.
  • Severite : Majeur

ECT-M02 — Absence de MfaExceptionFilter dans le plan

  • Categorie : Composant manquant
  • Localisation : Plan section 2 (Architecture) vs Code contracts controllers.MfaManagementController
  • Description : Les code contracts definissent un decorator @UseFilters(MfaExceptionFilter) sur le MfaManagementController (ligne 338). Cependant, ce composant n'apparait pas dans :
  • L'arborescence du plan (section 2)
  • Les composants a implementer (section 3)
  • Les phases d'implementation (section 4) Le MfaExceptionFilter est necessaire pour normaliser les erreurs ERR-238-* en reponses HTTP coherentes.
  • Severite : Majeur

4. Verdict confrontation

  • Verdict global : RESERVE
  • Justification : La review ChatGPT est globalement correcte avec 4 ecarts pleinement valides sur 8 et 3 partiellement valides. Un seul faux positif a ete identifie (ECT-08 sur la reponse 400). Cependant, 2 ecarts significatifs ont ete manques par ChatGPT :
  • L'absence de specification du circuit breaker/retry dans les code contracts
  • L'absence du MfaExceptionFilter dans le plan d'implementation

Ces ecarts manques, combines aux 4 ecarts valides de ChatGPT, justifient un verdict RESERVE. Les corrections requises avant implementation sont : - ECT-02 : Uniformiser JwtAuthGuard vers OidcJwtAuthGuard dans le plan - ECT-03 : Documenter le flux sessionId entre init et verify - ECT-04 : Specifier le mecanisme de mapping userId -> keycloakUserId - ECT-06 : Documenter les permissions Keycloak requises - ECT-M01 : Ajouter les specifications circuit breaker/retry dans les code contracts - ECT-M02 : Ajouter MfaExceptionFilter dans le plan d'implementation