Stand: 2026-03-05

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

Die WvdS-Plattform entstand aus einer Systemlandschaft, in der Authentifizierung und Benutzerverwaltung über mehrere isolierte Systeme verteilt war. AMED verwaltete seine Benutzer in eigenen Tabellen, LD/ENIVERS führte Personen und Rollen in tblPerson und tblRolle — beide Datenbanken, beide ohne Verbindung. Ein Benutzer, der das Unternehmen verließ, musste in mindestens zwei Systemen deaktiviert werden. Das konsequent zu tun war fehleranfällig. Ein neues System hinzuzufügen bedeutete: wieder eine eigene Benutzerverwaltung, wieder ein eigenes Passwort-Schema, wieder ein isolierter Audit-Pfad.

Der externe Zugriff war strukturell nicht vorgesehen. AMED und LD liefen als native Windows-Anwendungen mit impliziter Windows-Authentifizierung — wer keinen Domain-Account hatte, hatte keinen Zugang. Mobile Geräte, BYOD-Szenarien oder VPN-freie Heimarbeit erzeugten deshalb regelmäßig Sonderregelungen, die außerhalb des Systems lebten und nicht nachvollziehbar waren.

Die neue Auth-Architektur ersetzt dieses Flickwerk durch ein einziges zentrales Konzept: ENIVERSSIAM als alleinige Quelle für Identität, Rollen und Berechtigungen. Alle anderen Systeme — ENIVERSCAFM, ENIVERSPIMS, Gateway.Service — konsumieren diese Daten, ohne sie selbst zu verwalten. Ein neuer Benutzer wird einmal angelegt. Ein abgehender Benutzer wird einmal deaktiviert. Ein Audit-Trail existiert für jede Aktion über alle Schichten hinweg.

Gleichzeitig löst die PFX-basierte Schicht ein Problem, das reine Benutzerauthentifizierung nicht lösen kann: Wie weiß das System, dass die Installation selbst legitim ist? Das PFX-Zertifikat trägt Lizenz- und Deployment-Informationen als kryptografisch gesichertes Dokument — ausgestellt von einer internen CA, geprüft lokal, ohne Serververbindung. Erst wenn die Installation als vertrauenswürdig gilt, wird die Benutzerauthentifizierung überhaupt gestartet. Das Ergebnis ist ein zweistufiges Vertrauensmodell, das sowohl Lizenzkonformität als auch Benutzeridentität erzwingt — bevor irgendeine Extension lädt oder ein Business-Datum sichtbar wird.

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.

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

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     │                          │