Das Ziel: interne Oberflächen nur nach Login

In einer selbst gehosteten Umgebung sammeln sich schnell ein Dutzend Web-Oberflächen an: ein SIEM-Dashboard, ein Automatisierungswerkzeug, ein Benachrichtigungsdienst, Monitoring, Container-Verwaltung. Viele davon sind nur für Administratoren gedacht – aber technisch offen erreichbar, hinter ihrem jeweils eigenen (oder gar keinem) Login. Der Wunsch ist naheliegend: Alles soll nur nach einer zentralen Anmeldung erreichbar sein.

Das klassische Werkzeug dafür ist ForwardAuth: Der Reverse-Proxy (hier Traefik) fragt vor jeder Anfrage bei einem zentralen Identity-Provider (hier Authentik) nach, ob der Aufrufer angemeldet ist. Wer es nicht ist, wird zum Login umgeleitet. Ein einziges Middleware-Snippet, auf einen Router gelegt – fertig. So die Theorie. In der Praxis ist die richtige Frage nicht „Wie schalte ich das ein?“, sondern „Vor welche Pfade darf es überhaupt?“

Zwei Arten von Diensten – und warum das den Unterschied macht

Beim Durchgehen der Dienste zeigte sich eine saubere Trennung in zwei Gruppen.

Gruppe A – hat schon einen SSO-Login. Nextcloud, der Mailserver, die Git-Plattform, das CMS, Grafana: Sie sind bereits per OpenID Connect an denselben Identity-Provider angebunden. Ein ForwardAuth davor würde nichts gewinnen – „nur nach zentralem Login“ ist bereits erfüllt – aber viel zerstören: Diese Dienste sprechen nicht nur mit Browsern, sondern mit nicht-interaktiven Clients. Kalender- und Datei-Synchronisation (CalDAV/WebDAV), Mail-Clients (IMAP/SMTP/Autoconfig), git clone über HTTPS, eine öffentliche Lese-API fürs Blog. Keiner dieser Clients kann durch einen interaktiven Login-Redirect hindurch. Ein ForwardAuth pauschal auf alle Pfade zu legen, würde sie stumm abwürgen. Regel: Was schon SSO spricht, bekommt kein zweites Gate.

Gruppe B – hat keinen SSO-Login. Das SIEM-Dashboard, das Automatisierungswerkzeug, der Benachrichtigungsdienst. Diese bekommen das neue ForwardAuth-Gate. Aber auch hier lauert die eigentliche Lektion, denn zwei von ihnen haben ebenfalls Pfade, über die keine Browser sprechen.

Der Kern: das Gate pfad-scoped setzen

Das Automatisierungswerkzeug (n8n) hat eine Bedienoberfläche und Webhooks. Über die Webhooks laufen ein Kontaktformular und ein Chatbot der öffentlichen Website – die müssen von außen erreichbar bleiben. Der Benachrichtigungsdienst (Gotify) hat eine Weboberfläche und eine Push-API, über die sowohl die Handy-App als auch die Alarm-Sender (Container-Security, Update-Melder, das SIEM) ihre Meldungen zustellen.

Wer hier das Gate stumpf auf die ganze Domain legt, gilt fürs Erste als „sicher“ – und merkt erst Tage später, dass keine Kontaktanfrage mehr ankommt und das Handy keine Alarme mehr bekommt. Das ist die tückischste Sorte Fehler: ein stiller.

Die Lösung ist, das Gate pfad-scoped zu setzen. Der Reverse-Proxy erlaubt mehrere Router pro Domain mit unterschiedlicher Priorität. Man legt also:

Die höhere Priorität sorgt dafür, dass die Maschinen-Pfade zuerst greifen und das Gate umgehen; alles andere fällt auf den Hauptrouter und wird zum Login geschickt. Die Weboberfläche ist geschützt, die Automatik läuft weiter. Wichtig ist, wirklich nur die nötigen Pfade zu öffnen – beim Benachrichtigungsdienst etwa die Endpunkte für Nachrichten, den Live-Stream, die Client-Anmeldung und die App-Liste, nicht mehr.

Die Push-App-Falle: eine Härtung, die einen Client aussperrt

Ein besonders lehrreicher Nebenschauplatz: Nachdem die Weboberfläche des Benachrichtigungsdienstes hinter dem Gate lag, meldete die iOS-App plötzlich „kein Server gefunden“ – obwohl die Push-Pfade offen waren und Meldungen weiterhin ankamen.

Die Ursache lag in einer anderen, älteren Härtung. Um die Software-Version des Dienstes nicht nach außen zu zeigen, war der Endpunkt, der genau diese Version zurückgibt, extern blockiert. Die App aber prüft über exakt diesen Endpunkt, ob am anderen Ende ein gültiger Server sitzt. Blockiert man ihn, findet die App keinen Server.

Nicht für alle: Admin-only statt „irgendwie eingeloggt“

Ein Gate, das nur „ist überhaupt jemand angemeldet?“ prüft, ist für ein SIEM zu grobmaschig. In einer Umgebung mit mehreren Rollen – etwa Fachanwender neben Administratoren – soll nicht jeder angemeldete Nutzer ins Sicherheits-Dashboard oder in den Editor des Automatisierungswerkzeugs (der Zugriff auf Workflows, gespeicherte Zugangsdaten und Schlüssel gibt).

Im Identity-Provider bindet man die Anwendung deshalb an eine Admin-Gruppe. Nur deren Mitglieder kommen durch. Ein kleiner, aber wichtiger Handgriff – und einer, bei dem man sich vorher vergewissern sollte, selbst Mitglied dieser Gruppe zu sein, um sich nicht versehentlich auszusperren.

Verifikation: 302 gegen 401

Ob das Gate richtig sitzt, lässt sich präzise und ohne Rätselraten prüfen – am Statuscode der Antwort:

Der Unterschied ist die ganze Aussage. Ein 302 zum Login heißt: Das Gate fängt die Anfrage ab. Ein 401 vom Dienst selbst (kein Redirect!) heißt: Die Anfrage erreicht den Dienst ungehindert, und dessen eigene Token-Prüfung antwortet. Sieht man auf einem Maschinen-Pfad einen Redirect statt einer 401, ist die Ausnahme falsch gesetzt. Ein Fix ist erst dann fertig, wenn beide Richtungen belegt sind: das Geschützte geschützt, das Offene offen.

Lessons Learned

Eine zentrale Anmeldung vor alles zu ziehen klingt nach einem Schalter. Tatsächlich ist es eine Sortierarbeit: Wer spricht mit Menschen, wer mit Maschinen? Erst diese Trennung macht aus „alles hinter Login“ eine Lösung, die niemanden im Dunkeln stehen lässt.