Guide du développeur sur le contexte d’authentification de l’accès conditionnel

  • Article

L’accès conditionnel est le plan de contrôle Zero Trust qui vous permet de cibler des stratégies d’accès pour toutes vos applications (anciennes ou nouvelles, privées ou publiques, locales ou multiclouds). Grâce au contexte d’authentification de l’accès conditionnel, vous pouvez appliquer différentes stratégies au sein de ces applications.

Le contexte d’authentification de l’accès conditionnel (contexte d’authentification) vous permet d’appliquer des stratégies granulaires aux actions et données sensibles plutôt qu’au niveau de l’application. Vous pouvez affiner vos stratégies Zero Trust pour l’accès le moins privilégié tout en réduisant au minimum la friction de l’utilisateur et en gardant les utilisateurs plus productifs et vos ressources plus sécurisées. Aujourd’hui, cela est utilisé par les applications se servant d’OpenID Connect pour l’authentification développée par votre entreprise afin de protéger des ressources sensibles, comme les transactions de grande valeur ou la consultation des données personnelles des employés.

Pour déclencher un passage à une édition supérieure de l’authentification depuis votre application et vos services, utilisez la fonctionnalité de contexte d’authentification du moteur d’accès conditionnel Microsoft Entra. Les développeurs ont désormais la possibilité d’exiger de leurs utilisateurs finaux une authentification renforcée, de manière sélective (p. ex. : l’authentification multifacteur), à partir de leurs applications. Cette fonctionnalité aide les développeurs à créer des expériences utilisateur plus fluides pour la plupart des parties de leur application, tandis que l’accès à des opérations et des données plus sécurisées demeure derrière des contrôles d’authentification plus forts.

Définition du problème

Les administrateurs et régulateurs informatiques ont souvent du mal à trouver un équilibre entre le fait d’inviter trop fréquemment leurs utilisateurs à utiliser des facteurs d’authentification supplémentaires et celui d’assurer une sécurité adéquate et le respect des stratégies pour les applications et les services pouvant contenir des données et des opérations sensibles. Il faut parfois choisir entre une stratégie forte qui a un impact sur la productivité des utilisateurs lorsqu’ils accèdent à la plupart des données et des actions et une stratégie qui n’est pas suffisamment forte pour les ressources sensibles.

Ainsi, que se passerait-il si les applications pouvaient combiner les deux, en fonctionnant avec une sécurité relativement moindre et des invites moins fréquentes pour la plupart des utilisateurs et des opérations, tout en renforçant de manière conditionnelle les exigences de sécurité lorsque les utilisateurs accèdent à des parties plus sensibles ?

Scénarios courants

Par exemple, si les utilisateurs peuvent se connecter à SharePoint en utilisant l’authentification multifacteur, l’accès à la collection de sites dans un SharePoint contenant des documents sensibles peut nécessiter un appareil conforme et se faire uniquement à partir de plages d’adresses IP approuvées.

Prérequis

Tout d’abord, votre application doit être intégrée à la plateforme d’identités Microsoft à l’aide des protocoles OpenID Connect/ OAuth 2.0 pour l’authentification et l’autorisation. Nous vous recommandons d’utiliser les bibliothèques d’authentification de la plateforme d’identités Microsoft pour intégrer et sécuriser votre application avec Microsoft Entra ID. La documentation de la plateforme d’identités Microsoft est un bon point de départ pour apprendre à intégrer vos applications à la plateforme d’identités Microsoft. La prise en charge de la fonctionnalité du contexte d’authentification de l’accès conditionnel repose sur les extensions de protocole fournies par le protocole OpenID Connect standard. Les développeurs utilisent une valeur de référence pour le contexte d’authentification de l’accès conditionnel avec le paramètre Demande de revendications pour permettre aux applications de déclencher et de satisfaire la stratégie.

Deuxièmement, l’accès conditionnel nécessite une licence Microsoft Entra ID P1. Pour plus d’informations sur les licences, consultez la page de tarification de Microsoft Entra.

Troisièmement, à l’heure actuelle, la fonctionnalité est disponible uniquement pour les applications qui connectent les utilisateurs. Les applications qui s’authentifient elles-mêmes ne sont pas prises en charge. Pour en savoir plus sur les types d’applications et les flux d’authentification pris en charge par la plateforme d’identités Microsoft, utilisez le guide relatif aux flux d’authentification et aux scénarios d’applications.

Étapes d'intégration

Une fois que votre application est intégrée à l’aide des protocoles d’authentification pris en charge et qu’elle est inscrite dans un locataire Microsoft Entra disposant de la fonctionnalité d’accès conditionnel, vous pouvez commencer à intégrer cette fonctionnalité dans vos applications qui connectent les utilisateurs.

Remarque

Une présentation détaillée de cette fonctionnalité est également disponible sous la forme d’une session enregistrée : Utiliser le contexte d’authentification de l’accès conditionnel dans votre application pour une authentification renforcée.

Premièrement : Déclarez les contextes d’authentification et rendez-les disponibles dans votre locataire. Pour plus d’informations, consultez Configurer les contextes d’authentification.

Les valeurs C1 à C99 peuvent être utilisées comme ID de contexte d’authentification dans un locataire. Voici quelques exemples de contexte d’authentification :

  • C1 : Exiger une authentification forte
  • C2 : Exiger des appareils conformes
  • C3 : Exiger des emplacements approuvés

Créez ou modifiez vos stratégies d’accès conditionnel afin d’utiliser les contextes d’authentification d’accès conditionnel. Voici quelques exemples de stratégies :

  • Tous les utilisateurs qui se connectent à cette application web doivent avoir réussi l’authentification à deux facteurs pour l’ID de contexte d’authentification C1.
  • Tous les utilisateurs qui se connectent à cette application web doivent avoir réussi l’authentification à deux facteurs et accéder à l’application web à partir d’une certaine plage d’adresses IP pour l’ID de contexte d’authentification C3.

Notes

Les valeurs de contexte d’authentification de l’accès conditionnel sont déclarées et gérées séparément des applications. Il n’est pas recommandé que les applications dépendent fortement des ID de contexte d’authentification. Les stratégies d’accès conditionnel sont généralement conçues par les administrateurs informatiques, car ils ont une meilleure compréhension des ressources disponibles sur lesquelles appliquer les stratégies. Par exemple, pour un locataire Microsoft Entra, les administrateurs informatiques savent combien d’utilisateurs du locataire sont équipés pour utiliser l’authentification à deux facteurs pour l’authentification multifacteur et peuvent donc s’assurer que les stratégies d’accès conditionnel qui requièrent l’authentification à deux facteurs sont limitées à ces utilisateurs équipés. De même, si l’application est utilisée dans plusieurs locataires, les ID de contexte d’authentification utilisés peuvent être différents et, dans certains cas, ne pas être disponibles du tout.

Deuxièmement : Il est conseillé aux développeurs d’une application prévoyant d’utiliser un contexte d’authentification de l’accès conditionnel de fournir d’abord aux administrateurs de l’application ou aux administrateurs informatiques un moyen de mapper les actions potentiellement sensibles à des ID de contexte d’authentification. Les étapes sont à peu près les suivantes :

  1. Identifiez les actions dans le code qui peuvent être mises à disposition pour être mappées à des ID de contexte d’authentification.
  2. Créez un écran dans le portail d’administration de l’application (ou une fonctionnalité équivalente) que les administrateurs informatiques peuvent utiliser pour mapper des actions sensibles à un ID de contexte d’authentification disponible.
  3. Consultez l’exemple de code sur la page Utilisez le contexte d’authentification de l’accès conditionnel pour effectuer une authentification renforcée pour obtenir un exemple sur la façon de procéder.

Ces étapes sont les modifications que vous devez apporter à votre base de code. Les étapes sont essentiellement les suivantes :

  • Interrogez MS Graph pour répertorier tous les contextes d’authentification disponibles.
  • Permettez aux administrateurs informatiques de sélectionner les opérations sensibles ou à privilèges élevés et de les assigner aux contextes d’authentification disponibles à l’aide des stratégies d’autorité de certification.
  • Enregistrez ces informations de mappage dans votre base de données ou votre magasin local.

Flux de configuration pour la création d’un contexte d’authentification

Troisièmement : Votre application (pour cet exemple, nous supposons qu’il s’agit d’une API web) doit ensuite évaluer les appels par rapport au mappage sauvegardé et déclencher en conséquence les défis de revendication pour ses applications clientes. Pour vous préparer à cette action, procédez comme suit :

  1. Dans une opération sensible et protégée par le contexte d’authentification, évaluez les valeurs de la revendication acrs par rapport aux mappages d’ID de contexte d’authentification (enregistrés précédemment) et déclenchez un défi de revendications comme indiqué dans l’extrait de code suivant.

  2. Le diagramme suivant illustre l’interaction entre l’utilisateur, l’application cliente et l’API web.

    Diagramme montrant l’interaction entre l’utilisateur, l’application web, l’API et Microsoft Entra ID

    L’extrait de code suivant provient de l’exemple de code de la page Use the Conditional Access Auth Context to perform step-up authentication (Utiliser le contexte d’authentification de l’accès conditionnel pour effectuer une authentification renforcée). La première méthode (CheckForRequiredAuthContext() dans l’API) :

    • vérifie si l’action de l’application appelée requiert une authentification renforcée. Pour ce faire, elle recherche dans sa base de données un mappage enregistré pour cette méthode ;
    • si cette action nécessite effectivement un contexte d’authentification élevé, elle vérifie dans la revendication acrs s’il existe un ID de contexte d’authentification correspondant ;
    • Si aucun ID de contexte d’authentification correspondant n’est trouvé, cela déclenche un défi de revendications.
    public void CheckForRequiredAuthContext(string method)
{
    string authType = _commonDBContext.AuthContext.FirstOrDefault(x => x.Operation == method
                && x.TenantId == _configuration["AzureAD:TenantId"])?.AuthContextId;

    if (!string.IsNullOrEmpty(authType))
    {
        HttpContext context = this.HttpContext;
        string authenticationContextClassReferencesClaim = "acrs";

        if (context == null || context.User == null || context.User.Claims == null
            || !context.User.Claims.Any())
        {
            throw new ArgumentNullException("No Usercontext is available to pick claims from");
        }

        Claim acrsClaim = context.User.FindAll(authenticationContextClassReferencesClaim).FirstOrDefault(x
            => x.Value == authType);

        if (acrsClaim == null || acrsClaim.Value != authType)
        {
            if (IsClientCapableofClaimsChallenge(context))
            {
                string clientId = _configuration.GetSection("AzureAd").GetSection("ClientId").Value;
                var base64str = Convert.ToBase64String(Encoding.UTF8.GetBytes("{\"access_token\":{\"acrs\":{\"essential\":true,\"value\":\"" + authType + "\"}}}"));

                context.Response.Headers.Append("WWW-Authenticate", $"Bearer realm=\"\", authorization_uri=\"https://login.microsoftonline.com/common/oauth2/authorize\", client_id=\"" + clientId + "\", error=\"insufficient_claims\", claims=\"" + base64str + "\", cc_type=\"authcontext\"");
                context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
                string message = string.Format(CultureInfo.InvariantCulture, "The presented access tokens had insufficient claims. Please request for claims requested in the WWW-Authentication header and try again.");
                context.Response.WriteAsync(message);
                context.Response.CompleteAsync();
                throw new UnauthorizedAccessException(message);
            }
            else
            {
                throw new UnauthorizedAccessException("The caller does not meet the authentication  bar to carry our this operation. The service cannot allow this operation");
            }
        }
    }
}

    Notes

    Le format du défi de revendications est décrit dans l’article Défi de revendications sur la plateforme d’identités Microsoft.

  3. Dans l’application cliente, interceptez le défi de revendications et redirigez l’utilisateur vers Microsoft Entra ID pour une évaluation plus approfondie des stratégies. L’extrait de code suivant provient de l’exemple de code de la page Use the Conditional Access Auth Context to perform step-up authentication (Utiliser le contexte d’authentification de l’accès conditionnel pour effectuer une authentification renforcée).

    internal static string ExtractHeaderValues(WebApiMsalUiRequiredException response)
{
    if (response.StatusCode == System.Net.HttpStatusCode.Unauthorized && response.Headers.WwwAuthenticate.Any())
    {
        AuthenticationHeaderValue bearer = response.Headers.WwwAuthenticate.First(v => v.Scheme == "Bearer");
        IEnumerable<string> parameters = bearer.Parameter.Split(',').Select(v => v.Trim()).ToList();
        var errorValue = GetParameterValue(parameters, "error");

        try
        {
            // read the header and checks if it contains error with insufficient_claims value.
            if (null != errorValue && "insufficient_claims" == errorValue)
            {
                var claimChallengeParameter = GetParameterValue(parameters, "claims");
                if (null != claimChallengeParameter)
                {
                    var claimChallenge = ConvertBase64String(claimChallengeParameter);

                    return claimChallenge;
                }
            }
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    return null;
}

    Traitez l’exception dans l’appel à l’API web. Si une demande de revendications est présentée, redirigez l’utilisateur vers Microsoft Entra ID pour poursuivre le traitement.

    try
{
    // Call the API
    await _todoListService.AddAsync(todo);
}
catch (WebApiMsalUiRequiredException hex)
{
    // Challenges the user if exception is thrown from Web API.
    try
    {
        var claimChallenge =ExtractHeaderValues(hex);
        _consentHandler.ChallengeUser(new string[] { "user.read" }, claimChallenge);

        return new EmptyResult();
    }
    catch (Exception ex)
    {
        _consentHandler.HandleException(ex);
    }

    Console.WriteLine(hex.Message);
}
return RedirectToAction("Index");

  4. (Facultatif) Déclarez la capacité du client. Les capacités du client aident les fournisseurs de ressources, comme notre API web ci-dessus, à détecter si l’application cliente appelante comprend le défi de revendications et peut personnaliser sa réponse en conséquence. Cette capacité peut être utile lorsque les clients de l’API ne sont pas tous capables de traiter les défis de revendications et que certains clients plus anciens attendent toujours une réponse différente. Pour plus d’informations, consultez la section Capacités du client.

Mises en garde et recommandations

Ne codez pas en dur les valeurs du contexte d’authentification dans votre application. Les applications doivent lire et appliquer le contexte d’authentification à l’aide d’appels MS Graph. Cette pratique est essentielle pour les applications mutualisées. Les valeurs de contexte d’authentification varient selon les locataires Microsoft Entra et ne sont pas disponibles dans l’édition gratuite de Microsoft Entra ID. Pour plus d’informations sur la façon dont une application doit interroger, définir et utiliser le contexte d’authentification dans son code, consultez l’exemple de code sur la page Use the Conditional Access Auth Context to perform step-up authentication (Utiliser le contexte d’authentification de l’accès conditionnel pour effectuer une authentification renforcée).

N’utilisez pas le contexte d’authentification lorsque l’application elle-même sera la cible de stratégies d’accès conditionnel. Cette fonctionnalité fonctionne mieux lorsque certaines parties de l’application exigent de l’utilisateur une authentification plus poussée.

Exemples de code

Contexte d’authentification [ACR] dans le comportement attendu de l’accès conditionnel

Satisfaction explicite du contexte d’authentification dans les demandes

Un client peut demander explicitement un jeton avec un contexte d’authentification (ACRS) via les revendications dans le corps de la demande. Si un ACRS a été demandé, l’accès conditionnel permet d’émettre le jeton avec l’ACRS demandé si toutes les difficultés ont été effectuées.

Comportement attendu lorsqu’un contexte d’authentification n’est pas protégé par l’accès conditionnel dans le locataire

L’accès conditionnel peut émettre un ACRS dans les revendications d’un jeton lorsque toutes les stratégies d’accès conditionnel affectées à la valeur ACRS ont été satisfaites. Si aucune stratégie d’accès conditionnel n’est affectée à une valeur ACRS, la revendication peut toujours être émise, car toutes les exigences de la stratégie ont été satisfaites.

Tableau récapitulatif du comportement attendu lorsque ACRS est explicitement demandé

ACRS demandé Stratégie appliquée Contrôle satisfait Ajout d’ACRS aux revendications
Oui No Oui Oui
Oui Oui No Non
Oui Oui Oui Oui
Oui Aucune stratégie configurée avec ACRS Oui Oui

Satisfaction du contexte d’authentification implicite par une évaluation opportuniste

Un fournisseur de ressources peut accepter la revendication « acrs » facultative. L’accès conditionnel tente d’ajouter ACRS aux revendications de jeton de manière opportuniste afin d’éviter les allers-retours pour acquérir de nouveaux jetons dans Microsoft Entra ID. Dans cette évaluation, l’accès conditionnel vérifie si les stratégies protégeant les défis du contexte d’authentification sont déjà satisfaites et ajoute l’ACRS aux revendications de jeton si c’est le cas.

Remarque

Chaque type de jeton doit être choisi individuellement (jeton d’ID, jeton d’accès).

Si un fournisseur de ressources n’accepte pas la revendication « acrs » facultative, la seule façon d’obtenir un ACRS dans le jeton consiste à le demander explicitement dans une demande de jeton. Il ne bénéficie pas des avantages de l’évaluation opportuniste. Par conséquent, chaque fois que l’ACRS requis est manquant dans les revendications de jeton, le fournisseur de ressources demande au client d’acquérir un nouveau jeton qui le contient dans les revendications.

Comportement attendu avec le contexte d’authentification et les contrôles de session pour l’évaluation opportuniste ACRS implicite

Fréquence de connexion par intervalle

L’accès conditionnel considère que la « fréquence de connexion par intervalles » est satisfaite pour une évaluation ACRS opportuniste lorsque tous les instants d’authentification actuels des facteurs d’authentification se trouvent dans l’intervalle de la fréquence de connexion. Si le premier instant d’authentification du facteur est obsolète, ou si le deuxième facteur (MFA) est présent et que son instant d’authentification est obsolète, la fréquence de connexion par intervalle n’est pas satisfaite et l’ACRS n’est pas émis dans le jeton de façon opportuniste.

Cloud App Security (CAS)

L’accès conditionnel considère que le contrôle de session CAS est satisfait pour une évaluation ACRS opportuniste, lorsqu’une session CAS a été établie au cours de cette demande. Par exemple, lorsqu’une requête arrive et qu’une stratégie d’accès conditionnel est appliquée et appliquée une session CAS, et en outre, il existe une stratégie d’accès conditionnel qui nécessite également une session CAS, puisque la session CAS sera appliquée, qui satisfait le contrôle de session CAS pour l’évaluation opportuniste.

Comportement attendu lorsqu’un locataire contient des stratégies d’accès conditionnel protégeant le contexte d’authentification

Le tableau ci-dessous montre tous les cas d’angle où ACRS est ajouté aux revendications du jeton par une évaluation opportuniste.

Stratégie A : Exiger l’authentification multifacteur de tous les utilisateurs, à l’exclusion de l’utilisateur « Ariel », lors de la demande d’acrs « c1 ». Stratégie B : Bloquer tous les utilisateurs, à l’exception de l’utilisateur « Jay », lors de la demande d’acrs « c2 » ou « c3 ».

Flux ACRS demandé Stratégie appliquée Contrôle satisfait Ajout d’ACRS aux revendications
Ariel demande un jeton d’accès « c1 » None Oui pour « c1 ». Non pour « c2 » et « c3 » « c1 » (demandé)
Ariel demande un jeton d’accès « c2 » Stratégie B Bloqué par la stratégie B None
Ariel demande un jeton d’accès None None Oui pour « c1 ». Non pour « c2 » et « c3 » « c1 » (ajouté de façon opportuniste à partir de la stratégie A)
Jay demande un jeton d’accès (sans MFA) « c1 » Stratégie A Non None
Jay demande un jeton d’accès (avec MFA) « c1 » Stratégie A Oui « c1 » (demandé), « c2 » (ajouté de façon opportuniste à partir de la stratégie B), « c3 » (ajouté de manière opportuniste à partir de la stratégie B)
Jay demande un jeton d’accès (sans MFA) « c2 » None Oui pour « c2 » et « c3 ». Non pour « c1 » « c2 » (demandé), « c3 » (ajouté de façon opportuniste à partir de la stratégie B)
Jay demande un jeton d’accès (avec MFA) « c2 » None Oui pour « c1 », « c2 » et « c3 » « c1 » (meilleur effort de A), « c2 » (demandé), « c3 » (ajouté de façon opportuniste à partir de la stratégie B)
Jay demande un jeton d’accès (avec MFA) None None Oui pour « c1 », « c2 » et « c3 » « c1 », « c2 », « c3 » tous ajoutés de manière opportuniste
Jay demande un jeton d’accès (sans MFA) None None Oui pour « c2 » et « c3 ». Non pour « c1 » « c2 », « c3 » tous ajoutés de manière opportuniste

Étapes suivantes