Aller au contenu

PD-27 — Authentification Multi-Facteurs (MFA) déléguée à l’IdP

1. Objectif

La présente spécification définit de manière canonique, contractuelle et opposable les règles d’authentification multi‑facteurs (MFA) applicables à ProbatioVault.

Elle garantit que tout accès utilisateur est conditionné à un niveau d’assurance d’authentification suffisant, fondé sur des preuves factuelles fournies par l’Identity Provider (IdP) via les claims OIDC standard.

Cette spécification ne définit aucun mécanisme cryptographique MFA et ne décrit aucune implémentation. Elle formalise exclusivement les conditions d’acceptation ou de rejet d’une session d’authentification du point de vue de ProbatioVault.


2. Périmètre

2.1 Inclus

  • Obligation d’authentification multi‑facteurs pour tous les utilisateurs.
  • Définition contractuelle d’un device et de sa confiance.
  • Conditions d’exigence du MFA (nouveau device, actions sensibles, événements de sécurité).
  • Règles de décision fondées sur les claims OIDC (amr, acr).
  • Délégation explicite des mécanismes MFA à l’IdP (Keycloak).

2.2 Exclus (hors périmètre)

  • Génération, stockage ou validation de secrets TOTP.
  • Gestion des QR codes, applications d’authentification ou facteurs physiques.
  • Implémentation des mécanismes anti‑bruteforce.
  • Procédures humaines ou administratives de récupération d’accès.

Les éléments listés ci‑dessus sont hors périmètre et non testables dans le cadre de cette spécification.


3. Définitions

  • MFA : authentification reposant sur au moins deux facteurs distincts.
  • TOTP : mot de passe à usage unique basé sur le temps (RFC 6238).
  • IdP : Identity Provider assurant l’authentification (Keycloak).
  • Device : couple (client_id, device_fingerprint).
  • Device de confiance : device ayant validé une authentification MFA.
  • Action sensible : action nécessitant un niveau d’assurance renforcé.
  • amr : claim OIDC listant les méthodes d’authentification utilisées.
  • acr : claim OIDC indiquant le niveau d’assurance revendiqué.

4. Invariants (non négociables)

ID Invariant
I1 Toute session utilisateur acceptée par ProbatioVault repose sur une authentification validée par l’IdP.
I2 Le MFA est obligatoire pour tous les utilisateurs.
I3 Aucun secret MFA n'apparait dans les interfaces publiques, payloads, logs applicatifs, ou persistance applicative de ProbatioVault.
I4 La satisfaction du MFA est déterminée exclusivement par les claims OIDC.
I5 Un device ne peut être de confiance sans authentification MFA réussie.

5. Règles normatives

5.1 Obligation MFA

R1. Le MFA est obligatoire pour tous les utilisateurs de ProbatioVault.

R2. Le MFA est exigé lors de la première authentification depuis un nouveau device.

R2.a. Hors cas R2 et R7, une authentification depuis un device de confiance NE REQUIERT PAS de MFA, sauf politique de securite explicite plus stricte.

5.2 Gestion des devices

R3. Un device est défini contractuellement comme le couple (client_id, device_fingerprint).

R3.a. Le device_fingerprint DOIT etre stable pour un meme device sur la periode de confiance (R5) et DOIT permettre de distinguer deux devices distincts pour un meme client_id.

R4. Un device devient de confiance uniquement après une authentification MFA réussie.

R5. La confiance associée à un device expire après 90 jours calendaires sans authentification réussie depuis ce device.

R5.a. La reference temporelle pour le calcul des 90 jours est celle de l'IdP.

R5.b. Une authentification reussie au sens de R5 est une session acceptee par l'IdP et satisfaisant les exigences MFA applicables (R2, R2.a, R7).

R6. La confiance d’un device est révoquée en cas de : - déconnexion globale, - réinitialisation des paramètres de sécurité, - tentatives d’authentification infructueuses répétées.

La révocation de la confiance n’entraîne pas automatiquement le verrouillage du compte.

NOTE : Le seuil et les conditions de "tentatives d'authentification infructueuses repetées" sont delegues a l'IdP et sont non testables dans le cadre de PD-27 sans artefact externe.

5.3 Actions sensibles

R7. L’accès à une action classée sensible requiert une authentification MFA, y compris depuis un device de confiance.

R8. La classification des actions sensibles relève de la politique de sécurité de ProbatioVault et n’est pas limitée aux exemples suivants : export, partage ou suppression de données.

NOTE : La liste normative des actions sensibles est definie dans l'annexe "Security Policy - Sensitive Actions List vX" incluse ci-dessous.

5.4 Claims OIDC requis

Precondition normative : les jetons OIDC DOIVENT etre valides conformement aux exigences PD-26 (signature, issuer, audience, expiration, et autres controles applicables).

R9. Le claim amr DOIT être présent dans le jeton d’authentification.

R10. Le MFA est considéré comme satisfait si et seulement si le claim amr contient "otp".

R11. Le claim acr PEUT être utilisé comme signal complémentaire de niveau d’assurance.

R12. Si le claim acr est présent et n'est pas egal a la valeur minimale requise par la politique de securite, la session DOIT etre rejetee.

R12.a. La valeur minimale requise est : urn:probatiovault:acr:mfa.


6. Codes de secours

La gestion des codes de secours (génération, format, usage, régénération) est entièrement déléguée à l’IdP et est hors périmètre de la présente spécification.


6bis. Diagrammes

6bis.1 Diagramme d’états — Cycle de confiance d’un device

Modélise les transitions de confiance d’un device selon les règles R2, R4, R5, R6. Référence invariants : I5 (pas de confiance sans MFA), I2 (MFA obligatoire).

stateDiagram-v2
    [*] --> Nouveau : Première connexion (R2)
    Nouveau --> DeConfiance : MFA réussie via IdP (R4, I5)
    DeConfiance --> DeConfiance : Auth réussie < 90j (R5.b)
    DeConfiance --> Expiré : 90j sans auth réussie (R5, R5.a)
    DeConfiance --> Révoqué : Déconnexion globale / Reset sécurité / Échecs répétés (R6)
    Expiré --> DeConfiance : MFA réussie via IdP (R4)
    Révoqué --> DeConfiance : MFA réussie via IdP (R4)

    note right of Nouveau
        Device = (client_id, device_fingerprint) — R3
        Fingerprint stable sur période de confiance — R3.a
    end note

    note right of Révoqué
        La révocation n’entraîne pas
        le verrouillage du compte — R6
    end note

6bis.2 Diagramme de séquence — Authentification MFA déléguée (flux nominal)

Modélise le flux d’authentification entre le client, ProbatioVault et l’IdP (Keycloak). Référence invariants : I1 (session validée par IdP), I3 (aucun secret MFA dans PV), I4 (décision par claims OIDC).

sequenceDiagram
    participant C as Client
    participant PV as ProbatioVault
    participant IdP as Keycloak (IdP)

    C->>PV : Demande d’authentification
    PV->>IdP : Redirection OIDC (authorization request)
    IdP->>C : Challenge MFA (TOTP) — I3 : secret hors PV
    C->>IdP : Réponse MFA (OTP)
    IdP->>IdP : Validation MFA + émission jeton
    IdP->>PV : Jeton OIDC (amr, acr)

    alt amr contient "otp" ET acr >= urn:probatiovault:acr:mfa (R10, R12, R12.a)
        PV->>PV : MFA satisfait — I4
        PV->>PV : Device marqué de confiance (R4, I5)
        PV->>C : Session acceptée — I1
    else amr absent (E1) OU amr sans "otp" (E2) OU acr insuffisant (E3)
        PV->>C : Rejet explicite (401/403)
    end

6bis.3 Diagramme de séquence — Accès à une action sensible

Modélise le step-up MFA requis pour les actions sensibles, même depuis un device de confiance. Référence invariants : I2 (MFA obligatoire), I4 (décision par claims OIDC). Règles : R7, R8.

sequenceDiagram
    participant C as Client
    participant PV as ProbatioVault
    participant IdP as Keycloak (IdP)

    C->>PV : Action sensible (ex: EXPORT_DATA) — R7
    PV->>PV : Vérification : action classée sensible (R8)
    PV->>PV : MFA requis même si device de confiance (R7)

    alt Session courante avec amr "otp" valide
        PV->>PV : MFA déjà satisfait — I4
        PV->>C : Action autorisée
    else MFA non satisfait dans session courante
        PV->>IdP : Step-up authentication request
        IdP->>C : Challenge MFA (TOTP)
        C->>IdP : Réponse MFA (OTP)
        IdP->>PV : Nouveau jeton OIDC (amr, acr)
        PV->>PV : Validation claims (R9, R10, R12)
        PV->>C : Action autorisée
    end

7. Cas d’erreur

ID Situation Comportement attendu
E1 Absence du claim amr Rejet explicite de la session
E2 Claim amr sans "otp" alors que MFA requis Rejet explicite
E3 Claim acr présent mais insuffisant Rejet explicite
E4 Tentative d’accès à une action sensible sans MFA valide Rejet explicite

8. Critères d’acceptation

ID Critère
CA1 Une session MFA valide est acceptée.
CA2 Une session sans MFA valide est rejetée.
CA3 Le MFA est exigé sur tout nouveau device.
CA4 Le MFA est exigé pour toute action sensible.
CA5 Aucune donnée MFA n’est manipulée par ProbatioVault.

9. Sécurité et conformité

  • Le MFA renforce la protection contre l’accès non autorisé.
  • La délégation à l’IdP limite la surface d’attaque de ProbatioVault.
  • La non‑manipulation des secrets MFA par ProbatioVault est un objectif de conception testable indirectement.
  • Les propriétés cryptographiques intrinsèques du TOTP sont hors périmètre.

10. Contrôle de version

  • Document : PD-27-specification.md
  • Epic : PD-182 AUTH
  • Dépendances : PD-23, PD-26
  • Statut : Draft
  • Version : 1.0

Annexe A — Security Policy - Sensitive Actions List vX

1. Objet

Le present document definit la politique de classification des actions sensibles au sens de la securite applicative ProbatioVault. Une action sensible est toute action dont l'execution presente un risque accru en matiere de : confidentialite, integrite, disponibilite, valeur probatoire, ou securite du compte utilisateur. Cette politique est normative et referencee contractuellement par les specifications applicatives (notamment PD-27).

2. Portee

2.1 Inclus

La presente politique s'applique : aux actions declenchees par un utilisateur authentifie, sur l'ensemble des interfaces ProbatioVault (web, mobile, API), independamment du type de device ou du niveau de confiance du device.

2.2 Exclus (hors perimetre)

Les actions purement informatives sans effet sur l'etat du compte ou des donnees. Les actions internes automatisees sans interaction utilisateur directe.

3. Principe normatif

R-SP-01 — Principe general Toute action classee "sensible" DOIT exiger une authentification MFA valide, independamment du statut de confiance du device, sauf exception explicitement documentee. Cette exigence est cumulative avec toute autre politique de securite.

4. Categories d'actions sensibles

Les categories suivantes sont normatives. Toute action relevant d'une de ces categories est implicitement sensible, meme si elle n'est pas listee individuellement.

4.1 Actions affectant la securite du compte

Incluent notamment : changement de mot de passe, activation, desactivation ou modification du MFA, modification des parametres de securite, recuperation de compte, invalidation de sessions ou devices, modification des identifiants ou facteurs d'authentification.

4.2 Actions affectant l'acces ou le partage des donnees

Incluent notamment : partage de donnees ou de documents avec un tiers, modification des droits d'acces, generation ou revocation de liens de partage, delegation d'acces.

4.3 Actions destructives ou irreversibles

Incluent notamment : suppression de donnees ou de documents, revocation definitive d'un acces, purge de contenus, toute action non annulable ou non recuperable.

4.4 Actions d'export ou d'exfiltration de donnees

Incluent notamment : export de documents, export de metadonnees, telechargement massif, generation d'archives ou de snapshots.

4.5 Actions a valeur probatoire ou juridique elevee

Incluent notamment : validation finale d'un depot probatoire, scellement ou cloture d'un dossier, generation ou validation d'une preuve, toute action engageant la valeur legale des donnees.

5. Liste d'exemples (non exhaustive)

ATTENTION : Cette liste est illustrative et non exhaustive. L'appartenance a une categorie prevaut sur la presence dans la liste.

Exemples : EXPORT_DATA DELETE_DOCUMENT SHARE_DOCUMENT REVOKE_ACCESS CHANGE_PASSWORD DISABLE_MFA RESET_SECURITY_SETTINGS ACCOUNT_RECOVERY FINALIZE_PROOF PURGE_VAULT

6. Gouvernance et evolution

R-SP-02 — Autorite de classification La classification des actions sensibles releve de la politique de securite ProbatioVault, maintenue par l'equipe securite.

R-SP-03 — Evolution De nouvelles actions PEUVENT etre classees sensibles a tout moment. L'ajout d'actions sensibles NE DOIT PAS reduire les garanties existantes. L'evolution de cette politique NE DOIT PAS invalider retroactivement les exigences MFA deja appliquees.

7. Observabilite et auditabilite

R-SP-04 — Tracabilite Pour toute action sensible : le declenchement de l'exigence MFA, la satisfaction ou le rejet de cette exigence, DOIVENT etre auditables via des evenements ou journaux de securite.

8. References normatives

PD-27 — MFA & Device Trust Policy PD-26 — OAuth2 / OIDC / IdP Politique de securite ProbatioVault (document maitre)

9. Versioning

Champ\tValeur Document\tSecurity Policy - Sensitive Actions List Version\tvX Statut\tNormatif Date\tYYYY-MM-DD Proprietaire\tSecurite ProbatioVault