# WP-57 — Least-privilege client scopes Status: todo Phase: 10 — OpenZaak production hardening ## Why The harness's OpenZaak client is granted `heeft_alle_autorisaties: true` in `setup_configuration/data.yaml` — acceptable for a disposable test rig, wrong for anything closer to production, where the BFF's client should hold only the Autorisaties it actually exercises. ## Read first - `backend/openzaak/setup_configuration/data.yaml` - `backend/src/BigRegister.Api/Zgw/OpenZaakZaakSource.cs` and `OpenZaakDocumentSource.cs` (the actual ZGW endpoints/verbs called) ## Decisions (pre-made, don't relitigate) - Scope precisely to what the BFF calls today: zaken (aanmaken, bijwerken, lezen), statussen (aanmaken), rollen (aanmaken), documenten/zaakinformatieobjecten (aanmaken, lezen) — enumerate exactly at kickoff from the client code, don't guess broader. - No wildcard/all-scope grant in any environment beyond the pre-WP-56 disposable dev rig. ## Files - `backend/openzaak/setup_configuration/data.yaml` (Autorisaties block) - `backend/openzaak/README.md` ## Steps 1. Grep `OpenZaakZaakSource.cs` and `OpenZaakDocumentSource.cs` for every ZGW endpoint/verb called. 2. Replace `heeft_alle_autorisaties: true` with an explicit `autorisaties` list matching exactly that set. 3. Re-run the full integration suite against the narrowed client; add any scope a 403 surfaces. ## Acceptance criteria - [ ] Client config has no wildcard/all-scopes grant. - [ ] `OpenZaakIntegrationTests` (WP-54) pass unchanged against the narrowed client. ## Verification `cd backend && dotnet test --filter Category=Integration` against the harness with the narrowed client. ## Out of scope Rotating/expiring the client credential itself — defer until multi-tenant/production ops actually need it. ## Risks An overlooked scope only surfaces as a runtime 403 against a real instance — mitigated by running the full integration suite, which already exercises every current call path (WP-54). Depends on: WP-56 (provisioning mechanism this scopes down).