docs(backlog): add phase 10 (OpenZaak hardening) and phase 11 (behandelportal)

WP-55..60 harden the OpenZaak integration for production (secrets/TLS, idempotent provisioning, least-privilege scopes, real notifications, confidentialiteit config, write-divergence resilience). WP-61..66 stand up a staff-facing behandelportal per ADR-0002, wired to the same backend via BFF-lite decision DTOs. Both phases are independent tracks; WP-60's Decisions block is deliberately left open for a planner-agent kickoff. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 11:59:11 +02:00
parent 66f8125ccd
commit f21c3c7ca2
13 changed files with 840 additions and 0 deletions
@@ -0,0 +1,66 @@
+# WP-55 — Real secrets + TLS for the OpenZaak harness
+
+Status: todo
+Phase: 10 — OpenZaak production hardening
+
+## Why
+
+`backend/openzaak/docker-compose.openzaak.yml` is explicitly a throwaway dev/test harness:
+`SECRET_KEY: wp-54-local-harness-not-for-prod`, `POSTGRES_HOST_AUTH_METHOD=trust` (no DB
+password), `IS_HTTPS: 'no'`, `DISABLE_2FA: 'true'`. Before anything else in this phase can
+be called "production," the instance needs real secrets, real DB auth, and TLS. The BFF
+side is already fine — `ZgwOptions.cs` binds from `IConfiguration`, so this is a deploy-config
+change, not application code.
+
+## Read first
+
+- [openzaak-integration.md](../reference/openzaak-integration.md)
+- `backend/openzaak/README.md`
+- [ADR-0005 — OpenZaak behind the BFF](../reference/architecture/0005-openzaak-behind-bff.md)
+
+## Decisions (pre-made, don't relitigate)
+
+- Secrets come from the deployment environment (env vars / secrets manager), never
+  checked into compose or appsettings.
+- TLS termination happens at a reverse proxy/ingress in front of OpenZaak — OpenZaak
+  itself doesn't need built-in cert handling.
+- The existing dev harness stays as-is for local iteration (WP-54's trimmed rig is
+  intentional and still valuable); this WP adds a production compose/override or an
+  env-driven parameterization of the same file, not a replacement of the dev rig.
+
+## Files
+
+- `backend/openzaak/docker-compose.openzaak.yml` (or a new `docker-compose.openzaak.prod.yml` override)
+- `backend/openzaak/README.md`
+- `backend/src/BigRegister.Api/appsettings*.json` / `Zgw/ZgwOptions.cs` (confirm only, likely no change)
+
+## Steps
+
+1. Parameterize `SECRET_KEY`, DB user/password, and the ZGW JWT secret via env vars;
+   remove hardcoded values from the committed file.
+2. Switch `POSTGRES_HOST_AUTH_METHOD` from `trust` to password auth, password from env.
+3. Set `IS_HTTPS: 'yes'`; document the required reverse-proxy/ingress TLS termination.
+4. Update `backend/openzaak/README.md` with the required env vars and the TLS note.
+5. Confirm the BFF's JWT secret already comes from config — no code change expected.
+
+## Acceptance criteria
+
+- [ ] No secret value is hardcoded in any committed compose/config file.
+- [ ] The production compose fails fast (or docs state clearly) when secrets aren't
+      supplied — no silent fallback to a real-looking default.
+- [ ] README documents exactly which env vars must be set and how TLS is terminated.
+
+## Verification
+
+`docker compose -f backend/openzaak/docker-compose.openzaak.yml config` with required env
+vars set; `cd backend && dotnet test` (WP-54 harness tests unaffected); manual: the local
+dev harness still works with its dev-only values documented as dev-only.
+
+## Out of scope
+
+Catalogus provisioning (WP-56), client scope narrowing (WP-57), notifications (WP-58).
+
+## Risks
+
+If TLS/secrets docs lag an actual deploy, someone could ship with dev defaults — mitigate
+by making the prod compose fail without required env vars rather than silently defaulting.