Spring Cloud Azure-Authentifizierung

Dieser Artikel bezieht sich auf: ✔️ Version 4.14.0 ✔️ Version 5.8.0

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

DefaultAzureCredential

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

Hinweis

DefaultAzureCredential soll den Einstieg in das SDK erleichtern, indem häufige Szenarien mit vernünftigem Standardverhalten behandelt werden. Wenn Sie mehr Kontrolle wünschen oder Ihr Szenario nicht von den Standardeinstellungen bedient wird, sollten Sie andere Anmeldeinformationstypen verwenden.

DefaultAzureCredential versucht, sich über die folgenden Mechanismen in der angegebenen Reihenfolge zu authentifizieren:

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

Tipp

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.

Hinweis

Seit Spring Cloud Azure AutoConfigure 4.1.0 wird standardmäßig ein ThreadPoolTaskExecutor Bean-Name springCloudAzureCredentialTaskExecutor automatisch registriert und verwaltet alle Threads, die von Azure Identity erstellt wurden. Der Name jedes Threads, der von diesem Threadpool verwaltet wird, wird mit dem Präfix " az-identity-. Dieser ThreadPoolTaskExecutor Bohnen ist unabhängig von der Executor von Spring Boot bereitgestellten Bohnen.

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. Dank verwalteter Identitäten müssen keine Anmeldeinformationen mehr verwaltet werden. Verwaltete Identitäten stellen eine Identität bereit, mit deren Hilfe Anwendungen eine Verbindung mit Ressourcen herstellen können, welche 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 es besser sein, das Szenario zu entwickeln, DefaultAzureCredential lokal mithilfe von lokal gespeicherten Kontoinformationen zu entwickeln und dann die Anwendung in Azure Cloud bereitzustellen und verwaltete Identität zu verwenden.

Arten von verwalteten Identitäten

Es gibt zwei Arten von verwalteten Identitäten:

• System zugewiesen – Einige Azure-Dienste ermöglichen es Ihnen, eine verwaltete Identität direkt in einer Dienstinstanz zu aktivieren. Wenn Sie eine systemseitig zugewiesene verwaltete Identität aktivieren, wird in Microsoft Entra eine Identität erstellt, die an den Lebenszyklus der jeweiligen Dienstinstanz gebunden ist. Daher löscht Azure automatisch die Identität, wenn die Ressource gelöscht wird. Entwurfsbedingt kann nur diese Azure-Ressource diese Identität zum Anfordern von Token von Microsoft Entra ID verwenden.
• Vom Benutzer zugewiesen – Sie können auch eine verwaltete Identität als eigenständige Azure-Ressource erstellen. Sie können eine benutzerseitig zugewiesene verwaltete Identität erstellen und diese einer oder mehreren Instanzen eines Azure-Diensts zuweisen. Bei benutzerseitig zugewiesenen verwalteten Identitäten wird die Identität getrennt von den Ressourcen verwaltet, für die sie verwendet wird.

Hinweis

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

Tipp

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 von den DefaultAzureCredential oder den Standardeinstellungen bedient wird, sollten Sie andere Anmeldeinformationstypen verwenden.

Authentifizierung und Autorisierung über 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. Zunächst wird die Identität des Sicherheitsprinzipals authentifiziert und ein OAuth 2.0-Token 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.

Authentifizierung mit 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:

Eigenschaft	Beschreibung
client-id	Die Client-ID, die beim Ausführen der Dienstprinzipalauthentifizierung mit Azure verwendet werden soll.
client-secret	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.
username	Der Benutzername, der bei der Authentifizierung mit Benutzername/Kennwort bei Azure verwendet werden soll.
Kennwort	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.

Tipp

Die 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 Anmeldeinformationen 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>

Hinweis

Die zulässigen tenant-id Werte sind: common, , organizations, consumers, oder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt "Verwendet" des falschen Endpunkts (persönliche und Organisationskonten) des Fehlers AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandanten vorhanden. 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>

Hinweis

Die zulässigen tenant-id Werte sind: common, , organizations, consumers, oder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt "Verwendet" des falschen Endpunkts (persönliche und Organisationskonten) des Fehlers AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandanten vorhanden. 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>

Hinweis

Die zulässigen tenant-id Werte sind: common, , organizations, consumers, oder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt "Verwendet" des falschen Endpunkts (persönliche und Organisationskonten) des Fehlers AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandanten vorhanden. 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>

Hinweis

Die zulässigen tenant-id Werte sind: common, , organizations, consumers, oder die Mandanten-ID. Weitere Informationen zu diesen Werten finden Sie im Abschnitt "Verwendet" des falschen Endpunkts (persönliche und Organisationskonten) des Fehlers AADSTS50020 – Benutzerkonto des Identitätsanbieters ist nicht im Mandanten vorhanden. Informationen zum Konvertieren Ihrer Einzelmandanten-App finden Sie unter Konvertieren einer Einzelmandanten-App in multitenant auf Microsoft Entra ID.

Autorisieren des Zugriffs mit Microsoft Entra ID

Der Autorisierungsschritt erfordert, dass dem Sicherheitsprinzipal mindestens eine Azure-Rolle zugewiesen wird. Die möglichen Berechtigungen eines Sicherheitsprinzipals sind durch die Rollen vorgegeben, die dem Prinzipal zugewiesen sind.

Tipp

Eine Liste aller integrierten Azure-Rollen finden Sie in den 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 Configuration-Datenbesitzer	Ermöglicht den Vollzugriff auf App Configuration-Daten.
App Configuration-Datenleser	Ermöglicht den Lesezugriff auf App Configuration-Daten.
Azure Event Hubs-Datenbesitzer	Ermöglicht vollzugriff auf Azure Event Hubs-Ressourcen.
Azure Event Hubs-Datenempfänger	Ermöglicht Empfängern den Zugriff auf die Azure Event Hubs-Ressourcen.
Azure Event Hubs-Datensender	Ermöglicht Absendern den Zugriff auf die Azure Event Hubs-Ressourcen.
Azure Service Bus-Datenbesitzer	Ermöglicht vollzugriff auf Azure Service Bus-Ressourcen.
Azure Service Bus-Datenempfänger	Ermöglicht den Zugriff auf Azure Service Bus-Ressourcen.
Azure Service Bus-Datensender	Ermöglicht das Senden des Zugriffs auf Azure Service Bus-Ressourcen.
Besitzer von Speicherblobdaten	Bietet Vollzugriff auf Azure Storage-Blobcontainer und -daten, einschließlich POSIX-Zugriffssteuerung.
Leser von Speicherblobdaten	Lesen und Auflisten von Azure Storage-Containern und -Blobs.
Storage-Warteschlangendatenleser	Lesen und Auflisten von Azure Storage-Warteschlangen und -Warteschlangennachrichten.
Mitwirkender von Redis-Cache	Verwalten von Redis-Caches.

Hinweis

Wenn Sie Spring Cloud Azure Resource Manager zum Abrufen der Verbindungszeichenfolge 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 für Redis ist besonders, und Sie können die Rolle auch zuweisen, um die Redis Cache Contributor Redis-Eigenschaften abzurufen.

Hinweis

Eine Key Vault-Zugriffsrichtlinie legt fest, ob ein bestimmter Sicherheitsprinzipal (eine Anwendung oder eine Benutzergruppe) verschiedene Vorgänge für Geheimnisse, Schlüssel und Zertifikate in Key Vault 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 Key Vault-Zugriffsrichtlinie.

Wichtig

Azure Cosmos DB macht zwei integrierte Rollendefinitionen verfügbar: Cosmos DB Built-in Data Reader und Cosmos DB Built-in Data Contributor. Azure-Portal Unterstützung 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 spring.cloud.azure.storage.blob.sas-token z. B. die Authentifizierung beim Speicher-Blob-Dienst.

Verbindungszeichenfolgen

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