Moderne Authentifizierung für Legacy-Anwendungen erklärt

Ihr ERP-System kennt keine SAML-Assertion. Genauso wenig wie das 15 Jahre alte interne Tool, das Ihre Lagerverwaltung steuert. Aber Ihr Identity-Team hat gerade Microsoft Entra ID mit bedingtem Zugriff, MFA und Zero-Trust-Richtlinien flächendeckend eingeführt.

Diese Lücke schließt die moderne Authentifizierung für Legacy-Anwendungen. Sie bildet die Schnittstelle, die es alten, an Anmeldeinformationen gebundenen Systemen ermöglicht, sich in Single Sign-On (SSO), Multi-Faktor-Authentifizierung (MFA) und zentralisierte Identitätsverwaltung zu integrieren, ohne dass Sie eine einzige Zeile des Codes ändern müssen.

Wenn Sie entscheiden müssen, wie ein 10 Jahre altes ERP-System in Ihre Entra ID-Einführung passt oder ob es endlich an der Zeit ist, LDAP-Bindungen und NTLM abzuschaffen, finden Sie hier alles, was Sie über die Modernisierung von Legacy-Anwendungen wissen müssen.

Warum Legacy-Anwendungen moderne Authentifizierung benötigen

Die meisten älteren Anwendungen wurden vor 10, 15, sogar 20 Jahren entwickelt, als Authentifizierung noch ein Anmeldeformular und eine Passwortprüfung anhand einer lokalen Datenbank oder einer Verzeichnisbindung bedeutete.

Die meisten herkömmlichen Authentifizierungsmethoden wurden nie für eine Welt entwickelt, in der die Identität über Cloud-Anwendungen, VPNs und mobile Geräte hinweg übertragen werden muss oder in der moderne MFA-, Gerätestatus-, Standort- oder risikobasierte Richtlinien nativ durchgesetzt werden müssen.

Währenddessen lief der Rest Ihrer Infrastruktur weiter. Ihre Cloud-Anwendungen sind durch einen Identitätsanbieter geschützt. Ihre Mitarbeiter melden sich einmal an und haben Zugriff auf alles, was sie für ihre Arbeit benötigen.

Die älteren Anwendungen haben die Neuerungen nicht mitbekommen, und genau diese Sicherheitslücke suchen Angreifer als Erstes. Wir haben die spezifischen Risiken ausführlich in unserer Analyse der Risiken veralteter Authentifizierungssysteme beschrieben . Diese ist lesenswert, wenn Sie intern Argumente für die Sicherheitslücken sammeln müssen.

Ihre bestehenden Anwendungen nutzen intern formularbasierte, LDAP-, WIA-, headerbasierte und Kerberos-Authentifizierung. Keine dieser Methoden unterstützt jedoch nativ MFA oder bewertet Gerätestatus, Standort oder Risiko vor der Zugriffsgewährung.

Für Compliance-Teams ist die Situation noch schwieriger. DSGVO, HIPAA, SOC 2 und PCI-DSS fordern allesamt eine starke Authentifizierung und Transparenz der Zugriffsrechte. Eine App ohne Multi-Faktor-Authentifizierung und ohne zentrale Protokollierung stellt eine Sicherheitslücke dar, die Ihr Auditor aufdecken wird.

Traditionelle vs. moderne Authentifizierung: Was ist der tatsächliche Unterschied?

Bei der herkömmlichen Authentifizierung überprüft die Anwendung selbst Ihre Identität. Sie speichert die Anmeldeinformationen oder fragt diese direkt ab, validiert das Passwort und startet eine Sitzung. Alles findet innerhalb der Anwendung selbst statt.

Moderne Authentifizierung verlagert diese Aufgabe aus der Anwendung heraus. Sie ist der aktuelle Standard zur Überprüfung der Benutzeridentität. Dabei verifiziert ein Identitätsanbieter (IdP) den Benutzer, stellt ein signiertes Token oder eine Assertion aus, und die Anwendung vertraut diesem Token, anstatt selbst ein Passwort zu überprüfen. Authentifizierung und Anwendung werden somit zu zwei getrennten Prozessen.

Dieser Unterschied ist der Hauptgrund, warum ältere Anwendungen in der Vergangenheit bei modernen Sicherheitsarchitekturen vernachlässigt wurden. Ältere Anwendungen gehen davon aus, dass sie die Authentifizierung selbst kontrollieren. Moderne Sicherheitsmodelle lassen dies nicht zu.

Die Lösung besteht in einem Übersetzer, der zwischen den beiden Modellen positioniert ist. Und genau dafür ist ein Access Gateway konzipiert – dazu später mehr.

Wie Legacy-Anwendungen heute authentifiziert werden

Die Authentifizierung älterer Anwendungen lässt sich üblicherweise einem von fünf Mustern zuordnen. Bevor Sie irgendetwas modernisieren, müssen Sie für jede Anwendung wissen, welches Muster zutrifft.

Formularbasierte Authentifizierung

Die App generiert eine eigene Anmeldeseite, sendet Benutzername und Passwort an ihren Server und validiert diese anhand einer lokalen Datenbank oder LDAP/Active Directory. Einfach und völlig unabhängig von Identitätsanbietern oder MFA-Richtlinien in Ihrer Systemarchitektur.

LDAP-Authentifizierung

Die App verbindet sich direkt mit einem LDAP-Server oder Active Directory und verwendet dabei die vom Benutzer eingegebenen Anmeldeinformationen. Das funktioniert. Allerdings hat die App nun eine direkte, aktive Verbindung zu Ihrem Verzeichnis: kein Token, kein Ablaufdatum, keine einfache Möglichkeit, einen zweiten Faktor hinzuzufügen.

Windows-integrierte Authentifizierung

WIA nutzt intern NTLM oder Kerberos über SPNEGO, sodass sich ein in die Domäne eingebundener Rechner im Browser automatisch authentifiziert. Im Firmennetzwerk ist das ideal. Sobald sich jedoch jemand remote, mit einem privaten Gerät oder außerhalb der Domäne befindet, versagt das System.

Header-basierte Authentifizierung

Die App sieht niemals ein Passwort. Sie vertraut einem HTTP-Header, üblicherweise etwas wie REMOTE_USER, der von einem vorgeschalteten Gerät gesetzt wird, in der Regel einem Reverse-Proxy oder einem Webserver-Modul. Genau diese Vertrauensgrenze ist die Tür, durch die ein modernes Zugriffsgateway geht.

Kerberos-Authentifizierung

Ein ticketbasiertes Verfahren, das in Active Directory integriert ist. Der Client fordert vom KDC ein Ticket zur Ticketvergabe an und anschließend für jede Ressource, auf die er zugreifen möchte, ein Service-Ticket. Da kein Passwort übertragen wird, ist die Sicherheit erhöht. Dennoch ist das System eng an die Windows-Domäne gebunden und für Cloud- oder Remote-Anwendungen umständlich.

Der moderne Authentifizierungs-Stack zur Absicherung älterer Anwendungen

Das sind die Bausteine. Und die meisten Implementierungen kombinieren mehrere davon gleichzeitig.

SAML-2.0

Die Security Assertion Markup Language (SAML) ist ein XML-basierter Standard für die Übermittlung von Authentifizierungszusicherungen von einem Identitätsanbieter an einen Dienstanbieter. Sie ist die Standardwahl für viele SSO-Lösungen in Unternehmen und wird von den meisten älteren Integrationstools standardmäßig unterstützt, da viele Identitätsanbieter SAML-Zusicherungen standardmäßig ausgeben.

OAuth 2.0

Hier ist Präzision wichtig: OAuth 2.0 ist ein Autorisierungsframework, kein Authentifizierungsprotokoll. Es regelt den delegierten Zugriff und ermöglicht es einer App, ein Token mit einem bestimmten Gültigkeitsbereich zu erhalten, um im Namen eines Benutzers mit einer API zu interagieren, ohne jemals das Passwort des Benutzers einzusehen.

OpenID-Connect (OIDC)

OIDC ergänzt OAuth 2.0 um eine Identitätsebene. Es führt das ID-Token ein, ein signiertes JWT mit Angaben wie E-Mail-Adresse und Name des Benutzers, das die eigentliche Benutzerauthentifizierung durchführt. Moderne Anwendungen, die sowohl Login- als auch API-Zugriff benötigen, kombinieren in der Regel beides.

Identitätsanbieter (IdP)

Microsoft Entra ID, Okta, Ping Identity und Google Workspace erfüllen alle die gleiche Kernaufgabe: Sie verwalten Ihr Verzeichnis, verifizieren Benutzer und stellen signierte Token oder Assertions für jede verbundene Anwendung aus, einschließlich älterer Anwendungen, sobald diese eingebunden sind.

Einmaliges Anmelden (SSO)

Ein Login, eine vertrauenswürdige Sitzung, Zugriff auf alles, womit es verbunden ist. Damit eine ältere Anwendung in diese Welt integriert werden kann, muss ihr nativer Login in den SSO-Ablauf übersetzt werden, da die Anwendung selbst nie für die Kommunikation mit SAML oder OIDC entwickelt wurde.

Multi-Faktor-Authentifizierung (MFA)

Ein zweiter Identitätsnachweis: etwas, das Sie besitzen oder sind, zusätzlich zu Ihrem Wissen. Anstatt die Multi-Faktor-Authentifizierung (MFA) einzeln in jede bestehende Anwendung zu integrieren, wird sie auf der Ebene des Identitätsanbieters oder Gateways erzwungen, und jede verbundene Anwendung übernimmt sie automatisch.

So aktivieren Sie die moderne Authentifizierung für ältere Anwendungen

Schritt 1. Bewerten Sie die bestehende Authentifizierungsmethode.

Prüfen und katalogisieren Sie jede Anwendung: Nutzt sie formularbasierte, LDAP-, WIA-, headerbasierte oder Kerberos-Authentifizierung? Was nicht erfasst ist, lässt sich nicht integrieren, und selbst eine fehlende Angabe kann später unbemerkt zu Problemen bei der Implementierung führen. Die meisten Legacy-Anwendungen lassen sich in wenige Kategorien einteilen: Eigenentwicklungen oder benutzerdefinierte Tools, Drittanbieter- oder kommerzielle Software, ERP- und CRM-Systeme wie PeopleSoft, JD Edwards sowie alle Anwendungen mit headerbasierter oder LDAP-basierter Authentifizierung.

Schritt 2. Wählen Sie einen kompatiblen Identitätsanbieter aus.

Microsoft Entra ID, Okta, Ping Identity, Google Workspace oder Ihr bestehendes Active Directory. Ziel dieses Schritts ist es, Ihren bestehenden Identitätsanbieter (IdP) mit älteren Anwendungen zu verbinden und ihn nicht zu ersetzen.

Schritt 3. Wählen Sie einen Ansatz für die Authentifizierungsintegration.

Für die meisten älteren Webanwendungen ist ein Reverse-Proxy, ein vorgeschaltetes Zugriffsgateway, der schnellste Weg. Er fängt die Anfrage ab, verarbeitet den SAML- oder OIDC-Handshake mit dem Identitätsanbieter und stellt der Anwendung anschließend eine vertrauenswürdige Sitzung bereit, häufig über dieselbe Header-basierte Vertrauensstellung, die die Anwendung bereits kennt.

Schritt 4. Einmaliges Anmelden konfigurieren

Richten Sie das Gateway oder den Connector auf Ihren gewählten Identitätsanbieter aus und konfigurieren Sie die Vertrauensbeziehung: Metadatenaustausch für SAML, Client-ID und Client-Geheimnis für OIDC.

Schritt 5. Multi-Faktor-Authentifizierung aktivieren

Aktivieren Sie die Multi-Faktor-Authentifizierung (MFA) auf der IdP- oder Gateway-Ebene. Da diese vor der Anwendung liegt, erbt jede nachfolgende Legacy-Anwendung automatisch dieselbe MFA-Richtlinie.

Schritt 6. Testen Sie die Authentifizierungsabläufe

Gehen Sie jeden Zugriffspfad durch: Anmeldung, Abmeldung, Sitzungs-Timeout und das Verhalten bei kurzzeitiger Nichterreichbarkeit des Identitätsanbieters. Ältere Anwendungen weisen oft Sonderfälle auf, wie z. B. ungewöhnliches Timeout-Verhalten oder feste Sitzungslängen, die nicht den modernen Standardeinstellungen entsprechen. Testen Sie daher mit einer realen Pilotgruppe, nicht nur mit Ihrem IT-Team.

Schritt 7. Produktionsfreigabe

Beginnen Sie mit einer Pilotgruppe, beobachten Sie die Anmeldeerfolgsraten und Supportanfragen und erweitern Sie die Gruppe anschließend. Behalten Sie den bisherigen Ausweichanmeldeprozess bei, bis sich der neue als stabil erwiesen hat.

Herausforderungen, bewährte Verfahren und die Wahl der richtigen Lösung

Gemeinsame Herausforderungen

Einige Dinge tauchen in fast jedem Modernisierungsprojekt für Altanwendungen immer wieder auf. Es ist gut, das vor Beginn zu wissen.

• Unvollständiges App-Inventar: Teams modernisieren die ihnen bekannten Anwendungen und übersehen dabei diejenigen, die unauffällig im Hintergrund laufen: ein veraltetes Reporting-Tool, ein Anbieterportal, ein Skript, das ein Dienstkonto verwendet.
• Sitzungs- und Zeitüberschreitungsprobleme: Ältere Anwendungen gehen oft von langen, ununterbrochenen Sitzungen aus. Moderne Token-Lebensdauern sind jedoch standardmäßig kürzer. Wird dies nicht berücksichtigt, werden Benutzer mitten in ihrer Arbeit abgemeldet.
• Probleme mit Header- oder Cookie-Vertrauenswerten: Wenn ein Gateway die Identität per Header oder Cookie übermittelt, muss die Legacy-Anwendung diesem Gateway vollständig vertrauen. Eine Fehlkonfiguration schafft ein Spoofing-Risiko, anstatt es zu beseitigen.
• BenutzerwiderstandJede Änderung des Anmeldeverhaltens, selbst eine positive, stößt ohne klare Kommunikation auf Widerstand. Eine neue MFA-Abfrage in einer 15 Jahre alten App kann bereits in der ersten Woche zahlreiche Supportanfragen generieren.

Bei der Auswahl einer Lösung hierfür gibt es einige Dinge, die wichtiger sind als die Verkaufspräsentation. Hier sind beispielsweise einige Punkte, die Sie vor der Entscheidung für die richtige Lösung berücksichtigen sollten.

• Protokollabdeckung Dazu gehören die Legacy-Seite (LDAP, Kerberos, Header-basiert) sowie SAML, OAuth und OIDC.
• "Keine Codeänderungen" Gilt für Ihre tatsächlichen App-Typen oder auch nur für die einfachen.
• Kompatibilität mit dem IdP Sie verwenden bereits eine Anwendung, sei es Microsoft Entra ID, Okta, Ping Identity oder Google Workspace.
• Pilotprojekt mit 10 Apps und Skalierbarkeit auf Unternehmensebene mit 200 Apps und einfache Implementierung, ohne dass Sie mittendrin das Werkzeug wechseln müssen.

Praxisbeispiele

Die in diesem Artikel beschriebene Lücke soll die Legacy Apps SSO & MFA -Lösung von miniOrange schließen. Sie verwendet ein Access Gateway , das vor Ihren Legacy-Anwendungen platziert wird und diese mit SSO, MFA und Ihrem bestehenden Identitätsanbieter verbindet.

Hier sind einige bewährte Vorgehensweisen, die alle guten Anbieter bei der Implementierung moderner Authentifizierung in Legacy-Anwendungen befolgen:

• Beginnen Sie mit einer PilotgruppeKeine vollständige Einführung. Wählen Sie eine Abteilung oder eine Anwendung aus, testen Sie Authentifizierung und Autorisierung separat, klären Sie die Details und skalieren Sie dann.
• Ordnen Sie jedes Servicekonto zu. und die Integration ohne Benutzeroberfläche, nicht nur die Anmeldung von Benutzern. Diese werden am häufigsten übersehen und führen später zu Ausfällen.
• Die MFA-Richtlinien sollten einheitlich gestaltet werden. Dies gilt für ältere und moderne Anwendungen gleichermaßen. Benutzer sollten keine unterschiedlichen Sicherheitseinstellungen erhalten, je nachdem, in welche Anwendung sie sich einloggen.
• Dokumentieren Sie den Ausweichplan. Wissen Sie genau, wie Sie die Änderungen rückgängig machen können, falls die neue Authentifizierungsmethode in der Produktionsumgebung zu Problemen führt.

Fazit

Moderne Authentifizierung für Legacy-Anwendungen funktioniert am besten als zusätzliche Sicherheitsebene vor der bestehenden Infrastruktur, anstatt als Komplettaustausch. Führen Sie die Bedarfsanalyse sorgfältig durch, wählen Sie einen vertrauenswürdigen Identitätsanbieter, und der Rest ist im Wesentlichen eine Frage der richtigen Reihenfolge.

Wenn Sie eine detailliertere Architekturbeschreibung wünschen, haben wir separat darüber geschrieben, wie Access Gateway die Modernisierung von Legacy-Anwendungen unterstützt.

Und falls Legacy-Anwendungen nur ein Teil Ihrer umfassenderen Identitätsimplementierung sind, bietet Ihnen unser vollständiger IAM Suite deckt den Rest ab.

Häufig gestellte Fragen

Was ist moderne Authentifizierung?

Bei modernen Authentifizierungsverfahren wird die Authentifizierung von einem zentralen Identitätsanbieter anstelle der einzelnen Anwendung durchgeführt. Dabei werden signierte Token oder Assertions (SAML, OAuth 2.0 oder OIDC) verwendet, anstatt dass die Anwendung selbst ein Passwort überprüft.

Können ältere Anwendungen moderne Authentifizierungsmethoden verwenden?

Ja, die meisten webbasierten Legacy-Anwendungen können das, üblicherweise über einen Reverse-Proxy oder ein Access-Gateway, das vor der Anwendung sitzt und den modernen Authentifizierungsablauf übernimmt, ohne den Code der Anwendung zu verändern.

Kann ich Single Sign-On aktivieren, ohne den Anwendungscode zu ändern?

In den meisten Fällen ja. Ein Zugriffsgateway fängt die Anfrage vor der Anwendung ab und leitet eine vertrauenswürdige Sitzung an diese weiter, üblicherweise über dieselbe headerbasierte Vertrauenswürdigkeit, auf die viele ältere Anwendungen bereits angewiesen sind.

Welche Authentifizierungsprotokolle eignen sich am besten für ältere Anwendungen?

Das hängt davon ab, welche Kommunikationsschnittstellen die Anwendung bereits unterstützt. Header-basierte und LDAP-basierte Anwendungen lassen sich problemlos über ein Gateway integrieren, während Anwendungen, die SAML nativ unterstützen, sich direkt mit einem Identitätsanbieter verbinden können.

Kann ich die Multi-Faktor-Authentifizierung zu bestehenden Anwendungen hinzufügen?

Ja. Die Multi-Faktor-Authentifizierung (MFA) wird auf der Ebene des Identitätsanbieters oder Gateways erzwungen, sodass die Legacy-Anwendung sie ohne eigene native MFA-Unterstützung erbt.