SAML ist nach wie vor einer der zentralen Standards für Unternehmensidentität — aber leicht fehlerhaft umgesetzt
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.
Unser Ansatz
Ein einziges AAM-Gateway terminiert SAML am Rand korrekt; der Rest der Zugriffs-Engine setzt darauf auf.
Standardkonformer SAML-2.0-Service-Provider
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.
IdP-Routing pro Anwendung und Tenant
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.
NameID- und Attribut-Mapping — auf die AAM-Sitzungs-Identität
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.
Koordiniert mit MFA, Conditional Access, Gerätevertrauen und Backend-SSO
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.
Fähigkeiten
Standardkonformer SAML-2.0-SP plus die operativen Funktionen, die Föderation im großen Maßstab sicher und verwaltbar machen.
SP-initiiertes SSO mit signierter AuthnRequest
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.
RelayState-bewusstes IdP-initiiertes SSO
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.
Vollständige Assertion-Validierung — Signatur, Audience, Gültigkeit, Restriction
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.
Optionale Assertion-Verschlüsselung mit privater Schlüsselverarbeitung
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.
NameID-Formatauswahl und Attribut-Mapping pro IdP
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.
IdP-Bindung pro Tenant für Multi-Tenant-Deployments
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.
Single Logout (SLO) koordiniert mit AAM-Sitzungsbereinigung
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.
Operative Tiefe
Die Mechanik, die eine SAML-Föderation sicher, aktuell und beobachtbar hält.
IdP-Metadaten-Austausch — Upload, Abruf per URL oder manuelle Konfiguration
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.
SP-Metadaten-Veröffentlichung für das IdP-Onboarding
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.
Rotation von Signaturschlüsseln und Zertifikaten ohne Unterbrechung
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.
Toleranz für Uhrenabweichung mit begrenztem Drift-Fenster
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.
Audit und Korrelation mit dem AAM-Sitzungslebenszyklus
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.
Welche Teams es nutzen
Behördliche Identitätsföderation
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.
Unternehmens-IdPs (AD FS, Entra ID, Okta, Ping, Auth0)
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.
Multi-Tenant-Deployments mit IdP pro Tenant
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.
Edge-MFA und Conditional Access über einem IdP, der MFA und Conditional Access nicht durchsetzt
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.
Häufig gestellte Fragen
Mit welchen IdPs föderiert AAM?
Wie verteidigt AAM gegen bekannte SAML-Angriffe?
Kann ein einziges AAM-Gateway unterschiedliche Tenants oder Anwendungen an unterschiedliche IdPs routen?
Unterstützt AAM Single Logout (SLO)?
Was passiert mit der Identität, nachdem AAM die Assertion konsumiert hat?
SAML richtig gemacht, am Rand
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.