Initial commit with inital CMS

2026-06-15 17:00:16 +02:00
commit 95d986790e
132 changed files with 7624 additions and 0 deletions
@@ -0,0 +1,38 @@
+# Business Rules — Unit 02: Identity & RBAC
+
+Dit document beschrijft de validatieregels en logica voor identiteitsbeheer en autorisatie.
+
+## 1. Hiërarchische Rollen (BR-ID-01)
+
+- **Hiërarchie**: Owner (100) > Administrator (50) > User (10).
+- **Beperking**: Een gebruiker kan alleen acties uitvoeren op gebruikers met een **lagere** rol in de hiërarchie.
+    - Uitzondering: Een Owner kan acties uitvoeren op andere Owners (bijv. de-activeren, mits niet de laatste Owner).
+    - Een Administrator kan een User beheren, maar geen andere Administrator of Owner.
+- **Rolverandering**: Een gebruiker kan een andere gebruiker nooit een rol toekennen die hoger is dan zijn eigen rol.
+
+## 2. Gebruikerscreatie & Uitnodiging (BR-ID-02)
+
+- **Geen Zelfregistratie**: Het systeem staat geen publieke registratie toe.
+- **Uitnodigingsflow**: 
+    1. Administrator/Owner maakt een uitnodiging aan (e-mail + rol).
+    2. Systeem genereert een `InvitationToken` met een beperkte geldigheidsduur (bijv. 24 uur).
+    3. Gebruiker moet via een specifiek endpoint (`POST /api/setup/complete-invitation`) zijn wachtwoord instellen met dit token.
+    4. Na succesvolle instelling wordt het token ongeldig en het account geactiveerd.
+
+## 3. Bootstrapping (BR-ID-03)
+
+- **Setup Endpoint**: Bij een lege database is een eenmalig endpoint `POST /api/setup/init` beschikbaar.
+- **Eerste Owner**: Dit endpoint accepteert de gegevens voor de eerste Owner. Na succesvolle aanmaak wordt dit endpoint permanent geblokkeerd of verwijderd uit de routing.
+
+## 4. Authenticatie & Sessies (BR-ID-04)
+
+- **Wachtwoord Hashen**: Wachtwoorden moeten gehasht worden volgens de ASP.NET Core Identity standaard (PBKDF2 met HMAC-SHA256).
+- **Refresh Tokens**: 
+    - Refresh tokens zijn gekoppeld aan een specifieke gebruiker en client/apparaat.
+    - Refresh tokens kunnen maar één keer worden gebruikt (Rotation-principe).
+    - Bij gebruik van een oud refresh token worden alle actieve sessies van die gebruiker ongeldig gemaakt (beveiligingsmaatregel tegen token diefstal).
+
+## 5. Module-specifieke Rechten (BR-ID-05)
+
+- **Fine-grained Access**: Naast de globale rollen kunnen Beheerders specifieke rechten per module toekennen aan Users.
+- **Default**: Zonder expliciete module-rechten heeft een User alleen leesrechten of basisrechten binnen een module (afhankelijk van de module-implementatie).
@@ -0,0 +1,37 @@
+# Domain Entities — Unit 02: Identity & RBAC
+
+Dit document beschrijft de data-entiteiten die nodig zijn voor identiteitsbeheer.
+
+## 1. ApplicationUser
+
+Breidt de standaard `IdentityUser` uit.
+
+- **Email**: Unieke identifier.
+- **Role**: De primaire hiërarchische rol (`Owner`, `Administrator`, `User`).
+- **IsActive**: Boolean status.
+- **CreatedAt**: Tijdstip van aanmaak.
+- **ModulePermissions**: Navigatie-eigenschap naar module-specifieke rechten.
+
+## 2. RefreshToken
+
+- **Id**: Guid.
+- **Token**: De gehashte token string.
+- **UserId**: Link naar de `ApplicationUser`.
+- **ExpiryDate**: Wanneer het token verloopt.
+- **IsUsed**: Boolean (voor re-use detection).
+- **IsRevoked**: Boolean (handmatige intrekking).
+- **CreatedByIp**: IP adres voor audit trail.
+
+## 3. Invitation
+
+- **Email**: Adres waar de uitnodiging naar verzonden is.
+- **Role**: De toegekende rol na acceptatie.
+- **Token**: Unieke GUID/String.
+- **ExpiryDate**: Geldigheidsduur van de uitnodiging.
+- **IsAccepted**: Boolean.
+
+## 4. ModulePermission
+
+- **UserId**: Link naar `ApplicationUser`.
+- **ModuleName**: Naam van de module.
+- **Permission**: De specifieke string-gebaseerde permissie (bijv. "Write", "Admin").
@@ -0,0 +1,62 @@
+# Business Logic Model — Unit 02: Identity & RBAC
+
+Dit document beschrijft de processen en datastromen voor authenticatie en autorisatie.
+
+## 1. Authenticatie Flow (JWT)
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant AuthController
+    participant AuthService
+    participant UserManager
+    participant Database
+
+    Client->>AuthController: Login(Email, Password)
+    AuthController->>AuthService: AuthenticateAsync(Email, Password)
+    AuthService->>UserManager: FindByEmailAsync(Email)
+    UserManager->>Database: Get User
+    Database-->>UserManager: User Data
+    UserManager->>UserManager: CheckPasswordAsync(User, Password)
+    AuthService->>AuthService: GenerateTokens(User)
+    AuthService->>Database: Save RefreshToken
+    AuthService-->>AuthController: AccessToken, RefreshToken
+    AuthController-->>Client: 200 OK (Tokens)
+```
+
+## 2. Uitnodigingsproces
+
+```mermaid
+graph TD
+    A[Admin/Owner] -->|Create Invitation| B(InvitationService)
+    B -->|Generate Token| C(InvitationToken)
+    C -->|Save to DB| D[(Database)]
+    B -->|Send Email| E[User]
+    E -->|Click Link| F[Setup Page]
+    F -->|Submit Password + Token| G(SetupController)
+    G -->|Validate Token| B
+    B -->|Create Account| H(UserManager)
+    H -->|Activate User| D
+```
+
+## 3. Hiërarchische Autorisatie Logic
+
+De autorisatie wordt afgehandeld via ASP.NET Core `AuthorizationPolicies`.
+
+- **Policy: `RequireLowerRole`**:
+    - Haalt de rol van de huidige gebruiker (X) en de doelgebruiker (Y) op.
+    - Vergelijkt de numerieke waarden van de rollen.
+    - Slaagt alleen als `RoleValue(X) > RoleValue(Y)` (of `X == Y` en `X == Owner`).
+
+## 4. Token Refresh Logic
+
+1. Client stuurt `Expired Access Token` + `Refresh Token`.
+2. Systeem controleert of `Refresh Token` bestaat in de database en niet verlopen is.
+3. Systeem controleert of `Refresh Token` al eerder is gebruikt (Re-use detection).
+4. Indien geldig:
+    - Genereer nieuw `Access Token`.
+    - Genereer nieuw `Refresh Token` (Rotation).
+    - Verwijder/Invalideer het oude `Refresh Token`.
+5. Indien ongeldig of re-use:
+    - Trek alle tokens van de gebruiker in.
+    - Retourneer `401 Unauthorized`.