PD-30 - Specification Canonique Contractuelle : Session Management Redis¶

1. Objectif¶

Definir le comportement contractuel du service de gestion de sessions pour garantir, sans ambiguite : - le controle en temps reel des sessions actives d'un utilisateur ; - l'expiration automatique et le renouvellement conditionnel des sessions ; - l'invalidation immediate d'une session, d'un appareil, ou de toutes les sessions utilisateur ; - la tracabilite probatoire des evenements de session ; - la robustesse en mode degrade (fallback in-memory avec TTL) lorsque le store central est indisponible.

Besoins fonctionnels contractualises (F-30-01 a F-30-12)¶

2. Perimetre / Hors perimetre¶

Inclus¶

• Cycle de vie de session : creation, lecture, renouvellement, expiration, invalidation.
• Gestion multi-device par utilisateur avec isolation stricte inter-utilisateurs.
• Invalidation cross-instance avec borne de latence contractuelle.
• Journalisation append-only des evenements de session.
• Rate limiting des operations sensibles de session.
• Mode degrade quand le store central est indisponible (fallback in-memory avec TTL).

Exclu¶

• Mecanisme d'authentification primaire (PD-23, PD-25, PD-26).
• Gestion des enveloppes de cles/HSM (PD-37, PD-40).
• Interfaces UX mobile/web de consultation/revocation des appareils.
• Alerting/monitoring infra (hors telemetry applicative minimale de ce scope).

Hors perimetre (regles non testables en l'etat)¶

• HP-30-01 : Exigence de "montee en charge lineaire" sans cible numerique de charge/latence validee.
• HP-30-02 : Exigence de "coherence avec mecanisme d'ancrage probatoire" sans contrat d'interface technique explicite dans les entrees de cette story.

3. Definitions¶

Operations sensibles (rate limiting INV-30-15)¶

Valeurs TTL par contexte (INV-30-07)¶

4. Invariants (non negociables)¶

5. Flux nominaux¶

FN-30-01 - Creation de session apres authentification¶

1. Le systeme recoit la confirmation d'authentification reussie.
2. Le systeme cree une session active unique avec tous les attributs contractuels (INV-30-03).
3. Le systeme applique le TTL du contexte (WEB/MOBILE/API/SENSITIVE).
4. Le systeme journalise CREATE.
5. La session est utilisable immediatement.

FN-30-02 - Expiration automatique¶

1. Le systeme calcule expiresAt a la creation/au renouvellement.
2. A l'atteinte de expiresAt, la session passe en etat EXPIRED.
3. Toute requete utilisant cette session est rejetee.
4. Le systeme journalise EXPIRE.

FN-30-03 - Renouvellement TTL sur activite continue¶

1. Une requete authentifiee valide est recue avant expiration.
2. Le systeme verifie que la session est ACTIVE.
3. Le systeme met a jour lastActivityAt et expiresAt selon la politique du contexte.
4. Le systeme journalise REFRESH.

FN-30-04 - Consultation appareils/sessions actives¶

1. L'utilisateur authentifie demande la liste de ses appareils connectes.
2. Le systeme retourne uniquement les sessions de ce userId.
3. Chaque entree expose strictement les champs autorises (INV-30-12).
4. Les donnees retournees ont un decalage maximal de 2 secondes par rapport a l'etat courant du store central.

FN-30-05 - Revocation ciblee (session ou appareil)¶

1. L'acteur legitime (utilisateur ou systeme) demande la revocation.
2. Le systeme applique le rate limiting (INV-30-15).
3. Le systeme invalide la session ciblee ou toutes les sessions du deviceId cible.
4. Le systeme garantit la propagation cross-instance selon INV-30-09.
5. Le systeme journalise REVOKE_SESSION ou REVOKE_DEVICE.

FN-30-06 - Revocation globale utilisateur¶

1. Un declencheur autorise demande la revocation globale.
2. Le systeme applique le rate limiting si declencheur utilisateur.
3. Le systeme invalide toutes les sessions du userId.
4. Le systeme garantit la propagation cross-instance selon INV-30-10.
5. Le systeme journalise REVOKE_ALL avec motif.

FN-30-07 - Invalidation par evenement de securite/conformite¶

1. Le systeme recoit l'un des evenements contractuels : PASSWORD_CHANGED, DEVICE_REVOKED, INTRUSION_SUSPECTED, JUDICIAL_REQUEST.
2. Le systeme applique la politique de portee :
3. PASSWORD_CHANGED -> REVOKE_ALL utilisateur ;
4. DEVICE_REVOKED -> REVOKE_DEVICE cible ;
5. INTRUSION_SUSPECTED -> REVOKE_ALL utilisateur ;
6. JUDICIAL_REQUEST -> REVOKE_ALL utilisateur ou portee precisee par la requete judiciaire ; si la portee n'est pas precisee, appliquer REVOKE_ALL utilisateur avec motif JUDICIAL_DEFAULT_SCOPE.
7. Le systeme journalise l'evenement source et l'invalidation effectuee.

5bis. Diagrammes Mermaid¶

Diagramme d'etats -- Cycle de vie d'une session¶

Modelise les transitions entre les 3 etats d'une session. Ref. INV-30-01 (creation), INV-30-05 (expiration automatique), INV-30-06 (renouvellement conditionnel), INV-30-09/INV-30-10 (invalidation immediate), INV-30-18/INV-30-19 (mode degrade).

stateDiagram-v2
    [*] --> ACTIVE : Authentification reussie\n[INV-30-01, FN-30-01]

    ACTIVE --> ACTIVE : Requete valide avant expiration\nRefresh TTL [INV-30-06, FN-30-03]
    ACTIVE --> EXPIRED : expiresAt atteint\nExpiration automatique [INV-30-05, FN-30-02]
    ACTIVE --> INVALIDATED : REVOKE_SESSION / REVOKE_DEVICE\n[INV-30-09, FN-30-05]
    ACTIVE --> INVALIDATED : REVOKE_ALL\n[INV-30-10, FN-30-06]
    ACTIVE --> INVALIDATED : Evenement securite\nPASSWORD_CHANGED / INTRUSION_SUSPECTED\nDEVICE_REVOKED / JUDICIAL_REQUEST\n[INV-30-11, FN-30-07]

    EXPIRED --> [*]
    INVALIDATED --> [*]

    note right of ACTIVE
        TTL selon contexte [INV-30-07] :
        WEB=3600s | MOBILE=604800s
        API=86400s | SENSITIVE=900s
    end note

    note right of INVALIDATED
        Propagation cross-instance :
        p95 < 100 ms, p99 < 250 ms
        [INV-30-09, INV-30-10]
    end note

Diagramme de sequence -- Creation de session et renouvellement¶

Illustre les interactions multi-service pour la creation (FN-30-01) et le renouvellement (FN-30-03), incluant la journalisation probatoire (INV-30-16) et la comparaison timing-safe (INV-30-14).

sequenceDiagram
    participant Client
    participant AuthService
    participant SessionService
    participant Redis as Redis (Store central)
    participant AuditLog as Audit Log (append-only)

    Note over Client, AuditLog: FN-30-01 — Creation de session

    AuthService->>SessionService: createSession(userId, deviceId, context, ipHash, userAgentHash)
    SessionService->>SessionService: Generer sessionId unique [INV-30-02]
    SessionService->>SessionService: Calculer TTL selon context [INV-30-07]
    SessionService->>Redis: SET session:{sessionId} {payload} EX {ttl}
    Redis-->>SessionService: OK
    SessionService->>Redis: SADD user_sessions:{userId} {sessionId}
    Redis-->>SessionService: OK
    SessionService->>AuditLog: Journaliser CREATE [INV-30-16]
    SessionService-->>AuthService: Session ACTIVE (sessionId, expiresAt)

    Note over Client, AuditLog: FN-30-03 — Renouvellement TTL sur activite

    Client->>SessionService: Requete authentifiee (sessionId)
    SessionService->>SessionService: Comparaison timing-safe [INV-30-14]
    SessionService->>Redis: GET session:{sessionId}
    Redis-->>SessionService: Session (status, expiresAt)
    alt Session ACTIVE et non expiree [INV-30-06]
        SessionService->>Redis: SET session:{sessionId} {updated} EX {ttl}
        Redis-->>SessionService: OK
        SessionService->>AuditLog: Journaliser REFRESH [INV-30-16]
        SessionService-->>Client: 200 OK
    else Session EXPIRED ou INVALIDATED
        SessionService->>AuditLog: Journaliser SESSION_REJECTED [ECT-30-01]
        SessionService-->>Client: 401 SESSION_INVALID
    end

Diagramme de sequence -- Invalidation par evenement de securite et mode degrade¶

Illustre la revocation declenchee par evenement (FN-30-07, INV-30-11), la propagation cross-instance (INV-30-09/INV-30-10), et le fallback in-memory (INV-30-18/INV-30-19).

sequenceDiagram
    participant EventBus
    participant SessionService
    participant Redis as Redis (Store central)
    participant Instance2 as Instance N (autres noeuds)
    participant AuditLog as Audit Log (append-only)
    participant Fallback as Fallback (in-memory)

    Note over EventBus, AuditLog: FN-30-07 — Invalidation par evenement securite

    EventBus->>SessionService: PASSWORD_CHANGED(userId)
    SessionService->>SessionService: Resoudre portee → REVOKE_ALL [INV-30-11]
    SessionService->>Redis: SMEMBERS user_sessions:{userId}
    Redis-->>SessionService: [sessionId1, sessionId2, sessionId3]
    SessionService->>Redis: DEL session:{sessionId1}, session:{sessionId2}, session:{sessionId3}
    Redis-->>SessionService: OK
    SessionService->>Redis: DEL user_sessions:{userId}
    Redis-->>SessionService: OK

    par Propagation cross-instance [INV-30-10]
        SessionService->>Instance2: Pub/Sub INVALIDATE_ALL(userId)
        Note right of Instance2: p95 < 100 ms, p99 < 250 ms
    end

    SessionService->>AuditLog: Journaliser REVOKE_ALL + motif PASSWORD_CHANGED [INV-30-16]

    Note over EventBus, Fallback: INV-30-18/INV-30-19 — Bascule mode degrade

    SessionService->>Redis: Healthcheck
    Redis--xSessionService: Timeout / Erreur

    SessionService->>Fallback: Activer fallback in-memory (< 1s) [INV-30-18]
    SessionService->>AuditLog: Journaliser FALLBACK_ON [INV-30-16]

    Note over SessionService, Fallback: Operations locales OK, operations globales rejetees [INV-30-19]

6. Cas d'erreur¶

7. Criteres d'acceptation (testables)¶

8. Scenarios de test (Given / When / Then)¶

ST-30-01 - Creation session¶

Given un utilisateur authentifie avec succes en contexte WEB When la session est creee Then une session ACTIVE unique est stockee avec tous les champs obligatoires et un TTL WEB

ST-30-02 - Expiration automatique¶

Given une session ACTIVE dont expiresAt est atteint When une requete authentifiee est emise avec cette session Then la requete est rejetee avec SESSION_INVALID et un evenement EXPIRE est present

ST-30-03 - Refresh avant expiration¶

Given une session ACTIVE non expiree When une requete valide est traitee Then lastActivityAt et expiresAt sont mis a jour et REFRESH est journalise

ST-30-04 - Refresh apres expiration (interdit)¶

Given une session expiree When une tentative de renouvellement est soumise Then le renouvellement est refuse et la session reste invalide

ST-30-05 - Liste appareils isolee¶

Given deux utilisateurs avec sessions actives distinctes When l'utilisateur A consulte ses appareils Then seules les sessions de A sont retournees avec les champs autorises

ST-30-06 - Revocation session ciblee multi-instance¶

Given une session active presente sur un cluster multi-instance When une revocation ciblee est declenchee Then l'usage du token est refuse sur toutes les instances avec p95 < 100 ms et p99 < 250 ms

ST-30-07 - Revocation globale suite changement mot de passe¶

Given un utilisateur avec 3 sessions actives When l'evenement PASSWORD_CHANGED est emis Then les 3 sessions deviennent inutilisables dans les bornes contractuelles

ST-30-08 - Revocation device¶

Given un utilisateur avec 2 sessions sur device-X et 1 session sur device-Y When device-X est revoque Then les 2 sessions de device-X sont invalidees et celle de device-Y reste active

ST-30-09 - Rate limit utilisateur¶

Given un utilisateur authentifie sur operation sensible When il emet 4 requetes en moins de 15 minutes Then la 4e requete est rejetee RATE_LIMIT_USER

ST-30-10 - Rate limit IP¶

Given plusieurs comptes derriere une meme IP When 6 requetes sensibles sont emises en moins de 15 minutes Then la 6e requete est rejetee RATE_LIMIT_IP

ST-30-11 - Fallback active¶

Given le store central devient indisponible When le service bascule en mode degrade Then FALLBACK_ON est journalise en < 1 s et les sessions fallback expirent selon TTL

ST-30-12 - Restriction mode degrade¶

Given le mode degrade est actif When une operation globale REVOKE_ALL_USER_SESSIONS est demandee Then la requete est rejetee DEGRADED_MODE_RESTRICTION et tracee

ST-30-13 - Journal probatoire complet¶

Given une sequence create -> refresh -> revoke When l'audit est extrait Then les 3 evenements sont presents, horodates, ordonnes, avec acteur et motif

9. Hypotheses explicites¶

10. Points a clarifier¶

References¶

• Epic : PD-182 (AUTH)
• JIRA : PD-30
• Repos concernes : ProbatioVault-backend
• Documents associes : Architecture 41, Specifications techniques 42