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

S’applique à : Cercle vert des locataires de main-d’œuvre Locataires externes (en savoir plus)

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, il peut être utilisé par les applications utilisant OpenID Connect pour l’authentification développée par votre société afin de protéger les ressources sensibles, comme les transactions de grande valeur ou la consultation des données personnelles des collaborateurs.

La fonctionnalité de contexte d’authentification du moteur d’accès conditionnel Microsoft Entra vous permet de déclencher une authentification par étapes depuis vos applications et services. Les développeurs ont désormais la possibilité d’exiger de leurs utilisateurs finaux une authentification par étapes, 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 informatiques et les organismes de réglementation ont souvent du mal à trouver un équilibre entre le fait de demander aux utilisateurs de fournir des facteurs d'authentification supplémentaires et l'obtention d'une sécurité adéquate ainsi que de la conformité aux politiques pour les applications. Il peut s’agir d’un choix entre une stratégie forte qui affecte la productivité des utilisateurs ou une stratégie qui n’est pas assez forte pour les ressources sensibles.

Alors, que se passe-t-il si les applications étaient en mesure de combiner les deux ? Fonctionnement avec un niveau de sécurité inférieur et moins de sollicitations pour la plupart des scénarios. Ensuite, l'ajustement conditionnel des exigences de sécurité lorsque des données plus sensibles sont consultées ?

Scénarios courants

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

Prerequisites

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’intégrer et de sécuriser votre application avec Microsoft Entra ID à l’aide des bibliothèques d’authentification de la plateforme d’identités Microsoft. La documentation sur la plateforme d’identités Microsoft est un bon point de départ pour découvrir comment 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 en savoir plus 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. Découvrez les types d’applications et les flux d’authentification pris en charge par la plateforme d’identités Microsoft à l’aide du guide relatif aux flux d’authentification et aux scénarios d’applications.

Étapes d’intégration

Vous pouvez commencer à intégrer cette fonctionnalité dans vos applications une fois qu’elle est intégrée à l’aide des protocoles d’authentification pris en charge et inscrites dans un locataire Microsoft Entra disposant de la fonctionnalité d’accès conditionnel disponible.

Premièrement, déclarez les contextes d’authentification et mettez-les à disposition dans votre abonné. 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 abonné. Voici quelques exemples de contexte d’authentification :

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

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

• Tous les utilisateurs qui se connectent à cette application web doivent réussir l'authentification à deux facteurs (2FA) pour l’ID de contexte d’authentification C1.
• Tous les utilisateurs qui se connectent à cette application web doivent terminer 2FA et accéder également à l’application à partir d’une plage d’adresses IP définie pour l’ID de contexte d’authentification C3.

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, Utilisez le contexte d’authentification de l’accès conditionnel pour effectuer une authentification pas à pas pour obtenir un exemple.

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’accès conditionnel.
• Enregistrez ces informations de mappage dans votre base de données ou votre magasin local.

Troisièmement : votre application (sachant que pour cet exemple, nous supposons qu’il s’agit d’une API web) doit ensuite évaluer les appels par rapport au mappage enregistré 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.

   

   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 par étapes). La première méthode (CheckForRequiredAuthContext() dans l’API) :

   • vérifie si l’action de l’application appelée requiert une authentification par étapes. 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");
               }
           }
       }
   }
   

   Note

   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 par étapes).

   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 fonctionnalités clientes aident les fournisseurs de ressources (RP) comme notre API web à détecter si l’application cliente comprend le défi des revendications et peut ensuite 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 du contexte d’authentification varient entre les locataires Microsoft Entra et ne sont pas disponibles dans l’édition gratuite de l’ID Entra Microsoft. 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, utiliser le contexte d’authentification de l’accès conditionnel pour effectuer une authentification pas à pas.

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

• Effectuer une authentification par étapes pour les opérations à privilèges élevés dans une application web à l’aide du contexte d’authentification de l’accès conditionnel
• Effectuer une authentification par étapes pour les opérations à privilèges élevés dans une API web à l’aide du contexte d’authentification de l’accès conditionnel
• Effectuer une authentification renforcée pour les opérations à privilèges élevés dans une application mono-page React et une API web Express à l’aide du contexte d’authentification de l’accès conditionnel

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 tous les défis ont été effectués.

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

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 sont 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 stratégie sont satisfaites.

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

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 de contexte d’authentification sont déjà satisfaites et ajoute l’ACRS aux revendications de jeton si tel est le cas.

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 intervalle » est satisfaite pour l’évaluation ACRS opportuniste lorsque tous les instants d’authentification actuels des facteurs d’authentification se trouvent dans l’intervalle de fréquence de connexion. Si l’un des facteurs 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 manière 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 demande arrive et qu’une stratégie d’accès conditionnel a appliqué 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 abonné comporte 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 ».

Étapes suivantes

• Accès conditionnel granulaire pour les actions et les données sensibles (blog)
• Zero Trust avec la plateforme d’identités Microsoft
• Création d’applications Zero Trust avec la plateforme d’identités Microsoft
• Contexte d’authentification de l’accès conditionnel
• Type de ressource authenticationContextClassReference - MS Graph
• Défi de revendications, demande de revendications et fonctionnalités client sur la plateforme d’identités Microsoft
• Utilisation du contexte d’authentification avec Microsoft Purview Information Protection et SharePoint
• Guide pratique pour utiliser des API dotées d’Évaluation continue de l’accès dans vos applications