34 lines
1.8 KiB
Markdown
34 lines
1.8 KiB
Markdown
# NFR Design Plan — Unit 02: Identity & RBAC
|
|
|
|
Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor Unit 02.
|
|
|
|
## NFR Design Stappen
|
|
- [x] Uitwerken van de `ApplicationDbContext` configuratie voor schone tabelnamen.
|
|
- [x] Ontwerpen van de `HierarchicalRoleRequirement` en bijbehorende `Handler`.
|
|
- [x] Definiëren van de `IAuthService` contracten voor JWT en Refresh Token management.
|
|
- [x] Uitwerken van het beveiligingsmechanisme voor het eenmalige Setup endpoint.
|
|
- [x] Vastleggen van de database schema voor de `RefreshToken` en `Invitation` entiteiten.
|
|
|
|
## Vragen voor NFR Design (Unit 02)
|
|
|
|
### 1. Setup Endpoint Beveiliging
|
|
**Vraag 1.1**: Hoe moeten we garanderen dat het `POST /api/setup/init` endpoint echt maar één keer bruikbaar is?
|
|
- A) **Database Check**: Controleer of er al een gebruiker met de rol `Owner` bestaat. Zo ja, retourneer 403 Forbidden.
|
|
- B) **Feature Flag/Config**: Gebruik een vlag in de database `IsSystemInitialized`.
|
|
- C) **File System**: Controleer op de aanwezigheid van een lock-file (minder geschikt voor cloud/docker).
|
|
|
|
### 2. JWT Signing
|
|
**Vraag 2.1**: Waar moeten de JWT signing keys worden opgeslagen voor de MVP?
|
|
- A) In `appsettings.json` (niet aanbevolen voor productie, maar eenvoudig voor dev).
|
|
- B) In Environment Variables.
|
|
- C) Gebruik van een lokaal gegenereerd certificaat/key file (voorbereiding op KeyVault).
|
|
|
|
### 3. Invitation Token
|
|
**Vraag 3.1**: Wat voor soort token moeten we gebruiken voor de uitnodigingen?
|
|
- A) Een cryptografisch veilige random string (bijv. 32 bytes Base64).
|
|
- B) Een GUID.
|
|
- C) Een kort JWT token (self-contained, maar vereist key management).
|
|
|
|
## Volgende Stappen
|
|
Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/identity-rbac/nfr-design/`.
|