Aller au contenu

PD-28 — Scénarios de tests contractuels

1. Références

  • Spécification : PD-28-specification.md
  • Epic : EPIC-182 AUTH
  • Rôle QA : Architecte QA senior / auditeur qualité indépendant

2. Matrice de couverture

ID Invariant ID Critère ID Test Couverture Commentaire
INV-01 CA-01 TC-INV-01 Oui Validation préalable requise pour tout accès protégé
INV-02 CA-02 TC-INV-02 Oui Session révoquée jamais acceptée
INV-03 CA-03 TC-INV-03 Oui Maintien uniquement si confiance (PD-27) valide
INV-04 CA-04 TC-INV-04 Oui Toute décision d’accès est traçable
§2.3 Définition TC-INV-01 Oui Endpoint protégé (C1–C4)
§2.4 Définition TC-INV-01 Oui Niveau homogène (V1–V4)
§2.4 (V5) Définition TC-NOM-01 Oui Décision déterministe multi-endpoint
CA-01 TC-NOM-01 Oui Requête avec session valide ⇒ accès accordé
CA-01 TC-ERR-01 Oui Session absente/expirée/invalide ⇒ rejet
CA-02 TC-ERR-02 Oui Session révoquée ⇒ rejet
CA-03 TC-NOM-02 Oui Maintien sans rupture de confiance ⇒ accès continu
CA-03 TC-ERR-03 Oui Renouvellement interdit après rupture de confiance
CA-04 TC-NOM-03 Oui Logs présents pour validation
CA-04 TC-ERR-04 Oui Décision non traçable ⇒ non-conformité
TC-NOM-04 Oui R-28-02 : rejet déterministe sans effet de bord
TC-NOM-05 Partiel R-28-04 : portée proportionnée (nécessite règles PD-27 sur périmètre)

3. Scénarios de test – Flux nominaux

TEST-ID: TC-INV-01
Référence spec: INV-01, R-28-01, §2.3, §2.4 (V1–V4)

GIVEN
  - Un endpoint backend qualifié « protégé » au sens de §2.3 (C1–C4)
  - Une session S associée à une identité authentifiée
  - Des preuves observables que S satisfait V1–V4 (existence, validité temporelle, intégrité, continuité)
WHEN
  - Une requête est émise vers l’endpoint protégé en présentant la session S
THEN
  - La décision d’accès est une validation
AND
  - La trace d’audit associée à cette décision est produite (voir R-28-07 / R-28-08)
TEST-ID: TC-INV-02
Référence spec: INV-02, R-28-03

GIVEN
  - Un endpoint backend protégé
  - Une session S précédemment valide
  - Une révocation explicite appliquée à S (événement de rupture de confiance au sens PD-27, ou décision de révocation)
WHEN
  - Une requête est émise en présentant S
THEN
  - La décision d’accès est un rejet
AND
  - Le rejet est traçable avec une justification fonctionnelle indiquant une révocation
AND
  - Aucun accès aux ressources protégées n’est accordé
TEST-ID: TC-INV-03
Référence spec: INV-03, R-28-05, R-28-06

GIVEN
  - Une session S valide
  - L’absence d’événement de rupture de confiance (au sens PD-27) depuis la « dernière authentification valide » de S
WHEN
  - Une séquence de N requêtes (N≥2) est émise vers des endpoints protégés sur une période d’usage nominale
THEN
  - Aucune requête n’est rejetée pour cause de « renouvellement interdit »
AND
  - Les décisions d’accès restent traçables (R-28-07)

NOTE
  - Ce test démontre le maintien d’une session légitime, sans exiger de définir une durée maximale (hors périmètre PD-28).
TEST-ID: TC-INV-04
Référence spec: INV-04, R-28-07, R-28-08, CA-04

GIVEN
  - Un endpoint backend protégé
  - Deux situations distinctes :
      (A) une requête validée (session S valide)
      (B) une requête rejetée (session absente/expirée/révoquée)
WHEN
  - Les requêtes (A) et (B) sont exécutées
THEN
  - Une trace d’audit est disponible pour (A) et pour (B)
AND
  - Chaque trace d’audit contient au minimum :
      - nature de la décision (validation/rejet)
      - moment de la décision
      - périmètre (session, device, compte)
      - justification_code parmi la taxonomie §5.4.1
      - pd27_event_ref parmi la taxonomie §5.4.1 (ou NONE)
TEST-ID: TC-NOM-01
Référence spec: CA-01, R-28-01, §2.4 (V5)

GIVEN
  - Deux endpoints backend protégés E1 et E2 (au sens de §2.3)
  - Une session S valide
WHEN
  - Une requête est émise vers E1 en présentant S
  - Une requête est émise vers E2 en présentant S
THEN
  - L’accès est accordé pour E1 et E2
AND
  - La décision d’accès est identique pour une session équivalente, quel que soit l’endpoint protégé
AND
  - La décision est journalisée (R-28-07)
TEST-ID: TC-NOM-02
Référence spec: CA-03, R-28-05

GIVEN
  - Une session S valide
  - Aucun événement de rupture de confiance PD-27 depuis la dernière authentification valide
WHEN
  - Une requête est émise après un délai non nul (preuve que « maintenir dans le temps » est exercé)
THEN
  - L’accès est accordé
AND
  - La justification fonctionnelle en log ne mentionne pas une rupture de confiance

NON-OBJECTIF
  - Ce scénario ne prouve pas une durée maximale (explicitement hors périmètre PD-28).
TEST-ID: TC-NOM-03
Référence spec: CA-04, R-28-07, R-28-08

GIVEN
  - Une requête validée et une requête rejetée (voir TC-INV-04)
WHEN
  - Les journaux d’audit sont consultés
THEN
  - Chaque décision dispose d’une trace distincte
AND
  - Les champs minimaux exigés par R-28-08 sont présents et exploitables pour un audit a posteriori
AND
  - Les valeurs `justification_code` et `pd27_event_ref` sont conformes à la taxonomie §5.4.1
TEST-ID: TC-NOM-04
Référence spec: R-28-02, §2.3 (C2, C4)

GIVEN
  - Un endpoint backend protégé
  - Une requête sans session valide (absence ou invalidité observable)
WHEN
  - La requête est émise vers l’endpoint protégé
THEN
  - La décision d’accès est un rejet explicite
AND
  - Aucun effet de bord métier n’est observable
AND
  - La décision est déterministe pour un même état de session
TEST-ID: TC-NOM-05
Référence spec: R-28-04

GIVEN
  - Une taxonomie normative des événements PD-27 permettant de déterminer si un événement affecte la confiance « globale compte » ou « contexte spécifique »
  - Une session S active sur au moins deux contextes distincts (ex. deux devices) OU deux sessions distinctes
WHEN
  - Un événement PD-27 classé « global compte » survient
THEN
  - Toutes les sessions pertinentes sont rejetées ensuite

AND WHEN
  - Un événement PD-27 classé « contexte spécifique » survient
THEN
  - Seules les sessions du contexte visé sont rejetées ensuite

NON TESTABLE (si prérequis absent)
  - Sans taxonomie PD-27 normative et sans définition opposable de « portée », la proportionnalité (R-28-04) ne peut être vérifiée objectivement.

4. Scénarios de test – Cas d’erreur

TEST-ID: TC-ERR-01
Référence spec: E-01, CA-01

GIVEN
  - Un endpoint backend protégé
  - Une requête sans session OU avec session explicitement expirée/invalide (preuve observable)
WHEN
  - La requête est émise
THEN
  - La décision d’accès est un rejet
AND
  - Aucun accès aux ressources protégées n’est accordé
AND
  - La décision est journalisée (R-28-07)
TEST-ID: TC-ERR-02
Référence spec: E-02, CA-02

GIVEN
  - Un endpoint backend protégé
  - Une session S révoquée
WHEN
  - Une requête est émise en présentant S
THEN
  - La décision d’accès est un rejet
AND
  - La justification fonctionnelle mentionne la révocation (sans exiger de détails techniques)
AND
  - La décision est journalisée (R-28-07)
TEST-ID: TC-ERR-03
Référence spec: E-03, R-28-06

GIVEN
  - Une session S active
  - Survenue d’un événement de rupture de confiance PD-27 après la dernière authentification valide
WHEN
  - Une tentative de maintien/renouvellement implicite est exercée (via une requête nécessitant une session valide)
THEN
  - La décision d’accès est un rejet explicite
AND
  - Une ré-authentification explicite est exigée
AND
  - Aucun accès aux ressources protégées n’est accordé
AND
  - Le renouvellement n’est pas accordé
AND
  - La décision est journalisée

NOTE
  - La spécification PD-28 ne définit pas la forme de la « ré-authentification explicite » ; le test vérifie qu’elle est exigée.
TEST-ID: TC-ERR-04
Référence spec: E-04, CA-04

GIVEN
  - Une requête (validation ou rejet) pour laquelle aucune trace d’audit n’est disponible malgré l’observabilité requise
WHEN
  - Un audit de conformité est exécuté
THEN
  - Le système est déclaré non conforme

5. Tests d’invariants (non négociables)

Invariant Test(s) dédiés Observable Commentaire
INV-01 TC-INV-01 Décision « validation » uniquement si session validée Validation préalable systématique
INV-02 TC-INV-02 Rejet systématique après révocation Zéro acceptation post-révocation
INV-03 TC-INV-03 Accès continu sans rupture / rejet après rupture Alignement PD-27
INV-04 TC-INV-04 Existence + contenu minimal des logs Auditabilité

6. Tests de non-régression

Test ID Objet Observable Commentaire
TC-NR-01 Révocation reste effective dans le temps Rejet persistant de S révoquée Assure non-retour à l’état valide
TC-NR-02 Journalisation inchangée entre versions Présence des champs minimaux R-28-08 Test interne non contractuel (non opposable)
TC-NR-03 Contrôle homogène inchangé lors d’ajout d’endpoints Taux de couverture de validation Dépend d’un inventaire endpoints (sinon partiel)

7. Tests négatifs et adversariaux

Test ID Entrée invalide / abus Résultat attendu Observable
TC-NEG-01 Réutilisation d’une session après révocation Rejet systématique Statut de rejet + log
TC-NEG-02 Tentative d’accès avec session explicitement invalide Rejet Statut de rejet + log
TC-NEG-03 Multiples rejets consécutifs (bruit) Décisions toujours traçables Logs complets et corrélables
TC-NEG-04 Tentative de maintenir une session après rupture PD-27 Renouvellement interdit Rejet + justification fonctionnelle

8. Observabilité requise pour les tests

Les éléments suivants DOIVENT être accessibles à l’audit/test (peu importe la forme) : - Résultat de décision d’accès : validation ou rejet, et motif fonctionnel minimal. - Capacité à constater l’état logique d’une session : valide / invalide / révoquée (par un moyen d’observation contractuel). - Journal d’audit consultable permettant de vérifier R-28-07 / R-28-08. - Valeurs justification_code et pd27_event_ref observables pour vérification de conformité à §5.4.1. - Traçabilité des événements de rupture de confiance PD-27 utilisés comme déclencheurs dans les tests (source normative ou journal d’événements).


9. Règles non testables

Règle Raison Impact
R-28-04 (proportionnalité de la portée) Nécessite une taxonomie normative PD-27 définissant la portée et les attendus « global vs ciblé » Majeur (non opposable sans prérequis)
« Latence compatible avec usage normal » (contrainte 4.3) Aucun seuil ni critère d’acceptation temporel n’est défini Mineur à Majeur selon exigences de perf ultérieures

10. Verdict QA

⚠️ Testable partiellement (avec réserves listées)

  • Les invariants INV-01..INV-04 et les critères CA-01..CA-04 sont testables avec l’observabilité définie.
  • Une règle reste conditionnellement testable :
  • R-28-04 exige une taxonomie normative PD-27 décrivant la portée attendue des événements.

Tant que ces prérequis ne sont pas fournis, les tests correspondants ne peuvent pas être rendus pleinement opposables contractuellement.