Moderne Identität: SAML, OIDC und hybride Ansätze

Security Assertion Markup Language 2.0 (SAML) ist ein XML-basierter offener Standard für Single Sign-On in Unternehmensumgebungen. SAML wurde 2005 standardisiert und ermöglicht es einem Identity Provider (IdP), digital signierte XML-Assertionen an Service Provider (SPs) auszustellen. Dadurch können sich Benutzer einmal authentifizieren und auf mehrere Dienste zugreifen, ohne ihre Anmeldedaten erneut einzugeben.

Bei SAML ist der Identity Provider (IdP) die Instanz, die Benutzer authentifiziert und Assertionen ausstellt. Beispiele sind Okta, Microsoft Entra ID und PingFederate. Der Service Provider (SP) ist die Anwendung, die sich auf die Assertion des IdP verlässt. Beispiele sind Salesforce, Workday und ServiceNow. Der SP vertraut der Signatur des IdP, um den Zugriff zu gewähren.

SAML-Assertionen müssen vom IdP mithilfe eines RSA- oder EC-Schlüsselpaares digital signiert werden, damit der SP ihre Authentizität überprüfen kann. Assertionen können außerdem für die Vertraulichkeit während der Übertragung verschlüsselt werden. Der SP muss die Signatur validieren, die Zeitstempel NotBefore und NotOnOrAfter prüfen und die Audience-Beschränkung überprüfen, um Replay-Angriffe zu verhindern.

OpenID Connect (OIDC) ist eine moderne Identitätsschicht auf Basis von OAuth 2.0, die denselben SSO-Zweck wie SAML erfüllt, jedoch JSON und JWTs statt XML verwendet. OIDC wurde 2014 veröffentlicht und eignet sich besser für mobile Apps, Single-Page-Anwendungen und REST-APIs, während SAML in traditionellen Webanwendungen von Unternehmen weiterhin vorherrschend ist.

OIDC erweitert OAuth 2.0, indem es dem Autorisierungsablauf von OAuth 2.0 ein ID-Token (ein JWT mit Identitäts-Claims) hinzufügt. OAuth 2.0 übernimmt die Autorisierung (delegierten Zugriff auf APIs), während OIDC die Authentifizierung ergänzt (die Überprüfung der Benutzeridentität). OIDC erfordert den Scope openid und gibt neben dem OAuth-Access-Token auch ein ID-Token zurück.

Microsoft Entra ID (früher Azure Active Directory) ist ein cloudnativer Identity Provider, der sowohl SAML als auch OIDC/OAuth 2.0 für föderiertes SSO unterstützt. Über Entra Connect kann es mit lokalem Active Directory synchronisiert werden. So entsteht ein hybrides Identitätsmanagement, bei dem Cloudressourcen und lokale Ressourcen ein gemeinsames Identitätsverzeichnis nutzen.

Active Directory Federation Services (AD FS) ist der lokale Föderationsserver von Microsoft, der SAML- und WS-Federation-Endpunkte für lokales Active Directory bereitstellt. AD FS verbindet ältere SAML-basierte Anwendungen mit Active-Directory-Anmeldedaten. In hybriden Bereitstellungen wird AD FS mit Entra ID föderiert, um SSO auf Cloudanwendungen auszuweiten.

System for Cross-domain Identity Management (SCIM) ist ein REST-API-Standard zur Automatisierung der Provisionierung und Deprovisionierung von Benutzern über Identitätssysteme und Anwendungen hinweg. Wenn ein neuer Mitarbeiter zu Entra ID oder Okta hinzugefügt wird, erstellt SCIM automatisch entsprechende Konten in verbundenen SaaS-Anwendungen und entfernt sie, wenn der Mitarbeiter das Unternehmen verlässt.

Moderne Identity Provider implementieren Richtlinien für bedingten Zugriff, die vor der Zugriffserteilung Risikosignale wie Gerätekonformität, Standort und Benutzerverhalten auswerten. Diese Richtlinien können für sensible Ressourcen eine verstärkte Multi-Faktor-Authentifizierung verlangen. In Kombination mit OIDC- oder SAML-SSO ermöglicht der bedingte Zugriff adaptive Sicherheit ohne zusätzlichen Aufwand durch wiederholte Authentifizierung.

Eine Zero-Trust-Architektur behandelt den Netzwerkstandort als irrelevant für Zugriffsentscheidungen: Es wird kein implizites Vertrauen gewährt, nur weil sich ein Benutzer innerhalb des Unternehmensnetzwerks befindet. Anstelle der Kerberos-Authentifizierung am Perimeter verwendet Zero Trust eine kontinuierliche Identitätsprüfung, Überprüfungen des Gerätezustands und Richtlinien für den Zugriff mit geringsten Berechtigungen, die bei jeder Zugriffsanforderung auf eine Ressource über OIDC oder SAML durchgesetzt werden.

Verwenden Sie SAML für ältere Unternehmensanwendungen, die vor 2014 entwickelt wurden und SAML bereits unterstützen. Verwenden Sie OIDC für neue Anwendungen, mobile Apps, SPAs und APIs. Beide Protokolle werden von wichtigen IdPs unterstützt. Daher hängt die Wahl häufig von der vorhandenen Unterstützung der Anwendung und nicht von Sicherheitsunterschieden ab. Für alle neuen Entwicklungen wird OIDC bevorzugt.

Welche Aussage beschreibt einen wichtigen Unterschied zwischen SAML und OIDC korrekt?

SAML 2.0 bietet XML-basiertes SSO für traditionelle Unternehmensanwendungen. OIDC ergänzt OAuth 2.0 um Identität, verwendet dafür JWT-Token und wird für moderne Anwendungen bevorzugt. Entra ID unterstützt beide Protokolle als hybrider Cloud-IdP. AD FS verbindet lokales AD mit SAML-basierten Anwendungen. SCIM automatisiert die Provisionierung. Zero Trust ersetzt das Kerberos-Modell mit Perimetervertrauen durch eine kontinuierliche, richtliniengesteuerte Identitätsprüfung.