Spring Cloud Azure-Authentifizierung

Dieser Artikel gilt für:✅ Version 4.19.0 ✅ Version 5.19.0

In diesem Artikel werden alle Spring Cloud Azure-Authentifizierungsmethoden beschrieben.

DefaultAzureCredential

Die DefaultAzureCredential eignet sich für die meisten Szenarien, in denen die Anwendung in der Azure Cloud ausgeführt werden soll. Dies liegt daran, dass die DefaultAzureCredential Anmeldeinformationen kombiniert, die häufig zur Authentifizierung verwendet werden, wenn sie mit Anmeldeinformationen für die Authentifizierung in einer Entwicklungsumgebung bereitgestellt werden.

Anmerkung

DefaultAzureCredential soll die ersten Schritte mit dem SDK vereinfachen, indem allgemeine Szenarien mit angemessenen Standardverhalten behandelt werden. Wenn Sie mehr Kontrolle wünschen oder Ihr Szenario nicht von den Standardeinstellungen bedient wird, sollten Sie andere Anmeldeinformationstypen verwenden.

Die DefaultAzureCredential versucht, sich über die folgenden Mechanismen zu authentifizieren:

• Umgebung – Die DefaultAzureCredential liest Kontoinformationen, die über Umgebungsvariablen angegeben sind, und verwendet sie zur Authentifizierung.
• Verwaltete Identität – Wenn die Anwendung auf einem Azure-Host mit aktivierter verwalteter Identität bereitgestellt wird, authentifiziert sich die DefaultAzureCredential mit diesem Konto.
• IntelliJ – Wenn Sie sich über das Azure Toolkit für IntelliJ authentifiziert haben, authentifiziert sich der DefaultAzureCredential mit diesem Konto.
• Visual Studio Code – Wenn Sie sich über das Visual Studio Code Azure-Konto-Plug-In authentifiziert haben, authentifiziert sich der DefaultAzureCredential mit diesem Konto.
• Azure CLI – Wenn Sie ein Konto über den Azure CLI-az login-Befehl authentifiziert haben, authentifiziert sich der DefaultAzureCredential mit diesem Konto.

Trinkgeld

Stellen Sie sicher, dass dem Sicherheitsprinzipal ausreichende Berechtigungen für den Zugriff auf die Azure-Ressource erteilt wurden. Weitere Informationen finden Sie unter Autorisieren des Zugriffs mit microsoft Entra ID.

Anmerkung

Seit Spring Cloud Azure AutoConfigure 4.1.0 wird standardmäßig ein ThreadPoolTaskExecutor bean namens springCloudAzureCredentialTaskExecutor automatisch registriert und verwaltet alle Threads, die von Azure Identity erstellt wurden. Der Name jedes threads, der von diesem Threadpool verwaltet wird, wird az-identity-vorangestellt. Diese ThreadPoolTaskExecutor Bohnen ist unabhängig von der Executor von Spring Boot bereitgestellt.

Verwaltete Identitäten

Eine häufige Herausforderung ist die Verwaltung von geheimen Schlüsseln und Anmeldeinformationen, die zur Sicherung der Kommunikation zwischen verschiedenen Komponenten verwendet werden, die eine Lösung bilden. Verwaltete Identitäten vermeiden die Notwendigkeit, Anmeldeinformationen zu verwalten. Verwaltete Identitäten stellen eine Identität für Anwendungen bereit, die beim Herstellen einer Verbindung mit Ressourcen verwendet werden sollen, die die Microsoft Entra-Authentifizierung unterstützen. Anwendungen können die verwaltete Identität verwenden, um Microsoft Entra-Token abzurufen. Beispielsweise kann eine Anwendung eine verwaltete Identität verwenden, um auf Ressourcen wie Azure Key Vault zuzugreifen, wo Sie Anmeldeinformationen auf sichere Weise speichern oder auf Speicherkonten zugreifen können.

Wir empfehlen, verwaltete Identitäten zu verwenden, anstatt Verbindungszeichenfolge oder Schlüssel in Ihrer Anwendung zu verwenden, da sie sicherer ist und die Probleme beim Verwalten von geheimen Schlüsseln und Anmeldeinformationen speichert. In diesem Fall könnte DefaultAzureCredential besser für das Szenario dienen, lokal mithilfe von lokal gespeicherten Kontoinformationen zu entwickeln und dann die Anwendung in Azure Cloud bereitzustellen und verwaltete Identität zu verwenden.

Verwaltete Identitätstypen

Es gibt zwei Arten von verwalteten Identitäten:

• vom System zugewiesenen – Einige Azure-Dienste ermöglichen es Ihnen, eine verwaltete Identität direkt in einer Dienstinstanz zu aktivieren. Wenn Sie eine vom System zugewiesene verwaltete Identität aktivieren, wird eine Identität in Microsoft Entra erstellt, die an den Lebenszyklus dieser Dienstinstanz gebunden ist. Wenn die Ressource also gelöscht wird, löscht Azure automatisch die Identität für Sie. Standardmäßig kann nur diese Azure-Ressource diese Identität verwenden, um Token von Der Microsoft Entra-ID anzufordern.
• vom Benutzer zugewiesenen – Sie können auch eine verwaltete Identität als eigenständige Azure-Ressource erstellen. Sie können eine vom Benutzer zugewiesene verwaltete Identität erstellen und sie einer oder mehreren Instanzen eines Azure-Diensts zuweisen. Bei vom Benutzer zugewiesenen verwalteten Identitäten wird die Identität getrennt von den Ressourcen verwaltet, die sie verwenden.

Anmerkung

Bei Verwendung einer vom Benutzer zugewiesenen verwalteten Identität können Sie die Client-ID über spring.cloud.azure.credential.client-id oder spring.cloud.azure.<azure-service>.credential.client-idangeben. Sie benötigen keine Konfiguration für Anmeldeinformationen, wenn Sie eine vom System zugewiesene verwaltete Identität verwenden.

Trinkgeld

Stellen Sie sicher, dass dem Sicherheitsprinzipal ausreichende Berechtigungen für den Zugriff auf die Azure-Ressource erteilt wurden. Weitere Informationen finden Sie unter Autorisieren des Zugriffs mit microsoft Entra ID.

Weitere Informationen zu verwalteter Identität finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen?.

Andere Anmeldeinformationstypen

Wenn Sie mehr Kontrolle wünschen oder Ihr Szenario nicht vom DefaultAzureCredential oder den Standardeinstellungen bereitgestellt wird, sollten Sie andere Anmeldeinformationstypen verwenden.

Authentifizierung und Autorisierung mit Microsoft Entra ID

Mit Microsoft Entra-ID können Sie die rollenbasierte Zugriffssteuerung (Azure RBAC) von Azure verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen, bei dem es sich um einen Benutzer oder einen Anwendungsdienstprinzipal handeln kann. Wenn ein Sicherheitsprinzipal (ein Benutzer oder eine Anwendung) versucht, auf eine Azure-Ressource zuzugreifen, z. B. eine Event Hubs-Ressource, muss die Anforderung autorisiert sein. Mit microsoft Entra ID ist der Zugriff auf eine Ressource ein zweistufiger Prozess:

1. Zuerst wird die Identität des Sicherheitsprinzipals authentifiziert, und ein OAuth 2.0-Token wird zurückgegeben.
2. Als Nächstes wird das Token als Teil einer Anforderung an den Azure-Dienst übergeben, um den Zugriff auf die angegebene Ressource zu autorisieren.

Authentifizieren mit Der Microsoft Entra-ID

Um Anwendungen mit Ressourcen zu verbinden, die die Microsoft Entra-Authentifizierung unterstützen, können Sie die folgenden Konfigurationen mit dem Präfix spring.cloud.azure.credential oder spring.cloud.azure.<azure-service>.credential

In der folgenden Tabelle sind die Authentifizierungseigenschaften aufgeführt:

Eigentum	Beschreibung
Client-ID	Die Client-ID, die beim Ausführen der Dienstprinzipalauthentifizierung mit Azure verwendet werden soll.
Geheimer Clientschlüssel	Der geheime Clientschlüssel, der beim Ausführen der Dienstprinzipalauthentifizierung mit Azure verwendet werden soll.
Clientzertifikatpfad	Pfad einer PEM-Zertifikatdatei, die beim Ausführen der Dienstprinzipalauthentifizierung mit Azure verwendet werden soll.
Clientzertifikat-Kennwort	Das Kennwort der Zertifikatdatei.
Nutzername	Der Benutzername, der bei der Authentifizierung mit Benutzername/Kennwort bei Azure verwendet werden soll.
Passwort	Das Kennwort, das beim Ausführen der Authentifizierung mit Benutzername/Kennwort mit Azure verwendet werden soll.
managed-identity-enabled	Gibt an, ob verwaltete Identität aktiviert werden soll.

Trinkgeld

Eine Liste aller Spring Cloud Azure-Konfigurationseigenschaften finden Sie unter Spring Cloud Azure-Konfigurationseigenschaften.

Die Anwendung sucht an mehreren Stellen nach verfügbaren Anmeldeinformationen und verwendet DefaultAzureCredential, wenn keine Anmeldeinformationseigenschaften konfiguriert sind. Wenn Sie bestimmte Anmeldeinformationen verwenden möchten, finden Sie in den folgenden Beispielen Anleitungen.

Das folgende Beispiel zeigt, wie Sie sich mithilfe einer vom System zugewiesenen verwalteten Identität authentifizieren:

spring.cloud.azure:
  credential:
    managed-identity-enabled: true

Das folgende Beispiel zeigt, wie Sie sich mithilfe einer vom Benutzer zugewiesenen verwalteten Identität authentifizieren:

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
    client-id: ${AZURE_CLIENT_ID}

Das folgende Beispiel zeigt, wie Sie sich mithilfe eines Dienstprinzipals mit einem geheimen Clientschlüssel authentifizieren:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-secret: ${AZURE_CLIENT_SECRET}
  profile:
    tenant-id: <tenant>

Anmerkung

Die für tenant-id zulässigen Werte sind: common, organizations, consumersoder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt Abschnitt Abschnitt Fehler-AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandantenvorhanden. Informationen zum Konvertieren Ihrer Einzelmandanten-App finden Sie unter Konvertieren einer Einzelmandanten-App in multitenant auf Microsoft Entra ID.

Das folgende Beispiel zeigt, wie Sie sich mithilfe eines Dienstprinzipals mit einem PFX-Clientzertifikat authentifizieren:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
    client-certificate-password: ${AZURE_CLIENT_CERTIFICATE_PASSWORD}
  profile:
    tenant-id: <tenant>

Anmerkung

Die für tenant-id zulässigen Werte sind: common, organizations, consumersoder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt Abschnitt Abschnitt Fehler-AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandantenvorhanden. Informationen zum Konvertieren Ihrer Einzelmandanten-App finden Sie unter Konvertieren einer Einzelmandanten-App in multitenant auf Microsoft Entra ID.

Das folgende Beispiel zeigt, wie Sie sich mithilfe eines Dienstprinzipals mit dem PEM-Clientzertifikat authentifizieren:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
  profile:
    tenant-id: <tenant>

Anmerkung

Die für tenant-id zulässigen Werte sind: common, organizations, consumersoder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt Abschnitt Abschnitt Fehler-AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandantenvorhanden. Informationen zum Konvertieren Ihrer Einzelmandanten-App finden Sie unter Konvertieren einer Einzelmandanten-App in multitenant auf Microsoft Entra ID.

Das folgende Beispiel zeigt, wie Sie sich mithilfe einer Benutzeranmeldeinformationen authentifizieren:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    username: ${AZURE_USER_USERNAME}
    password: ${AZURE_USER_PASSWORD}

Das folgende Beispiel zeigt, wie Sie sich mit Key Vault mithilfe eines anderen Dienstprinzipals authentifizieren. In diesem Beispiel wird die Anwendung mit zwei Anmeldeinformationen konfiguriert: eine vom System zugewiesene verwaltete Identität und ein Dienstprinzipal. Der Key Vault Secret-Client verwendet den Dienstprinzipal, aber alle anderen Komponenten verwenden stattdessen verwaltete Identität.

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
  keyvault.secret:
    credential:
      client-id: ${AZURE_CLIENT_ID}
      client-secret: ${AZURE_CLIENT_SECRET}
    profile:
      tenant-id: <tenant>

Anmerkung

Die für tenant-id zulässigen Werte sind: common, organizations, consumersoder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt Abschnitt Abschnitt Fehler-AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandantenvorhanden. Informationen zum Konvertieren Ihrer Einzelmandanten-App finden Sie unter Konvertieren einer Einzelmandanten-App in multitenant auf Microsoft Entra ID.

Autorisieren des Zugriffs mit der Microsoft Entra-ID

Der Autorisierungsschritt erfordert, dass dem Sicherheitsprinzipal mindestens eine Azure-Rolle zugewiesen wird. Die Rollen, die einem Sicherheitsprinzipal zugewiesen sind, bestimmen die Berechtigungen, über die der Prinzipal verfügt.

Trinkgeld

Die Liste aller integrierten Azure-Rollen finden Sie unter integrierten Azure-Rollen.

In der folgenden Tabelle sind die integrierten Azure-Rollen für die Autorisierung des Zugriffs auf Azure-Dienste aufgeführt, die in Spring Cloud Azure unterstützt werden:

Rolle	Beschreibung
App-Konfigurationsdatenbesitzer	Ermöglicht vollzugriff auf App-Konfigurationsdaten.
App-Konfigurationsdatenleser	Ermöglicht lesezugriff auf App-Konfigurationsdaten.
Azure Event Hubs Data Owner	Ermöglicht vollzugriff auf Azure Event Hubs-Ressourcen.
Azure Event Hubs Data Receiver	Ermöglicht den Zugriff auf Azure Event Hubs-Ressourcen.
Azure Event Hubs Data Sender	Ermöglicht das Senden des Zugriffs auf Azure Event Hubs-Ressourcen.
Azure Service Bus Data Owner	Ermöglicht vollzugriff auf Azure Service Bus-Ressourcen.
Azure Service Bus Data Receiver	Ermöglicht den Zugriff auf Azure Service Bus-Ressourcen.
Azure Service Bus Data Sender	Ermöglicht das Senden des Zugriffs auf Azure Service Bus-Ressourcen.
des Speicherblobdatenbesitzers	Bietet vollzugriff auf Azure Storage-BLOB-Container und -Daten, einschließlich des Zuweisens der POSIX-Zugriffssteuerung.
	Lesen und Auflisten von Azure Storage-Containern und Blobs.
des Speicherwarteschlangen-Datenlesers	Lesen und Auflisten von Azure Storage-Warteschlangen und Warteschlangennachrichten.
Redis Cache-Mitwirkender	Verwalten von Redis-Caches.

Anmerkung

Wenn Sie Spring Cloud Azure Resource Manager zum Abrufen der Verbindungszeichenfolgen für Event Hubs, Service Bus und Speicherwarteschlange oder die Eigenschaften von Cache für Redis verwenden, weisen Sie die integrierte Azure-Rolle Contributorzu. Azure Cache for Redis ist besonders, und Sie können auch die rolle Redis Cache Contributor zuweisen, um die Redis-Eigenschaften abzurufen.

Anmerkung

Eine Schlüsseltresor-Zugriffsrichtlinie bestimmt, ob ein bestimmter Sicherheitsprinzipal, nämlich ein Benutzer, eine Anwendung oder eine Benutzergruppe, unterschiedliche Vorgänge für Schlüsseltresorschlüssel, Schlüssel und Zertifikate ausführen kann. Sie können Zugriffsrichtlinien über das Azure-Portal, die Azure CLI oder Azure PowerShell zuweisen. Weitere Informationen finden Sie unter Zuweisen einer Zugriffsrichtlinie für den Schlüsseltresor.

Wichtig

Azure Cosmos DB macht zwei integrierte Rollendefinitionen verfügbar: Cosmos DB Built-in Data Reader und Cosmos DB Built-in Data Contributor. Die Unterstützung des Azure-Portals für die Rollenverwaltung ist jedoch noch nicht verfügbar. Weitere Informationen zum Berechtigungsmodell, Rollendefinitionen und Rollenzuweisung finden Sie unter Konfigurieren der rollenbasierten Zugriffssteuerung mit Microsoft Entra ID für Ihr Azure Cosmos DB-Konto.

SAS-Token

Sie können auch Dienste für die Authentifizierung mit freigegebener Zugriffssignatur (SHARED Access Signature, SAS) konfigurieren. spring.cloud.azure.<azure-service>.sas-token ist die zu konfigurierende Eigenschaft. Verwenden Sie z. B. spring.cloud.azure.storage.blob.sas-token, um sich beim Storage Blob-Dienst zu authentifizieren.

Verbindungszeichenfolgen

Verbindungszeichenfolge wird von einigen Azure-Diensten unterstützt, um Verbindungsinformationen und Anmeldeinformationen bereitzustellen. Um eine Verbindung mit diesen Azure-Diensten mithilfe der Verbindungszeichenfolge herzustellen, konfigurieren Sie einfach spring.cloud.azure.<azure-service>.connection-string. Konfigurieren Sie z. B. spring.cloud.azure.eventhubs.connection-string, um eine Verbindung mit dem Event Hubs-Dienst herzustellen.