Guide de migration d’AppAuthentication vers Azure.Identity

Lorsque la bibliothèque Microsoft.Azure.Services.AppAuthentication a été publiée pour la première fois à l’automne 2017, elle a été spécifiquement conçue pour aider à atténuer le problème commun et systémique des informations d’identification dans le code source. Il a introduit un nouveau paradigme pour le développement d’applications qui a permis aux développeurs d’écrire du code une fois et de permettre AppAuthentication à la bibliothèque cliente de déterminer comment s’authentifier en fonction de l’environnement d’application, que ce soit sur une station de travail de développeur à l’aide d’un compte de développeur ou déployée dans Azure à l’aide d’une identité de service managée. Les développeurs pourraient complètement éviter de gérer directement les informations d’identification, ce qui simplifie à la fois le développement et améliore la sécurité en empêchant la divulgation accidentelle des informations d’identification dans le code source. Compte tenu de ses avantages en matière de simplicité et de sécurité, AppAuthentication il a été bien accueilli par les développeurs. NuGet a reçu plus de 160 millions de téléchargements, et il a été utilisé dans d’autres bibliothèques et infrastructures pour les services Azure, tels que le fournisseur de configuration Azure Key Vault dans .NET Core et le kit SDK Microsoft.Azure.ServiceBus.

Publiée à l’automne 2019, la bibliothèque cliente Azure.Identity est le successeur spirituel de la AppAuthentication bibliothèque. Azure.Identity présente un avantage majeur par rapport AppAuthentication à sa disponibilité plus large dans plusieurs langages qui offrent une conception cohérente et une utilisation similaire entre ces langages, alors qu’il AppAuthentication n’était disponible que pour .NET. En plus de sa prise en charge de plusieurs langages, une fonctionnalité de conception clé d’Azure.Identity est ses différentes implémentations de la classe TokenCredential abstraite, que les sdk clients Azure plus récents acceptent. Ces sdk Azure plus récents se distinguent facilement par des noms de package et des espaces de noms qui commencent par « Azure », c’est-à-dire « Azure.Identity », « Azure.Storage.Blobs ». Pour l’authentification, le type souhaité d’objet TokenCredential est instancié et simplement passé directement à la classe cliente du KIT de développement logiciel (SDK) Azure. Cette conception offre à l’utilisation d’Azure.Identity un avantage de sécurité supplémentaire par rapport à l’utilisation d’AppAuthentication et d’anciens sdk qui nécessitent la spécification du jeton d’accès, car les jetons d’accès n’ont pas besoin d’être gérés directement par l’application elle-même. Cela atténue le risque supplémentaire de divulgation accidentelle de jetons d’accès par le biais de traces, de journaux et d’autres sources.

Si vous démarrez le développement d’une nouvelle application, il est vivement recommandé d’utiliser Azure.Identity et les nouveaux SDK du client Azure. Si vous disposez d’une application existante qui utilise AppAuthentication et que vous souhaitez utiliser Azure.Identity, le chemin d’accès préféré consiste à mettre à jour votre application pour utiliser les nouveaux SDK clients Azure qui prennent en charge l’acceptation de TokenCredentials. AppAuthentication est désormais considéré comme déprécié et il n’y aura plus d’investissement dans son développement. L’utilisation de DefaultAzureCredential dans Azure.Identity fournit des fonctionnalités similaires à AzureServiceTokenProvider dans AppAuthentication, où le fournisseur d’authentification utilisé change en fonction de l’environnement actuel. Si vous utilisez une chaîne de AppAuthentication connexion pour un fournisseur d’authentification spécifique à l’aide AppAuthenticationde , consultez le tableau ci-dessous pour voir comment utiliser le même fournisseur d’authentification en créant le JetonCredential approprié dans Azure.Identity.

Bien qu’Azure.Identity prenne en charge la plupart des scénarios d’authentification et des fournisseurs d’AppAuthentication, certains scénarios et fonctionnalités ne sont actuellement pas pris en charge :

• Fournisseur d’authentification intégré Windows

• Implémentation de System.Data.SqlClient.SqlAuthenticationProvider (SqlAppAuthenticationProvider)

  • Pour Microsoft.Data.SqlClient, consultez Authentification par défaut Active Directory. Ce mode d’authentification fournit des fonctionnalités similaires où DefaultAzureCredential est utilisé pour obtenir un jeton d’accès pour l’authentification auprès des instances SQL.

• Utiliser directement des certificats dans le magasin de certificats en tant qu’informations d’identification client (à l’aide du nom d’objet ou de l’identificateur d’empreinte numérique)

• Utiliser directement des certificats dans Key Vault comme informations d’identification client (à l’aide de Key Vault identificateur secret de certificat)

• Modifier le fournisseur d’authentification avec la configuration d’environnement (c’est-à-dire les chaînes de connexion dans AppAuthentication)

  • Prise en charge limitée dans Azure.Identity avec DefaultAzureCredential et EnvironmentCredential. Consultez variables d’environnement

• Déterminer le fournisseur d’authentification et l’identité utilisés pour l’authentification basée sur l’environnement (propriété AzureServiceTokenProvider.PrincipalUsed)

  • Peut déterminer le fournisseur d’authentification utilisé avec DefaultAzureCredential dans Azure.Identity à l’aide d’AzureEventSourceListener

Voici quelques exemples de migration d’un kit de développement logiciel (SDK) client Azure plus ancien à l’aide d’AppAuthentication vers la version plus récente du KIT de développement logiciel (SDK) du client Azure à l’aide d’Azure.Identity. Le code utilisant Azure.Identity est souvent beaucoup plus simple et plus simple que le code AppAuthentication

Microsoft.Azure.KeyVault vers Azure.Security.KeyVault :

• Utilisation de la AppAuthentication bibliothèque

AzureServiceTokenProvider tokenProvider = new AzureServiceTokenProvider();
var client = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(tokenProvider.KeyVaultTokenCallback));
var secretBundle = await client.GetSecretAsync("https://keyvaultname.vault.azure.net/secrets/secretname");

Console.WriteLine(secretBundle.Value);

• Utilisation de la Azure.Identity bibliothèque

var client = new SecretClient(new Uri("https://keyvaultname.vault.azure.net"), new DefaultAzureCredential());
var secret = client.GetSecret("secretName").Value;

Console.WriteLine(secret.Value);

Microsoft.Azure.Storage.Queues vers Azure.Storage.Queues :

• Utilisation de la AppAuthentication bibliothèque

var tokenProvider = new AzureServiceTokenProvider();
var accessToken = await tokenProvider.GetAccessTokenAsync("https://storageaccountname.queue.core.windows.net");

var tokenCredential = new StorageTokenCredential(accessToken);
var storageCredentials = new StorageCredentials(tokenCredential);

var uri = new StorageUri(new Uri("https://storageaccountname.queue.core.windows.net"));
var client = new CloudQueueClient(uri, storageCredentials);

var queue = client.GetQueueReference("queuename");
queue.AddMessage(new CloudQueueMessage("Microsoft.Azure.Storage.Queues"));

• Utilisation de la Azure.Identity bibliothèque

QueueClient queueClient = new QueueClient(new Uri("https://storageaccountname.queue.core.windows.net/queuename"), new DefaultAzureCredential());
queueClient.SendMessage("Azure.Storage.Queues");

Récupération des jetons d’accès

• Utilisation de la AppAuthentication bibliothèque

var tokenProvider = new AzureServiceTokenProvider();
var accessToken = await tokenProvider.GetAccessTokenAsync(ResourceId);

• Utilisation de la Azure.Identity bibliothèque

var tokenCredential = new DefaultAzureCredential();
var accessToken = await tokenCredential.GetTokenAsync(
    new TokenRequestContext(scopes: new string[] { ResourceId + "/.default" }) { }
);