# Synthetic data All credentials here are **dev-only** synthetic test data — never real personal data, never used outside local development. ## Keycloak realms (S-02) Keycloak runs at (admin console: **admin / admin**). Four realms are imported at boot from `infra/keycloak/realms/`. Each has a public OIDC client **`big-portal`** (standard flow + direct access grants enabled, redirect URIs `*` for dev). All test users share the password **`test123`**. | Realm | Mimics | User | Identifying claim | |---|---|---|---| | `digid` | DigiD (burgers) | `jan-burger` | `bsn` = `123456782` | | `digid` | DigiD (burgers) | `sanne-burger` | `bsn` = `231477813` (S-26 resume e2e — its own user so it can leave an open registration) | | `eherkenning` | eHerkenning (bedrijven) | `acme-ondernemer` | `kvk` = `12345678` | | `eidas` | eIDAS (EU) | `pierre-dupont` | `eidas_id` = `FR/NL/AB-1234-5678` | | `medewerker` | Internal staff | `merel-behandelaar` | role `behandelaar` | | `medewerker` | Internal staff | `tom-teamlead` | roles `behandelaar`, `teamlead` | | `medewerker` | Internal staff | `bram-beheerder` | role `beheerder` | `medewerker` users additionally need a **second factor**: that realm enforces MFA (S-15c, ADR-0031). All three share the fixture TOTP secret `BIGMEDEWERKEROTPSEED`; print a current code with `python3 infra/keycloak/check_realms.py otp`. The identifying claims are injected via OIDC protocol mappers on `big-portal` (user-attribute → token claim); `medewerker` roles appear in `realm_access.roles`. ## Get a token (for testing) ```bash curl -s -X POST \ http://localhost:8180/realms/digid/protocol/openid-connect/token \ -d grant_type=password -d client_id=big-portal \ -d username=jan-burger -d password=test123 -d scope=openid | jq -r .access_token ``` For a `medewerker` user, add `-d totp=$(python3 infra/keycloak/check_realms.py otp)` — without it the grant is refused with `invalid_grant`. Decode the JWT payload to see the `bsn` claim. `make keycloak-smoke` checks every realm automatically.