Partager via

Guide de migration d’AppAuthentication vers Azure.Identity

  • Article

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.

Fournisseur d’authentification AppAuthentication
Chaîne de connexion		 Azure.Identity
TokenCredential
(par défaut) basé sur l’environnement Par défaut : aucune chaîne de connexion utilisée new DefaultAzureCredential()*
Azure CLI RunAs=Developer ;
DeveloperTool=AzureCli		 new AzureCliCredential()
Visual Studio RunAs=Developer ; DeveloperTool=VisualStudio new VisualStudioCredential()
Authentification Windows intégrée RunAs=CurrentUser Aucune prise en charge
Identité managée affectée par le système RunAs=App new ManagedIdentityCredential()
Identité managée affectée par l’utilisateur RunAs=App ; AppId=appId new ManagedIdentityCredential(appId)
Certificat client principal de service RunAs=App ; AppId=appId;
KeyVaultCertificateSecretIdentifier=kvIdentifier		 Aucune prise en charge
Certificat client principal de service RunAs=App ; AppId=appId; TenantId=tenantId;
CertificateThumbprint=empreinte numérique;
CertificateStoreLocation=location		 new EnvironmentCredential()**
new ClientCertificateCredential(tenantId, appId, certObjOrFilePath)
Certificat client principal de service RunAs=App ; AppId=appId; TenantId=tenantId;
CertificateSubjectName=subject;
CertificateStoreLocation=location		 new EnvironmentCredential()**
new ClientCertificateCredential(tenantId, appId, certObjOrFilePath)
Clé secrète client du principal de service RunAs=App ; AppId=appId; TenantId=tenantId;
AppKey=secret		 new EnvironmentCredential()**
new ClientSecretCredential(tenantId, appId, secret)

Notes

* Les fournisseurs d’authentification et l’ordre sont différents entre AzureServiceTokenProvider et DefaultAzureCredential
** Besoin de définir des variables d’environnement

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" }) { }
);

Notes

Vous trouverez plus d’informations sur l’étendue .defaultici.