Share via

Authentification Spring Cloud Azure

  • Article

Cet article s’applique à : ✔️ Version 4.14.0 ✔️ Version 5.8.0

Cet article décrit toutes les méthodes d’authentification Spring Cloud Azure.

DefaultAzureCredential

Il DefaultAzureCredential convient à la plupart des scénarios où l’application est destinée à être exécutée dans le cloud Azure. Cela est dû au fait que les DefaultAzureCredential informations d’identification combinent les informations d’identification couramment utilisées pour s’authentifier lorsqu’elles sont déployées avec des informations d’identification utilisées pour s’authentifier dans un environnement de développement.

Remarque

DefaultAzureCredential vise à simplifier la prise en main du Kit de développement logiciel (SDK) en gérant des scénarios courants avec des comportements par défaut raisonnables. Si vous souhaitez un contrôle supplémentaire ou que votre scénario n’est pas pris en charge par les paramètres par défaut, vous devez utiliser d’autres types d’informations d’identification.

Les DefaultAzureCredential essaieront l’authentification via les mécanismes suivants dans l’ordre :

Diagram showing the authentication mechanism for `DefaultAzureCredential`.

  • Environnement - Les DefaultAzureCredential lisent les informations de compte spécifiées via des variables d’environnement et les utilisent pour l’authentification.
  • Identité managée - Si l’application est déployée sur un hôte Azure avec l’identité managée activée, les DefaultAzureCredential authentifient auprès de ce compte.
  • IntelliJ : si vous vous êtes authentifié via Azure Toolkit for IntelliJ, DefaultAzureCredential s’authentifie avec ce compte.
  • Visual Studio Code : si vous vous êtes authentifié via le plug-in de compte Azure Visual Studio Code, DefaultAzureCredential s’authentifie avec ce compte.
  • Azure CLI : si vous avez authentifié un compte via la commande Azure CLI az login, DefaultAzureCredential s’authentifie avec ce compte.

Conseil

Vérifiez que le principal de sécurité a reçu une autorisation suffisante pour accéder à la ressource Azure. Pour plus d’informations, consultez Autoriser l’accès avec Microsoft Entra ID.

Remarque

Étant donné que Spring Cloud Azure AutoConfigure 4.1.0, un ThreadPoolTaskExecutor bean nommé springCloudAzureCredentialTaskExecutor sera automatiquement inscrit par défaut et gérera tous les threads créés par Azure Identity. Le nom de chaque thread géré par ce pool de threads est préfixé az-identity-par . Ce ThreadPoolTaskExecutor haricot est indépendant du Executor haricot fourni par Spring Boot.

Identités managées

Un défi courant est la gestion des secrets et des informations d’identification utilisés pour sécuriser la communication entre différents composants constituant une solution. Les identités managées éliminent la nécessité de gérer les informations d’identification. Les identités gérées fournissent une identité que les applications peuvent utiliser lors de la connexion à des ressources prenant en charge l'authentification Microsoft Entra. Les applications peuvent utiliser l’identité managée pour obtenir des jetons Microsoft Entra. Par exemple, une application peut utiliser une identité managée pour accéder à des ressources telles qu’Azure Key Vault, où vous pouvez stocker des informations d’identification de manière sécurisée ou pour accéder aux comptes de stockage.

Nous encourageons l’utilisation de l’identité managée au lieu d’utiliser chaîne de connexion ou clé dans votre application, car elle est plus sécurisée et permet de réduire les problèmes de gestion des secrets et des informations d’identification. Dans ce cas, DefaultAzureCredential cela pourrait mieux servir le scénario de développement local à l’aide d’informations de compte stockées localement, puis de déployer l’application sur Azure Cloud et à l’aide d’une identité managée.

Types d’identités managées

Il existe deux types d’identités administrées :

  • Affecté par le système : certains services Azure vous permettent d’activer une identité managée directement sur une instance de service. Lorsque vous activez une identité managée affectée par le système, une identité liée au cycle de vie de cette instance de service est créée dans Microsoft Entra. Ainsi, quand la ressource est supprimée, Azure supprime automatiquement l’identité. Par défaut, seule cette ressource Azure peut utiliser cette identité pour demander des jetons à Microsoft Entra ID.
  • Affecté par l’utilisateur : vous pouvez également créer une identité managée en tant que ressource Azure autonome. Vous pouvez créer une identité managée affectée par l’utilisateur et l’attribuer à une ou plusieurs instances d’un service Azure. Avec les identités managées affectées par l’utilisateur, l’identité est gérée séparément des ressources qui l’utilisent.

Remarque

Lorsque vous utilisez une identité managée affectée par l’utilisateur, vous pouvez spécifier l’ID client via spring.cloud.azure.credential.managed-identity-client-id ou spring.cloud.azure.<azure-service>.credential.managed-identity-client-id. Vous n’avez pas besoin de configuration d’informations d’identification si vous utilisez une identité managée affectée par le système.

Conseil

Vérifiez que le principal de sécurité a reçu une autorisation suffisante pour accéder à la ressource Azure. Pour plus d’informations, consultez Autoriser l’accès avec Microsoft Entra ID.

Pour plus d’informations sur l’identité managée, consultez Qu’est-ce que les identités managées pour les ressources Azure ?.

Autres types d’informations d’identification

Si vous souhaitez un contrôle supplémentaire ou si votre scénario n’est pas servi par les paramètres par défaut ou par DefaultAzureCredential défaut, vous devez utiliser d’autres types d’informations d’identification.

Authentification et autorisation avec Microsoft Entra ID

Avec l’ID Microsoft Entra, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité, qui peut être un utilisateur ou un principal de service d’application. Lorsqu’un principal de sécurité (un utilisateur ou une application) tente d’accéder à une ressource Azure, par exemple une ressource Event Hubs, la demande doit être autorisée. Avec Microsoft Entra ID, l’accès à une ressource est un processus en deux étapes :

  1. Pour commencer, l’identité du principal de sécurité est authentifiée, et un jeton OAuth 2.0 est renvoyé.
  2. Ensuite, le jeton est transmis dans le cadre d’une demande au service Azure pour autoriser l’accès à la ressource spécifiée.

S’authentifier avec Microsoft Entra ID

Pour connecter des applications aux ressources qui prennent en charge l’authentification Microsoft Entra, vous pouvez définir les configurations suivantes avec le préfixe spring.cloud.azure.credential ou spring.cloud.azure.<azure-service>.credential

Le tableau suivant répertorie les propriétés d’authentification :

Propriété Description
client-id ID client à utiliser lors de l’authentification du principal de service avec Azure.
client-secret Clé secrète client à utiliser lors de l’authentification du principal de service avec Azure.
client-certificate-path Chemin d’un fichier de certificat PEM à utiliser lors de l’authentification du principal de service avec Azure.
client-certificate-password Mot de passe du fichier de certificat.
username Nom d’utilisateur à utiliser lors de l’exécution de l’authentification par nom d’utilisateur/mot de passe avec Azure.
mot de passe Mot de passe à utiliser lors de l’exécution de l’authentification par nom d’utilisateur/mot de passe avec Azure.
managed-identity-enabled Indique s’il faut activer l’identité managée.

Conseil

Pour obtenir la liste de toutes les propriétés de configuration d’Azure Spring Cloud, consultez les propriétés de configuration d’Azure Spring Cloud.

L’application recherche plusieurs emplacements pour trouver des informations d’identification disponibles et l’utilise DefaultAzureCredential si aucune propriété d’informations d’identification n’est configurée. Si vous souhaitez utiliser des informations d’identification spécifiques, consultez les exemples suivants pour obtenir des conseils.

L’exemple suivant montre comment vous authentifier à l’aide d’une identité managée affectée par le système :

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

L’exemple suivant montre comment vous authentifier à l’aide d’une identité managée affectée par l’utilisateur :

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

L’exemple suivant montre comment vous authentifier à l’aide d’un principal de service avec une clé secrète client :

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

Remarque

Les valeurs autorisées tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la section Utiliser le point de terminaison incorrect (comptes personnels et d’organisation) de l’erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans le locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur l’ID Microsoft Entra.

L’exemple suivant montre comment vous authentifier à l’aide d’un principal de service avec un certificat PFX client :

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>

Remarque

Les valeurs autorisées tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la section Utiliser le point de terminaison incorrect (comptes personnels et d’organisation) de l’erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans le locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur l’ID Microsoft Entra.

L’exemple suivant montre comment vous authentifier à l’aide d’un principal de service avec un certificat PEM client :

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

Remarque

Les valeurs autorisées tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la section Utiliser le point de terminaison incorrect (comptes personnels et d’organisation) de l’erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans le locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur l’ID Microsoft Entra.

L’exemple suivant montre comment vous authentifier à l’aide d’informations d’identification de l’utilisateur :

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

L’exemple suivant montre comment vous authentifier auprès de Key Vault à l’aide d’un autre principal de service. Cet exemple configure l’application avec deux informations d’identification : une identité managée affectée par le système et un principal de service. Le client secret Key Vault utilise le principal de service, mais tous les autres composants utilisent plutôt l’identité managée.

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>

Remarque

Les valeurs autorisées tenant-id sont : common, organizations, consumersou l’ID de locataire. Pour plus d’informations sur ces valeurs, consultez la section Utiliser le point de terminaison incorrect (comptes personnels et d’organisation) de l’erreur AADSTS50020 - Le compte d’utilisateur du fournisseur d’identité n’existe pas dans le locataire. Pour plus d’informations sur la conversion de votre application monolocataire, consultez Convertir une application monolocataire en multilocataire sur l’ID Microsoft Entra.

Autoriser l’accès avec Microsoft Entra ID

L’étape d’autorisation exige qu’un ou plusieurs rôles Azure soient attribués au principal de sécurité. Les rôles qui sont attribués à un principal de sécurité déterminent les autorisations dont disposera le principal.

Conseil

Pour obtenir la liste de tous les rôles intégrés Azure, consultez les rôles intégrés Azure.

Le tableau suivant répertorie les rôles intégrés Azure pour autoriser l’accès aux services Azure pris en charge dans Spring Cloud Azure :

Rôle Description
Propriétaire des données App Configuration Permet l’accès total aux données App Configuration.
Lecteur des données App Configuration Permet de lire les données App Configuration.
Propriétaire de données Azure Event Hubs Autorise l’accès complet aux ressources Azure Event Hubs.
Récepteur de données Azure Event Hubs Permet d’obtenir un accès en réception aux ressources Azure Event Hubs.
Expéditeur de données Azure Event Hubs Permet d’obtenir un accès en envoi aux ressources Azure Event Hubs.
Propriétaire de données Azure Service Bus Autorise l’accès complet aux ressources Azure Service Bus.
Récepteur de données Azure Service Bus Autorise l’accès aux ressources Azure Service Bus.
Expéditeur de données Azure Service Bus Autorise l’accès aux ressources Azure Service Bus.
Propriétaire des données Blob du stockage Fournit un accès total aux conteneurs d’objets blob et aux données du Stockage Azure, notamment l’attribution du contrôle d’accès POSIX.
Lecteur des données blob du stockage Lire et répertorier des conteneurs et objets blob du stockage Azure.
Lecteur des données en file d’attente du stockage Lire et répertorier des files d’attente et messages en file d’attente du stockage Azure.
Contributeur Cache Redis Gérer les caches Redis.

Remarque

Lorsque vous utilisez Spring Cloud Azure Resource Manager pour obtenir les chaîne de connexion pour Event Hubs, Service Bus et Stockage File d’attente, ou les propriétés du Cache pour Redis, attribuez le rôle Contributorintégré Azure. Azure Cache pour Redis est spécial et vous pouvez également attribuer le Redis Cache Contributor rôle pour obtenir les propriétés Redis.

Remarque

Une stratégie d’accès Key Vault détermine si un principal de sécurité donné, à savoir un utilisateur, une application ou un groupe d’utilisateurs, peut effectuer différentes opérations sur des secrets, clés et certificats de Key Vault. Vous pouvez attribuer des stratégies d’accès à l’aide du portail Azure, d’Azure CLI ou d’Azure PowerShell. Pour plus d’informations, consultez Attribuer une stratégie d’accès Key Vault.

Important

Azure Cosmos DB expose deux définitions de rôle intégrées : Cosmos DB Built-in Data Reader et Cosmos DB Built-in Data Contributor. Toutefois, Portail Azure prise en charge de la gestion des rôles n’est pas encore disponible. Pour plus d’informations sur le modèle d’autorisation, les définitions de rôles et l’attribution de rôle, consultez Configurer le contrôle d’accès en fonction du rôle avec l’ID Microsoft Entra pour votre compte Azure Cosmos DB.

Jetons SAS

Vous pouvez également configurer des services pour l’authentification avec signature d’accès partagé (SAP). spring.cloud.azure.<azure-service>.sas-token est la propriété à configurer. Par exemple, utilisez cette méthode spring.cloud.azure.storage.blob.sas-token pour l’authentification auprès de Stockage service Blob.

Chaînes de connexion

Connecter chaîne d’Connecter est prise en charge par certains services Azure pour fournir des informations de connexion et des informations d’identification. Pour vous connecter à ces services Azure à l’aide de chaîne de connexion, configurez spring.cloud.azure.<azure-service>.connection-stringsimplement . Par exemple, configurez spring.cloud.azure.eventhubs.connection-string pour vous connecter au service Event Hubs.