Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

OAuth 2.0 Autorisierungsserver und Zugriffstoken in ONTAP

07/23/2026 Beitragende

PDFs

Autorisierungsserver erfüllen als zentrale Komponente innerhalb des OAuth 2.0 Autorisierungsframeworks mehrere wichtige Funktionen.

OAuth 2.0 Autorisierungsserver

Autorisierungsserver sind primär für die Erstellung und Signierung von Zugriffstoken zuständig. Diese Token enthalten Identitäts- und Autorisierungsinformationen, die es einer Clientanwendung ermöglichen, selektiv auf geschützte Ressourcen zuzugreifen. Die Server sind in der Regel voneinander isoliert und können auf verschiedene Arten implementiert werden, beispielsweise als eigenständiger dedizierter Server oder als Teil eines umfassenderen Identitäts- und Zugriffsmanagementprodukts.

Für einen Autorisierungsserver werden mitunter unterschiedliche Bezeichnungen verwendet, insbesondere wenn die OAuth 2.0 Funktionalität in ein umfassenderes Produkt oder eine Lösung für Identitäts- und Zugriffsmanagement integriert ist. Beispielsweise wird der Begriff Identitätsanbieter (IdP) häufig synonym mit Autorisierungsserver verwendet.

Verwaltung

Autorisierungsserver stellen nicht nur Zugriffstoken aus, sondern bieten auch zugehörige administrative Dienste an, typischerweise über eine Web-Benutzeroberfläche. Beispielsweise lassen sich folgende Elemente definieren und verwalten:

Benutzer und Benutzerauthentifizierung
Bereiche
Administrative Trennung durch Mandanten und Realms
Durchsetzung der Richtlinien
Verbindung zu verschiedenen externen Diensten
Unterstützung für andere Identitätsprotokolle (wie SAML)

ONTAP ist kompatibel mit Autorisierungsservern, die dem OAuth 2.0 Standard entsprechen.

Definition für ONTAP

Es ist erforderlich, einen oder mehrere Autorisierungsserver für ONTAP zu definieren. ONTAP kommuniziert sicher mit jedem Server, um Token zu überprüfen und andere damit verbundene Aufgaben zur Unterstützung der Clientanwendungen durchzuführen.

Die wichtigsten Aspekte der ONTAP Konfiguration werden unten dargestellt. Weitere Informationen finden Sie auch unter "OAuth 2.0 Bereitstellungsszenarien".

Wie und wo die Zugriffstoken validiert werden

Es gibt zwei Optionen zur Validierung von Zugriffstoken.

Lokale Validierung

ONTAP kann Zugriffstoken lokal anhand der vom ausstellenden Autorisierungsserver bereitgestellten Informationen validieren. Die vom Autorisierungsserver abgerufenen Informationen werden von ONTAP zwischengespeichert und in regelmäßigen Abständen aktualisiert.
Remote-Introspektion

Remote-Introspektion kann ebenfalls verwendet werden, um Token auf dem Autorisierungsserver zu validieren. Introspektion ist ein Protokoll, das autorisierten Parteien ermöglicht, einen Autorisierungsserver bezüglich eines Zugriffstokens abzufragen. ONTAP wird damit in die Lage versetzt, bestimmte Metadaten aus einem Zugriffstoken zu extrahieren und das Token zu validieren. ONTAP speichert einige der Daten aus Performancegründen im Cache.

Netzwerkstandort

ONTAP befindet sich möglicherweise hinter einer Firewall. In diesem Fall ist im Rahmen der Konfiguration ein Proxy anzugeben.

Wie die Autorisierungsserver definiert werden

Sie können einen Autorisierungsserver für ONTAP über jede der administrativen Schnittstellen definieren, einschließlich der ONTAP CLI, des System Manager oder der ONTAP REST API. Beispielsweise wird mit der ONTAP CLI der Befehl security oauth2 client create verwendet.

Weitere Informationen zu security oauth2 client create finden sich in der "ONTAP-Befehlsreferenz".

Anzahl der Autorisierungsserver

Sie können bis zu acht Autorisierungsserver für einen einzelnen ONTAP Cluster definieren. Derselbe Autorisierungsserver kann mehrfach für denselben ONTAP Cluster definiert werden, solange die Issuer- oder Issuer/Audience-Claims eindeutig sind. Bei Keycloak ist dies beispielsweise immer der Fall, wenn verschiedene Realms verwendet werden.

In ONTAP unterstützte OAuth 2.0-Funktionen

Die Unterstützung für OAuth 2.0 war erstmals mit ONTAP 9.14.1 verfügbar und wird mit nachfolgenden Versionen kontinuierlich verbessert. Die von ONTAP unterstützten OAuth 2.0-Funktionen werden im Folgenden beschrieben.

Funktionen, die mit einer bestimmten ONTAP Version eingeführt wurden, werden in zukünftige Versionen übernommen.

ONTAP 9.16.1

ONTAP 9.16.1 erweitert die Standardfunktionen von OAuth 2.0 um Entra ID spezifische Erweiterungen für native Entra ID Gruppen. Dies beinhaltet die Verwendung von GUIDs im Zugriffstoken anstelle von Namen. Darüber hinaus bietet diese Version Unterstützung für externes Rollenmapping, um die nativen Rollen des Identitätsanbieters mithilfe des Felds „roles“ im Zugriffstoken ONTAP Rollen zuzuordnen.

ONTAP 9.14.1

Ab ONTAP 9.14.1 werden Autorisierungsserver durch die folgenden Standard OAuth 2.0-Funktionen für Anwendungen unterstützt, die Folgendes verwenden:

OAuth 2.0 mit den Standardfeldern „iss“, „aud“ und „exp“, wie in "RFC6749: Das OAuth 2.0 Autorisierungsframework" und "RFC 7519: JSON Web Token (JWT)" beschrieben. Dies umfasst auch die Unterstützung für die eindeutige Identifizierung von Benutzern durch Felder im Zugriffstoken wie „upn“, „appid“, „sub“, „username“ oder „preferred_username“.
ADFS-herstellerspezifische Erweiterungen für Gruppennamen mit dem Feld "group".
Azure anbieterspezifische Erweiterungen für Gruppen-UUIDs mit dem Feld "group".
ONTAP Erweiterungen zur Unterstützung der Autorisierung mithilfe von in sich geschlossenen und benannten Rollen innerhalb des OAuth 2.0 Zugriffstokenbereichs. Dies umfasst die Felder „scope“ und „scp“ sowie Gruppennamen innerhalb des Bereichs.

Verwendung von OAuth 2.0 Zugriffstoken

Die von den Autorisierungsservern ausgestellten OAuth 2.0 Zugriffstoken werden von ONTAP überprüft und zur rollenbasierten Zugriffsentscheidung für ONTAP REST API Clientanfragen verwendet.

Ein Zugriffstoken erwerben

Sie benötigen ein Zugriffstoken von einem Autorisierungsserver, der dem ONTAP Cluster zugeordnet ist, auf dem Sie die ONTAP REST API verwenden. Zum Erhalt eines Tokens ist der Autorisierungsserver direkt zu kontaktieren.

ONTAP stellt keine Zugriffstoken aus und leitet Anfragen von Clients nicht an die Autorisierungsserver weiter.

Wie Sie ein Token anfordern, hängt von mehreren Faktoren ab, darunter:

Autorisierungsserver und seine Konfigurationsoptionen
OAuth 2.0 Grant-Typ
Client oder Softwaretool, das zum Ausstellen der Anfrage verwendet wird

Grant-Typen

Ein Grant ist ein klar definierter Prozess, der eine Reihe von Netzwerkabläufen umfasst und zum Anfordern und Empfangen eines OAuth 2.0 Zugriffstokens dient. Je nach Client, Umgebung und Sicherheitsanforderungen können verschiedene Grant Typen verwendet werden. Eine Liste der gängigen Grant Typen ist in der folgenden Tabelle dargestellt.

Grant-Typ	Beschreibung
Client-Anmeldeinformationen	Ein gängiger Berechtigungstyp, der ausschließlich auf Anmeldeinformationen (wie einer ID und einem gemeinsamen Geheimnis) basiert. Es wird davon ausgegangen, dass der Client ein enges Vertrauensverhältnis zum Ressourceninhaber hat.
Passwort	Der Grant-Typ „Resource Owner Password Credentials“ kann in Fällen verwendet werden, in denen zwischen dem Ressourceninhaber und dem Client eine etablierte Vertrauensbeziehung besteht. Er kann auch bei der Migration von Legacy-HTTP-Clients zu OAuth 2.0 nützlich sein.
Autorisierungscode	Dieser Berechtigungstyp eignet sich ideal für vertrauliche Clients und basiert auf einem Umleitungsablauf. Er kann verwendet werden, um sowohl ein Zugriffstoken als auch ein Aktualisierungstoken zu erhalten.

Grant-Typ

Beschreibung

Client-Anmeldeinformationen

Ein gängiger Berechtigungstyp, der ausschließlich auf Anmeldeinformationen (wie einer ID und einem gemeinsamen Geheimnis) basiert. Es wird davon ausgegangen, dass der Client ein enges Vertrauensverhältnis zum Ressourceninhaber hat.

Passwort

Der Grant-Typ „Resource Owner Password Credentials“ kann in Fällen verwendet werden, in denen zwischen dem Ressourceninhaber und dem Client eine etablierte Vertrauensbeziehung besteht. Er kann auch bei der Migration von Legacy-HTTP-Clients zu OAuth 2.0 nützlich sein.

Autorisierungscode

Dieser Berechtigungstyp eignet sich ideal für vertrauliche Clients und basiert auf einem Umleitungsablauf. Er kann verwendet werden, um sowohl ein Zugriffstoken als auch ein Aktualisierungstoken zu erhalten.

JWT Inhalt

Ein OAuth 2.0 Zugriffstoken ist als JWT formatiert. Der Inhalt wird vom Autorisierungsserver basierend auf Ihrer Konfiguration erstellt. Für Clientanwendungen sind die Token jedoch undurchsichtig. Ein Client hat keinen Grund, ein Token zu untersuchen oder sich über dessen Inhalt bewusst zu sein.

Jedes JWT-Zugriffstoken enthält eine Reihe von Claims. Die Claims beschreiben Eigenschaften des Ausstellers und der Autorisierung gemäß den administrativen Definitionen am Autorisierungsserver. Einige der im Standard registrierten Claims sind in der folgenden Tabelle beschrieben. Alle Zeichenketten sind Groß-/Kleinschreibung.

Beanspruchen	Stichwort	Beschreibung
Emittent	ist	Gibt den Auftraggeber an, der das Token ausgestellt hat. Die Verarbeitung der Claims ist anwendungsspezifisch.
Betreff	Unter	Der Betreff bzw. Benutzer des Tokens. Der Name ist so gewählt, dass er global oder lokal eindeutig ist.
Zielgruppe	aud	Die Empfänger, für die das Token bestimmt ist. Implementiert als Array von Zeichenketten.
Ablauf	exp	Die Zeit, nach der das Token abläuft und abgelehnt werden muss.

Beanspruchen

Stichwort

Beschreibung

Emittent

ist

Gibt den Auftraggeber an, der das Token ausgestellt hat. Die Verarbeitung der Claims ist anwendungsspezifisch.

Betreff

Unter

Der Betreff bzw. Benutzer des Tokens. Der Name ist so gewählt, dass er global oder lokal eindeutig ist.

Zielgruppe

aud

Die Empfänger, für die das Token bestimmt ist. Implementiert als Array von Zeichenketten.

Ablauf

exp

Die Zeit, nach der das Token abläuft und abgelehnt werden muss.

Siehe "RFC 7519: JSON Web Tokens" für weitere Informationen.