Partager via

Authentifiez les applications .NET auprès des services Azure à l'aide de la bibliothèque Azure Identity.

  • Article

Lorsqu'une application doit accéder à une ressource Azure, elle doit être authentifiée auprès d'Azure. Cela est vrai pour toutes les applications, qu'elles soient déployées sur Azure, déployées sur local ou en cours de développement sur un poste de travail de développeur local. Cet article décrit les approches recommandées pour authentifier une application auprès d'Azure lors de l'utilisation des bibliothèques client Azure SDK.

Il est recommandé que les applications utilisent l'authentification par jeton plutôt que des chaînes de connexion pour s'authentifier auprès des ressources Azure. La bibliothèque Azure Identity fournit des classes qui prennent en charge l'authentification par jeton et permettent aux applications de s'authentifier de manière transparente auprès des ressources Azure, que l'application soit en développement local, déployée sur Azure ou sur un serveur local.

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

Diagramme montrant les stratégies d'authentification par jeton recommandées pour une application en fonction de l'endroit où elle s'exécute.

Lorsqu'une application est :

  • Exécutée localement pendant le développement, l'application peut s'authentifier auprès d'Azure en utilisant soit un principe de service d'application pour le développement local, soit les informations d'identification Azure du développeur. Chaque option est discutée plus en détail lors de l'authentification au cours du développement local.
  • Hébergée sur Azure, l'application doit s'authentifier auprès des ressources Azure à l'aide d'une identité gérée. Cette option est décrite plus en détail dans l’authentification dans les environnements serveur.
  • Hébergée et déployée sur place, 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 dans l’authentification dans les environnements serveur.

DefaultAzureCredential

La classe DefaultAzureCredential fournie par la bibliothèque Azure Identity 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étectera et utilisera 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 de l'utilisation de DefaultAzureCredential sont abordés à la rubrique UtilisationDefaultAzureCredential dans une application.

Avantages de l'authentification par jeton

L'authentification basée sur des jetons offre les avantages suivants par rapport aux 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é gérée, il n'y a pas de secret d'application à stocker. L'application est donc plus sûre, car il n'y a pas de chaîne de connexion ou de secret d'application susceptible d'être compromis.
  • Le package Azure.Identity acquiert et gère pour vous les jetons Microsoft Identity. Cela rend l'utilisation de l'authentification basée sur les tokens aussi simple que l'utilisation d'une chaîne de connexion.

L'utilisation des chaînes de connexion doit être limitée aux applications de démonstration initiales ou aux prototypes de développement qui n'accèdent pas aux données de production ou aux données sensibles. Sinon, les classes d'authentification basées sur des jetons disponibles dans la bibliothèque Azure Identity doivent toujours être privilégiées lors de l'authentification aux ressources Azure.

Authentification dans les environnements serveur

Lors de l'hébergement dans un environnement serveur, chaque application doit se voir attribuer une identité d'application unique par environnement dans lequel l'application est exécutée. Dans Azure, l'identité d'une 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.

En savoir plus 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. Les AZURE_CLIENT_ID, AZURE_TENANT_IDet AZURE_CLIENT_SECRET seraient tous stockés en tant que variables d’environnement pour être lues par l’application au moment de l’exécution et pour permettre à l’application de s’authentifier auprès d’Azure à l’aide du principal du 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 lors d'un développement local, il doit tout de même s'authentifier auprès de tous les 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 sous forme de variables d’environnement pour être accessibles par l’application lorsqu’elle est exécutée dans un environnement de 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.

En savoir plus 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 ce cas, le développeur doit se connecter à Azure à partir de Visual Studio, de l'extension Azure Tools pour VS Code, d'Azure CLI ou d'Azure PowerShell sur son poste de travail local. L'application peut alors accéder aux informations d'identification du développeur à partir du magasin d'informations d'identification et utiliser ces informations d'identification pour accéder aux ressources Azure à partir de l'application.

Cette méthode présente l'avantage d'une installation plus facile, puisqu'un développeur n'a qu'à se connecter à son compte Azure à partir de Visual Studio, VS Code ou de l'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. Par conséquent, cette approche ne reproduit pas exactement les permissions avec lesquelles l'application fonctionnera en production.

En savoir plus sur l'authentification à partir d'applications hébergées par Azure

Utiliser DefaultAzureCredential dans une application

DefaultAzureCredential est une séquence ordonnée et fondée d’authentification auprès de Microsoft Entra ID. Chaque mécanisme d’authentification est une classe dérivée de la classe TokenCredential et est connu sous le nom de crédentiel. Au moment de l’exécution, DefaultAzureCredential tente de s’authentifier à l’aide du premier identifiant. Si ces informations d'identification ne parviennent pas à acquérir un jeton d'accès, les informations d'identification suivantes de la séquence sont utilisées, et ainsi de suite jusqu'à l'obtention d'un jeton d'accès. De cette façon, votre application peut utiliser différentes informations d'identification dans différents environnements sans qu'il soit nécessaire d'écrire du code propre à l'environnement.

Pour utiliser DefaultAzureCredential, ajoutez les packages Azure.Identity et éventuellement Microsoft.Extensions.Azure à votre application :

Dans un terminal de votre choix, accédez au répertoire du projet d'application et exécutez les commandes suivantes :

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

Les services Azure sont accessibles à l'aide de classes clientes spécialisées à partir des différentes bibliothèques de client du Kit de développement logiciel (SDK) Azure. Ces classes et vos propres services personnalisés doivent être enregistrés afin qu'ils soient accessibles via l'injection de dépendances dans l'ensemble de votre application. Dans Program.cs, effectuez les étapes suivantes pour enregistrer une classe client etDefaultAzureCredential :

  1. Inclure les espaces de noms Azure.Identity et Microsoft.Extensions.Azure via les directives using.
  2. Inscrivez le client du service Azure à l’aide de la méthode d’extension préfixée Addcorrespondante.
  3. Passez une instance de DefaultAzureCredential à la méthode UseCredential.

Exemple :

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

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

Une alternative à UseCredential est d'instancier DefaultAzureCredential directement :

using Azure.Identity;

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

Lorsque le code précédent s'exécute sur votre station de travail locale, il recherche dans les variables d'environnement un principal de service d'application ou dans les outils de développement installés localement, tels que Visual Studio, un ensemble d'informations d'identification du développeur. Vous pouvez utiliser l'une ou l'autre de ces approches 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 automatiquement les paramètres d’environnement et les configurations d’identité managée pour authentifier d'autres services.