## What & why S-15a, the first of the S-15 (#16) split. A new **beheer** portal (medewerker realm, like behandel) shows the ZTC catalogus — the published zaaktypen — **read-only**. A beheerder logs in and sees the seeded BIG-REGISTRATIE zaaktype. Closes #130 ### The vertical portal → BFF `GET /beheer/catalogi/zaaktypen` (medewerker realm + `beheerder` role) → ACL `GET /catalogi/zaaktypen` → ZGW Catalogi API. - **ACL**: new read-only `GET /catalogi/zaaktypen` listing published zaaktypen (reuses the ADR-0021 Catalogi client; public-safe `identificatie`/`omschrijving`). - **BFF**: new typed `IAclClient` + `Downstream:Acl:BaseUrl`, and `GET /beheer/catalogi/zaaktypen` behind a new `beheerder` policy (reuses the medewerker bearer scheme + realm-role lifting). OpenAPI spec + generated Angular client regenerated. - **Keycloak**: `beheerder` realm role + `bram-beheerder` test user in the medewerker realm. - **Frontend**: new `apps/beheer` Angular app (copied from behandel) with a read-only catalogus page; `SECURE_API_ROUTES=['/beheer/']`. - **Infra**: `beheer` compose service (port 8143), added to `WAIT_SVCS` + CI log-dump; a Playwright e2e (beheerder login → catalogus shows BIG-REGISTRATIE). ### New boundary → ADR-0025 The BFF now reaches the **ACL directly** for the catalogus read — a new service-to-service edge (§14). The catalogus is neither a domain nor a projection concern, and §8.1 means only the ACL may read ZGW; routing through the domain would pollute it with a non-domain passthrough. §8.1/§8.3 stay intact. Recorded in **ADR-0025**. ## Definition of Done - [x] Failing test committed before each implementation (red→green per layer: ACL, BFF, frontend). - [x] Conventional Commits referencing #130. - [ ] CI green — pending Gitea Actions run. - [x] `docker compose up` brings up `beheer` (health-gated in `WAIT_SVCS`). - [x] Docs — ADR-0025 + demo-script S-15a note. - [x] Demo note in `docs/demo-script.md`. ## Verified locally lint (`dotnet format`) ✓ · .NET unit (Acl 57 / Big 152 / EventSubscriber 19 / Bff 40) ✓ · frontend lint+test (8 projects) ✓ · frontend build (4 apps) ✓. Mutation ratchet: added a gateway unit test for the new `ListZaaktypenAsync` mapping so the ACL score holds. verify-stack (compose smoke + e2e) runs in CI. ## Notes for reviewers - The BFF drops the ZGW URL from `BeheerZaaktype` (public-safe: identificatie + omschrijving only). - The catalogus e2e asserts on the stable seeded `BIG-REGISTRATIE` (not a per-test reference), safe on the shared verify stack. - Follow-ups: **S-15b** (#131) default-fill CRUD, **S-15c** (#132) medewerker-realm MFA. 🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #133
This commit was merged in pull request #133.
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
# ADR-0025: The BFF reads the catalogus directly from the ACL
|
||||
|
||||
- **Status:** Accepted
|
||||
- **Date:** 2026-07-24
|
||||
- **Deciders:** Respellion engineering
|
||||
- **Slice:** S-15a (#130), first of the S-15 (#16) split
|
||||
|
||||
## Context
|
||||
|
||||
The beheer portal shows a read-only view of the ZTC catalogus (the published
|
||||
zaaktypen). Two coupling rules constrain where that data can come from:
|
||||
|
||||
- **§8.1** — only the ACL may talk to the ZGW APIs (Catalogi included). So the
|
||||
catalogus read *must* originate in the ACL.
|
||||
- **§8.3** — portals talk only to the BFF. So the portal reaches the ACL only
|
||||
through the BFF.
|
||||
|
||||
That leaves the question of *how the BFF gets the data*. Until now the BFF fanned
|
||||
out to exactly two backends — the Domain Service and the read projection. The
|
||||
catalogus is neither: it is not a registration (domain) nor a projected read model.
|
||||
|
||||
## Decision
|
||||
|
||||
**The BFF calls the ACL directly for the beheer catalogus read** — a new typed
|
||||
`IAclClient` (`GET /catalogi/zaaktypen`), configured by `Downstream:Acl:BaseUrl`,
|
||||
mirroring the existing `IDomainClient` / `IProjectionClient` pattern.
|
||||
|
||||
Rejected alternative — **route it through the Domain Service** (BFF → domain →
|
||||
ACL): the catalogus is not a domain concern, so the domain would gain a
|
||||
pass-through endpoint that owns no aggregate and no invariant, blurring the
|
||||
domain's responsibility purely to avoid a new edge. That is worse coupling, not
|
||||
better.
|
||||
|
||||
This adds one service-to-service edge (BFF → ACL) — an architecturally
|
||||
significant boundary change (§14), hence this ADR. It does **not** bend §8: the
|
||||
ACL stays the only code that reads ZGW, and the portal still talks only to the
|
||||
BFF. The ACL endpoint is a plain read that trusts its callers (§8.3); the
|
||||
beheerder authorization lives at the BFF (medewerker realm + `beheerder` role).
|
||||
|
||||
## Consequences
|
||||
|
||||
**Positive**
|
||||
|
||||
- The catalogus read follows the shortest honest path; the domain stays about
|
||||
registrations.
|
||||
- Symmetric with the other downstream clients — nothing new to learn.
|
||||
|
||||
**Negative / costs**
|
||||
|
||||
- The BFF now depends on three backends instead of two. The ACL must be reachable
|
||||
for the beheer portal to load (it already is — the BFF is on the same network).
|
||||
- A second consumer of the ACL (alongside the domain and event-subscriber), so
|
||||
ACL read endpoints are now part of more than one caller's contract.
|
||||
|
||||
## Coupling rules touched (CLAUDE.md §8)
|
||||
|
||||
A new BFF → ACL edge. §8.1 and §8.3 remain intact; §14 (boundary change) is the
|
||||
reason this ADR exists.
|
||||
@@ -5,6 +5,32 @@ copy-pasteable walkthrough against a local `make up` stack.
|
||||
|
||||
---
|
||||
|
||||
## S-15a — Beheer-portal: read-only catalogus viewer (#130, ADR-0025)
|
||||
|
||||
**Outcome:** a new **beheer** portal (medewerker realm, like behandel) shows the ZTC catalogus —
|
||||
the published zaaktypen — **read-only**. A beheerder logs in and sees the seeded BIG-REGISTRATIE
|
||||
zaaktype. The read path is portal → BFF `GET /beheer/catalogi/zaaktypen` (medewerker realm +
|
||||
`beheerder` role) → ACL `GET /catalogi/zaaktypen` → ZGW Catalogi API. The BFF reaches the ACL
|
||||
directly (ADR-0025); managing the default-fill config (S-15b) and MFA (S-15c) come next.
|
||||
|
||||
```bash
|
||||
make up
|
||||
# 1. Log in as bram-beheerder / test123 → the catalogus lists the published zaaktypen.
|
||||
open http://localhost:8143
|
||||
#
|
||||
# 2. Automated (a CI verify-stack e2e): a beheerder logs in and sees BIG-REGISTRATIE.
|
||||
make verify-e2e # → catalogus.spec: "a beheerder sees the published zaaktypen in the catalogus"
|
||||
#
|
||||
# 3. The BFF endpoint is behind the beheerder role — a plain behandelaar gets 403 (BFF unit tests):
|
||||
# Bff.Tests → BeheerEndpointTests.
|
||||
```
|
||||
|
||||
**Auth:** the `beheerder` realm role + `bram-beheerder` user live in the medewerker realm
|
||||
(`infra/keycloak/realms/medewerker-realm.json`); the BFF reuses the medewerker bearer scheme and its
|
||||
realm-role lifting, requiring `beheerder` rather than `behandelaar`.
|
||||
|
||||
---
|
||||
|
||||
## S-16c — Prometheus metrics + golden-signal Grafana dashboard (#124, ADR-0023)
|
||||
|
||||
**Outcome:** the five .NET services now expose OpenTelemetry metrics in Prometheus format at `/metrics`
|
||||
|
||||
Reference in New Issue
Block a user