Partager via

Authentification Spring Cloud Azure

  • Article

Cet article s’applique à :✅ version 4.19.0 ✅ version 5.19.0

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

DefaultAzureCredential

Le 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 le DefaultAzureCredential combine 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.

Note

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.

Le DefaultAzureCredential tentera de s’authentifier via les mécanismes suivants dans l’ordre :

Diagramme montrant le mécanisme d’authentification pour « DefaultAzureCredential ».

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

Pourboire

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.

Note

É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é par az-identity-. Cette ThreadPoolTaskExecutor haricot est indépendante de la Executor bean fournie 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 managées fournissent une identité pour les applications à utiliser lors de la connexion aux ressources qui prennent 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 la chaîne de connexion ou la clé dans votre application, car elle est plus sécurisée et enregistre les problèmes de gestion des secrets et des informations d’identification. Dans ce cas, DefaultAzureCredential 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 d’utiliser l’identité managée.

Types d’identité managée

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

  • affectée 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é est créée dans Microsoft Entra lié au cycle de vie de cette instance de service. Par conséquent, lorsque la ressource est supprimée, Azure supprime automatiquement l’identité pour vous. Par conception, seule cette ressource Azure peut utiliser cette identité pour demander des jetons à partir de Microsoft Entra ID.
  • affectée 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’affecter à 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.

Note

Lorsque vous utilisez une identité managée affectée par l’utilisateur, vous pouvez spécifier l’ID client via spring.cloud.azure.credential.client-id ou spring.cloud.azure.<azure-service>.credential.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.

Pourboire

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 que votre scénario n’est pas servi par les DefaultAzureCredential ou les paramètres par défaut, vous devez utiliser d’autres types d’informations d’identification.

Authentification et autorisation avec l’ID Microsoft Entra

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 l’ID Microsoft Entra, l’accès à une ressource est un processus en deux étapes :

  1. Tout d’abord, l’identité du principal de sécurité est authentifiée et un jeton OAuth 2.0 est retourné.
  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 l’ID Microsoft Entra

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.
nom d’utilisateur 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.

Pourboire

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

L’application recherche plusieurs emplacements pour trouver des informations d’identification disponibles et 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>

Note

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

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>

Note

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

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>

Note

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

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>

Note

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

Autoriser l’accès avec l’ID Microsoft Entra

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

Pourboire

Pour obtenir la liste de tous les rôles intégrés Azure, consultez 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 Autorise l’accès complet aux données App Configuration.
lecteur de données App Configuration Autorise l’accès en lecture aux 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 Autorise l’accès aux ressources Azure Event Hubs.
l’expéditeur de données Azure Event Hubs Autorise l’accès aux ressources Azure Event Hubs.
propriétaire des 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.
l’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 complet aux conteneurs et données d’objets blob Stockage Azure, y compris l’attribution du contrôle d’accès POSIX.
Lecteur de données blob de stockage Lire et répertorier les conteneurs et objets blob stockage Azure.
lecteur de données de file d’attente de stockage Lire et répertorier les files d’attente et les messages de file d’attente stockage Azure.
contributeur cache Redis Gérer les caches Redis.

Note

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

Note

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 les secrets, clés et certificats 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 Affecter 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, la prise en charge du portail Azure pour 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 Microsoft Entra ID pour votre compte Azure Cosmos DB.

Jetons SAP

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 spring.cloud.azure.storage.blob.sas-token pour vous authentifier auprès du service Blob de stockage.

Chaînes de connexion

La chaîne de connexion 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 la chaîne de connexion, configurez simplement spring.cloud.azure.<azure-service>.connection-string. Par exemple, configurez spring.cloud.azure.eventhubs.connection-string pour vous connecter au service Event Hubs.