Exécuter des tests d’intégration automatisés

  • Article

En tant que développeur, vous voulez exécuter des tests d’intégration automatisés sur les applications que vous développez. Appeler votre API protégée par la plateforme d’identité Microsoft (ou d’autres API protégées comme Microsoft Graph) dans des tests d’intégration automatisés est une opération difficile. Microsoft Entra ID nécessite souvent une invite de connexion utilisateur interactive, difficile à automatiser. Cet article explique comment vous pouvez utiliser un flux non interactif, appelé ROPC (octroi d’informations d’identification par mot de passe du propriétaire des ressources), pour connecter automatiquement des utilisateurs à des fins de test.

Pour préparer vos tests d’intégration automatisés, créez des utilisateurs de test, créez et configurez une inscription d’application et apportez d’éventuelles modifications de configuration à votre locataire. Certaines de ces étapes nécessitent des privilèges administratifs. De plus, Microsoft vous recommande de ne pas utiliser le flux ROPC dans un environnement de production. Créez un locataire de test distinct dont vous êtes administrateur pour pouvoir exécuter vos tests d’intégration automatisés de manière sécurisée et efficace.

Avertissement

Microsoft vous recommande de ne pas utiliser le flux ROPC dans un environnement de production. Dans la plupart des scénarios de production, des alternatives plus sécurisées sont disponibles et recommandées. Le flux ROPC nécessite un degré de confiance très élevé dans l’application et comporte des risques qui ne sont pas présents dans d’autres flux d’authentification. Vous devez uniquement utiliser ce flux à des fins de test dans un locataire de test distinct, et uniquement avec des utilisateurs de test.

Important

  • La plateforme d’identité Microsoft prend en charge ROPC uniquement dans les locataires Microsoft Entra, et non les comptes personnels. Cela signifie que vous devez utiliser un point de terminaison spécifique au locataire (https://login.microsoftonline.com/{TenantId_or_Name}) ou le point de terminaison organizations.
  • Les comptes personnels qui sont invités sur un locataire Microsoft Entra ne peuvent pas utiliser ROPC.
  • Les comptes sans mots de passe ne peuvent pas se connecter avec ROPC, ce qui signifie que les fonctionnalités telles que la connexion SMS, FIDO et l’application Authenticator ne fonctionneront pas avec ce flux.
  • Si les utilisateurs doivent utiliser l’authentification multifacteur (MFA) pour se connecter à l’application, ils seront au lieu de cela bloqués.
  • ROPC n’est pas pris en charge dans les scénarios de fédération d’identités hybrides (par exemple, Microsoft Entra ID et les services de fédération Active Directory (AD FS) utilisés pour authentifier des comptes locaux). Si les utilisateurs sont redirigés en page complète vers un fournisseur d’identité local, Microsoft Entra ID ne peut pas tester le nom d’utilisateur et le mot de passe sur ce fournisseur d’identité. L’authentification directe est toutefois prise en charge avec ROPC.
  • Voici une exception à un scénario de fédération d’identités hybrides : la stratégie de découverte du domaine d’accueil avec l’ensemble AllowCloudPasswordValidation défini sur TRUE permet au flux ROPC de fonctionner pour les utilisateurs fédérés lorsque le mot de passe local est synchronisé avec le Cloud. Pour plus d’informations, consultez Activer l’authentification ROPC directe des utilisateurs fédérés pour les applications héritées.

Créer un locataire de test distinct

L’utilisation du flux d’authentification ROPC est risquée dans un environnement de production, donc créez un locataire distinct pour tester vos applications. Vous pouvez utiliser un locataire de test existant, mais vous devez être administrateur dans ce locataire, car certaines des étapes suivantes nécessitent des privilèges administratifs.

Création et configuration d’un coffre de clés

Nous vous recommandons de stocker de manière sécurisée les noms d’utilisateur de test et les mots de passe sous forme de secrets dans Azure Key Vault. Quand vous exécutez les tests ultérieurement, ceux-si s’exécutent dans le contexte d’un principal de sécurité. Le principal de sécurité est un utilisateur Microsoft Entra si vous exécutez les tests localement (par exemple, dans Visual Studio ou Visual Studio Code), ou un principal de service ou une identité managée si vous exécutez les tests dans Azure Pipelines ou une autre ressource Azure. Le principal de sécurité doit être autorisé à lire et lister les secrets pour que l’exécuteur de tests puisse obtenir les noms d’utilisateur de test et les mots de passe auprès de votre coffre de clés. Pour plus d’informations, consultez Authentification dans Azure Key Vault.

  1. Créez un coffre de clés si vous n’en avez pas encore un.
  2. Notez la valeur de la propriété URI du coffre (similaire à https://<your-unique-keyvault-name>.vault.azure.net/), utilisée dans l’exemple de test mentionné plus loin dans cet article.
  3. Affectez une stratégie d’accès pour le principal de sécurité qui exécute les tests. Autorisez l’utilisateur, le principal de service ou l’identité managée à obtenir et lister les secrets dans le coffre de clés.

Créer des utilisateurs de test

Conseil

Les étapes décrites dans cet article peuvent varier légèrement en fonction du portail de départ.

Créez des utilisateurs de test dans votre locataire à des fins de test. Étant donné que les utilisateurs de test ne sont pas de véritables personnes, nous vous recommandons de leur attribuer des mots de passe complexes et de les stocker de manière sécurisée sous forme de secrets dans Azure Key Vault.

  1. Connectez-vous au Centre d’administration de Microsoft Entra au minimum en tant qu’Administrateur d’application cloud.
  2. Accédez à Identité>Utilisateurs>Tous les utilisateurs.
  3. Sélectionnez Nouvel utilisateur et créez un ou plusieurs comptes d’utilisateur de test dans votre annuaire.
  4. L’exemple de test mentionné plus loin dans cet article utilise un seul utilisateur de test. Ajoutez le nom d’utilisateur de test et le mot de passe sous forme de secrets dans le coffre de clés que vous avez créé précédemment. Ajoutez le nom d’utilisateur sous forme de secret nommé « TestUserName » et le mot de passe sous forme de secret nommé « TestPassword ».

Créer et configurer une inscription d’application

Inscrivez une application qui sert d’application cliente lors de l’appel d’API pendant les tests. Il ne doit pas s’agir de la même application que celle que vous avez déjà en production. Vous devez disposer d’une application distincte à utiliser uniquement à des fins de test.

Inscrire une application

Créer une inscription d’application. Vous pouvez suivre les étapes indiquées dans le guide de démarrage rapide de l’inscription d’application. Vous n’avez pas besoin d’ajouter un URI de redirection ni d’ajouter des informations d’identification. Vous pouvez donc ignorer ces sections.

Notez la valeur de l’ID d’application (client), utilisée dans l’exemple de test mentionné plus loin dans cet article.

Activer votre application pour les flux clients publics

Le flux ROPC étant un flux client public, vous avez besoin d’activer votre application pour les flux clients publics. À partir de l’inscription de votre application dans le centre d’administration Microsoft Entra, accédez à Authentification>Paramètres avancés>Autoriser les flux clients publics. Définissez le bouton bascule sur Oui.

Étant donné que le flux ROPC n’est pas un flux interactif, aucun écran vous invitant à confirmer ces autorisations ne s’affichera au moment de l’exécution. Acceptez les autorisations au préalable pour éviter des erreurs lors de l’acquisition de jetons.

Ajoutez les autorisations à votre application. N’ajoutez pas d’autorisations sensibles ni hautement privilégiées à l’application. Nous vous recommandons de limiter vos scénarios de test à des scénarios d’intégration de base à Microsoft Entra ID.

À partir de l’inscription de votre application dans le centre d’administration Microsoft Entra, accédez à Autorisations de l’API>Ajouter une autorisation. Ajoutez les autorisations dont vous avez besoin pour appeler les API que vous allez utiliser. Un exemple de test donné plus loin dans cet article utilise les autorisations https://graph.microsoft.com/User.Read et https://graph.microsoft.com/User.ReadBasic.All.

Une fois les autorisations ajoutées, vous avez besoin de les accepter. L’acceptation des autorisations dépend du fait que votre application de test se trouve ou non dans le même locataire que l’inscription de l’application et du fait que vous êtes ou non administrateur dans le locataire.

L’application et l’inscription de l’application se trouvent dans le même locataire et vous êtes administrateur

Si vous envisagez de tester votre application dans le même locataire que celui dans lequel vous l’avez inscrite et que vous êtes administrateur dans ce locataire, vous pouvez accepter les autorisations à partir du centre d’administration Microsoft Entra. Dans l’inscription de votre application dans le portail Azure, accédez à Autorisations de l’API et sélectionnez le bouton Accorder un consentement d’administrateur pour <nom_de_votre_locataire> en regard du bouton Ajouter une autorisation, puis sélectionnez Oui pour confirmer.

L’application et l’inscription de l’application se trouvent dans des locataires différents ou vous n’êtes pas administrateur

Si vous n’envisagez pas de tester votre application dans le même locataire que celui dans lequel vous l’avez inscrite ou que vous n’êtes pas administrateur dans votre locataire, vous ne pouvez pas accepter les autorisations à partir du centre d’administration Microsoft Entra. Vous pouvez quand même donner votre consentement à certaines autorisations, en déclenchant une invite de connexion dans un navigateur web.

Dans l’inscription de votre application dans le centre d’administration Microsoft Entra, accédez à Authentification>Configurations de plateforme>Ajouter une plateforme>Web. Ajoutez l’URI de redirection "https://localhost", puis sélectionnez Configurer.

Il n’existe aucun moyen pour les utilisateurs non-administrateurs de donner leur consentement préalable par le biais du portail Azure. Envoyez alors la requête suivante dans un navigateur. Quand l’écran de connexion s’affiche, connectez-vous avec un compte de test que vous avez créé à l’étape précédente. Acceptez les autorisations qui vous sont proposées. Vous devrez peut-être répéter cette étape pour chaque API à appeler et chaque utilisateur de test à utiliser.

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id={your_client_ID}
&response_type=code
&redirect_uri=https://localhost
&response_mode=query
&scope={resource_you_want_to_call}/.default
&state=12345

Remplacez {locataire} par votre ID de locataire, {votre_ID_client} par l’ID client de votre application et {ressource_à_appeler} par l’URI de l’identificateur (par exemple, "https://graph.microsoft.com") ou l’ID d’application de l’API à laquelle vous tentez d’accéder.

Exclure des applications et utilisateurs de test de votre stratégie MFA

Votre locataire a probablement une stratégie d’accès conditionnel qui nécessite une authentification multifacteur (MFA) pour tous les utilisateurs, comme recommandé par Microsoft. L’authentification multifacteur ne fonctionne pas avec le flux ROPC. Vous devez donc exempter vos applications et utilisateurs de test de cette exigence.

Pour exclure des comptes d’utilisateur :

  1. Connectez-vous au Centre d’administration de Microsoft Entra au minimum en tant qu’Administrateur d’application cloud.
  2. Accédez à Identité>Security Center dans le volet de navigation gauche, puis sélectionnez Accès conditionnel.
  3. Dans Stratégies, sélectionnez la stratégie d’accès conditionnel qui exige une authentification MFA.
  4. Sélectionnez Utilisateurs ou identités de charge de travail.
  5. Sélectionnez l’onglet Exclure, puis cochez la case Utilisateurs et groupes.
  6. Sélectionnez les comptes d’utilisateur à exclure dans Sélectionner les utilisateurs exclus.
  7. Sélectionnez le bouton Sélectionner, puis Enregistrer.

Pour exclure une application de test :

  1. Dans Stratégies, sélectionnez la stratégie d’accès conditionnel qui exige une authentification MFA.
  2. Sélectionnez Applications ou actions cloud.
  3. Sélectionnez l’onglet Exclure, puis cochez Sélectionner les applications cloud exclues.
  4. Sélectionnez les applications à exclure dans Sélectionner les applications cloud exclues.
  5. Sélectionnez le bouton Sélectionner, puis Enregistrer.

Écrire vos tests d’application

Maintenant que vous êtes prêt, vous pouvez écrire vos tests automatisés. Les éléments suivants sont des tests pour :

  1. L’exemple de code .NET utilise la Bibliothèque d’authentification Microsoft (MSAL) et xUnit, une infrastructure de test courante.
  2. L’exemple de code JavaScript suivant utilise la Bibliothèque d’authentification Microsoft (MSAL) et Playwright, une infrastructure de test courante.

Configurer votre fichier appsettings.json

Ajoutez l’ID client de l’application de test que vous avez créée précédemment, les étendues nécessaires et l’URI du coffre de clés au fichier appsettings.json de votre projet de test.

{
  "Authentication": {
    "AzureCloudInstance": "AzurePublic", //Will be different for different Azure clouds, like US Gov
    "AadAuthorityAudience": "AzureAdMultipleOrgs",
    "ClientId": <your_client_ID>
  },

  "WebAPI": {
    "Scopes": [
      //For this Microsoft Graph example.  Your value(s) will be different depending on the API you're calling
      "https://graph.microsoft.com/User.Read",
      //For this Microsoft Graph example.  Your value(s) will be different depending on the API you're calling
      "https://graph.microsoft.com/User.ReadBasic.All"
    ]
  },

  "KeyVault": {
    "KeyVaultUri": "https://<your-unique-keyvault-name>.vault.azure.net//"
  }
}

Configurer votre client pour une utilisation dans toutes vos classes de test

Utilisez SecretClient() pour obtenir les secrets nom d’utilisateur de test et mot de passe auprès d’Azure Key Vault. Le code utilise un backoff exponentiel pour les nouvelles tentatives en cas de limitation du coffre de clés.

DefaultAzureCredential() s’authentifie auprès d’Azure Key Vault en obtenant un jeton d’accès issu d’un principal de service configuré par des variables d’environnement ou une identité managée (si le code s’exécute sur une ressource Azure avec une identité managée). Si le code s’exécute localement, DefaultAzureCredential utilise les informations d’identification de l’utilisateur local. Pour plus d’informations, consultez le contenu de la bibliothèque cliente Azure Identity.

Utilisez la bibliothèque d’authentification Microsoft (MSAL) pour vous authentifier à l’aide du flux ROPC et obtenir un jeton d’accès. Le jeton d’accès est transmis en tant que porteur dans la requête HTTP.

using Xunit;
using System.Threading.Tasks;
using Microsoft.Identity.Client;
using System.Security;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using Microsoft.Extensions.Configuration;
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using Azure.Core;
using System;

public class ClientFixture : IAsyncLifetime
{
    public HttpClient httpClient;

    public async Task InitializeAsync()
    {
        var builder = new ConfigurationBuilder().AddJsonFile("<path-to-json-file>");

        IConfigurationRoot Configuration = builder.Build();

        var PublicClientApplicationOptions = new PublicClientApplicationOptions();
        Configuration.Bind("Authentication", PublicClientApplicationOptions);
        var app = PublicClientApplicationBuilder.CreateWithApplicationOptions(PublicClientApplicationOptions)
            .Build();

        SecretClientOptions options = new SecretClientOptions()
        {
            Retry =
                {
                    Delay= TimeSpan.FromSeconds(2),
                    MaxDelay = TimeSpan.FromSeconds(16),
                    MaxRetries = 5,
                    Mode = RetryMode.Exponential
                 }
        };

        string keyVaultUri = Configuration.GetValue<string>("KeyVault:KeyVaultUri");
        var client = new SecretClient(new Uri(keyVaultUri), new DefaultAzureCredential(), options);

        KeyVaultSecret userNameSecret = client.GetSecret("TestUserName");
        KeyVaultSecret passwordSecret = client.GetSecret("TestPassword");

        string password = passwordSecret.Value;
        string username = userNameSecret.Value;
        string[] scopes = Configuration.GetSection("WebAPI:Scopes").Get<string[]>();
        SecureString securePassword = new NetworkCredential("", password).SecurePassword;

        AuthenticationResult result = null;
        httpClient = new HttpClient();

        try
        {
            result = await app.AcquireTokenByUsernamePassword(scopes, username, securePassword)
                .ExecuteAsync();
        }
        catch (MsalException) { }

        string accessToken = result.AccessToken;
        httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("bearer", accessToken);
    }

    public Task DisposeAsync() => Task.CompletedTask;
}

Utilisation dans vos classes de test

L’exemple suivant est un test qui appelle Microsoft Graph. Remplacez ce test par ce que vous voulez tester sur votre propre application ou API.

public class ApiTests : IClassFixture<ClientFixture>
{
    ClientFixture clientFixture;

    public ApiTests(ClientFixture clientFixture)
    {
        this.clientFixture = clientFixture;
    }

    [Fact]
    public async Task GetRequestTest()
    {
        var testClient = clientFixture.httpClient;
        HttpResponseMessage response = await testClient.GetAsync("https://graph.microsoft.com/v1.0/me");
        var responseCode = response.StatusCode.ToString();
        Assert.Equal("OK", responseCode);
    }
}