So fügen Sie Legacy-Anwendungen SAML-Authentifizierung hinzu: Eine Schritt-für-Schritt-Anleitung

Viele Unternehmen setzen nach wie vor auf veraltete Anwendungen für ihre Kernprozesse. Dies birgt jedoch Einschränkungen. Laut dem Workforce Agility Report gaben 50 % der CIOs an, dass veraltete Anwendungen die digitale Transformation behindern. Noch wichtiger ist, dass sie erhebliche Sicherheitslücken verursachen.

Die meisten älteren Anwendungen, wie beispielsweise Oracle EBS, PeopleSoft, SAP und JD Edwards, verwenden Authentifizierungsmethoden, die nicht den modernen Anforderungen an die Identitätsverwaltung entsprechen.

Doch die bloße Ablösung veralteter Systeme ist nicht die beste Lösung, denn für viele Unternehmen sind diese Systeme unerlässlich für den laufenden Betrieb. Sie benötigen daher eine Möglichkeit, Ihre bestehenden Systeme um moderne Sicherheitsfunktionen zu erweitern.

Die Legacy-SAML-Authentifizierung bietet einen praktikablen Weg in die Zukunft. Sie ermöglicht es Ihnen, ältere Software mithilfe moderner Standards zu schützen.

In diesem Leitfaden erfahren Sie, wie Sie SAML SSO für Ihre bestehenden Anwendungen implementieren können, ohne den Code neu schreiben zu müssen.

Warum Legacy-Anwendungen moderne Authentifizierung benötigen

Legacy-Anwendungen bleiben oft im Einsatz, weil sie geschäftskritische Arbeitsabläufe unterstützen. Ihre Ablösung kann Jahre dauern. Gleichzeitig ist sie, angesichts des Zeit- und Kostenaufwands, nicht so einfach, wie es scheint.

Das Festhalten an veralteten Anwendungen kann jedoch auch teuer werden, wenn auch auf andere Weise.

Einschränkungen der traditionellen Authentifizierung

Legacy-Systeme sind in der Regel auf veraltete Mechanismen zur Identitätsprüfung angewiesen:

• Lokale Benutzerkonten: Die Benutzer verwalten für jede einzelne App separate Zugangsdaten, was den Verwaltungsaufwand erhöht.
• LDAP-Authentifizierung: Die Systeme verbinden sich direkt über LDAP mit den Verzeichnissen, welches über keine modernen risikobasierten Funktionen verfügt.
• Headerbasierte Authentifizierung: Anwendungen vertrauen auf Benutzeridentitätsinformationen, die über HTTP-Header übermittelt werden. Ungesicherte HTTP-Header bergen daher ein Manipulationsrisiko.
• Windows-integrierte Authentifizierung: Diese Tools binden die Nutzer an bestimmte Netzwerk-Ökosysteme und behindern so die Migration in die Cloud.
• Formularbasierte Anmeldung: Einfache Benutzernamen- und Passwortformulare setzen Systeme der Gefahr von Credential-Stuffing-Angriffen aus.

Risiken veralteter Authentifizierungsmethoden

Das Festhalten an diesen Authentifizierungsmethoden birgt mehrere Haftungsrisiken für das Unternehmen:

• Passwortmüdigkeit: Die Verwaltung mehrerer Passwörter verleitet Mitarbeiter dazu, diese aufzuschreiben oder schwache Passwörter wiederzuverwenden.
• Schwache Sicherheitskontrollen: Viele ältere Anwendungen können dies nicht nativ erzwingen. Multi-Faktor-Authentifizierung (MFA) oder bedingter Zugriff.
• Fehlendes zentralisiertes Identitätsmanagement: IT-Administratoren können den Zugriff auf alle Anwendungen nicht sofort widerrufen, wenn ein Mitarbeiter das Unternehmen verlässt.
• Compliance-Herausforderungen: Wenn Zugriffe nicht zentral protokolliert und geprüft werden, wird es schwierig, behördliche Prüfungen zu bestehen.

Diese Einschränkungen machen eine moderne, zentrale Authentifizierungsebene erforderlich.

Was ist SAML-Authentifizierung?

Security Assertion Markup Language (SAML) ist ein XML-basierter offener Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten. Er ermöglicht SAML-SSO, sodass sich ein Benutzer einmal anmelden und auf mehrere unabhängige Systeme zugreifen kann.

Der Prozess beruht auf dem Vertrauensverhältnis zwischen drei zentralen SAML-Komponenten:

• Identitätsanbieter (IdP): Das zentrale System, das den Benutzer authentifiziert und seine Anmeldeinformationen überprüft, wie zum Beispiel Microsoft Entra-ID or Okta SSO.
• Dienstleister (SP): Die gehostete Anwendung oder der Dienst, der vor der Zugriffsgewährung eine Authentifizierung erfordert.
• SAML-Behauptungen: Sichere XML-Dokumente, die vom IdP an den SP gesendet werden und Benutzeridentitätsdaten sowie Autorisierungsberechtigungen enthalten.

Ein Benutzer kann sich beispielsweise bei Microsoft Entra ID anmelden. Der Identitätsanbieter (IdP) sendet daraufhin eine SAML-Assertion an den Dienstanbieter. Die Anwendung validiert die Assertion und erstellt eine Sitzung für den Benutzer.

Warum ältere Anwendungen SAML nicht nativ unterstützen

Die naheliegende Frage: Wenn die SAML-Integration so effektiv ist, warum nutzen ältere Anwendungen sie dann nicht einfach nativ?

Erstens wurden diese Legacy-Anwendungen lange vor der Etablierung von SAML als Industriestandard entwickelt. Sie basieren auf proprietären oder veralteten Authentifizierungsmethoden und bieten daher keinerlei integrierte Unterstützung für Föderationsprotokolle.

Darüber hinaus kann die Änderung von bestehendem Anwendungscode riskant sein, wenn man nicht über die ursprünglichen Entwickler oder zumindest die Dokumentation verfügt. Die Wahrscheinlichkeit, kritische Geschäftsfunktionen zu beeinträchtigen, ist hoch.

Aus diesem Grund ist die Verwendung einer externen Zugriffsschicht für SSO bei Legacy-Anwendungen die bessere Wahl, anstatt die Anwendung selbst zu modifizieren.

Möglichkeiten zum Hinzufügen der SAML-Authentifizierung zu älteren Anwendungen

Die Legacy-SAML-Authentifizierung lässt sich auf verschiedene Arten hinzufügen. Jeder Ansatz bietet ein ausgewogenes Verhältnis zwischen Entwicklungsaufwand und betrieblicher Komplexität.

1. Den Anwendungscode ändern

Sie können den Quellcode öffnen und native SAML-Integrationslogik in das System schreiben.

Vorteile:

• Unterstützt eine direkte SAML-Integration.
• Ermöglicht Ihnen die Kontrolle über das Verhalten der Anwendung.
• Kann detaillierte Attribut- und Rollenzuordnung unterstützen.

Nachteile:

• Erfordert Entwicklung, Tests und laufende Wartung.
• Kann für nicht unterstützte oder geschäftskritische Anwendungen riskant sein.
• Dies ist möglicherweise nicht möglich, wenn der Quellcode nicht verfügbar ist.
• Kann Modernisierungsprojekte für Altanwendungen verzögern.

Diese Option eignet sich in der Regel am besten, wenn die Anwendung aktiv gepflegt wird und Sie planen, sie langfristig zu behalten.

2. Verwenden Sie einen Reverse-Proxy.

Sie können einen Reverse-Proxy vor der Anwendung einsetzen, um den Webverkehr abzufangen. Der Proxy übernimmt den SAML-Handshake und leitet die Identitätsinformationen an die Backend-Anwendung weiter.

Vorteile:

• Kann den Bedarf an Änderungen am Anwendungscode verringern.
• Kann die Zugriffskontrolle am Anwendungsrand zentralisieren.
• Kann gut funktionieren für Webanwendungen, die vertrauenswürdige Header oder ein Upstream-Authentifizierungsmodell unterstützen.

Nachteile:

• Dadurch wird nicht automatisch jede Anwendung SAML-kompatibel.
• Die Anwendung muss die resultierende Authentifizierungsmethode akzeptieren können.
• Die Verarbeitung der Header muss sorgfältig abgesichert werden, um Spoofing zu verhindern.
• Das Sitzungsverhalten kann komplex werden, wenn sowohl der Proxy als auch die Anwendung Sitzungen verwalten.

Beispielsweise kann Microsoft Entra Application Proxy headerbasierte Authentifizierungsmuster für bestimmte lokale Webanwendungen unterstützen. In diesem Modell authentifiziert der Vermittler den Benutzer und übergibt die erforderlichen Header an die Anwendung.

3. Bereitstellung eines Zugriffsgateways

Das miniOrange Access Gateway fungiert als spezialisierter, identitätsbasierter Proxy. Es dient als dedizierter Vermittler zwischen modernen Identitätsanbietern (IdPs) und älteren Anwendungen.

Vorteile:

• Fügt SAML SSO und MFA hinzu, ohne dabei direkt Änderungen am Anwendungscode vorzunehmen.
• Zentralisiert Authentifizierungsrichtlinien für mehrere ältere Anwendungen.
• Sichere Anwendungen, die headerbasierte Authentifizierung, Cookies, Kerberos, Integrated Windows Authentication (IWA) und andere unterstützte Authentifizierungsmethoden verwenden.
• Lässt sich nahtlos in bestehende Identitätsquellen wie Active Directory, Google Workspace, OpenLDAP und die wichtigsten Identitätsanbieter integrieren.
• Kann lokale, kundenspezifische und vom Anbieter gehostete Webanwendungen unterstützen.
• Kann dabei helfen, einheitliche Zugriffsrichtlinien in älteren Systemen anzuwenden.

Wichtige Aspekte:

• Für die Erstimplementierung ist eine Planung von Zertifikaten, Netzwerkarchitektur und Anwendungsauthentifizierungsabläufen erforderlich.
• Unterschiedliche Anwendungen erfordern möglicherweise unterschiedliche Authentifizierungskonnektoren oder Integrationsmethoden.
• Vor der unternehmensweiten Einführung sollten Produktionsimplementierungen mit Pilotnutzern validiert werden.

Dieser Ansatz eignet sich häufig gut für Unternehmensumgebungen mit vielen älteren Anwendungen, die unterschiedliche Authentifizierungsmethoden verwenden. Mit miniOrange können Sie die Authentifizierung modernisieren und gleichzeitig Ihre bestehenden Verzeichnisse und Ihre Unternehmensidentitätsinfrastruktur weiter nutzen.

4. Erstellen Sie eine benutzerdefinierte Authentifizierungsbrücke

Sie können eine benutzerdefinierte Zwischenanwendung schreiben, die ein SAML-Token entgegennimmt und es in ein Format konvertiert, das das Altsystem versteht.

Vorteile:

• Kann hochgradig individualisierte Anwendungsanforderungen erfüllen.
• Kann funktionieren, wenn Standard-Proxy- oder Gateway-Muster nicht passen.
• Bestehende Anwendungsworkflows können beibehalten werden.

Nachteile:

• Erfordert individuelle Entwicklung und Wartung.
• Kann ein Sicherheitsrisiko darstellen, wenn Assertions, Sessions oder Header nicht korrekt behandelt werden.
• Die Unterstützung kann schwierig sein, wenn Entwickler das Unternehmen verlassen oder die Dokumentation unzureichend ist.

Nutzen Sie diese Option, wenn die Anwendung spezielle Anforderungen hat, die nicht durch eine unterstützte Gateway- oder Reverse-Proxy-Integration erfüllt werden können.

Schritt-für-Schritt-Anleitung zum Hinzufügen der SAML-Authentifizierung

Wenn Sie die Legacy-SAML-Authentifizierung ohne Programmierung realisieren möchten, folgen Sie dieser Standard-Bereitstellungssequenz:

Schritt 1: Bewerten Sie die bestehende Authentifizierungsmethode

Prüfen Sie die Anwendung, um herauszufinden, wie sie derzeit Benutzer validiert, ob über Header, vertrauenswürdige Header oder lokale Datenbanken.

Schritt 2: Wählen Sie einen SAML-Identitätsanbieter aus

Wählen Sie einen Cloud- oder On-Premises-IdP wie Microsoft Entra ID, Okta SSO oder Ping Identity.

Schritt 3: SAML-Integration konfigurieren

Richten Sie das Anwendungsprofil in Ihrer IdP-Konsole ein, indem Sie Entitäts-IDs und Endpunkte definieren.

Schritt 4: Benutzerattribute und Rollen zuordnen

Verknüpfen Sie Benutzerfelder aus Ihrem Verzeichnis (z. B. E-Mail-Adressen oder Mitarbeiter-IDs) mit den von der Zielanwendung benötigten Parametern.

Schritt 5: Vertrauensstellung zwischen Identitätsanbieter und Anwendung konfigurieren

Tauschen Sie kryptografische Zertifikate und Metadatendateien zwischen dem Identitätsanbieter (IdP) und Ihrem Proxy oder Gateway aus.

Schritt 6: Testen der Authentifizierungsabläufe

Führen Sie Testanmeldungen durch, um zu überprüfen, ob die Zusicherungen erfolgreich bestanden werden und die Benutzersitzungen korrekt initialisiert werden.

Schritt 7: Einführung in der Produktion

Verlegen Sie das Setup in den Produktionsbetrieb und leiten Sie den Live-Benutzerverkehr über den sicheren Authentifizierungspfad.

Bewährte Verfahren zur Implementierung der SAML-Authentifizierung

Beachten Sie diese Architekturrichtlinien, um eine sichere und reibungslose Bereitstellung der älteren SAML-Authentifizierung zu gewährleisten:

• Vermeiden Sie nach Möglichkeit Änderungen am Anwendungscode: Codeänderungen führen zu Fehlern und verlängern die Projektlaufzeiten. Verwenden Sie stattdessen Middleware.
• Planen Sie die Attributzuordnung sorgfältig: Nicht übereinstimmende Benutzernamen oder fehlende Rollenattribute führen dazu, dass berechtigte Benutzer vom System ausgeschlossen werden.
• Aktivieren Sie die Multi-Faktor-Authentifizierung: Kombinieren Sie Ihre SAML-Einführung mit MFA auf der IdP-Ebene, um sich gegen Credential-Angriffe zu schützen.
• Überwachung der Authentifizierungsprotokolle: Verfolgen und zentralisieren Sie Ihre Gateway-Protokolle, um Anomalien bei den Anmeldeinformationen oder Konfigurationsfehler frühzeitig zu erkennen.
• Testen von Failover-Szenarien: Richten Sie redundante Gateway-Instanzen ein, um die Verfügbarkeit von Anwendungen während eines Netzwerkausfalls aufrechtzuerhalten.
• Führen Sie eine stufenweise Einführung durch: Das neue Authentifizierungssystem sollte zunächst in kleinen Pilotgruppen eingeführt werden, bevor es unternehmensweit startet.

Häufige Herausforderungen und wie man sie überwindet

Die Integration moderner Identitätstools in ältere Architekturen deckt häufig technische Probleme auf. So lassen sie sich beheben:

Herausforderung: Anwendungen ohne SAML-Unterstützung

Lösung: Verwenden Sie einen dedizierten Übersetzungsproxy oder ein Gateway, um die modernen Protokolle im Namen der Anwendung zu verarbeiten.

Herausforderung: Probleme bei der Attributzuordnung

Lösung: Stellen Sie sicher, dass die Benutzeransprüche in Ihrem IdP-Format exakt mit den Header-Namen oder Datenbankwerten übereinstimmen, die die Anwendung erwartet.

Herausforderung: Konflikte aufgrund von Sitzungstimeouts

Lösung: Synchronisieren Sie die Sitzungslebensdauern Ihres Gateways, IdP und Ihrer Anwendung, um zu verhindern, dass Benutzer unerwartet abgemeldet werden.

Herausforderung: Herausforderungen bei der Benutzerbereitstellung

Lösung: Implementieren Sie automatisierte Bereitstellungstools oder Synchronisierungstools, um Benutzerkonten ohne manuelle Dateneingabe zu verwalten.

Herausforderung: Authentifizierungsschleifen

Lösung: Überprüfen Sie Ihre Weiterleitungs-URLs. Wenn die Anwendung die Proxy-Sitzung nicht erkennt, leitet sie den Benutzer immer wieder zum Identitätsanbieter zurück.

Herausforderung: Integration mit lokalem Active Directory

Lösung: Verwenden Sie moderne Hybrid-Verzeichniskonnektoren, um Ihre lokalen Konten sicher mit Cloud-IdPs zu synchronisieren.

Wie ein Access Gateway die SAML-Authentifizierung vereinfacht

Ein Access Gateway ermöglicht die Implementierung der herkömmlichen SAML-Authentifizierung, ohne dass die Anwendung selbst neu geschrieben werden muss. Sie benötigen keine Workarounds, da das Gateway die gesamte Abwicklung am Netzwerkrand übernimmt.

Dieses Modell unterstützt Folgendes:

• SAML-Integration mit Microsoft Entra ID, Okta SSO, Ping Identity, Google Workspace und anderen SAML-kompatiblen Identitätsanbietern
• Zentralisierte Authentifizierung für mehrere Legacy-Anwendungen
• MFA-Durchsetzung durch den IdP
• Unterstützung für lokale und kundenspezifische Webanwendungen
• Protokollübersetzung oder Authentifizierungsüberbrückung, sofern unterstützt
• Reduzierter Bedarf an Anwendungscodeänderungen

Beispielsweise kann miniOranges Access Gateway Ihnen dabei helfen, komplexe Anwendungen abzusichern. Sie können SSO für Anwendungen wie Oracle E-Business Suite , JD Edwards oder PeopleSoft aktivieren, ohne das zugrundeliegende System zu beeinträchtigen.

Fazit

Die Modernisierung Ihrer bestehenden Anwendungsauthentifizierung bedeutet nicht, dass Sie diese komplett ersetzen müssen. Das kann teuer und mit erheblichen Störungen verbunden sein.

Sie können SSO für ältere Anwendungen auf verschiedene Weise hinzufügen. Sie können den Anwendungscode ändern, einen Reverse-Proxy verwenden, ein Access Gateway bereitstellen oder eine benutzerdefinierte Authentifizierungsbrücke erstellen.

Ein Access Gateway bietet unter anderem eine praktische Möglichkeit, SAML SSO- und MFA-Kontrollen hinzuzufügen, ohne geschäftskritische Anwendungen neu schreiben zu müssen.

Erfahren Sie mehr darüber, wie die Legacy Apps SSO & MFA-Lösung von miniOrange Ihre Zugriffssicherheit noch heute modernisieren kann.

Häufig gestellte Fragen

Können ältere Anwendungen die SAML-Authentifizierung unterstützen?

Ja. Ältere Anwendungen können die SAML-Authentifizierung durch native SAML-Integration, Codeänderungen, einen Reverse-Proxy oder ein Access Gateway unterstützen. Kann die Anwendung SAML-Assertions nicht direkt verarbeiten, kann ein Access Gateway Benutzer über einen SAML-Identitätsanbieter authentifizieren und sie mithilfe einer unterstützten Authentifizierungsmethode mit der Anwendung verbinden.

Wie fügt man SAML zu einer bestehenden Anwendung hinzu?

Ermitteln Sie zunächst, wie die Anwendung Benutzer aktuell authentifiziert, z. B. über LDAP, Windows-integrierte Authentifizierung, lokale Konten, Header oder formularbasierte Anmeldung. Konfigurieren Sie anschließend einen SAML-Identitätsanbieter, ordnen Sie Benutzerattribute zu, stellen Sie eine Vertrauensstellung zur Anwendung oder zum Gateway her, testen Sie die Anmeldeabläufe und gewähren Sie den Zugriff schrittweise.

Lässt sich SAML implementieren, ohne den Anwendungscode zu ändern?

Sie können SAML-SSO hinzufügen, ohne den Anwendungscode zu ändern, indem Sie einen Reverse-Proxy oder ein Access Gateway vor die Anwendung schalten. Das Gateway übernimmt die SAML-Authentifizierung mit dem Identitätsanbieter und leitet die authentifizierten Benutzerdaten über eine kompatible Methode, wie z. B. Header, LDAP oder Kerberos, an die Anwendung weiter.

Wie lässt sich die Authentifizierung in Legacy-Anwendungen am besten modernisieren?

Die beste Vorgehensweise hängt von der aktuellen Authentifizierungsmethode der Anwendung und ihren technischen Beschränkungen ab. Für viele Organisationen ist ein Access Gateway eine praktikable Option, da es zentralisiertes Single Sign-On (SSO) und Multi-Faktor-Authentifizierung (MFA) ermöglicht, ohne dass Änderungen am Anwendungscode erforderlich sind. Außerdem können Sie damit ältere Anwendungen an einen modernen Identitätsanbieter anbinden.

Funktioniert SAML mit LDAP-Authentifizierung?

Ja, aber SAML ersetzt LDAP nicht in jeder Konfiguration. SAML übernimmt die Benutzerauthentifizierung über einen Identitätsanbieter, während LDAP weiterhin Benutzerverzeichnisinformationen speichern und validieren kann. Ein Zugriffsgateway oder eine Authentifizierungsbrücke kann SAML für die Anmeldung verwenden und eine Verbindung zu einer Anwendung herstellen, die weiterhin auf LDAP basiert.

Können ältere Anwendungen Microsoft Entra ID verwenden?

Ja. Ältere Anwendungen können Microsoft Entra ID über eine direkte SAML-Integration oder über einen Vermittler wie einen Reverse-Proxy oder ein Access Gateway nutzen. Der Vermittler authentifiziert Benutzer mit Microsoft Entra ID und verbindet sie über die unterstützte Authentifizierungsmethode mit der älteren Anwendung.

Kann ich MFA zu einer bestehenden Anwendung hinzufügen?

Ja. Sie können einer bestehenden Anwendung Multi-Faktor-Authentifizierung (MFA) hinzufügen, indem Sie MFA über den Identitätsanbieter oder ein Zugriffsgateway erzwingen. Benutzer müssen die MFA vor dem Zugriff auf die Anwendung durchführen, selbst wenn die bestehende Anwendung MFA nicht nativ unterstützt.