Skip to content

feat(ra-console): révocation et salle de quorum dans le navigateur (étape 6c) - #72

Closed
PhilippeVienne wants to merge 7 commits into
feat/ra-console-frontend-requestsfrom
feat/ra-console-frontend-revoke
Closed

feat(ra-console): révocation et salle de quorum dans le navigateur (étape 6c)#72
PhilippeVienne wants to merge 7 commits into
feat/ra-console-frontend-requestsfrom
feat/ra-console-frontend-revoke

Conversation

@PhilippeVienne

@PhilippeVienne PhilippeVienne commented Sep 27, 2026

Copy link
Copy Markdown
Contributor

Objet

docs/WEBUI.md §8 et §15 étape 6, tranche 6c ; docs/UI-UX.md §3.2. Deux opérateurs CA distincts révoquent un certificat depuis la console. Empilée sur #71 (feat/ra-console-frontend-requests, tête d05e829).

  • API : GET /api/v1/certificates?status=issued|revoked — certificats émis, en lecture seule sur la table de ca-server (que le rôle de la console lisait déjà), numéro de série en hexadécimal minuscule, la forme canonique qu'attend la révocation. Les certificats reserved n'y figurent pas.
  • Navigation entre demandes RA, certificats et quorum.
  • Certificats : liste des actifs (numéro de série par paires, UI-UX §4.2), inspecteur, « Révoquer… » → motif RFC 5280 parmi ceux qu'admet ca-server (1, 3, 4, 5, 9), justification obligatoire, modale de signature (corps figé + empreinte). La première signature part en salle de quorum (« 1 sur 2 »).
  • Salle de quorum : actions en attente, corps figé, empreinte, qui a déjà signé ; co-signature désactivée pour qui a déjà signé (« le double contrôle requiert un opérateur distinct ») — garde d'affichage, ca-server la refuse de toute façon.
  • sign() rend désormais la réponse de l'autorité (pour afficher AWAITING_QUORUM / EXECUTED).
  • Harnais e2e : trois opérateurs (alice ra_operateur, bob et carol ca_operateur), une vraie CA sur la même base avec le révocateur de ca-server, deux certificats émis.

Vérifications

  • Test Rust the_console_lists_issued_certificates : liste, filtre, passage en revoked après double signature, 400 sur un état inconnu, 401 sans session.
  • Playwright 8/8 en local sur trois passes : bob signe la révocation (rien n'est révoqué, « 1 sur 2 »), ne peut pas co-signer lui-même ; carol voit « Quorum (1) », co-signe, le certificat passe revoked côté serveur, la salle se vide ; un ra_operateur se voit refuser la préparation par l'autorité, rien n'est figé. Parcours de 6a/6b toujours verts.
  • Mutation : sans la désactivation de la co-signature pour son propre signataire, le parcours échoue.
  • cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings (1.97 et 1.98.1), cargo test --workspace avec PostgreSQL, cargo audit --ignore RUSTSEC-2023-0071, npm run typecheck : verts.

Revue humaine obligatoire

Voir PROVENANCE.md. Chaque case est cochée par le
contributeur humain qui valide la PR, après l'avoir fait lui-même.

  • Revue d'architecture validée par l'humain
  • Code relu et tests unitaires/intégration vérifiés localement
  • Absence de dépendances tierces incompatibles avec la double licence EUPL-1.2 / AGPL-3.0 (make licenses)
  • Validation de l'apport intellectuel et de la paternité humaine sur la modification

Assistance par IA

  • Cette PR a été produite avec l'assistance de Claude Code : les commits concernés portent la remorque Co-authored-by: Claude <noreply@anthropic.com>, auteur et committer restent humains, et scripts/provenance.py archive a été lancé
  • Cette PR a été écrite sans assistance par IA

PhilippeVienne and others added 6 commits September 27, 2026 10:02
@PhilippeVienne @claude
feat(ra-console): préparation des actions signées approve/reject (éta…
37958f4 
…pe 3a)

docs/WEBUI.md §15 étape 3, schéma de signature §4 étapes 1 à 3 :
`POST /api/v1/webauthn/challenge` relaie à ca-server
(`/internal/v1/challenge`) l'action demandée par l'opérateur connecté ;
ca-server la fige et rend le corps qu'il exécutera, son empreinte et les
options WebAuthn.

- Le challenge vise l'opérateur de la session : `operator_hint` vient de
  la session (Authenticated gagne `operator_id`), jamais du navigateur.
  L'action est relue dans l'énumération fermée d'oe_actions puis
  resérialisée : un champ en trop ne franchit pas la console.
- Seuls approve_request et reject_request sont préparés à ce stade (403
  action_not_available sinon, sans solliciter ca-server). Le rôle et
  l'état de la demande restent jugés par ca-server.
- Journal de la console : ra.action_challenge (AppState gagne `journal`).
- action_challenge.rs, contre le vrai service d'actions de ca-server et
  PostgreSQL ; trois mutations tuées (indice venu du navigateur, filtre
  de l'étape, session non exigée).
- docs/RA-CONSOLE.md mis à jour.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): exécution des décisions signées approve/reject (éta…
457dc7e 
…pe 3b)

docs/WEBUI.md §15 étape 3, §4 étapes 5 à 7 : `POST
/api/v1/requests/{id}/approve|reject` relaie à ca-server
(`/internal/v1/actions`) l'identifiant du challenge et l'assertion brute,
jamais de corps : ca-server exécute celui qu'il a figé.

- Lien assertion ↔ demande contrôlé par ca-server (décision de
  l'utilisateur) : la console joint `expect` (action et demande du
  chemin) ; oe_actions::Service::execute_expecting le compare au corps
  figé avant de retirer l'état de la cérémonie, et refuse (409
  action_mismatch) s'il diffère. Une signature obtenue pour une demande
  ne décide jamais d'une autre, ni l'inverse de ce qui a été signé, et
  l'assertion reste utilisable sur la bonne route. `expect` ne peut que
  restreindre ; `execute` sans attente est inchangé.
- Réponse de la forme du §5 : `decided_by` est l'opérateur dont la clé a
  signé, lu dans le registre de ca-server.
- Journal de la console : ra.action_relayed.
- Tests de bout en bout (approbation, rejet, rejeu, mauvaise cible,
  corps non relayés) et unitaire d'Expect ; trois mutations tuées
  (contrôle retiré, contrôle après consommation, expect non envoyé).

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): révocation d'un certificat, première signature (éta…
aac4dbc 
…pe 4a)

docs/WEBUI.md §15 étape 4, §8 : la console prépare `revoke_certificate`
et relaie la signature par `POST /api/v1/certificates/{serial}/revoke`.
La politique de ca-server exige deux ca_operateur distincts : la
première signature est enregistrée, rien n'est révoqué
(AWAITING_QUORUM, 1/2). La co-signature est l'étape 4b.

- oe_actions::Expect gagne `serial` : ca-server compare le certificat de
  la route au corps figé avant toute consommation, comme pour une
  décision ; une cible sans rapport avec le type d'action est refusée.
- ra-console : relay_assertion factorise le relais d'une assertion
  (décisions et révocation) ; numéro de série exigé sous forme
  canonique (hexadécimal minuscule, 20 octets au plus) avant relais.
- Tests : harnais doté d'une vraie CA sur PostgreSQL et du révocateur de
  ca-server ; première signature sans révocation, mauvaise cible,
  forme non canonique, refus pour un ra_operateur. Deux mutations tuées.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): double contrôle, co-signature et salle d'attente (é…
4525c07 
…tape 4b)

docs/WEBUI.md §8, §15 étape 4 : deux ca_operateur distincts révoquent
ensemble depuis la console.

- Co-signature : `POST /api/v1/webauthn/challenge` accepte
  `{"action_id"}` (action existante, non exécutée, proposée à ce stade),
  puis `POST /api/v1/quorum/{action_id}/sign`. oe_actions::Expect gagne
  `action_id`, comparé avant toute consommation : une co-signature ne
  compte que pour l'action pour laquelle son challenge a été émis.
- Salle d'attente : `GET /api/v1/quorum?state=PENDING` lit `actions` et
  `decision_evidence` de ca-server en lecture seule (décision de
  l'utilisateur) : corps figé, empreinte, signatures, signataires. Le
  rôle de la console gagne SELECT sur `actions` (aucun secret n'y
  figure) ; le test de schéma est mis à jour.
- Écart assumé avec le §8, en plus sûr : pas de tables de collecte, la
  console ne conserve jamais d'assertion (ca-server enregistre chaque
  signature au fil de l'eau). WEBUI.md §8 dit ce qui est construit.
- Tests : révocation à deux de bout en bout, seconde signature du même
  opérateur refusée, exécution unique, co-signature présentée pour une
  autre action sur le même certificat refusée. Deux mutations tuées.
- Mise à jour d'un déploiement : rejouer ra_console_grants.sql.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): frontend, socle (étape 6a)
6e3e1c2 
docs/WEBUI.md §15 étape 6, docs/UI-UX.md : la console sert son interface,
en TypeScript compilé par esbuild (choix de l'utilisateur), sans
framework ni dépendance d'exécution.

- Assets embarqués dans le binaire (include_bytes!, src/web.rs) depuis
  web/dist, versionné : compiler ra-console n'exige pas Node.
- En-têtes de sécurité sur toutes les réponses, API comprise (UI-UX
  §6.3) : CSP stricte sans unsafe-inline ni CDN, frame-ancestors 'none',
  X-Frame-Options DENY, nosniff, Referrer-Policy, Cache-Control no-store.
  `http::app` compose l'API, le frontend et ces en-têtes.
- Bannière d'environnement (OPENEIDAS_RA_ENVIRONMENT, « non déclaré » à
  défaut), connexion par nom et clé FIDO2, poste de travail (identité et
  rôle relus sur le serveur, compteurs des files), déconnexion,
  verrouillage après 15 min d'inactivité (avertissement à 14). Aucun
  innerHTML : le contenu de l'API est inséré en texte.
- Tests : tests/web.rs (en-têtes et assets, sans navigateur) ; Playwright
  contre une console réelle (examples/e2e_console.rs, PostgreSQL), clé du
  SoftToken confiée à l'authentificateur WebAuthn virtuel de Chromium.
- CI : job frontend (typage strict, dist/ conforme aux sources, parcours
  de bout en bout). Dépendances npm de développement seulement (esbuild
  MIT, TypeScript et Playwright Apache-2.0), jamais dans l'image.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): file des demandes et modale de signature (étape 6b)
d05e829 
docs/WEBUI.md §15 étape 6, docs/UI-UX.md §3.1, §3.4, §5, §6.1 : les
décisions RA se prennent dans le navigateur, avec la clé FIDO2.

- File des demandes en attente : tableau dense, sélection au clavier
  (j/k, a approuver, r rejeter), inspecteur latéral.
- Justification avant signature, obligatoire pour un rejet (garde
  d'interface : attribut required et contrôle du script).
- Modale de signature (<dialog> natif) : corps figé par ca-server
  affiché tel quel avec son empreinte SHA-256, puis la clé ; erreur sans
  fermeture, challenge redemandé s'il est consommé ou expiré, Échap
  bloqué pendant la cérémonie matérielle.
- Harnais e2e : le vrai service d'actions de ca-server derrière le lien
  mTLS, et huit demandes en attente. Parcours Playwright : approbation
  (corps et empreinte affichés, état APPROVED côté serveur), rejet au
  clavier avec motif obligatoire, renoncement sans effet.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne PhilippeVienne mentioned this pull request Sep 27, 2026
Closed
6 tasks
@PhilippeVienne @claude
feat(ra-console): révocation et salle de quorum dans le navigateur (é…
9e19ad5 
…tape 6c)

docs/WEBUI.md §8, §15 étape 6, docs/UI-UX.md §3.2 : deux opérateurs CA
distincts révoquent un certificat depuis la console.

- `GET /api/v1/certificates?status=issued|revoked` : certificats émis, en
  lecture seule sur la table de ca-server, numéro de série sous la forme
  canonique qu'attend la révocation (test Rust : liste, filtre, passage
  en « revoked » après double signature, refus sans session).
- Navigation entre demandes, certificats et quorum. Écran des
  certificats : motif RFC 5280 parmi ceux qu'admet ca-server,
  justification obligatoire, modale de signature ; la première
  signature part en salle de quorum.
- Salle de quorum : corps figé, empreinte, signataires ; co-signature
  désactivée pour qui a déjà signé (ca-server la refuserait aussi).
- Harnais e2e : trois opérateurs (alice RA, bob et carol CA), une CA
  sur la même base avec son révocateur, deux certificats. Parcours :
  révocation à deux de bout en bout, refus pour un opérateur RA.
  Mutation tuée (co-signature par soi-même non désactivée).

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne
PhilippeVienne force-pushed the feat/ra-console-frontend-revoke branch from 942f85a to 9e19ad5 Compare September 30, 2026 13:09
@PhilippeVienne
PhilippeVienne force-pushed the feat/ra-console-frontend-requests branch from d05e829 to 42716c4 Compare September 30, 2026 17:17
@PhilippeVienne
PhilippeVienne deleted the branch feat/ra-console-frontend-requests September 30, 2026 18:01
@PhilippeVienne

PhilippeVienne commented Sep 30, 2026

Copy link
Copy Markdown
Contributor Author

Remplacée par #90 (base dev) : fermée par GitHub à la suppression de sa branche de base après la fusion de #89.

This was referenced Sep 30, 2026
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@PhilippeVienne