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.

Client-Authentifizierung mit gegenseitigem TLS

Beitragende
PDFs

Je nach Ihren Sicherheitsanforderungen können Sie optional Mutual TLS (MTLS) zur Implementierung einer starken Clientauthentifizierung konfigurieren. Bei Verwendung mit ONTAP als Teil einer OAuth 2.0-Bereitstellung garantiert MTLS, dass die Zugriffstoken nur von den Clients verwendet werden, für die sie ursprünglich ausgegeben wurden.

Gegenseitiges TLS mit OAuth 2.0

Transport Layer Security (TLS) wird verwendet, um einen sicheren Kommunikationskanal zwischen zwei Anwendungen herzustellen, in der Regel zwischen einem Client-Browser und einem Webserver. Mutual TLS erweitert dies durch eine starke Identifizierung des Clients über ein Client-Zertifikat. Bei Verwendung in einem ONTAP-Cluster mit OAuth 2.0 wird die Basis-MTLS-Funktionalität durch das Erstellen und Verwenden von Sender-beschränkten Zugriffstoken erweitert.

Ein vom Absender beschränktem Zugriffstoken kann nur vom Client verwendet werden, an den es ursprünglich ausgegeben wurde. Um diese Funktion zu unterstützen, muss ein neuer Bestätigungsantrag gestellt werden (cnf) Wird in das Token eingefügt. Das Feld enthält die Eigenschaft x5t#S256 Enthält einen Digest des Clientzertifikats, das bei der Anforderung des Zugriffstoken verwendet wird. Dieser Wert wird von ONTAP im Rahmen der Überprüfung des Tokens überprüft. Von Autorisierungsservern ausgegebene Zugriffstoken, die nicht durch den Absender eingeschränkt sind, enthalten keinen zusätzlichen Bestätigungsanspruch.

Sie müssen ONTAP so konfigurieren, dass MTLS für jeden Autorisierungsserver separat verwendet wird. Beispiel: Der CLI-Befehl security oauth2 client Enthält 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 das Ergebnis und die von ONTAP ergriffenen Maßnahmen vom Wert des Konfigurationsparameters sowie vom Inhalt des Zugriffstoken und des Clientzertifikats ab. Die Parameter in der Tabelle sind vom kleinsten bis zum restriktivsten organisiert.
Parameter Beschreibung

Keine

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

Anforderung

Die gegenseitige TLS-Authentifizierung von OAuth 2.0 wird erzwungen, wenn ein vom Absender beschränktes Zugriffstoken vom Client angezeigt wird. Das heißt, MTLS wird nur erzwungen, wenn die Bestätigung Anspruch (mit Eigentum x5t#S256) Ist im Access-Token vorhanden. Dies ist die Standardeinstellung.

Erforderlich

Die gegenseitige TLS-Authentifizierung OAuth 2.0 wird für alle Zugriffstoken durchgesetzt, die vom Autorisierungsserver ausgegeben werden. Daher müssen alle Zugriffstoken durch den Absender eingeschränkt sein. Die Authentifizierung und die REST-API-Anforderung schlagen fehl, wenn der Bestätigungsanspruch nicht im Zugriffstoken vorhanden ist oder wenn ein ungültiges Clientzertifikat vorliegt.

Grundlegende Implementierungsablaufs

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 Authentication und Certificate-bound Access Tokens" Entnehmen.

Schritt 1: Erstellen und installieren Sie ein Client-Zertifikat

Die Ermittlung der Kundenidentität basiert auf dem Nachweis der Kenntnis eines privaten Kundenschlüssels. Der entsprechende öffentliche Schlüssel wird in ein signiertes X.509-Zertifikat gelegt, das vom Client vorgelegt wird. Auf einer übergeordneten Ebene umfassen die Schritte zur Erstellung des Clientzertifikats Folgendes:

  1. Erzeugen Sie ein öffentliches und privates Schlüsselpaar

  2. Erstellen Sie eine Zertifikatsignierungsanforderung

  3. Senden Sie die CSR-Datei an eine bekannte Zertifizierungsstelle

  4. CA überprüft die Anforderung und stellt das signierte Zertifikat aus

Sie können das Clientzertifikat normalerweise in Ihrem lokalen Betriebssystem installieren oder direkt mit einem gängigen Dienstprogramm wie Curl verwenden.

Schritt 2: Konfigurieren Sie ONTAP für die Verwendung von MTLS

Sie müssen ONTAP für die Verwendung von MTLS konfigurieren. Diese Konfiguration erfolgt für jeden Autorisierungsserver separat. Beispielsweise mit dem CLI-Befehl security oauth2 client Wird mit dem optionalen Parameter verwendet use-mutual-tls. Siehe "Implementieren Sie OAuth 2.0 in ONTAP" Finden Sie weitere Informationen.

Schritt 3: Client fordert ein Zugriffstoken an

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

Schritt 4: Der Autorisierungsserver generiert das Zugriffstoken

Der Autorisierungsserver überprüft die Clientanforderung und erstellt ein Zugriffstoken. Dazu wird ein Nachrichtendigest des Client-Zertifikats erstellt, das als Bestätigungsforderung im Token enthalten ist (Feld cnf).

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

Die Client-Anwendung führt einen REST-API-Aufruf zum ONTAP-Cluster durch und schließt das Zugriffstoken in den Header der Autorisierungsanforderung als Bearer Token ein. Der Client muss MTLS mit demselben Zertifikat verwenden, das für die Anforderung des Zugriffstoken verwendet wird.

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

ONTAP erhält das Zugriffstoken in einer HTTP-Anfrage sowie das Clientzertifikat, das als Teil der MTLS-Verarbeitung verwendet wird. ONTAP validiert zuerst die Signatur im Zugriffstoken. Basierend auf der Konfiguration generiert ONTAP einen Nachrichtendigest des Client-Zertifikats und vergleicht ihn mit dem Bestätigungsanspruch cnf im Token. Wenn die beiden Werte übereinstimmen, hat ONTAP bestätigt, dass der Client, der die API-Anforderung erstellt, derselbe Client ist, für den das Zugriffstoken ursprünglich ausgegeben wurde.