1. Auth-Architektur — Gesamtübersicht

Stand: 2026-03-05

Übergeordnet: WvdS-Plattform — Gesamtübersicht Verwandt: 2. WvdS.Shell | 3. Gateway.Service | 4. Datenschicht | 5. Migration

Konzept

Die Auth-Architektur der WvdS-Plattform ist in drei Schichten aufgeteilt — GUI-Schicht (WvdS.Shell), Service-Schicht (Gateway.Service) und Datenschicht (ENIVERSSIAM) — sowie einem separaten Migrations-Track für Legacy-Systeme.

Zweischichtiges Auth-Modell

Schicht	Träger	Zweck
1. PFX-Zertifikat	WvdS.Shell (lokal)	Installations- und Lizenznachweis, offline-fähig
2. Identity Provider	Gateway.Service	Benutzer-Authentifizierung: Kerberos (SSO) oder MFA-Flow (extern)

Beide Schichten müssen erfolgreich abgeschlossen sein, bevor Extensions laden oder Business-Daten sichtbar sind.

Details zur Shell-seitigen Umsetzung: 2. WvdS.Shell Auth-Architektur

Auth-Modi

Kontext	Verfahren	Bedingung
Corpnet / VPN	Kerberos (SSPI Negotiate)	Domain-joined, DC erreichbar
Extern / BYOD	Username + Passwort + TOTP	DC nicht erreichbar, Gateway erreichbar
Offline	PFX als Credential	Gateway nicht erreichbar

Auth-Flow (Detail)

WvdS.Shell                 Gateway.Service            DC / ENIVERSSIAM
     │                            │                          │
     │  1. PFX prüfen (lokal)     │                          │
     │     ↓ Schicht 1 OK         │                          │
     │                            │                          │
     │  2a. SSPI Negotiate ──────►│── Kerberos-Ticket ──────►│
     │      (Corpnet / VPN)       │◄─ Identität bestätigt ───│
     │◄─── JWT (access+refresh) ──│                          │
     │                            │                          │
     │  2b. username+pw ─────────►│── LDAP/DB-Check ────────►│
     │      (Extern / BYOD)       │◄─ OK ────────────────────│
     │◄─── TOTP-Challenge ────────│                          │
     │──── TOTP-Code ────────────►│── HMAC-SHA1 intern       │
     │◄─── JWT (access+refresh) ──│                          │
     │                            │                          │
     │  3. GET /api/v1/features ─►│── ENIVERSASYS-DB         │
     │◄─── Feature-Flags JSON ────│                          │
     │                            │                          │
     │  4. Extension-Scan, UI     │                          │

Token-Lebensdauer

Token	Lebensdauer	Speicherort (Client)
Access Token	15 Minuten	RAM (Shell SessionManager)
Refresh Token	30 Tage	DPAPI SecretStorage
TOTP Challenge	5 Minuten	Gateway-RAM (nach Ablauf gelöscht)

CWE-Referenzen (Auth-spezifisch)

CWE	Beschreibung	Umsetzung
CWE-208	Timing Side-Channel	ConstantTimeEqual für Basic/ApiKey-Auth
CWE-256	Plaintext-Passwort	Legacy-Passwörter nicht migriert; FillChar nach Validierung
CWE-287	Improper Authentication	Kerberos-Ticket vollständig validiert (kein Presence-Check)
CWE-290	Token Spoofing	JWT-Signatur (ML-DSA-65) bei jedem Request geprüft
CWE-316	Heap Inspection	SecureZeroString / FillChar für Credentials im RAM
CWE-384	Session Fixation	`jti` (JWT ID) einmalig; Replay via jti-Blacklist
CWE-532	Log Information Exposure	Credentials und Tokens werden nie geloggt
CWE-613	Insufficient Session Expiration	Refresh Token: 30 Tage, serverseitig revokierbar
CWE-620	Unverified Password Change	TOTP-Enrollment erfordert bestätigten ersten Code

Dokumente dieser Sektion

Nr	Dokument	Inhalt
1	Auth-Architektur — Gesamtübersicht	Diese Seite
2	WvdS.Shell — GUI-Schicht	PFX-Validator, Context-Detector, JWT-Manager, TOTP-Dialog
3	Gateway.Service — Service-Schicht	Auth-Endpoints, JWT (ML-DSA-65), TOTP-Service, Kerberos/SSPI
4	Datenschicht — DB-Schemas	ENIVERSSIAM Schema (auth.* + core.person), ENIVERSCAFM, PIMS
4.1	DB-Funktionen — Auth Controller	Stored Procedures, Functions, Views für Controller.Auth
5	Auth-Migration — Legacy-Systeme	Phasen 1–5, Mapping-Tabellen, SQL-Skripte

Inhaltsverzeichnis