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

ONTAP Client-Authentifizierung mit OAuth 2.0 Mutual TLS

Beitragende netapp-aaron-holt netapp-perveilerk netapp-bhouser netapp-dbagwell dmp-netapp
Änderungen vorschlagen

Je nach Ihren Sicherheitsanforderungen kann optional Mutual TLS (mTLS) konfiguriert werden, um eine starke Client-Authentifizierung zu implementieren. Bei Verwendung mit ONTAP im Rahmen einer OAuth 2.0-Implementierung garantiert mTLS, dass die Zugriffstoken nur von den Clients verwendet werden, denen sie ursprünglich ausgestellt wurden.

Gegenseitiges TLS mit OAuth 2.0

Transport Layer Security (TLS) dient dem Aufbau eines sicheren Kommunikationskanals zwischen zwei Anwendungen, typischerweise einem Client-Browser und einem Webserver. Mutual TLS erweitert dies durch die starke Identifizierung des Clients mittels eines Client-Zertifikats. Bei Verwendung in einem ONTAP Cluster mit OAuth 2.0 wird die Basisfunktionalität von mTLS durch die Erstellung und Verwendung von sender-constrained Zugriffstoken erweitert.

Ein absenderbeschränktes Zugriffstoken kann nur von dem Client verwendet werden, dem es ursprünglich ausgestellt wurde. Zur Unterstützung dieser Funktion wird dem Token ein neuer Bestätigungsanspruch (cnf eingefügt. Das Feld enthält die Eigenschaft x5t#S256, die einen Digest des Clientzertifikats speichert, das bei der Anforderung des Zugriffstokens verwendet wurde. Dieser Wert wird von ONTAP im Rahmen der Überprüfung des Tokens validiert. Zugriffstoken, die von Autorisierungsservern ausgestellt werden, die nicht absenderbeschränkt sind, enthalten den zusätzlichen Bestätigungsanspruch nicht.

Sie müssen ONTAP für die Verwendung von mTLS für jeden Autorisierungsserver separat konfigurieren. Der CLI-Befehl security oauth2 client enthält beispielsweise den Parameter use-mutual-tls zur Steuerung der mTLS-Verarbeitung anhand von drei Werten, wie in der folgenden Tabelle dargestellt.

Hinweis In jeder Konfiguration hängen Ergebnis und Vorgehensweise von ONTAP vom Wert des Konfigurationsparameters sowie vom Inhalt des Zugriffstokens und des Clientzertifikats ab. Die Parameter in der Tabelle sind von den am wenigsten bis zu den am stärksten restriktiven geordnet.
Parameter Beschreibung

keine

OAuth 2.0 gegenseitige TLS-Authentifizierung ist für den Autorisierungsserver vollständig deaktiviert. ONTAP führt keine mTLS-Client-Authentifizierung durch, selbst wenn der Bestätigungsanspruch im Token vorhanden ist oder ein Clientzertifikat mit der TLS-Verbindung übermittelt wird.

Anfrage

Die OAuth 2.0 Mutual-TLS-Authentifizierung wird erzwungen, wenn der Client ein senderbeschränktes Zugriffstoken vorlegt. Das heißt, mTLS wird nur dann erzwungen, wenn der Bestätigungsanspruch (mit Eigenschaft x5t#S256) im Zugriffstoken vorhanden ist. Dies ist die Standardeinstellung.

erforderlich

OAuth 2.0 gegenseitige TLS-Authentifizierung wird für alle vom Autorisierungsserver ausgestellten Zugriffstoken erzwungen. Daher müssen alle Zugriffstoken absenderbeschränkt sein. Authentifizierung und die REST API-Anfrage schlagen fehl, wenn der Bestätigungsanspruch im Zugriffstoken fehlt oder ein ungültiges Client-Zertifikat vorliegt.

Implementierungsablauf auf hoher Ebene

Die typischen Schritte bei der Verwendung von mTLS mit OAuth 2.0 in einer ONTAP Umgebung sind nachfolgend dargestellt. Siehe "RFC 8705: OAuth 2.0 Mutual-TLS-Client-Authentifizierung und zertifikatsgebundene Access-Tokens" für weitere Details.

Schritt 1: Erstellen und Installieren eines Client-Zertifikats

Die Identifizierung eines Clients basiert auf dem Nachweis der Kenntnis seines privaten Schlüssels. Der zugehörige öffentliche Schlüssel ist in einem signierten X.509-Zertifikat enthalten, das vom Client vorgelegt wird. Auf hoher Ebene umfassen die Schritte zur Erstellung des Client-Zertifikats:

  1. Ein öffentliches und privates Schlüsselpaar generieren

  2. Zertifikatsignierungsanforderung erstellen

  3. Die CSR-Datei an eine anerkannte Zertifizierungsstelle senden

  4. Die Zertifizierungsstelle prüft die Anfrage und stellt das signierte Zertifikat aus

Normalerweise kann das Client-Zertifikat im lokalen Betriebssystem installiert oder direkt mit einem gängigen Hilfsprogramm wie curl verwendet werden.

Schritt 2: ONTAP für die Verwendung von mTLS konfigurieren

ONTAP muss für die Verwendung von mTLS konfiguriert werden. Diese Konfiguration wird für jeden Autorisierungsserver separat durchgeführt. Beispielsweise wird in der CLI der Befehl security oauth2 client mit dem optionalen Parameter use-mutual-tls verwendet. Siehe "OAuth 2.0 in ONTAP bereitstellen" für weitere Informationen.

Schritt 3: Der Client fordert ein Zugriffstoken an

Der Client muss ein Zugriffstoken vom Autorisierungsserver anfordern, der für ONTAP konfiguriert ist. Die Clientanwendung muss mTLS mit dem in Schritt 1 erstellten und installierten Zertifikat verwenden.

Schritt 4: Der Autorisierungsserver generiert das Zugriffstoken

Der Autorisierungsserver überprüft die Clientanfrage und generiert ein Zugriffstoken. Dabei erstellt er einen Message Digest des Clientzertifikats, der als Bestätigungsanspruch (Feld cnf) in das Token aufgenommen wird.

Schritt 5: Die Client-Anwendung präsentiert das Zugriffstoken an ONTAP

Die Clientanwendung sendet einen REST-API-Aufruf an den ONTAP Cluster und fügt das Zugriffstoken als Bearer-Token in den Autorisierungsanfrage-Header ein. Der Client muss mTLS mit demselben Zertifikat verwenden, das auch für die Anforderung des Zugriffstokens verwendet wurde.

Schritt 6: ONTAP überprüft Client und Token.

ONTAP empfängt das Zugriffstoken in einer HTTP-Anfrage sowie das Clientzertifikat, das im Rahmen der mTLS-Verarbeitung verwendet wird. ONTAP validiert zunächst die Signatur im Zugriffstoken. Basierend auf der Konfiguration erzeugt ONTAP einen Message Digest des Clientzertifikats und vergleicht diesen mit dem Bestätigungsanspruch cnf im Token. Wenn die beiden Werte übereinstimmen, ist bestätigt, dass der Client, der die API-Anfrage stellt, derselbe Client ist, dem das Zugriffstoken ursprünglich ausgestellt wurde.