Spring Cloud Azure-Authentifizierung

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

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

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.

Anmeldeinformationstypen

Mit Spring Cloud Azure können Sie verschiedene Anmeldeinformationstypen für die Authentifizierung konfigurieren, einschließlich DefaultAzureCredential, WorkloadIdentityCredential, ManagedIdentityCredential, ClientSecretCredential, AzureCliCredentialusw.

DefaultAzureCredential

DefaultAzureCredential eignet sich für die meisten Szenarien, in denen die Anwendung in der Azure Cloud ausgeführt werden soll, da sie die folgenden Anmeldeinformationen kombiniert:

• Anmeldeinformationen, die häufig für die Authentifizierung bei der Bereitstellung verwendet werden.
• Anmeldeinformationen, die für die Authentifizierung in einer Entwicklungsumgebung verwendet werden.

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

• Umgebung – DefaultAzureCredential versucht, Kontoinformationen zu lesen, die über Umgebungsvariablen angegeben wurden, und verwendet diese zum Authentifizieren.
• Verwaltete Identität – Wenn die Anwendung auf einem Azure-Host mit aktivierter verwalteter Identität bereitgestellt wird, versucht DefaultAzureCredential, sich mit diesem Konto zu authentifizieren.
• Workload Identity – Wenn die Anwendung auf einem virtuellen Computer (VM) bereitgestellt wird, versucht DefaultAzureCredential, sich mit diesem Konto zu authentifizieren.
• Cache für freigegebene Token – Wenn Sie sich über Visual Studio authentifiziert haben, versucht DefaultAzureCredential, sich mit diesem Konto zu authentifizieren.
• IntelliJ – Wenn Sie sich über das Azure Toolkit für IntelliJ authentifiziert haben, versucht DefaultAzureCredential, sich mit diesem Konto zu authentifizieren.
• Azure CLI – Wenn Sie ein Konto über den Befehl Azure CLI az login authentifiziert haben, versucht DefaultAzureCredential, sich mit diesem Konto zu authentifizieren.
• Azure PowerShell – Wenn Sie sich über Azure PowerShell authentifiziert haben, versucht DefaultAzureCredential, sich mit diesem Konto zu authentifizieren.
• Azure Developer CLI – Wenn Sie sich über die Azure Developer CLI authentifiziert haben, versucht DefaultAzureCredential, sich mit diesem Konto zu authentifizieren.

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.

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

Andere Anmeldeinformationstypen

Wenn Sie mehr Kontrolle als die von DefaultAzureCredentialbereitgestellten Elemente wünschen oder die Standardeinstellungen Ihr Szenario nicht unterstützen, sollten Sie andere Anmeldeinformationstypen verwenden.

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:

Die Anwendung sucht an mehreren Stellen nach verfügbaren Anmeldeinformationen. Jede Azure SDK-Client-Generator-Factory verwendet zuerst einen benutzerdefinierten Bean vom Typ TokenCredential, wenn die Eigenschaft angegeben wird, token-credential-bean-name angegeben ist, und greift auf die Verwendung DefaultAzureCredential zurück, wenn keine Anmeldeinformationseigenschaften konfiguriert sind.

Authentifizieren mithilfe einer benutzerdefinierten TokenCredential Bean

Das folgende Beispiel zeigt, wie Sie eine benutzerdefinierte TokenCredential Bohnen definieren, um die Authentifizierung auszuführen:

@Bean
TokenCredential myTokenCredential() {
    // Your concrete TokenCredential instance
}

spring.cloud.azure:
  credential:
    token-credential-bean-name: myTokenCredential

Authentifizieren mithilfe einer vom System zugewiesenen verwalteten Identität

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

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

Authentifizieren mithilfe einer vom Benutzer zugewiesenen verwalteten Identität

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}

Authentifizieren mithilfe eines Dienstprinzipals mit geheimem Clientschlüssel

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>

Authentifizieren mithilfe eines Dienstprinzipals mit Clientzertifikat

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>

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>

Authentifizieren mithilfe von Benutzeranmeldeinformationen

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}

Authentifizieren eines Diensts mit anderen Anmeldeinformationen

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>

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.

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:

Authentifizieren mithilfe von 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.

Authentifizieren mithilfe von Verbindungszeichenfolgen

Einige Azure-Dienste unterstützen verbindungszeichenfolge, 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.