SAML (SAML 1.0 und 2.0) und OpenID Connect (OIDC) sind zwei Identitätsprotokolle für die Authentifizierung von Nutzern und die Bereitstellung von Identitätsdaten für die Zugriffskontrolle. SAML und OIDC bilden außerdem eine Methode, die Identität eines Nutzers zu kommunizieren. Jedes der Protokolle kann die Grundlage für Identitätsanbieter (IdPs) verschiedener Identitätsmanagementlösungen und -dienste sein und für Single-Sign-on-Anwendungen genutzt werden.

Der hauptsächlich für Unternehmens- und Regierungsanwendungen genutzte Standard SAML 2.0 ist eine ausgereifte Technologie aus dem Jahr 2005, die zahlreiche Identitätsfunktionen unterstützt. SAML nutzt das XML-Format für Identitätsdaten und Simple HTTP oder SOAP für die Datenübertragung. Der Dienst, der die Daten beim IdP anfragt und von diesem empfängt, wird als Relying Party (RP) bezeichnet. Die Nutzeridentitätsdaten, die in einem XML-Dokument namens SAML-Assertion enthalten sind, haben die Form von Attributen, z. B. E-Mail-Adresse, Name, Telefonnummer usw.

SAML kann einen Mechanismus für eine föderierte Identität bereitstellen.

Bevor ein Serviceprovider bzw. eine Relying Party mit einem IdP zwecks Authentifizierung kommunizieren kann, müssen zwischen der RP und dem IdP Metadaten ausgetauscht werden. Diese im XML-Format vorliegenden Metadaten spezifizieren Endpunkte, Signatur- und Verschlüsselungszertifikate, unterstützte Verbindungsverfahren, Attributformate usw., die beide Seiten der SAML-Verbindung voneinander kennen müssen. Die Parteien nutzen dann jeweils die Metadaten der anderen Partei, um ihre Seite des Systems zu konfigurieren.

Um einen Nutzer zu authentifizieren, stellt die RP eine Authentifizierungsanfrage (SAML AuthnRequest) an den IdP und nutzt dafür entweder einen HTTP Form-POST (POST-Binding) oder eine Redirect Query String (Redirect-Binding). Diese Anfrage wird normalerweise von der RP signiert.

Der IdP verifiziert die Anfrage, authentifiziert den Nutzer und sendet eine SAML-Antwort, die die SAML-Assertion mit den vereinbarten Attributen enthält, in einem Form-POST an die RP. Manche IdPs unterstützen die Zustimmung des Nutzers zur Freigabe von Attributen. Dieses Element ist im [SAML-Protokoll] (http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf) jedoch nicht enthalten. Normalerweise werden SAML-Antworten und Assertions digital vom IdP signiert. Assertions können auch verschlüsselt werden, wenn die Anwendung den HTTPS-Schutz als unzureichend erachtet.

SAML unterstützt eine Reihe von AuthnRequest-Optionen, die ein dynamisches Verhalten ermöglichen, z. B. die Festlegung der für die Authentifizierung der Nutzer zulässigen Verfahren, die Sperrung von SSO (d. h. die erzwungene Anmeldung über den IdP), die Beschränkung von Proxy-IdPs usw. Darüber hinaus werden weitere individuelle Optionen unterstützt.

Das [kontinuierlich weiterentwickelte OIDC] ist ein relativ neues Protokoll, das speziell für Web- und Mobilanwendungen entwickelt wurde (https://openid.net/developers/specs/). OICD ist eine benutzerfreundliche Erweiterung von OAuth2 mit Datenstrukturen im JSON-Format und Simple-HTTPS-Übermittlung. Die Nutzeridentitätsdaten („Claims“) werden in einem JSON-Web-Token (ID-Token) ausgestellt. Die Claims enthalten einen dauerhaften Identifikator, den sogenannten Persistent-Identifier, und Nutzerdaten, die von den angefragten Bereichen abhängen. In der Regel beinhaltet dieses Token eine digitale Signatur und kann bei Bedarf auch verschlüsselt werden.

Mithilfe von OIDC-Scopes wird bestimmt, welche möglichen Claims oder Gruppen von Claims vom IdP zurückgesendet werden können. Welche Scope-Werte zulässig sind und auf welche Claims sie sich genau beziehen, hängt vom IdP ab. In OIDC sind eine Reihe gängiger Scopes und Claims definiert, wie z. B. Profil, Adresse, E-Mail usw.

So enthält beispielsweise das Profil in der Regel den Namen des Nutzers und gegebenenfalls sein Bild, sein Geburtsdatum und andere personenbezogene Daten, je nachdem, welche Daten der IdP speichert und welche Daten er vorsieht.

Wie bei der SAML müssen die RP und der IdP auch hier zunächst bestimmte Daten austauschen, bevor OIDC genutzt werden kann. Diese Daten sind beim OIDC in der Regel jedoch weniger umfangreich. Die RP bezieht mindestens die Client-ID und das Client Secret vom IdP, vereinbart mögliche Scopes und teilt dem IdP einen URL-Endpunkt mit, an den Codes oder Tokens zurückgesendet werden sollen.

OIDC basiert auf OAuth 2.0 und hat eine Reihe von Anwendungsfällen, die sogenannten Flows, die festlegen, wie die RP und der IdP genau miteinander kommunizieren. Der einfachste Flow ist der Implicit-Flow, d. h. eine Umleitung der RP zum IdP mit der Client-ID und den gewünschten Scope-Werten. Nachdem der Nutzer authentifiziert wurde und der Weiterleitung dieser Daten zugestimmt hat, sendet der IdP die Claims im ID-Token zurück, indem er sie an den voreingestellten Endpunkt der RP leitet. Bei Flows mit höherer Sicherheit wird das ID-Token nicht direkt übermittelt. Stattdessen wird ein einmalig verwendeter Code zurückgesendet, den die RP über einen Backend-POST gegen das Token austauscht. Zusätzlich zum ID-Token kann auch ein Zugriffstoken ausgestellt werden, mit dem die RP Anfragen zu den im Scope enthaltenen Nutzerressourcen autorisieren kann.

SAML ist seit vielen Jahren als sichere Methode für den Austausch von Identitätsdaten bewährt und genießt das Vertrauen vieler Organisationen. SAML hat außerdem einen großen Funktionsumfang, der zahlreiche Identitätsanforderungen abdeckt.

OIDC ist noch relativ neu und befindet sich noch im Entwicklungsstadium (speziell im europäischen Bankwesen, mit Open Banking), sodass sein Funktionsumfang im Vergleich zu SAML noch nicht so ausgereift ist. So wird beispielsweise die dynamische Spezifikation von Proxy-IdPs noch nicht vollumfänglich unterstützt. Allerdings ist OIDC für Anwendungen mit geringeren Anforderungen in puncto Identitätsdaten speziell im Verbraucherbereich attraktiv, da es einfacher anzuwenden ist als SAML und im Unterschied zu SAML kein umständliches XML-Handling erfordert.

Zurzeit wird SAML hauptsächlich für die Bürgeridentifikation im öffentlichen Sektor und für die Unternehmensauthentifizierung genutzt. Dies ändert sich jedoch allmählich, da immer mehr moderne Systeme OIDC anstelle von SAML vorschreiben. Zurückzuführen ist dies darauf, dass die Datenverarbeitung mit OIDC und JSON-Tokens (ID-Tokens) anstelle von XML einfacher erscheint. OIDC ist ideal für mobile Apps und einseitige Web-Apps, für die SAML zu umständlich wäre.

Lesen Sie unsere Einführung in IAM, um sich über weitere Themen rund um das Identitäts- und Zugriffsmanagement zu informieren.