Single Sign-On for eldre webapplikasjonar: SAML-/OIDC-gateways, HTTP-header-autentisering og risikoar ved gamle sesjonsmekanismar

Der Irrtum klingt in vielen IT-Runden angenehm beruhigend: „Wir stellen ein SSO-Gateway davor, dann ist die Legacy-Webapp modern authentifiziert.“ Im Diagramm passen die Kästen sauber: Identity Provider (IdP), SAML oder OpenID Connect (OIDC), Reverse Proxy – fertig. In der Praxis kommen danach Tickets, die nicht nach „Auth-Protokoll“ aussehen: Login-Loops, „falscher Benutzer“ nach Schichtwechsel, Logout ohne Wirkung oder sporadisch fehlende Berechtigungen. Und spätestens beim Security-Review steht die unangenehme Frage im Raum: Wer garantiert eigentlich, dass die Legacy-Webapp den Authentifizierungs-Header nur vom Gateway bekommt – und dass ihre eigene Session nicht zum Einfallstor wird?

Single Sign-On für Legacy-Webapps ist weniger ein Login-Feature als ein Zusammenspiel aus Vertrauensgrenzen (Trust Boundaries), Protokollvalidierung, Netzwerkpfaden und Session-Mechanismen. Dieser Irrtum-Check prüft: Was an der Gateway-Idee stimmt, wo sie regelmäßig bricht, welche Ausnahmefälle wirklich zählen – und wie daraus ein abnehmbarer Vorgehensplan entsteht, der Betrieb und Security nicht gegeneinander ausspielt.

Single Sign-On für Legacy-Webapps in der Praxis

Der Kern des Irrtums ist die Gleichsetzung von „modernem Protokoll“ mit „sicherer Anwendung“. Ein SAML- oder OIDC-Flow kann korrekt sein, und trotzdem kann die Altanwendung unsicher oder fehleranfällig arbeiten, weil sie nach dem Login eine eigene Anwendungssession verwaltet. In vielen Legacy-Integrationen ist das der Normalfall: Das Gateway authentisiert, die Anwendung baut anschließend ihre Session auf Basis einer übergebenen Identität.

Genau dieses Muster wird in Plattformarchitekturen als „Header-based Authentication“ beschrieben: Ein vorgelagerter Intermediär authentisiert, setzt Identitätsinformationen als HTTP-Header, und die Anwendung erstellt daraufhin eine Session.^[Quelle] Praktisch ist das attraktiv, weil die Legacy-Webapp nicht „SAML lernen“ muss. Aber der Schutzanker verschiebt sich: Nicht das Token im Browser ist dann Ihr letzter Sicherheitsgurt, sondern (1) die Absicherung der Header-Quelle und (2) ein sauberes Session-Lifecycle hinter dem Gateway.

SSO-Architekturvarianten für Legacy-Webapps: drei Wege, drei Trust-Modelle

Die Diskussion wird schneller, wenn Sie zuerst das Trust-Modell benennen: Wo wird Identität geprüft, und wie wird sie an die Anwendung gebunden? Daraus ergeben sich Testaufwand, Betriebsrisiken und Wartbarkeit.

Die Abkürzungsfrage: Wie veränderbar ist die Legacy-Webapp wirklich?

Wenn die Webapp kaum noch änderbar ist (seltene Releases, kaum Tests, viele Abhängigkeiten), bleibt das Gateway-Pattern oft der einzige kurzfristig realistische Pfad. Das ist legitim – aber dann ist Infrastruktur nicht mehr „Transport“, sondern Teil Ihrer Sicherheitsarchitektur. Wenn Sie ohnehin modernisieren (Deployment, Datenzugriff, UI-Teile, Schnittstellen), ist ein definierter Handshake oder native OIDC/SAML oft die stabilere Investition, weil weniger implizite Annahmen im Proxy stecken und Fehler klarer zuordenbar sind.

Header-Auth: Warum es gewählt wird – und welche Zusagen Sie dafür einhalten müssen

Header-based Authentication ist ein Adapter für gewachsene Business-Software: Das Gateway kann SAML/OIDC, die Anwendung nicht. Also wird Identität nach erfolgreicher Authentisierung per Header an die Anwendung übergeben, die daraus ihren Login-Kontext ableitet.^[Quelle] Entscheidend ist dabei nicht „ob Header funktionieren“, sondern ob das Vertrauensmodell technisch erzwungen wird.

OWASP ASVS formuliert das als klare Anforderung: Authentifizierungs-Header, die von einem Intermediär gesetzt werden, dürfen nicht durch den Nutzer kontrollierbar sein.^[Quelle] Das ist keine akademische Fußnote, sondern die Abgrenzung zwischen „läuft“ und „vertretbar“.

Die wichtigste Betriebsbedingung: Die Legacy-Webapp darf nie direkt erreichbar sein

Header-Auth lebt davon, dass nur der Proxy die Auth-Header setzen kann. In gewachsenen Netzen gibt es aber Nebenpfade: alte DNS-Aliase, interne Hostnamen, zusätzliche Interfaces, ein „temporärer“ Wartungszugang oder ein zweiter Reverse Proxy vor einem Standortnetz. Sobald ein Client die Anwendung direkt erreicht, kann er – abhängig von Stack und Infrastruktur – Header fälschen oder durchreichen und damit Identität vortäuschen.

Legacy-Integrationsmuster betonen deshalb ausdrücklich: Der Zugriff muss auf „nur über den Reverse Proxy“ beschränkt werden, sonst wird der Trust-Anker umgangen.^[Quelle] Praktische Folgerung: Machen Sie daraus ein Abnahmekriterium mit Netztest und Dokumentation (Quelle → Ziel → Port). Ein Satz im Konzeptpapier ist kein Nachweis.

Header-Contract als Schnittstellenvertrag: klein, eindeutig, überprüfbar

Je mehr Attribute Sie per Header transportieren, desto mehr Änderungen und Fehlersuche landen im Proxy. In der Praxis reicht meist ein minimaler Vertrag:

• Eindeutiger Identitätsanker (z. B. stabiler Login-Name oder interne ID), nicht nur ein Anzeigename.
• Optional Mandanten-/Standortkontext, wenn die Anwendung davon abhängt.
• Optional Rollen/Gruppen, aber nur, wenn Mapping und Rezertifizierung geklärt sind.

Wichtig ist die Semantik: Normalisierung (Groß-/Kleinschreibung, Leerzeichen), erlaubte Zeichen, und das Fehlerverhalten. Fehlt der Identitätsheader, sollte die Anwendung den Request ablehnen und nicht in „halb-authentisierte“ Zustände laufen.

SAML/OIDC am Gateway: Validierung ist Pflicht – „Audience“ wird am häufigsten unterschätzt

Wenn das Gateway die Föderation übernimmt, muss es Assertions/Tokens korrekt validieren. Für OIDC sind Prüfungen wie Signatur, Aussteller (iss), Zielgruppe (aud) und Zeitfenster Teil der normativen Verarbeitung. Die OIDC-Core-Spezifikation beschreibt diese Validierungen als Anforderungen für Clients, nicht als optionales Hardening.^[Quelle]

Audience-Checks verhindern Querverwendung zwischen Anwendungen

In Multi-App-Umgebungen ist „Audience“ die unscheinbare Leitplanke: Für wen ist das Token gedacht? Gateways schützen oft mehrere Anwendungen und arbeiten mit sehr ähnlichen Konfigurationen. Wenn die Zielbindung nicht pro Anwendung sauber geprüft wird, entsteht Querverwendbarkeit: Ein Token, das für App A gedacht war, kann in App B akzeptiert werden – nicht weil OIDC/SAML „unsicher“ wären, sondern weil der Empfänger nicht eindeutig erzwungen wurde.

NIST benennt Audience-Restriction/Targeting als Kernanforderung in Föderationsmodellen, um Assertions an den beabsichtigten Empfänger zu binden und Fehladressierung zu verhindern.^[Quelle] Die Quelle schreibt keine konkrete Produktkonfiguration vor. Die betriebliche Folgerung ist trotzdem eindeutig: Trennen Sie Konfigurationen pro Anwendung (Client-ID/Audience, Redirect-URIs, Keys/Metadaten) und machen Sie „zentral geprüft, überall gültig“ zu einer bewusst dokumentierten Risikoannahme – falls Sie sie überhaupt vertreten wollen.

OAuth2/OIDC-Redirects: state ist Flow-Bindung, nicht „Kompatibilität“

Viele SSO-Störungen sitzen an der Redirect-Kante: falsche Ziel-URL nach Login, Tab-Konflikte, Back-Button-Effekte, unerwartete Re-Logins. RFC 6749 beschreibt den state-Parameter als Mechanismus zur Bindung von Request und Callback und zur Erschwerung von CSRF in Redirect-Flows; der Authorization Server muss CSRF-Schutz berücksichtigen.^[Quelle] Für Ihre Abnahme heißt das: Testen Sie Deep Links, parallele Tabs, abgelaufene Sessions, Reloads, Wechsel zwischen WLAN/VPN und die Browser, die in der Organisation wirklich genutzt werden.

Die Sollbruchstelle liegt meist hinter dem Gateway: alte Session-Mechanismen

Ein Gateway kann Identität beschaffen und Tokens prüfen. Es kann aber nicht automatisch sicherstellen, dass die Legacy-Webapp ihre Session korrekt behandelt. Und genau dort entstehen Fehlerbilder, die später teuer werden: schwer reproduzierbar, prozesskritisch und im Zweifel sicherheitsrelevant.

Session Fixation: Wenn die Session-ID vor und nach dem Login gleich bleibt

Session Fixation entsteht, wenn eine Anwendung einem Nutzer bereits vor der Authentisierung eine Session-ID zuweist und diese nach erfolgreichem Login beibehält. OWASP beschreibt das als Kernmechanismus; Gegenmaßnahme ist Session-Rotation nach Login (alte Session invalidieren, neue ausstellen).^[Quelle]

Das ist im SSO-Kontext besonders tückisch, weil der erste Request an die Anwendung durchaus „anonym“ sein kann (Ressourcen laden), während der Identitätsheader erst später greift. Wenn die App dann nicht rotiert, baut sie Authentisierung auf einem bereits existierenden Session-Konstrukt auf.

Cookie-Flags und SameSite: SSO macht alte Defaults sichtbar

SSO ist häufig domainübergreifend: Der IdP sitzt auf einer anderen Domain, Redirects sind Teil des Normalbetriebs. Legacy-Webapps verwenden oft Cookie-Defaults aus einer Zeit, in der moderne Browser-Regeln (u. a. SameSite-Handling) noch nicht so strikt waren. Typische Symptome sind Login-Loops oder sporadische „nicht angemeldet“-Zustände. Das ist selten „IdP instabil“, sondern eine Kollision aus Redirect-Flows und Cookie-Politik auf Proxy- und Anwendungsebene.

Timeouts: Sicherheitsniveau gegen Prozessrealität austarieren

In prozessnahen Softwarelösungen treffen Sie auf Nutzungsmuster, die Standard-SSO-Annahmen brechen: geteilte Schicht-PCs, Leitstände, lange Erfassungsdialoge, Scanner-/Druckstrecken, Freigaben kurz vor Schichtende. Wenn Sie nur die IdP-Session streng kurz halten, aber die App-Session sehr langlebig bleibt, bleibt das Risiko lokal bestehen. Wenn Sie alles aggressiv kurz einstellen, steigen Prozessabbrüche und Supportaufwand.

Tragfähig wird es meist über Differenzierung: Re-Authentisierung für privilegierte Aktionen, klare Inaktivitätszeit für allgemeine Nutzung, und ein definierter Umgang mit Shared Devices (z. B. konsequente Abmeldung plus kurze Zeitfenster). Das ist weniger Technik als eine bewusst beschlossene Betriebsregel, die zu Rollen und Prozessen passt.

Von „es klappt“ zu „es ist abnehmbar“: ein Entscheidungspfad für Projekte und Betrieb

SSO-Projekte scheitern selten am IdP. Sie scheitern an unklaren Zuständigkeiten zwischen Netzwerk, Gateway, Anwendung und Betrieb. Die folgende Schrittfolge ist bewusst operativ formuliert: Sie schneidet Arbeitspakete so, dass am Ende eine abnehmbare Lösung steht.

1. Zugriffspfade inventarisieren: DNS-Namen, VIPs, Ports, interne Aliase, Wartungs-URLs, VPN-Ausnahmen. Ziel: genau ein Entry-Point (Gateway), alles andere technisch gesperrt.
2. Trust Boundary festlegen: Wo endet „untrusted client“, wo beginnt „trusted gateway“? Entscheiden Sie, wie Proxy → Backend abgesichert wird und wie Direct Access nachweisbar verhindert wird.
3. Identitätsanker definieren: Welche Kennung ist in der Legacy-App maßgeblich (Login-Name, interne ID, E-Mail)? Das ist ein Daten- und Prozessentscheid; Dubletten und Offboarding-Lücken entstehen oft genau hier.
4. Header-Contract fixieren: Minimaler Satz, Semantik, Normalisierung, Fehlerverhalten. Abnahmekriterium: Fehlt Identität, wird abgelehnt.
5. Session-Mechanismus prüfen: Rotation nach Login, Timeout, parallele Sessions, Logout, Cookie-Flags, Verhalten bei Rollenwechsel. Übersetzen Sie das in Tests statt in Diskussionen.
6. Logout definieren: Was bedeutet „Logout“? Nur App-Session beenden, zusätzlich IdP-Session beenden oder bewusst nicht? Dokumentieren Sie Sonderfälle wie Shared Devices und Notbetrieb.
7. Observability aufbauen: Gateway-Logs (Redirects, Validierungsfehler), Backend-Logs (Header akzeptiert, Session neu/rotiert), Korrelation über Request-ID. Ohne Korrelation bleibt jedes Ticket eine Vermutung.
8. Pilot nach Prozessrollen: Rollen mit langen Sitzungen, Freigaben, geteilten Arbeitsplätzen. Prüfen Sie Randbedingungen: mehrere Browser, Mobilgeräte, alte Bookmarks, VPN-Wechsel.
9. Fallback/Rollback planen: Umschalten per Host/URL-Pfad, temporär alten Login reaktivieren, ohne die Anwendung zu verlieren. Das reduziert Change-Risiko spürbar.

Risikobilder, die im Betrieb teuer werden, wenn sie in der Konzeptphase „wegoptimiert“ werden

Header-Spoofing über unerwartete Zwischenpfade

Selbst wenn im Hauptkonzept „nur über Proxy“ steht, entstehen in der Realität Ausnahmen. Dann werden Header plötzlich doch durchgeschleust oder anders normalisiert. OWASP ASVS zielt mit der Forderung nach nicht user-kontrollierbaren Intermediary-Headern genau auf diese Fehlerklasse ab.^[Quelle] Ein typisches Diagnosemuster: Probleme treten „nur aus dem VPN“ oder „nur an Standort X“ auf. Das ist häufig ein anderer Infrastrukturpfad – und damit ein anderer Trust.

Token- und Session-Laufzeiten passen nicht zusammen

Wenn das Gateway kurzlebige Tokens korrekt validiert, die Legacy-App daraus aber eine sehr langlebige Session macht, entsteht Entkopplung: zentral kontrollierte Authentisierung, lokale Dauersitzung. Umgekehrt führt ein zu hartes Timeout ohne saubere Session-Erneuerung zu Prozessabbrüchen. Die Lösung ist eine klare Betriebsentscheidung mit Prozessbezug: Welche Aktionen erfordern Re-Auth? Welche dürfen ohne Unterbrechung laufen? Und wie wird das technisch an URLs, Rollen und Session-Erneuerung gebunden?

Rollen und Gruppen: SSO ist nicht automatisch Autorisierung

SSO beantwortet „wer ist das?“, nicht „was darf die Person?“. Wenn Sie Gruppen/Claims aus dem IdP übernehmen, müssen Mapping, Rezertifizierung und Offboarding geregelt sein. Wenn die Legacy-App Rollen lokal pflegt, brauchen Sie Prozesse für Joiner/Mover/Leaver. Mischmodelle funktionieren, erzeugen aber ohne Zuständigkeitsteilung Dauerstress: IAM sagt „Gruppe stimmt“, Anwendung sagt „Rolle stimmt nicht“, Betrieb steckt dazwischen.

Abnahmekriterien: Was vor Go-live schriftlich festgehalten sein sollte

Abnahme wird belastbar, wenn sie testbar ist. Für Session-Management liefert OWASP ASVS konkrete Verifikationspunkte (Lifecycle, Invalidierung, Session-Tokens) und eignet sich als Grundlage für einen prüfbaren Kriterienkatalog.^[Quelle]

Ein praxistauglicher Minimal-Katalog für Gateway + Legacy-Webapp:

• Backend-Isolation nachgewiesen: Direkter Zugriff auf die App scheitert (Netztest dokumentiert).
• Header-Trust erzwungen: Allowlist, eingehende Header entfernt/überschrieben, keine Manipulation über Nebenpfade.
• Session-Rotation nach Login: Session-ID wird nach erfolgreicher Authentisierung erneuert.
• Logout-Verhalten definiert und getestet: App-Session invalidiert; Verhalten gegenüber IdP/Gateway dokumentiert.
• Cookie-/Redirect-Robustheit: Flags und SameSite-Strategie passen zum SSO-Flow; keine reproduzierbaren Login-Loops im relevanten Browser-Mix.
• Diagnosefähigkeit: Logs und Korrelation trennen IdP/Gateway-Probleme von App-Problemen.

Der erste sinnvolle Schritt ist oft nicht SAML/OIDC – sondern Pfad- und Session-Tests

Wenn Sie priorisieren müssen, beginnen Sie mit zwei Prüfungen, die über „machbar oder nicht“ entscheiden: (1) Ist das Backend wirklich ausschließlich über den Proxy erreichbar? (2) Rotiert die Legacy-App ihre Session nach erfolgreicher Authentisierung? Erst wenn diese Basis steht, lohnt es, Claims, Gruppenmapping und UX-Details zu verfeinern.

Das spart Zeit, weil es Spätüberraschungen verhindert: „SSO ist fertig, aber Security stoppt wegen direktem Backend“ oder „SSO ist live, aber Nutzerkontexte vermischen sich wegen alter Sessions“. Wenn diese Grundlagen sauber sind, wird das Gateway-Projekt steuerbar: Pilotieren, messen, schrittweise aktivieren – statt Dauerfeuer im Betrieb.

Für dieses Thema sind auch Saml 2.0 und Oauth 2.0 Authorization Code Flow wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.