⬡ Webtest – Übersicht

Webtest ist eine Webanwendung zum Testen von Proxy- und Authentifizierungsinfrastruktur in Unternehmensumgebungen. Sie ermöglicht die Analyse von HTTP-Proxy-Verhalten, TLS-Konfigurationen, WebSocket-Durchgängigkeit und Content-Filterung sowie die Integration von Identity Providern via OIDC und SAML 2.0.

Funktionsübersicht

Architektur

Webtest besteht aus einer Node.js-Anwendung hinter einem nginx-Reverse-Proxy:

Technologie-Stack

Verzeichnisstruktur

/opt/webtest/
├── src/
│   ├── server.js           # Express-Einstiegspunkt
│   ├── db.js               # Datenbank-Init & Seeding
│   ├── auth/
│   │   ├── oidc.js         # Dynamischer OIDC-Client-Manager
│   │   ├── saml.js         # Dynamischer SAML-Strategie-Manager
│   │   └── graph.js        # Microsoft Graph API (Gruppenauflösung)
│   ├── middleware/
│   │   └── requireAuth.js  # Auth-Guards
│   ├── routes/
│   │   ├── auth.js         # Login/Callback-Routen
│   │   ├── config.js       # Provider-Verwaltung (Admin)
│   │   ├── index.js        # Dashboard & Startseite
│   │   ├── probe.js        # Test-Funktionen
│   │   └── profile.js      # Profil & Claims
│   └── views/
│       └── layout.js       # HTML-Layout-Hilfsfunktionen
├── static/                 # Statische Dateien (CSS, Docs)
├── downloads/              # Test-Downloads (via nginx)
├── data/                   # SQLite-Datenbank
├── .env                    # Konfiguration (nicht im Repo)
└── package.json

Erste Schritte

Nach der Installation ist die Anwendung unter https://dev1.boesls.de erreichbar.

Lokale Benutzer

Das Passwort für testuser ist in INITIAL_TEST_PASSWORD in der .env-Datei konfiguriert.

Authentifizierung

Webtest unterstützt drei Authentifizierungsmethoden:

Lokaler Login

Der lokale Login verwendet Benutzername und Passwort. Passwörter werden mit bcrypt (Cost 12) gehasht in SQLite gespeichert. Das Login-Formular ist gegen CSRF-Angriffe gesichert (zufälliges Token pro Session, im Hidden-Field).

OpenID Connect (OIDC)

Der OIDC-Flow verwendet Authorization Code Flow mit PKCE (Proof Key for Code Exchange). Es wird keine Implicit Flow oder Hybrid Flow verwendet.

Nach erfolgreichem Login werden alle Token-Claims, Gruppen und OIDC-Endpunkt-URLs in der Session gespeichert und unter /profile angezeigt.

Bei Microsoft Entra ID: Gruppen werden zusätzlich über die Microsoft Graph API (/me/memberOf) aufgelöst, um Anzeigenamen zu erhalten. Bei mehr als 200 Gruppen wird automatisch der Overage-Claim behandelt.

SAML 2.0

Der SAML-Flow ist SP-initiiert (Service Provider initiates). Der SP schickt eine AuthnRequest an den IdP, der Benutzer authentifiziert sich, und der IdP postet die SAML-Assertion an den Assertion Consumer Service (ACS) des SP.

Attribut-Normalisierung: Die Anwendung erkennt automatisch verschiedene Namensformate (Microsoft-Schema-URIs, Keycloak-Kurzformen, Standard-Attribute).

Konto wechseln

Viele Browser und Identity Provider speichern die zuletzt verwendete Identität. Webtest bietet an zwei Stellen die Möglichkeit, einen anderen Account zu verwenden, ohne den Browser-Cache zu leeren:

Login-Seite

Jede Provider-Karte zeigt zwei Optionen: Anmelden (nutzt die bestehende IdP-Session) und Anderen Account verwenden → (erzwingt die Kontoauswahl beim IdP).

Profil-Seite (bereits angemeldet)

Direkt unter dem angemeldeten Benutzer erscheinen zwei Schaltflächen: ⇄ Anderen Account verwenden startet einen neuen Auth-Flow ohne vorherigen Logout — die Session wird nach erfolgreicher Re-Authentifizierung automatisch überschrieben. Abmelden zerstört die aktuelle Session.

Provider konfigurieren

Provider werden über /config verwaltet (nur für den Admin-User zugänglich). Jeder Provider hat einen eindeutigen internen Namen (URL-sicherer Slug), der in den Login-URLs verwendet wird:

• OIDC: https://dev1.boesls.de/auth/oidc/{name}
• SAML: https://dev1.boesls.de/auth/saml/{name}

Mehrere Provider desselben Typs sind möglich, z.B. zwei Entra-ID-Tenants (contoso, fabrikam) und eine Keycloak-Instanz (keycloak-prod).

Provider-Typen

Microsoft Entra ID (OIDC)

Für die OIDC-Integration mit Entra ID wird eine App Registration im Azure Portal benötigt.

Mehrere Entra-ID-Tenants

Für jeden Tenant eine eigene App Registration erstellen und in Webtest als separater Provider mit eindeutigem Namen anlegen (z.B. contoso, fabrikam). Jeder Provider hat seine eigene Client ID, Client Secret und Tenant ID.

Keycloak (OIDC)

Keycloak und andere OIDC-konforme IdPs (Okta, Auth0, …) werden über den Typ Keycloak eingebunden. Anstelle der Tenant ID wird die Issuer URL angegeben.

SAML 2.0

Die SAML-Integration unterstützt jeden SAML 2.0-konformen Identity Provider (Entra ID SAML, ADFS, Keycloak SAML, Shibboleth, PingFederate, etc.).

SP-Informationen für den IdP

Beim Anlegen eines SAML-Providers werden folgende SP-Werte konfiguriert:

Attribut-Normalisierung

Webtest erkennt automatisch verschiedene SAML-Attributformate und normalisiert sie:

Gruppen-Einschränkung

Jeder Provider kann optional auf bestimmte Gruppen eingeschränkt werden. Die Konfiguration erfolgt im Provider-Bearbeitungsformular unter /config → Provider → Bearbeiten, ganz unten im Abschnitt Erlaubte Gruppen.

Verhalten

Format der Gruppen-IDs

Pro Zeile eine Gruppe. Groß-/Kleinschreibung wird ignoriert.

Ablauf bei verweigerten Zugriff

HTTP-Header-Analyse

Unter /probe/headers werden alle HTTP-Request-Header angezeigt, die der Server empfängt. Dies ermöglicht die Analyse des Verhaltens von HTTP-Proxies in Unternehmensumgebungen.

Was wird angezeigt?

• Alle Request-Header in einer Tabelle (Name + Wert)
• Proxy-Indikatoren werden farblich hervorgehoben (orange):
  via, x-forwarded-for, x-forwarded-proto, x-forwarded-host, x-real-ip, forwarded, x-request-id, x-correlation-id

Typische Erkenntnisse

• Via: Welche Proxies wurden durchlaufen?
• X-Forwarded-For: Originale Client-IP (ggf. Proxy-Kette)
• User-Agent: Wurde der Browser-User-Agent durch den Proxy verändert?
• Fehlende Header: Hat der Proxy bestimmte Header entfernt?
• Zusätzliche Header: Fügt der Proxy eigene Header hinzu?

TLS-Informationen

Unter /probe/tls werden TLS- und Verbindungsinformationen angezeigt.

Server-seitig (via nginx-Headern)

• TLS-Protokollversion (X-SSL-Protocol)
• Verwendete Cipher Suite (X-SSL-Cipher)
• Forwarded-Proto Header (Bestätigung HTTPS-Terminierung)

Client-seitig (via JavaScript)

• Detektiertes Protokoll aus Browser-Sicht (window.location.protocol)
• User-Agent und Browser-Informationen
• HTTP/2 vs. HTTP/1.1 Erkennung

WebSocket-Test

Unter /probe/websocket kann eine WebSocket-Verbindung interaktiv getestet werden.

Funktionen

• Verbinden / Trennen: WebSocket-Verbindung auf- und abbauen
• Echo-Test: Beliebige Nachrichten senden, Echo-Antwort empfangen
• Ping: Server sendet alle 10 Sekunden einen Ping
• Live-Log: Alle gesendeten und empfangenen Nachrichten mit Timestamp
• Status-Anzeige: Verbindungsstatus (Connecting / Connected / Error / Closed)

WebSocket-Endpunkt

Der WebSocket-Server läuft auf wss://dev1.boesls.de/ws. nginx leitet das Upgrade-Protokoll transparent weiter.

Nachrichtenformat (JSON)

{ "type": "connected",  "ts": "2026-01-01T12:00:00.000Z", "server": "Webtest" }
{ "type": "ping",       "ts": "..." }
{ "type": "echo",       "data": "Deine Nachricht", "ts": "..." }

Content-Filter-Test

Unter /probe/content können verschiedene Content-Typen getestet werden, die von Unternehmens-Proxies häufig gefiltert oder blockiert werden.

Test-Downloads

Testdateien verschiedener Typen und Größen werden direkt von nginx ausgeliefert (kein Node.js beteiligt):

JavaScript-Ausführungstest

Prüft ob JavaScript im Browser ausgeführt wird. Wenn ein Content-Filter JavaScript-Dateien blockiert oder manipuliert, schlägt dieser Test fehl.

Fetch-API-Test

Führt einen asynchronen HTTP-Request via fetch() aus und zeigt den Status und die empfangenen Header an. Testet ob der Proxy XMLHttpRequests oder Fetch-Requests blockiert.

Profil & Claims

Unter /profile werden alle Informationen aus dem Authentifizierungs-Token bzw. der SAML-Assertion angezeigt.

Angezeigte Informationen

Konto wechseln

Direkt unter dem angemeldeten Benutzer befinden sich zwei Schaltflächen:

• ⇄ Anderen Account verwenden — startet einen neuen Auth-Flow beim gleichen Provider mit erzwungener Account-Auswahl (prompt=select_account für OIDC, ForceAuthn=true für SAML). Kein vorheriger Logout nötig; die Session wird nach erfolgreicher Re-Authentifizierung überschrieben.
• Abmelden — zerstört die aktuelle Session und leitet zur Startseite weiter.

Die Gruppen-IDs in der Gruppen-Tabelle können direkt für die Gruppen-Einschränkung in der Provider-Konfiguration verwendet werden.

Endpunkt-Referenz

Vollständige Liste aller HTTP-Endpunkte. Detaillierte Liste unter /endpoints.

Authentifizierung

Konfiguration (Admin)

Test-Funktionen & Sonstiges

Sicherheit

Implementierte Maßnahmen

Hinweise

• OIDC Client Secrets und SAML-Zertifikate werden in der SQLite-Datenbank gespeichert
• Die Datenbankdatei sollte nur für den Service-User (webtest) lesbar sein
• Die .env-Datei enthält das Session-Secret und sollte entsprechend geschützt sein
• Session-Tokens haben eine Gültigkeit von 8 Stunden

Deployment

Voraussetzungen

• Debian/Ubuntu Linux
• Node.js 20 LTS
• nginx ≥ 1.25 (für http2 on;-Direktive)
• Certbot (für Let's Encrypt TLS-Zertifikat)

Umgebungsvariablen (.env)

systemd-Service

Die Anwendung läuft als systemd-Service unter dem Benutzer webtest. nodemon überwacht Änderungen in src/ und static/ und startet die Anwendung automatisch neu.

sudo systemctl status webtest
sudo systemctl restart webtest
journalctl -u webtest -f

Datenbankstruktur