PD-27 — Scénarios de tests contractuels
1. Références
- Spécification : PD-27-specification.md
- Epic : PD-182 AUTH
- Rôle QA : Architecte QA senior / auditeur qualité indépendant
- Dépendances (référencées par la spec) : PD-23, PD-26
2. Matrice de couverture
| Référence spec | Type | Test ID | Couvert | Commentaire |
| I1 | Invariant | TC-INV-01 | Oui | Session acceptée uniquement si validée par IdP |
| I2 | Invariant | TC-INV-02 | Oui | MFA obligatoire (règles d’exigence) |
| I3 | Invariant | TC-INV-03 | Oui | Aucune manipulation/stockage de secrets MFA |
| I4 | Invariant | TC-INV-04 | Oui | Décision MFA exclusivement via claims OIDC |
| I5 | Invariant | TC-INV-05 | Oui | Device de confiance uniquement après MFA |
| R1 | Normative | TC-NOM-01 | Oui | MFA obligatoire par défaut |
| R2 | Normative | TC-NOM-02 | Oui | MFA exigé sur nouveau device |
| R2.a | Normative | TC-NOM-04 | Oui | Pas de MFA sur device de confiance hors R2/R7 |
| R3 | Normative | TC-NOM-03 | Oui | Définition device = (client_id, device_fingerprint) |
| R3.a | Normative | TC-NOM-03 | Oui | Stabilite et distinction du device_fingerprint |
| R4 | Normative | TC-NOM-04 | Oui | Device devient de confiance après MFA |
| R5 | Normative | TC-NOM-05 | Oui | Expiration confiance 90 jours |
| R5.a | Normative | TC-NOM-05 | Oui | Reference temporelle IdP |
| R5.b | Normative | TC-NOM-05 | Oui | Authentification reussie avec MFA requis |
| R6 | Normative | TC-NOM-06 | Partiel | Révocation confiance (logout global/reset/échecs) ; seuils délégués à IdP |
| R7 | Normative | TC-NOM-07 | Oui | MFA exigé pour action sensible |
| R8 | Normative | TC-NOM-08 | Partiel | Politique d’actions sensibles (liste non exhaustive) — classification hors scope tests end-to-end |
| R9 | Normative | TC-ERR-01 | Oui | amr requis |
| R10 | Normative | TC-NOM-09 | Oui | amr contient "otp" => MFA satisfait |
| R11 | Normative | TC-NOM-10 | Oui | acr optionnel |
| R12 | Normative | TC-ERR-02 | Oui | acr insuffisant => rejet |
| §6 | Section | TC-SCOPE-01 | Oui | Codes de secours hors périmètre PD-27 |
| E1 | Erreur | TC-ERR-01 | Oui | amr absent => rejet |
| E2 | Erreur | TC-ERR-03 | Oui | amr sans otp quand MFA requis => rejet |
| E3 | Erreur | TC-ERR-02 | Oui | acr insuffisant => rejet |
| E4 | Erreur | TC-ERR-04 | Oui | Action sensible sans MFA valide => rejet |
| CA1 | Acceptation | TC-NOM-09 | Oui | Session MFA valide acceptée |
| CA2 | Acceptation | TC-ERR-01/03 | Oui | Session sans MFA valide rejetée |
| CA3 | Acceptation | TC-NOM-02 | Oui | MFA exigé sur nouveau device |
| CA4 | Acceptation | TC-NOM-07/ERR-04 | Oui | MFA exigé action sensible |
| CA5 | Acceptation | TC-INV-03 | Oui | Aucune donnée MFA manipulée |
3. Scénarios de test — Flux nominaux
TEST-ID: TC-NOM-01
Référence spec: R1, R2.a, I2
GIVEN
- Un utilisateur U existant
- Un IdP configuré (PD-26) capable d’émettre des tokens OIDC
WHEN
- U s’authentifie via le flux standard
THEN
- La session n’est considérée conforme que si les conditions MFA définies par PD-27 sont respectées
AND
- Toute session acceptée par ProbatioVault satisfait la politique MFA (cf. R2, R2.a, R7, R9–R12)
NOTE
- Ce test est une vérification d’alignement : l’obligation MFA est satisfaite au travers des règles d’exigence (nouveau device, actions sensibles) plutôt qu’un “MFA à chaque login”.
TEST-ID: TC-NOM-02
Référence spec: R2, CA3
GIVEN
- Deux devices distincts D1 et D2 tels que:
- D1 = (client_id_a, fingerprint_x)
- D2 = (client_id_a, fingerprint_y) avec fingerprint_y ≠ fingerprint_x
- Un utilisateur U
- Aucune confiance préexistante pour D1 et D2
WHEN
- U tente une authentification depuis D1
THEN
- Le backend exige une preuve MFA valide (cf. R9–R12)
AND
- Une session ne peut être acceptée que si amr contient "otp" (et acr si présent est suffisant)
AND
- Après authentification MFA réussie, D1 devient de confiance (cf. TC-NOM-04)
WHEN
- U tente une authentification depuis D2
THEN
- Le backend exige à nouveau une preuve MFA valide (nouveau device)
TEST-ID: TC-NOM-03
Référence spec: R3, R3.a
GIVEN
- Deux requêtes d’authentification produisant des tokens identiques sauf pour:
- client_id
- device_fingerprint
WHEN
- Les deux requêtes sont évaluées par ProbatioVault
THEN
- Le “device” est distingué exclusivement par le couple (client_id, device_fingerprint)
AND
- Toute logique de confiance/reconnaissance de device varie uniquement selon ce couple
AND
- Pour un meme device, device_fingerprint reste stable sur des authentifications successives
TEST-ID: TC-NOM-04
Référence spec: R4, R2.a, I5
GIVEN
- Un device D = (client_id, device_fingerprint)
- Un utilisateur U
WHEN
- U s’authentifie depuis D avec une preuve MFA valide (amr contient "otp")
THEN
- D est considéré “de confiance” pour U
AND
- Une authentification future depuis D avant expiration/révocation peut etre acceptee sans nouvelle preuve MFA si la politique de securite n'impose pas un step-up explicite (cf. R2.a, R7, R6)
TEST-ID: TC-NOM-05
Référence spec: R5, R5.a, R5.b
GIVEN
- Un utilisateur U
- Un device D déjà de confiance
- Un temps écoulé strictement supérieur ou égal à 90 jours calendaires depuis la derniere authentification reussie depuis D, selon la reference temporelle de l'IdP
WHEN
- U tente de s’authentifier depuis D
THEN
- D est traité comme non fiable
AND
- Une preuve MFA valide est exigée (nouvelle authentification MFA)
TEST-ID: TC-NOM-06
Référence spec: R6
GIVEN
- Un utilisateur U
- Un device D déjà de confiance
WHEN
- Un événement de révocation explicite survient:
- logout global OU reset paramètres de sécurité
THEN
- D perd son statut de confiance
AND
- Une authentification ultérieure depuis D exige une preuve MFA valide
STATUT: PARTIEL
Justification:
- Le cas « tentatives infructueuses répétées » est délégué à l’IdP sans seuil contractuel ; le test boîte noire ne peut forcer déterministiquement le déclenchement.
TEST-ID: TC-NOM-07
Référence spec: R7, CA4
GIVEN
- Un utilisateur U
- Un device D de confiance
- Une session active S issue d’une authentification sans preuve MFA récente (selon politique de step-up)
- Une action A classée “sensible” par la politique de sécurité
WHEN
- U tente d’exécuter l’action A
THEN
- ProbatioVault exige une preuve MFA valide
AND
- L’action A est rejetée tant que la preuve MFA valide n’est pas fournie
TEST-ID: TC-NOM-08
Référence spec: R8
GIVEN
- La liste normative des actions sensibles (Annexe A : Security Policy - Sensitive Actions List vX)
WHEN
- Une action classée sensible est tentée
THEN
- Le comportement suit TC-NOM-07
STATUT: PARTIEL
Justification:
- La spécification délègue la classification des actions sensibles à une politique externe non jointe ; les tests ne peuvent pas vérifier l’exhaustivité des actions sensibles.
TEST-ID: TC-NOM-09
Référence spec: R9, R10, CA1, I4
GIVEN
- Un token OIDC présenté à ProbatioVault
- Le claim amr est présent et contient "otp"
- Le claim acr est absent OU présent et suffisant (cf. TC-NOM-10)
WHEN
- ProbatioVault évalue la session
THEN
- La session est acceptée (MFA considéré satisfait)
TEST-ID: TC-NOM-10
Référence spec: R11, R12, R12.a
GIVEN
- Un token OIDC présenté à ProbatioVault
- amr contient "otp"
- acr est présent et egal a `urn:probatiovault:acr:mfa`
WHEN
- ProbatioVault évalue la session
THEN
- La session est acceptée
NOTE
- La comparaison est une egalite stricte avec la valeur minimale requise.
TEST-ID: TC-SCOPE-01
Référence spec: §6
GIVEN
- Une tentative d’exercer une fonctionnalité liée aux codes de secours (génération/affichage/usage)
WHEN
- La tentative est soumise à ProbatioVault
THEN
- La fonctionnalité est absente de l’API/produit sous PD-27 (hors périmètre)
AND
- Aucune exigence PD-27 ne peut être invoquée pour juger la conformité de ces mécanismes
4. Scénarios de test — Cas d’erreur
TEST-ID: TC-ERR-01
Référence spec: E1, R9, CA2
GIVEN
- Un token OIDC présenté à ProbatioVault
- Le claim amr est absent
WHEN
- ProbatioVault évalue la session
THEN
- La session est rejetée explicitement
TEST-ID: TC-ERR-02
Référence spec: E3, R12, R12.a
GIVEN
- Un token OIDC présenté à ProbatioVault
- Le claim amr est présent et contient "otp"
- Le claim acr est présent et different de `urn:probatiovault:acr:mfa`
WHEN
- ProbatioVault évalue la session
THEN
- La session est rejetée explicitement
TEST-ID: TC-ERR-03
Référence spec: E2, R10, CA2
GIVEN
- Un token OIDC présenté à ProbatioVault
- Le claim amr est présent mais ne contient pas "otp"
WHEN
- ProbatioVault évalue la session dans un contexte où MFA est requis
THEN
- La session est rejetée explicitement
TEST-ID: TC-ERR-04
Référence spec: E4
GIVEN
- Une action A classée sensible
- Une session S ne satisfaisant pas les conditions MFA (amr absent ou sans otp, ou acr insuffisant)
WHEN
- L’action A est tentée
THEN
- L’action est rejetée explicitement
5. Tests d’invariants (non négociables)
| Invariant | Test(s) dédiés | Observable | Commentaire |
| I1 | TC-INV-01 | Rejet si jeton IdP invalide/absent | Validation “IdP-gated” |
| I2 | TC-INV-02 | MFA exigé selon règles (device/action) | Obligation MFA |
| I3 | TC-INV-03 | Absence secrets/QR/codes de secours dans PV | Inspection |
| I4 | TC-INV-04 | Décision basée uniquement sur amr/acr | Contrôle claims |
| I5 | TC-INV-05 | Confiance conditionnée à MFA | Device trust |
TEST-ID: TC-INV-01
Référence spec: I1
GIVEN
- Une requête d’accès nécessitant authentification
WHEN
- Aucun jeton IdP valide n’est présenté
THEN
- Accès rejeté
AND
- Aucun mécanisme local à ProbatioVault ne permet de considérer une session comme authentifiée
TEST-ID: TC-INV-02
Référence spec: I2
GIVEN
- Un utilisateur U
- Un nouveau device D (cf. R3)
WHEN
- U tente une authentification depuis D sans preuve MFA
THEN
- Rejet (cf. TC-ERR-03)
AND
- Acceptation uniquement si amr contient "otp" (cf. TC-NOM-09)
TEST-ID: TC-INV-03
Référence spec: I3, CA5
GIVEN
- Un environnement ProbatioVault instrumenté pour inspection probatoire
WHEN
- Les interfaces publiques, payloads d’API, logs applicatifs et persistance applicative sont inspectés
THEN
- Aucun secret TOTP, QR code, seed, ou code de secours n’est stocké ou manipulé par ProbatioVault
STATUT: PARTIEL
Justification:
- La preuve exhaustive d’absence est de nature globale ; les tests ne peuvent que vérifier un périmètre défini d’observables (logs/persistences/interfaces).
TEST-ID: TC-INV-04
Référence spec: I4
GIVEN
- Deux tokens OIDC identiques sauf:
- Token A : amr contient "otp"
- Token B : amr ne contient pas "otp"
WHEN
- ProbatioVault évalue A puis B dans un contexte où MFA est requis
THEN
- A est accepté et B est rejeté
AND
- Aucune autre donnée que amr/acr n’est utilisée pour qualifier le MFA
TEST-ID: TC-INV-05
Référence spec: I5
GIVEN
- Un device D et un utilisateur U
WHEN
- U s’authentifie sans MFA (amr sans otp)
THEN
- D n’acquiert jamais le statut “de confiance”
WHEN
- U s’authentifie avec MFA (amr avec otp)
THEN
- D acquiert le statut “de confiance”
6. Tests de non-régression
| Test ID | Objet | Observable | Commentaire |
| TC-NR-01 | Confiance device inchangée sur tokens identiques | Même décision accept/reject | Stabilité décisionnelle |
| TC-NR-02 | Ajout d’une nouvelle action sensible n’altère pas les actions non sensibles | Non-interférence | Politique évolutive |
TEST-ID: TC-NR-01
Référence spec: I4
GIVEN
- Un token OIDC T présenté à ProbatioVault
WHEN
- T est évalué N fois dans les mêmes conditions (mêmes politiques, même contexte device)
THEN
- La décision (acceptation/rejet) est strictement identique
TEST-ID: TC-NR-02
Référence spec: R8
GIVEN
- Une action non sensible A0
- Une action sensible A1 issue de l'Annexe A : Security Policy - Sensitive Actions List vX
WHEN
- La politique de sécurité est mise à jour pour ajouter une nouvelle action sensible A2
THEN
- A0 conserve son comportement (pas de MFA step-up additionnel)
AND
- A1 et A2 exigent MFA step-up
STATUT: PARTIEL
Justification:
- Dépend d’une politique externe ; le test vérifie la non-interférence, pas le mécanisme de classification.
7. Tests négatifs et adversariaux
| Test ID | Abus / entrée invalide | Résultat attendu | Observable |
| TC-NEG-01 | Jeton forgé / claims incohérents | Rejet | Erreur explicite |
| TC-NEG-02 | Tentative d’accès action sensible avec token password-only | Rejet | E4 |
| TC-NEG-03 | Réutilisation d’un token sans MFA après révocation device | Rejet | MFA exigé |
TEST-ID: TC-NEG-01
Référence spec: I1, I4
GIVEN
- Un jeton OIDC invalide ou manifestement altéré
WHEN
- Le jeton est présenté
THEN
- La session est rejetée
AND
- Aucun fallback local n’est appliqué
TEST-ID: TC-NEG-02
Référence spec: R7, E4
GIVEN
- Une action sensible A
- Un token OIDC avec amr ne contenant pas "otp"
WHEN
- A est tentée
THEN
- Rejet explicite
TEST-ID: TC-NEG-03
Référence spec: R6
GIVEN
- Un device D précédemment de confiance
- Un événement de révocation explicite (logout global ou reset sécurité)
- Un token OIDC présenté depuis D sans "otp"
WHEN
- Une authentification est tentée
THEN
- Rejet explicite (MFA requis)
8. Observabilité requise pour les tests
- Décision d’accès (acceptation/rejet) et codes/raisons explicites.
- Jetons OIDC observables (au minimum claims
amr, acr). - Contexte device observable :
client_id et device_fingerprint. - Signal d’“action sensible” (classification fournie par la politique de sécurité).
- Événements de révocation explicite (logout global, reset sécurité).
- Capacité d’inspection probatoire des logs/persistences/interfaces de ProbatioVault pour vérifier l’absence de secrets MFA.
9. Règles non testables
| Règle / Partie | Raison | Impact |
| Détails des mécanismes MFA (TOTP secrets, QR, codes de secours) | Hors périmètre (délégué IdP) | Ne peut fonder un verdict PD-27 |
| Seuils de “tentatives infructueuses répétées” | Délégué IdP, non normé | Tests boîte noire non déterministes |
| Exhaustivité de la liste d’actions sensibles | Politique externe non jointe | Vérifiable uniquement si la politique est fournie |
| Absence totale de toute donnée MFA dans l’ensemble du système | Propriété globale ; vérification exhaustive impossible | Vérification par inspection d’un périmètre défini |
10. Verdict QA
✅ Testable partiellement (avec réserves listées)
- Les règles d’acceptation/rejet fondées sur
amr/acr, les exigences sur nouveau device, l’expiration 90 jours et le step-up sur actions sensibles sont testables de manière déterministe. - Les éléments explicitement délégués à l’IdP (seuils anti-bruteforce, codes de secours) et la classification exhaustive des actions sensibles sont non testables dans PD-27 sans artefacts externes.