Auch wenn OIDC in modernen Anwendungen zunehmend genutzt wird, ist SAML 2.0 bei Unternehmens- und Behörden-Identitätsintegrationen nach wie vor ein kritischer Standard. Viele Organisationen betreiben ihre bestehenden Verzeichnisse hinter AD FS, Entra ID, Okta, Ping, Auth0 oder einem Föderations-Gateway über SAML. Auch auf der Behördenseite sind nationale Identitätsföderationen und die daran angebundenen SaaS-Dienste häufig auf SAML 2.0 aufgebaut.
Deshalb ist der richtige Ansatz für eine neue oder modernisierte Anwendung nicht, eine separate Benutzerdatenbank zu erstellen. Die Anwendung sollte sich mit dem Identitätsprovider verbinden, dem die Organisation bereits vertraut. Dafür muss die Zugriffsschicht als SAML-2.0-Service-Provider agieren: den Benutzer an den richtigen IdP routen, die eingehende SAML-Antwort verifizieren, die Identität sicher extrahieren und sie in eine Sitzung übersetzen, die die Anwendung nutzen kann.
SAML-Integration ist jedoch nicht nur ein „XML abrufen, Benutzer lesen, Sitzung öffnen"-Vorgang. Falsch umgesetzt erzeugt sie schwerwiegende Sicherheitslücken. Die Signatur in der SAML-Antwort muss korrekt verifiziert, geprüft werden, welches Element tatsächlich signiert wurde, und Angriffe wie Signature Stripping oder das Einfügen gefälschter Assertions müssen verhindert werden. Gültigkeitsdauer, Audience-Restriction, Issuer-Information, NameID-Format und Attribut-Mappings dürfen nicht nur gelesen, sondern müssen strikt durchgesetzt werden.
Die operative Seite ist ebenso wichtig. Das Aktualisieren der IdP-Metadaten, die Rotation von Zertifikaten und Signaturschlüsseln, unterschiedliches IdP-Routing pro Tenant, unterschiedliche Mapping-Regeln für unterschiedliche Anwendungen und Single-Logout-Flows sind keine nachträglich hinzugefügten Kleinigkeiten. Sie sind grundlegende Bestandteile dafür, dass die SAML-Föderation sicher und nachhaltig läuft.
Einer der häufigsten Fehler ist, in jede Anwendung separat eine SAML-Bibliothek einzubetten. Dieser Ansatz verteilt die Identitätsverantwortung auf jedes Backend. Eine IdP-Änderung erfordert separate Aktualisierungen in zahlreichen Anwendungen. MFA, Conditional Access, Gerätevertrauen, Logout-Verhalten und Audit-Aufzeichnungen werden für jede Anwendung neu zu lösen versucht. Das Ergebnis ist keine zentrale Identität, sondern verteiltes Identitätschaos.
Der richtige Ort ist der Zugriffsrand. SAML sollte an einem einzigen Punkt terminiert und auf derselben Schicht wie Authentifizierung, MFA, Conditional Access, Gerätevertrauen und Backend-SSO verwaltet werden. So tragen Anwendungen nicht die Komplexität des Föderationsprotokolls; sie erhalten nur eine verifizierte, saubere und vertrauenswürdige Identität.
SAML richtig zu verwalten heißt nicht nur, sich mit einem IdP zu verbinden. Es heißt, das Identitätsvertrauen der Organisation an einem einzigen Punkt zu verifizieren, zu auditieren und sicher zu den Anwendungen zu transportieren.
Ein einziges AAM-Gateway terminiert SAML am Rand korrekt; der Rest der Zugriffs-Engine setzt darauf auf.
Signierte AuthnRequest beim Ausgang, vollständige Assertion-Validierung beim Eingang — Signatur, Audience, Gültigkeitsfenster, AudienceRestriction, NameID-Format. Sowohl HTTP-Redirect- als auch HTTP-POST-Bindings werden unterstützt. Die Signaturverarbeitung folgt den bestehenden SAML-2.0-Konformitätsregeln, um bekannte SAML-Angriffe zu vereiteln.
Ein einziges AAM-Gateway kann unterschiedliche Anwendungen an unterschiedliche IdPs und unterschiedliche Tenants derselben Anwendung gleichzeitig an unterschiedliche IdPs routen. Die IdP-Auswahl erfolgt pro Anfrage aus dem Anwendungskontext — kein separates Gateway pro IdP, keine manuelle Login-Seiten-Auswahl für den Benutzer.
Mapping-Regeln pro IdP übersetzen die NameID der SAML-Assertion und die Attributaussagen in die kanonischen Felder, die der Rest von AAM verwendet — Benutzername, E-Mail, Gruppen, Anzeigename, benutzerdefinierte Attribute. Dasselbe Mapping speist MFA-Gating, Conditional-Access-Ausdrücke, Audit-Logs und Backend-SSO-Injektionen.
Eine SAML-Authentifizierung läuft nicht allein — sie wird mit Edge-MFA (falls der IdP keinen Step-up durchgesetzt hat), Conditional-Access-Ausdrücken, kontinuierlicher Vertrauensbewertung und Backend-SSO-Injektion zum Backend hin orchestriert. Die SAML-Assertion wird zu einem Input für die AAM-Sitzung; sie wird nicht zur gesamten Sitzung.
Standardkonformer SAML-2.0-SP plus die operativen Funktionen, die Föderation im großen Maßstab sicher und verwaltbar machen.
Der Benutzer kommt zur Anwendung, AAM leitet mit einer signierten SAML-AuthnRequest zum konfigurierten IdP weiter, der Benutzer meldet sich beim IdP an, und der IdP gibt die signierte Assertion an den Assertion-Consumer-Service-Endpoint von AAM zurück. Für die ausgehende Anfrage wird das HTTP-Redirect-Binding und für die eingehende Assertion das HTTP-POST-Binding unterstützt.
Für Deployments, bei denen der Ausgangspunkt des Benutzers der IdP ist — eine Portal-Startrampe im IdP, ein Anwendungskatalog, ein behördliches Identitätsportal — wird IdP-initiiertes SSO akzeptiert. Der RelayState trägt das anvisierte Anwendungsziel; so landet der Benutzer nach dem Konsum der Assertion auf der richtigen Seite.
Die Signatur der Assertion wird gegen das konfigurierte IdP-Signaturzertifikat verifiziert; die Audience stimmt mit der konfigurierten AAM-SP-Kennung überein; NotBefore und NotOnOrAfter legen das Gültigkeitsfenster fest; AudienceRestriction wird durchgesetzt. Bekannte SAML-Angriffe (Signature Wrapping, Signature Stripping, NotBefore-Drift) werden ausdrücklich vereitelt, statt stillschweigend toleriert zu werden.
Wenn der IdP die Assertion verschlüsselt (xmlenc), entschlüsselt AAM die Assertion vor der Validierung mit dem konfigurierten privaten SP-Schlüssel. Verschlüsselte Assertions sind bei behördlicher Identitätsföderation und bei IdPs üblich, die nicht wollen, dass der Assertion-Inhalt auf der Binding-Schicht lesbar ist. Verschlüsselungsschlüssel werden verschlüsselt im Konfigurationsspeicher abgelegt und niemals protokolliert.
Jeder IdP kann mit einem bevorzugten NameID-Format (persistent, transient, email-address, unspecified) und einem Mapping von SAML-Attributnamen auf AAM-Sitzungsfelder konfiguriert werden. Unterschiedliche IdPs können die Identität unterschiedlich darstellen — ein nationaler Identitäts-Claim, eine E-Mail, eine eindeutige opake Kennung — und dennoch dasselbe kanonische AAM-Sitzungsformat erzeugen.
Ein einziges AAM-Gateway, das viele Tenants vorgelagert hält, kann jeden Tenant an seinen eigenen IdP routen. Die Auswahl erfolgt zur Anfragezeit aus dem Anwendungs- oder Tenant-Kontext — kein separates Gateway pro IdP, kein Selektor pro Benutzer. Dasselbe Gateway kann für einen Tenant eine behördliche Identitätsföderation und für einen anderen Tenant einen privaten Unternehmens-IdP gleichzeitig bedienen.
Wenn der IdP einen Logout startet, akzeptiert AAM die SAML-LogoutRequest, beendet die AAM-Sitzung und signalisiert dies an die Backends, die Backend-SSO-Injektion erhalten. Wenn die Anwendung den Logout startet, sendet AAM eine signierte LogoutRequest zum IdP hin und wartet auf die LogoutResponse, bevor es die Sitzung für beendet erklärt. Front-Channel-SLO wird unterstützt.
Back-Channel-SOAP-basiertes Single Logout, das SAML-ECP-Profil (Enhanced Client/Proxy) für nicht browserbasierte Clients und Holder-of-Key-Subject-Confirmation für Hochsicherheitsintegrationen sind auf der Roadmap. Das Konfigurationsobjekt und der Rest der SP-Pipeline bedienen diese bereits; was fehlt, ist der protokollspezifische Code.
Die Mechanik, die eine SAML-Föderation sicher, aktuell und beobachtbar hält.
Die IdP-Metadaten können durch Hochladen des vom IdP bereitgestellten Metadaten-XML, durch Konfigurieren einer Metadaten-URL, die AAM abruft und zwischenspeichert, oder durch manuelle Eingabe von Endpoints und Zertifikaten geladen werden. Die manuelle Konfiguration ist die realistische Option für IdPs, die keine standardkonformen Metadaten veröffentlichen; wo sie funktionieren, sind die beiden anderen Methoden vorzuziehen.
AAM veröffentlicht sein eigenes SP-Metadaten-Dokument unter einer stabilen URL; so kann der IdP-Operator es in den Vertrauensspeicher des IdP aufnehmen, statt Endpoints und Zertifikate manuell zu übertragen. Die Metadaten spiegeln die Live-SP-Konfiguration wider — aktuelle ACS-URL, aktuelles Signaturzertifikat, aktueller SLO-Endpoint.
SP-Signaturschlüssel und -Zertifikate haben eine begrenzte Lebensdauer. AAM unterstützt die Schlüsselrotation mit Überlappung — während des Rollover-Fensters werden sowohl der alte als auch der neue Schlüssel gegen die zwischengespeicherten Metadaten des IdP verifiziert. Operatoren planen die Rotation im Voraus; die Runtime akzeptiert während der Überlappungszeit beide, und die Rotation greift sauber.
Assertions tragen NotBefore- und NotOnOrAfter-Zeitstempel. Reale Uhren driften; AAM wendet ein konfigurierbares Toleranzfenster an; so lehnt eine kleine Abweichung keine gültigen Assertions ab, während große Abweichungen (ein Indikator für Fehlkonfiguration oder Replay) dennoch abgelehnt werden. Die Toleranz gilt pro IdP; ein gut synchronisierter IdP erhält ein enges Fenster, ein problematischer IdP einen dokumentierten Spielraum.
Jedes SAML-Ereignis — ausgehende AuthnRequest, eingehende Assertion, Ergebnis der Signaturprüfung, SLO-LogoutRequest, LogoutResponse — wird mit einer Korrelations-ID protokolliert, die auf die AAM-Sitzung, das/die dahinterliegende(n) Backend(s) und die Benutzeridentität zurückverweist. Die Frage „Wer hat sich wann über welchen IdP angemeldet?" wird mit einer einzigen Abfrage beantwortet.
Periodischer automatischer Refresh der IdP-Metadaten von der konfigurierten URL, Diff-Erkennung und eine Warnung an den Operator bei Änderungen des Signaturzertifikats sind auf der Roadmap. Rotations-Telemetrie — Metriken zum Schlüsselalter, Warnung zu den verbleibenden Tagen bis zum Ablaufdatum, automatische Rollover-Planung — ist ebenfalls geplant.
Anwendungen, die einen nationalen Identitätsföderations-IdP akzeptieren müssen — typisch für Behörden-Deployments, regulierte Branchen und an öffentliche Auftraggeber vertraglich gebundene SaaS-Dienste. AAM terminiert die SAML-Föderation am Rand und präsentiert der dahinterliegenden Anwendung eine saubere, verifizierte Identität.
Bestehende Unternehmens-IdPs, die für die Belegschaft bereits autoritativ sind. AAM klinkt sich als SAML-SP ein, ohne vom IdP-Team irgendeine Änderung zu verlangen. Neue Anwendungen treten der Föderation bei, indem sie einen Eintrag in AAM hinzufügen — nicht indem sie jeder Codebasis eine neue SAML-Bibliothek hinzufügen.
SaaS-Anwendungen, bei denen jeder Kunde seinen eigenen IdP mitbringt. Ein einziges AAM-Gateway hält alle Tenants vorgelagert; der Verkehr jedes Tenants wird an den IdP dieses Tenants geroutet. Einen Tenant hinzuzufügen bedeutet, einen IdP-Eintrag im Konfigurationsspeicher hinzuzufügen — kein Deployment.
Manche IdPs authentifizieren, setzen aber Step-up-MFA oder Conditional Access nicht durch — insbesondere ältere Föderations-Gateways. AAM akzeptiert die Authentifizierung des IdP, setzt dann seine eigene MFA, Conditional-Access-Ausdrücke und kontinuierliche Vertrauensbewertung darauf auf, bevor es Zugriff auf die Anwendung gewährt.
Lassen Sie uns AAM mit Ihrem IdP verbinden — Unternehmen oder behördliche Identitätsföderation — und den Rest der Zugriffs-Engine mit MFA, Conditional Access, Gerätevertrauen und Backend-SSO auf der Assertion aufsetzen.