Use-case-level BDD (Reqnroll) driving the real BFF over HTTP with fake downstreams and locally-minted tokens: a valid DigiD token is accepted and the bsn forwarded to the domain; a tokenless submit is 401; the openbaar register is anonymous and never exposes the bsn (ADR-0010). Real Keycloak validation is the verify-bff check. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
23 lines
1.1 KiB
Gherkin
23 lines
1.1 KiB
Gherkin
# language: en
|
|
# Drives S-07 (#8). The BFF is the portals' only backend (§8.3): it validates Keycloak digid tokens
|
|
# on the self-service submit and serves the openbaar register anonymously with only public-safe
|
|
# fields (ADR-0010). Tokens are minted with a local test key; real Keycloak validation is verify-bff.
|
|
Feature: Toegang via de BFF
|
|
Als portaal wil ik uitsluitend via de BFF met de backend praten
|
|
zodat tokenvalidatie en veilige velden centraal geregeld zijn.
|
|
|
|
Scenario: Indienen met een geldig token wordt doorgezet naar het domein
|
|
Given a zorgprofessional with a valid DigiD token for BSN "123456782"
|
|
When they submit a registration via the BFF
|
|
Then the BFF accepts it and forwards BSN "123456782" to the domain
|
|
|
|
Scenario: Indienen zonder token wordt geweigerd
|
|
Given a caller without a token
|
|
When they submit a registration via the BFF
|
|
Then the BFF rejects it as unauthorized
|
|
|
|
Scenario: Het openbaar register is anoniem en toont geen BSN
|
|
Given the projection contains a zaak "abc-111" for BSN "123456782"
|
|
When the openbaar register is queried anonymously
|
|
Then the response lists "abc-111" without exposing the BSN
|