PD-28 — Validation, maintien et révocation des sessions d’authentification backend¶

1. Objectif¶

Cette spécification définit de manière contractuelle les règles de validation, de maintien, de renouvellement et de révocation des sessions d’authentification utilisées pour l’accès aux fonctionnalités backend protégées de ProbatioVault.

Elle garantit que tout accès backend est cohérent avec : - la valeur probatoire des données manipulées, - les exigences de sécurité issues de l’authentification et du MFA définies par PD-27, - la nécessité d’auditabilité et de contrôle a posteriori.

La spécification ne décrit aucun mécanisme d’implémentation et fait foi pour l’évaluation de conformité.

2. Périmètre / Hors périmètre¶

2.1 Inclus¶

• Validation de la validité d’une session d’authentification lors de chaque accès backend protégé.
• Maintien et renouvellement conditionnel des sessions existantes.
• Révocation explicite des sessions à la suite d’événements de sécurité.
• Traçabilité des décisions d’accès (validation / rejet).

2.2 Exclu (hors périmètre)¶

• Définition du format interne des jetons d’authentification.
• Mécanismes cryptographiques de signature ou de vérification des jetons.
• Protocole d’échange avec le système d’identité amont.
• Architecture logicielle ou technologique du backend.
• Détermination des durées exactes de validité ou de renouvellement des sessions.

2.3 Définition normative : Endpoint backend protégé¶

2.3.1 Définition¶

Un endpoint backend protégé est un point d’accès exposé par le backend dont l’exécution nominale est conditionnée à l’existence d’une session valide associée à un utilisateur authentifié. Un endpoint backend protégé NE PEUT PAS être exécuté avec succès en l’absence d’une session valide, quelle que soit la nature de la requête ou de son contenu.

Note normative : la protection d’un endpoint est définie par son comportement observable, indépendamment de toute considération d’implémentation, de transport, de protocole ou de mécanisme technique.

2.3.2 Critères objectifs de qualification¶

Un endpoint backend est qualifié de protégé si, et seulement si, tous les critères suivants sont vérifiés :

• C1 — Dépendance à une session L’endpoint requiert l’existence d’une session backend valide pour toute exécution nominale.
• C2 — Refus systématique hors session Toute requête adressée à l’endpoint en l’absence de session valide entraîne un refus d’accès explicite, sans effet de bord métier.
• C3 — Indépendance du contenu Le refus d’accès est déclenché avant toute prise en compte du contenu fonctionnel de la requête (paramètres, payload, action demandée).
• C4 — Absence d’exécution partielle Aucune action métier, modification d’état, ni production de résultat fonctionnel ne doit être observable lorsque la session est invalide ou absente.
• C5 — Stabilité de classification La qualification d’un endpoint comme protégé est stable dans le temps et indépendante du contexte d’appel, hors validité de la session.

2.3.3 Exclusions explicites¶

Ne sont pas considérés comme des endpoints backend protégés :

• les endpoints accessibles sans session ;
• les endpoints publics ou techniques (ex. santé, disponibilité) ;
• les endpoints dont l’accès dépend uniquement de paramètres métier ou applicatifs sans notion de session.

2.4 Définition normative : Niveau homogène de validation de session¶

2.4.1 Définition¶

Le niveau homogène de validation de session désigne un ensemble invariant de vérifications fonctionnelles appliquées de manière identique, exhaustive et systématique à toute validation de session réalisée dans le cadre des endpoints backend protégés. Ce niveau est défini par les effets observables de la validation, indépendamment de toute méthode, technologie ou mécanisme technique.

2.4.2 Principe d’homogénéité¶

Le niveau de validation de session est dit homogène si, pour tout endpoint backend protégé : - les mêmes catégories de vérifications sont appliquées ; - selon les mêmes critères de validité ; - produisant les mêmes décisions d’acceptation ou de rejet à session équivalente.

Aucune dérogation locale, contextuelle ou spécifique à un endpoint n’est autorisée.

2.4.3 Critères normatifs du niveau attendu¶

Un niveau homogène de validation de session DOIT au minimum vérifier les éléments suivants :

• V1 — Existence La session est identifiable et effectivement existante.
• V2 — Validité temporelle La session est dans sa période de validité au moment de la requête.
• V3 — Intégrité La session n’est ni altérée, ni incohérente, ni partiellement invalide.
• V4 — Continuité La session n’a pas été explicitement révoquée, invalidée ou remplacée.
• V5 — Unicité de décision Pour un état de session donné, la décision (acceptation ou rejet) est strictement déterministe, quel que soit l’endpoint backend protégé ciblé.

Note normative : Ces critères définissent le périmètre fonctionnel minimal, sans préjuger des moyens techniques permettant de les vérifier.

3. Définitions¶

4. Invariants (non négociables)¶

5. Règles normatives¶

5.1 Validation des accès backend¶

5.1.1 Champ d’application¶

Les règles R-28-01 et R-28-02 s’appliquent exclusivement aux endpoints backend qualifiés de protégés au sens de la définition §2.3. Tout endpoint ne répondant pas strictement aux critères §2.3.2 est hors périmètre de ces règles.

5.1.2 R-28-01 (rappel normatif)¶

Pour tout endpoint backend protégé, le backend DOIT appliquer un niveau homogène de validation de session, tel que défini en §2.4, avant toute exécution nominale. Toute requête associée à une session ne satisfaisant pas l’ensemble des critères V1 à V5 DOIT être rejetée, sans effet de bord.

5.1.3 R-28-02 (rappel normatif)¶

Pour tout endpoint backend protégé, toute requête associée à une session absente ou invalide DOIT être rejetée de manière déterministe, sans effet de bord.

5.2 Révocation des sessions¶

R-28-03 — Événements déclencheurs de révocation
Tout événement qualifié de rupture de confiance d’authentification par PD-27 DOIT entraîner une révocation immédiate des sessions concernées.

R-28-04 — Portée de la révocation
Le périmètre de la révocation (globale ou ciblée) DOIT être proportionné à la portée de l’événement de rupture de confiance tel que défini par PD-27.

5.3 Maintien et renouvellement des sessions¶

R-28-05 — Condition de maintien
Une session existante PEUT être maintenue uniquement si aucun événement de rupture de confiance d’authentification n’est survenu depuis la dernière authentification valide.

R-28-06 — Interdiction de renouvellement
Le renouvellement d’une session DOIT être interdit dès lors que la confiance d’authentification n’est plus valide ou qu’une ré-authentification est requise. Lorsqu’un renouvellement de session est interdit à la suite d’une rupture de confiance, l’accès DOIT être refusé et une ré-authentification explicite DOIT être exigée. Aucun accès aux ressources protégées ne peut être accordé sans cette ré-authentification.

5.4 Audit et traçabilité¶

R-28-07 — Journalisation obligatoire
Toute décision d’accès backend, qu’elle aboutisse à une validation ou à un rejet, DOIT faire l’objet d’une journalisation.

R-28-08 — Contenu minimal des journaux
Les journaux DOIVENT permettre de déterminer, a posteriori : - la nature de la décision (validation / rejet), - le moment de la décision, - le périmètre concerné (session, device, compte), - la justification fonctionnelle de la décision, - le lien éventuel avec un événement de sécurité défini par PD-27.

5.4.1 Taxonomie normative des justificatifs et liens PD-27¶

Les journaux DOIVENT utiliser une taxonomie normative pour :

• la justification fonctionnelle (justification_code) ;
• le lien avec un événement PD-27 (pd27_event_ref).

Justification fonctionnelle (justification_code) : valeurs autorisées

Lien avec un événement PD-27 (pd27_event_ref) : valeurs autorisées

5bis. Diagrammes Mermaid¶

5bis.1 Diagramme d’états — Cycle de vie d’une session¶

stateDiagram-v2
    [*] --> ACTIVE : Authentification réussie (PD-27)

    ACTIVE --> ACTIVE : Accès validé (V1–V5 OK)\n[INV-01, R-28-01]
    ACTIVE --> RENEWED : Renouvellement conditionnel\n[R-28-05, R-28-06]
    ACTIVE --> REVOKED : Rupture de confiance PD-27\n[INV-02, R-28-03]
    ACTIVE --> EXPIRED : Dépassement durée de validité\n[V2]

    RENEWED --> ACTIVE : Session prolongée\n[R-28-05]
    RENEWED --> REVOKED : Rupture de confiance PD-27\n[INV-03, R-28-03]
    RENEWED --> EXPIRED : Dépassement durée de validité\n[V2]

    REVOKED --> [*] : Session définitivement invalidée\n[INV-02]
    EXPIRED --> [*] : Ré-authentification requise\n[R-28-06]

    note right of ACTIVE
        V1 Existence ✓
        V2 Validité temporelle ✓
        V3 Intégrité ✓
        V4 Continuité ✓
    end note

    note right of REVOKED
        Irréversible (INV-02)
        Portée proportionnée (R-28-04)
        Journalisée (INV-04)
    end note

5bis.2 Diagramme de séquence — Validation d’accès backend protégé¶

sequenceDiagram
    participant C as Client
    participant B as Backend (endpoint protégé)
    participant SV as Validation de session
    participant AL as Audit / Journal

    C->>B: Requête vers endpoint protégé
    activate B

    B->>SV: Valider session (V1–V5)
    activate SV

    alt Session valide (V1–V5 OK) [INV-01, R-28-01]
        SV-->>B: Session ACTIVE
        B->>AL: Journaliser ACCESS_VALIDATED [INV-04, R-28-07]
        B-->>C: 200 — Réponse nominale
    else Session absente [E-01, R-28-02]
        SV-->>B: Aucune session
        B->>AL: Journaliser ACCESS_REJECTED_NO_SESSION [INV-04, R-28-07]
        B-->>C: 401 — Accès rejeté
    else Session expirée / invalide [E-01, R-28-02]
        SV-->>B: Session EXPIRED / invalide
        B->>AL: Journaliser ACCESS_REJECTED_INVALID_SESSION [INV-04, R-28-07]
        B-->>C: 401 — Accès rejeté
    else Session révoquée [E-02, INV-02]
        SV-->>B: Session REVOKED
        B->>AL: Journaliser ACCESS_REJECTED_REVOKED_SESSION [INV-04, R-28-07]
        B-->>C: 401 — Accès rejeté
    end

    deactivate SV
    deactivate B

5bis.3 Diagramme de séquence — Révocation sur rupture de confiance PD-27¶

sequenceDiagram
    participant PD27 as PD-27 (Événement sécurité)
    participant SM as Gestion des sessions
    participant AL as Audit / Journal
    participant C as Client

    PD27->>SM: Rupture de confiance détectée\n(ex: PD27-R6-LOGOUT_GLOBAL)
    activate SM

    SM->>SM: Identifier sessions concernées\n[R-28-04 — portée proportionnée]
    SM->>SM: Révoquer sessions [INV-02, R-28-03]
    SM->>AL: Journaliser révocation\n[INV-04, R-28-07, R-28-08]

    deactivate SM

    Note over C,AL: Accès suivant du client

    C->>SM: Requête avec session révoquée
    activate SM
    SM-->>C: 401 — Accès rejeté\n+ Ré-authentification exigée [R-28-06]
    SM->>AL: Journaliser ACCESS_REJECTED_REAUTH_REQUIRED\n[INV-04, R-28-07]
    deactivate SM

6. Cas d’erreur¶

7. Critères d’acceptation (testables)¶

7.1 Traçabilité normative vers les tests¶

7.1.1 Correspondance définition ↔ tests¶

7.1.2 Principe de testabilité¶

Les tests TC-INV-01 et TC-NOM-01 valident exclusivement : - la qualification normative d’un endpoint comme protégé, - le comportement observable attendu en cas de session invalide ou absente.

Ils ne présupposent aucun mécanisme d’implémentation, ni aucune classification technique implicite.

7.2 Traçabilité normative vers les tests (niveau homogène)¶

7.2.1 Correspondance règles ↔ tests¶

7.2.2 Principe de non-interprétation¶

Les tests vérifient l’invariance comportementale du niveau de validation de session. Ils ne valident ni l’intensité technique des contrôles, ni leur implémentation interne.

8. Scénarios de test (Given / When / Then)¶

Les scénarios de test de référence sont définis dans le document PD-28-tests.md et couvrent l’ensemble des invariants et critères d’acceptation.

9. Hypothèses explicites¶

10. Points à clarifier¶

• Objet exact de la révocation : session logique, jeton d’accès ou les deux. La révocation s’applique à la session d’authentification en tant qu’état logique. Tout jeton associé à une session révoquée DOIT être considéré comme invalide et ne plus permettre l’accès aux ressources protégées.
• Délai maximal acceptable pour qu’une révocation soit effective. La révocation d’une session DOIT être effective sans délai injustifié du point de vue de l’accès aux ressources protégées. Toute acceptation d’accès postérieure à une révocation constitue une non-conformité.
• Durée maximale de maintien ou de renouvellement d’une session. La durée maximale de maintien ou de renouvellement d’une session DOIT être bornée. Les valeurs applicables sont définies par une politique de sécurité distincte. Une session ne DOIT en aucun cas être maintenue ou renouvelée indéfiniment.
• Politique de conservation des journaux d’audit. La durée de conservation des journaux d’audit DOIT être définie par une politique de sécurité distincte. Les journaux de décisions d’accès DOIVENT être conservés sur cette durée pour garantir l’auditabilité. L’expiration des journaux ne DOIT pas réduire les garanties d’auditabilité applicables sur la période requise.

Références¶

• Epic : PD-182 AUTH
• JIRA : PD-28
• Documents associés : PD-23, PD-26, PD-27