Comment authentifier des applications .NET auprès des services Azure à l’aide du SDK .NET Azure

Lorsqu’une application doit accéder à une ressource Azure, comme un stockage, un coffre de clés ou des services cognitifs, l’application doit être authentifiée auprès d’Azure. Cela est vrai pour toutes les applications, qu’elles soient déployées sur Azure/localement ou en cours de développement sur une station de travail de développeur locale. Cet article décrit les approches recommandées pour authentifier une application auprès d’Azure lors de l’utilisation du SDK Azure pour .NET.

Approche d’authentification d’application recommandée

Il est recommandé que les applications utilisent l’authentification basée sur les jetons plutôt que les chaînes de connexion lors de l’authentification auprès des ressources Azure. Le SDK Azure pour .NET fournit des classes qui prennent en charge l’authentification basée sur les jetons et permettent aux applications de s’authentifier en toute transparence auprès des ressources Azure, que l’application soit en développement local/sur Azure ou déployée sur un serveur local.

Le type spécifique d’authentification basée sur les jetons qu’une application doit utiliser pour s’authentifier auprès des ressources Azure dépend de l’endroit où l’application est exécutée et est illustré dans le diagramme suivant.

• Lorsqu’un développeur exécute une application pendant le développement local - L’application peut s’authentifier auprès d’Azure à l’aide d’un principal de service d’application pour le développement local ou à l’aide des informations d’identification Azure du développeur. Chacune de ces options est décrite plus en détail dans la section Authentification pendant le développement local.
• Quand une application est hébergée sur Azure - L’application doit s’authentifier auprès des ressources Azure à l’aide d’une identité managée. Cette option est décrite plus en détail ci-dessous dans la section Authentification dans les environnements serveur.
• Quand une application est hébergée et déployée localement - L’application doit s’authentifier auprès des ressources Azure à l’aide d’un principal de service d’application. Cette option est décrite plus en détail ci-dessous dans la section Authentification dans les environnements serveur.

DefaultAzureCredential

La classe DefaultAzureCredential fournie par le SDK Azure permet aux applications d’utiliser différentes méthodes d’authentification en fonction de l’environnement dans lequel elles sont exécutées. Cela permet aux applications d’être promues du développement local aux environnements de test en production sans modification du code. Vous configurez la méthode d’authentification appropriée pour chaque environnement, et DefaultAzureCredential détecte et utilise automatiquement cette méthode d’authentification. L’utilisation de DefaultAzureCredential doit être préférable au codage manuel d’indicateurs de logique conditionnelle ou de fonctionnalités pour utiliser différentes méthodes d’authentification dans différents environnements.

Les détails sur l’utilisation de la classe DefaultAzureCredential sont abordés plus loin dans cet article, dans la section Utiliser DefaultAzureCredential dans une application.

Avantages de l’authentification par jeton

L’authentification basée sur les jetons est fortement recommandée par rapport à l’utilisation de chaînes de connexion lors de la création d’applications pour Azure. L’authentification basée sur les jetons offre les avantages suivants par rapport à l’authentification avec des chaînes de connexion.

• Les méthodes d’authentification basées sur les jetons décrites ci-dessous vous permettent d’établir les autorisations spécifiques nécessaires à l’application sur la ressource Azure. Cette approche suit le principe du moindre privilège. En revanche, une chaîne de connexion accorde des droits complets à la ressource Azure.
• Alors que toute personne ou application disposant d’une chaîne de connexion peut se connecter à une ressource Azure, les méthodes d’authentification basées sur les jetons permettent d’étendre l’accès à la ressource uniquement aux applications destinées à y accéder.
• Dans le cas d’une identité managée, il n’existe aucun secret d’application à stocker. Cela rend l’application plus sécurisée, car il n’y a pas de chaîne de connexion ou de secret d’application qui peut être compromis.
• Le package Azure.Identity dans le SDK Azure gère les jetons pour vous en arrière-plan. Cela facilite l’utilisation de l’authentification basée sur les jetons en tant que chaîne de connexion.

L’utilisation des chaînes de connexion doit être limitée aux applications de preuve de concept initiales ou aux prototypes de développement qui n’accèdent pas aux données de production ou sensibles. Sinon, les classes d’authentification basées sur les jetons disponibles dans le SDK Azure doivent toujours être préférées lors de l’authentification auprès des ressources Azure.

Authentification dans les environnements serveur

Lors de l’hébergement dans un environnement serveur, une identité d’application unique doit être attribuée à chaque application par environnement dans lequel l’application est exécutée. Dans Azure, une identité d’application est représentée par un principal de service, un type spécial de principal de sécurité destiné à identifier et authentifier les applications auprès d’Azure. Le type de principal de service à utiliser pour votre application dépend de l’emplacement d’exécution de votre application.

Méthode d'authentification	Description
Applications hébergées dans Azure	Les applications hébergées dans Azure doivent utiliser un principal de service d’identité managée. Les identités managées sont conçues pour représenter l’identité d’une application hébergée dans Azure et ne peuvent être utilisées qu’avec des applications hébergées par Azure. Par exemple, une application web .NET hébergée dans Azure App Service se verra attribuer une identité managée. L’identité managée affectée à l’application sera ensuite utilisée pour authentifier l’application auprès d’autres services Azure. Découvrir plus d’informations sur l’authentification à partir d’applications hébergées par Azure
Applications hébergées en dehors d’Azure (par exemple, applications locales)	Les applications hébergées en dehors d’Azure (par exemple, les applications locales) qui doivent se connecter aux services Azure doivent utiliser un principal de service d’application. Un principal de service d’application représente l’identité de l’application dans Azure, et il est créé par le biais du processus d’inscription de l’application. Prenons l’exemple d’une application web .NET hébergée localement qui utilise le Stockage Blob Azure. Vous devez créer un principal de service d’application pour l’application à l’aide du processus d’inscription d’application. AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_CLIENT_SECRET sont tous stockés en tant que variables d’environnement pour être lus par l’application au moment de l’exécution, et lui permettre de s’authentifier auprès d’Azure à l’aide du principal de service d’application. En savoir plus sur l’authentification à partir d’applications hébergées en dehors d’Azure

Authentification pendant le développement local

Lorsqu’une application est exécutée sur la station de travail d’un développeur pendant le développement local, elle doit toujours s’authentifier auprès des services Azure utilisés par l’application. Les deux principales stratégies d’authentification des applications auprès d’Azure pendant le développement local sont les suivantes :

Méthode d'authentification	Description
Créer des objets de principal de service d’application dédiés à utiliser pendant le développement local	Dans cette méthode, les objets de principal de service d’application dédiés sont configurés à l’aide du processus d’inscription d’application afin d’être utilisés pendant le développement local. L’identité du principal de service est ensuite stockée en tant que variable d’environnement à laquelle l’application accède lorsqu’elle est exécutée dans le développement local. Cette méthode vous permet d’affecter les autorisations de ressources nécessaires à l’application aux objets de principal de service qui sont utilisés par les développeurs pendant le développement local. Cela garantit que l’application aura uniquement accès aux ressources dont elle a besoin, et réplique les autorisations dont l’application disposera en production. L’inconvénient de cette approche est la nécessité de créer des objets de principal de service distincts pour chaque développeur qui travaille sur une application. Découvrir plus d’informations sur l’authentification à partir d’applications hébergées par Azure
Authentifier l’application auprès d’Azure à l’aide des informations d’identification du développeur pendant le développement local	Dans cette méthode, un développeur doit être connecté à Azure à partir de Visual Studio, de l’extension Azure Tools pour VS Code, de l’interface Azure CLI ou d’Azure PowerShell sur leur station de travail locale. L’application peut ensuite accéder aux informations d’identification du développeur dans le magasin d’informations d’identification et utiliser celles-ci pour accéder aux ressources Azure à partir de l’application. Cette méthode présente l’avantage d’une configuration plus facile, car un développeur doit uniquement se connecter à son compte Azure à partir de Visual Studio, de VS Code ou de l’interface Azure CLI. L’inconvénient de cette approche est que le compte du développeur dispose probablement de plus d’autorisations que n’en nécessite l’application. Cette approche ne réplique donc pas précisément les autorisations avec lesquelles l’application s’exécute en production. Découvrir plus d’informations sur l’authentification à partir d’applications hébergées par Azure

Utiliser DefaultAzureCredential dans une application

DefaultAzureCredential prend en charge plusieurs méthodes d’authentification et détermine la méthode d’authentification utilisée au moment de l’exécution. De cette façon, votre application peut utiliser différentes méthodes d’authentification dans différents environnements sans implémenter de code spécifique à l’environnement.

L’ordre et les emplacements dans lesquels DefaultAzureCredential recherchent les informations d’identification se trouvent dans DefaultAzureCredential.

Pour implémenter DefaultAzureCredential, ajoutez d’abord les packages Azure.Identity et éventuellement Microsoft.Extensions.Azure à votre application. Pour ce faire, utilisez la ligne de commande ou le Gestionnaire de package NuGet.

Ligne de commande

Ouvrez un environnement de terminal de votre choix dans le répertoire du projet d’application et entrez la commande ci-dessous.

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

Gestionnaire de package NuGet

Cliquez avec le bouton droit sur le nœud de votre projet dans Visual Studio, puis sélectionnez Gérer les packages NuGet. Recherchez Azure.Identity dans le champ de recherche, puis installez le package correspondant. Répétez également ce processus pour le package Microsoft.Extensions.Azure.

Les services Azure sont généralement accessibles à l’aide des classes clientes correspondantes à partir du SDK. Ces classes et vos propres services personnalisés doivent être inscrits dans le fichier Program.cs afin qu’ils soient accessibles via l’injection de dépendances dans votre application. À l’intérieur de Program.cs, suivez les étapes ci-dessous pour configurer correctement votre service et DefaultAzureCredential.

1. Incluez les espaces de noms Azure.Identity et Microsoft.Extensions.Azure avec une instruction using.
2. Inscrivez le service Azure à l’aide des méthodes d’assistance appropriées.
3. Passez une instance de l’objet DefaultAzureCredential à la méthode UseCredential.

Un exemple de cela est illustré dans le segment de code suivant.

using Microsoft.Extensions.Azure;
using Azure.Identity;

// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
    x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
    x.UseCredential(new DefaultAzureCredential());
});

Vous pouvez également utiliser plus directement DefaultAzureCredential dans vos services sans l’aide de méthodes d’inscription Azure supplémentaires, comme indiqué ci-dessous.

using Azure.Identity;

// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x => 
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

Lorsque le code ci-dessus est exécuté sur votre station de travail locale pendant le développement local, il recherche dans les variables d’environnement un principal de service d’application ou dans Visual Studio, VS Code, Azure CLI ou Azure PowerShell un ensemble d’informations d’identification de développeur, qui peuvent être utilisées pour authentifier l’application auprès des ressources Azure pendant le développement local.

Lorsqu’il est déployé sur Azure, ce même code peut également authentifier votre application auprès d’autres ressources Azure. DefaultAzureCredential peut récupérer les paramètres d’environnement et les configurations d’identité managée pour s’authentifier automatiquement auprès d’autres services.

Exploration de la séquence des méthodes d’authentification DefaultAzureCredential

En interne, DefaultAzureCredential implémente une chaîne de fournisseurs d’informations d’identification pour l’authentification des applications auprès des ressources Azure. Chaque fournisseur d’informations d’identification est en mesure de détecter si les informations d’identification de ce type sont configurées pour l’application. DefaultAzureCredential vérifie séquentiellement chaque fournisseur dans l’ordre et utilise les informations d’identification du premier fournisseur sur lequel les informations d’identification sont configurées.

L’ordre et les emplacements dans lesquels DefaultAzureCredential recherchent les informations d’identification se trouvent dans DefaultAzureCredential.

Type d'informations d'identification	Description
principal de service d’application	DefaultAzureCredential lit un ensemble de variables d’environnement pour déterminer si un principal de service d’application (utilisateur d’application) a été défini pour l’application. Si c’est le cas, DefaultAzureCredential utilise ces valeurs pour authentifier l’application auprès d’Azure. Cette méthode est le plus souvent utilisée dans les environnements serveur, mais peut également être utilisée lors du développement local.
Identité managée	Si l’application est déployée sur un hôte Azure avec l’identité managée activée, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de cette identité managée. L’authentification à l’aide d’une identité managée est décrite dans la section Authentification dans les environnements serveur de ce document. Cette méthode n’est disponible que lorsqu’une application est hébergée dans Azure à l’aide d’un service comme Azure App Service, Azure Functions ou les machines virtuelles Azure.
Visual Studio	Si le développeur s’est authentifié auprès d’Azure en se connectant à Visual Studio, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de ce même compte.
Visual Studio Code	Si le développeur s’est authentifié auprès d’Azure à l’aide du plug-in de compte Azure Visual Studio Code, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de ce même compte.
Azure CLI	Si un développeur s’est authentifié auprès d’Azure à l’aide de la commande az login dans Azure CLI, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de ce même compte.
Azure PowerShell	Si un développeur s’est authentifié auprès d’Azure à l’aide de la cmdlet Azure PowerShell Connect-AzAccount, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de ce même compte.
Interactive	Si cette option est activée, DefaultAzureCredential authentifie le développeur de manière interactive via le navigateur par défaut du système actuel. Par défaut, cette option est désactivée.