eho
321ee50dcb
## What & why Brings the engineer-facing FDS documentation next to the code it describes. Imported from `projects/open-register-fd/` in `Respellion/innovation-lab` and translated to Dutch: **six ADRs**, the ADR index and template, the **L3 component view**, and the **slice-1 proposal**. The architecture blueprint, the FDS gap analysis and the two privacy views stay in the lab repo — the OKRs cite them and they feed tender responses. Each side names the split in a "Wat ligt waar" table, so nothing is documented twice. Closes #159 ### Why `docs/architecture/fds/` and not `docs/architecture/` This repo's own ADR series now runs `adr-0001-loose-coupling` … `adr-0010-bff-oidc`. The imported set is numbered 0001–0006, so a flat import would collide across the whole imported range. The subfolder preserves the imported numbering, and with it roughly thirty `ADR-000N` cross-references inside the imported text that would otherwise all need rewriting. In the MkDocs sidebar the imported six appear as **FDS ADR-000N** so they are not confused with this repo's series. `docs/architecture/fds/README.md` explains the two series. ### Mermaid support was missing `pymdownx.superfences` had no `custom_fences`, so the imported diagrams would have published to Gitea Pages as raw code blocks. This PR adds the mermaid custom fence, the nav group, and one link under *Where to go* in the docs index. ## Definition of Done - [x] Linked Gitea issue (above). - [ ] Failing test committed before the implementation. — n/a, documentation only. - [ ] Implementation makes the test pass. — n/a, documentation only. - [x] Conventional Commits referencing the issue (`refs #159`). - [x] Rebased on current `main`; no conflicts. - [ ] CI green — n/a for content; the docs verification is below. - [ ] `docker compose up` reaches green health checks. — n/a, no runtime change. - [x] Docs updated if behaviour, contracts, or operations changed. - [x] ADR added in `docs/architecture/` if a non-obvious decision was made. — six imported, plus the numbering decision recorded in the folder README. - [ ] Demo note in `docs/demo-script.md`. — n/a, nothing user-visible. ## Verification run - `mkdocs build` — clean. No missing-nav warning for any `architecture/fds/` entry. The two remaining warnings are pre-existing on `main` and untouched here: the set of pages absent from `nav`, and a broken link in `runbooks/ci.md` to `services/acl/stryker-config.json`. - Mermaid renders as a diagram, not a code block: `site/architecture/fds/c4-component-view/index.html` contains `class="mermaid"`. - All relative markdown links in the repo resolve. ## Notes for reviewers - **Language.** The imported documents are Dutch; this repo's own documents remain English. Deliberate, not an oversight — the lab repo standardised on Dutch and these pages moved with it. Translating the rest is a separate decision. - **Ownership.** This repo sits in the `eho/` namespace while it now holds the canonical FDS architecture decisions that tender answers point at. Worth deciding whether it should move to `Respellion/`. - **Scope drift, not fixed here.** The imported text is faithful to its source, so the slice-1 proposal and the ADRs assume NHR/KVK for slice 1, while the lab-side blueprint still uses BAG as its example register. The lab-side documents carry a banner about this; Blueprint v2 (slice 5) is where the diagrams get corrected. - **Companion PR:** `Respellion/innovation-lab` #34 holds the lab-side half of this split.Reviewed-on: #160
2.0 KiB
ADR-0003: Policy-based access control via OPA, FTV-klaar
- Status: accepted
- Datum: 2026-06-13
- Deciders: Lab Circle, FG (geconsulteerd)
- Vervangt / vervangen door: —
Context
Elke bevraging van persoonsgegevens uit BRP of NHR is een verwerking die een grondslag en een begrensde doelbinding nodig heeft. Toegangsregels moeten handhaafbaar en auditeerbaar zijn, en wijzigbaar zonder de bedrijfscode opnieuw uit te rollen.
De Federatieve Toegangsverlening (FTV) van het FDS beweegt naar policy-based access control, maar is nog geen afgeronde standaard.
Besluit
Introduceer een Policy Decision Point met Open Policy Agent (OPA). De applicatieservices roepen de PDP aan — via een Authorisation Port en een PDP Client — vóór elke registerbevraging, en geven rol, doel en grondslag mee.
Policies schrijven wij als code, geversioneerd in Gitea, en zij gaan via review naar productie. De PDP staat zo gepositioneerd dat wij bij de komst van FTV alleen het policy-dialect opnieuw uitdrukken, zonder de architectuurgrens te verplaatsen.
Gevolgen
Positief: doelbinding en grondslag worden gehandhaafd, en niet alleen gedocumenteerd. De FG kan de werkelijke regels in versiebeheer lezen, waardoor het verwerkingenregister en de gehandhaafde policy naar elkaar toe groeien. Toegangswijzigingen zijn reviewbaar en gedateerd.
Negatief en kosten: BRP-autorisatiebesluiten correct modelleren is juridisch werk, geen engineering. De PDP maakt de handhaving betrouwbaar, niet de policy juist. Daarnaast komt er een component bij om te exploiteren.
Vervolgwerk: een promotiepijplijn voor policies in Gitea Actions. Policies opnieuw uitdrukken zodra FTV stabiliseert. Een FG-review van de policy-set vóórdat er echte persoonsgegevens in komen.
Overwogen alternatieven
- Rolcontroles in de applicatiecode — afgewezen: niet auditeerbaar, niet wijzigbaar zonder deploy, en het verspreidt toegangslogica over de codebase.
- Wachten op FTV — afgewezen: de PBAC-vorm is al duidelijk. Nu OPA, later het FTV-dialect.