Viele Anwendungen in einem Unternehmen — interne Portale, Abrechnungssysteme, Betriebskonsolen, vom Hersteller bereitgestellte Admin-Panels, ältere Geschäftsanwendungen — wurden gebaut, bevor SAML oder OIDC zum Standard wurden. Sie erkennen den Benutzer typischerweise nicht über moderne Tokens, sondern über einen HTTP-Header, eine Basic-Auth-Zugangsdaten oder ein Session-Cookie, dem sie bereits vertrauen.
Diese Anwendungen auf modernes SSO zu migrieren klingt in der Theorie einfach: den Backend-Authentifizierungspfad neu schreiben, SAML/OIDC-Unterstützung hinzufügen und die Anwendung mit dem zentralen Identity Provider verbinden. In der Praxis geschieht dies fast nie. Der Quellcode kann veraltet sein, die Anwendung kann einem Hersteller gehören, die Änderung kann einen regulierten Workflow unterbrechen, oder der Aufwand ist für ein internes Tool, das funktioniert, schlicht nicht gerechtfertigt.
Organisationen stehen dann vor der Wahl zwischen zwei schlechten Optionen: Legacy-Anwendungen außerhalb des modernen Identitätsperimeters zu lassen oder für jede eine separate, fragile Integration aufzubauen. Das Endergebnis ist ein fragmentiertes Benutzererlebnis, dezentralisierte Zugriffskontrolle und Identitätslogik, die über das Legacy-Modell jedes Backends verstreut ist.
Der richtige Ansatz ist, die moderne Zugriffsschicht vor der Anwendung zu positionieren. Der Benutzer passiert zuerst zentrale Identität, MFA, bedingten Zugriff und Gerätevertrauensprüfungen; die verifizierte Identität wird dann in eine Form übersetzt, die das Backend bereits versteht. Die Anwendung erhält ein modernes SSO-Erlebnis ohne Code-Änderung.
Aber dieser Übergang muss sorgfältig durchgeführt werden. Wenn gefälschte Identitäts-Header vom Benutzer an das Backend weitergeleitet werden, ohne entfernt zu werden, kann jeder seinen eigenen X-Auth-User-Header zu seiner Anfrage hinzufügen und sich als ein anderer Benutzer ausgeben. Das Gateway muss nicht vertrauenswürdige eingehende Werte entfernen, nur die von ihm selbst produzierte vertrauenswürdige Identität injizieren und dies strikt pro Route begrenzen.
Logout, Session-Verlust und Backend-gesteuerte Identitätszustände müssen ebenfalls durch dieselbe Engine fließen. Andernfalls kann der Benutzer am Portal ausgeloggt erscheinen, während die Backend-Session aktiv bleibt, oder die Backend-Session kann wegfallen, ohne dass die Zugriffsschicht es bemerkt.
Backend SSO geht nicht darum, Legacy-Anwendungen zum Neuschreiben zu zwingen — es geht darum, moderne Identitätskontrolle vor die Anwendung zu stellen und die verifizierte Benutzeridentität sicher in die Sprache zu übersetzen, die das Backend bereits akzeptiert.
Ein Konfigurationsobjekt pro Backend, fünf Injektionsformen, koordiniert mit dem Rest der Zugriffs-Engine.
Jede Injektionsregel entfernt zunächst jede eingehende Kopie des Ziel-Headers, Cookies oder Authorization-Werts und injiziert dann die aus der verifizierten Session abgeleitete Version. Ein Benutzer, der seinen eigenen "X-Auth-User" sendet, kann sich nicht als jemand anderes ausgeben — sein Header wird entfernt, bevor das Gateway den vertrauenswürdigen hinzufügt.
Benutzerdefinierte Header (X-Auth-User, X-Forwarded-User oder was das Backend erwartet), Authorization Basic für Anwendungen, die ein Benutzername:Passwort-Paar wollen, Authorization Bearer für Token-freundliche Backends, Cookie-Wert-Zusammenführung für Anwendungen, die ein benanntes Cookie lesen, und SAML-SP für Backends, die eine signierte SAML-Assertion erwarten. Jede Injektion hat ihre eigene Konfiguration; ein Backend kann mehrere Formen gleichzeitig verwenden.
Jede Injektionsregel trägt ihren eigenen Bedingungsausdruck — nur auf dem Admin-Pfad anwenden, nur wenn ein bestimmtes Session-Attribut vorhanden ist, nur für einen Tenant. Dasselbe Backend kann auf privilegierten Routen eine umfangreichere Identität und auf öffentlichen Routen eine minimale Teilmenge erhalten.
Wenn das Backend meldet, dass die Session des Benutzers weg ist (eine bekannte Antwortform pro Service), oder wenn das Backend selbst den Benutzer ausloggt, erkennt AAM das Signal, bereinigt die Gateway-seitige Session und leitet gemäß der konfigurierten Policy weiter. Logout-Wins-Vorrang stellt sicher, dass die Bereinigung immer vor weiteren Injektionen ausgeführt wird.
Fünf produktive Injektionsformen, die Input-Stripping-Disziplin, die sie sicher macht, sowie die Roadmap für Injektionen auf höheren Protokollebenen.
Die einfachste und häufigste Form. Einen Header-Namen konfigurieren (X-Auth-User, X-Forwarded-User, REMOTE_USER — was das Backend auch liest) und die Smart-Variable auswählen, die den Wert produziert (Benutzername, E-Mail, Gruppenliste, Anzeigename). Der Header wird aus eingehenden Anfragen entfernt und dann aus der verifizierten Session wieder hinzugefügt — bevor die Anfrage das Backend erreicht.
Für Legacy-Anwendungen, die sich über HTTP Basic authentifizieren, injiziert das Gateway Authorization: Basic
Für Backends, die bereits Bearer-Tokens sprechen (interne APIs, Microservices, moderne Intranet-Anwendungen), injiziert AAM Authorization: Bearer
Anwendungen, die Identität aus einem benannten Cookie lesen, werden mit Cookie-Wert-Injektion bedient. Das Gateway fügt das injizierte Name=Wert-Paar in den Cookie-Header der Anfrage ein, ohne andere Cookies zu überschreiben — die fehleranfälligste der vier Header-Style-Formen, verarbeitet mit expliziter Zusammenführungslogik statt naiver Überschreibung.
Für Backends, die bei jeder Anfrage eine signierte SAML-Assertion erwarten, erstellt das Gateway eine SAML 2.0-Assertion aus der verifizierten Session, signiert sie mit AAMs SAML-Signaturschlüssel und leitet sie über den konfigurierten Header an das Backend weiter. Typisch für Identitätsföderation-Integrationen im öffentlichen Sektor und Enterprise-SaaS-Backends. Der Benutzer meldet sich mit einem modernen IdP an; das Backend erhält bei jeder Anfrage eine frische, begrenzte SAML-Assertion.
Jede Injektion ist mit einem eingehenden Strip desselben Ziels gekoppelt. Ein Benutzer, der X-Auth-User in seiner eigenen Anfrage setzt, der ein gefälschtes Cookie mit einem manipulierten Identitätswert sendet oder der einen Authorization-Header von woanders wiedergibt, kann den Wert nicht am Gateway vorbeibringen. Die Injektion läuft nur, nachdem der Strip den Slot geleert hat.
Jede Injektionsregel kann eine Bedingung hinzufügen — dieselbe Ausdruckssprache wie die Richtlinie für bedingten Zugriff. Nur auf dem Admin-Pfad injizieren; nur injizieren, wenn der Benutzer in einer bestimmten Gruppe ist; nur die privilegierte Variante injizieren, wenn ein Attribut vorhanden ist. Bedingungen werden ACL-Vorrang-sicher kompiliert, sodass mehrere Regeln auf einem Backend korrekt kombiniert werden.
Alle Injektionen sind hinter dem verifizierten Zustand gesichert — sie laufen nur, wenn die Anfrage eine gültige AAM-Session trägt. Ein Benutzer, der die Authentifizierung über eine falsch konfigurierte Route umgeht, kann nicht versehentlich injizierte Backend-Zugangsdaten erhalten; eine anonyme Anfrage erreicht das Backend immer ohne Injektion.
Injektionsformen auf höherer Protokollebene — Kerberos Constrained Delegation für Backends, die ein Service-Ticket benötigen, NTLM für ältere Windows-Umgebungen — sind auf der Roadmap. Das Konfigurationsobjekt und die bedingte Infrastruktur unterstützen sie bereits; die protokollspezifische Runtime ist die verbleibende Arbeit.
Die Mechanismen, die Header-Grade-Injektion am Zugriffs-Edge sicher machen.
Bedingungen pro Injektion werden mit den anderen ACL-gesteuerten Entscheidungen des Gateways (Authentifizierungsstatus, Zugriffsrichtlinie, Backend-Auswahl) kombiniert. Der Bedingungscompiler verwendet ein Extra-Entries-Muster, sodass Injektionsbedingungen immer nach Authentifizierung und Richtlinie ausgewertet werden, nie davor — eine Injektionsregel kann nicht versehentlich das Ergebnis einer höher priorisierten Richtlinienentscheidung umkehren.
Wenn eine Injektion einen Wert benötigt, der nicht im Session-Bag ist — ein aus einem Per-Request-Abruf abgeleiteter Wert (Gruppenerweiterung, Attribut-Lookup) — gibt der Dispatcher einen bedingten Abruf aus, der nur dann ausgeführt wird, wenn die Bedingung der Injektion übereinstimmt. Backends, die niemals eine Injektion sehen, zahlen niemals die Kosten für das Abrufen des Werts.
Jeder Service kann die Antwortsignatur deklarieren, die "meine Session ist weg" bedeutet — einen bestimmten Status-Code, einen bestimmten Antwort-Header, einen Body-Marker. Wenn das Gateway diese Signatur sieht, setzt es ein Session-Verlust-Flag, bereinigt die Gateway-seitige Session und leitet gemäß der konfigurierten Richtlinie weiter.
Wenn das Backend selbst den Benutzer ausloggt — typischerweise durch Antworten mit einer bekannten Logout-Signatur — führt das Gateway eine dreistufige Bereinigung durch: Gateway-seitige Cookies löschen, Session-Datensatz löschen und über das konfigurierte Ziel weiterleiten. Logout-Wins-Vorrang stellt sicher, dass dieser Pfad jede im Flug befindliche Injektion schlägt.
Von Injektionen verwendete Zugangsdaten und Tokens werden verschlüsselt im Konfigurationsspeicher abgelegt und niemals im Klartext in Zugriffs-Logs geschrieben. Audit-Einträge verzeichnen, dass eine Injektion bei einer Anfrage ausgeführt wurde, nicht welchen Wert sie trug. Operatoren sehen die Richtlinie; der Draht-Payload bleibt auf dem Draht.
Ein stiller Re-Auth-Flow, der eine 302-Weiterleitung zum AAM-Daemon nutzt, um eine Backend-Session neu aufzubauen, ohne den Benutzer auf eine Login-Seite zu schicken, ist auf der Roadmap. AAM-initiierte Logout-Weitergabe — das Weiterleiten eines Logout-Signals an jedes Backend, das eine injizierte Identität erhalten hat — ist ebenfalls auf der Roadmap.
Ein internes Portal, das seit einem Jahrzehnt X-Remote-User vertraut, liest weiterhin X-Remote-User. Das Gateway betreibt modernes SAML/OIDC am Edge und injiziert dann denselben Header, den das Portal immer gesehen hat. Kein Backend-Deploy, kein Migrations-Cutover.
Ein Cluster interner Microservices möchte Bearer-Token-Authentifizierung, will aber keinen Identitätsflow pro Service betreiben. Das Gateway stellt pro Anfrage einen signierten Token aus und injiziert ihn; jeder Service verifiziert den Token gegen die Schlüssel des Gateways.
In einem Multi-App-Deployment will eine Anwendung Basic Auth, eine will einen benutzerdefinierten Header, und eine will ein Cookie. Ein AAM-Gateway behandelt das Login einmal; jedes Backend bekommt die erwartete Form, gleichzeitig, mit Per-Route-Bedingungen.
Compliance-Regimes, die eine klare Identitätskette erfordern — "wer war authentifiziert, als diese Anfrage das Backend traf" — erhalten diese Kette aus dem Audit-Stream des Gateways. Header-Werte, Injektionsbedingungen und das verifizierte Subjekt werden zusammen aufgezeichnet.
Wir deployen Backend SSO gegen Ihre echten Anwendungen — mit Beibehaltung der bestehenden Vertrauensmodelle, Entfernung der Zugangsdaten aus den Händen des Benutzers und Erzeugung einer Audit-fähigen Identitätskette für jede Anfrage.