Guida per gli sviluppatori al contesto di autenticazione dell'accesso condizionale

L'accesso condizionale è il piano di controllo Zero Trust che consente di definire come destinazione i criteri per l'accesso a tutte le app, ovvero vecchie o nuove, private o pubbliche, locali o multicloud. Con il contesto di autenticazione dell'accesso condizionale, è possibile applicare criteri diversi all'interno di tali app.

Il contesto di autenticazione dell'accesso condizionale (contesto di autenticazione) consente di applicare criteri granulari a dati e azioni sensibili anziché solo a livello di app. È possibile perfezionare i criteri Zero Trust per l'accesso con privilegi minimi riducendo al minimo l'attrito degli utenti e mantenendo gli utenti più produttivi e le risorse più sicure. Oggi viene usato dalle applicazioni che usano OpenId Connessione per l'autenticazione sviluppata dall'azienda per proteggere le risorse sensibili, ad esempio transazioni di alto valore o visualizzare i dati personali dei dipendenti.

Per attivare un'autenticazione dettagliata dall'interno delle applicazioni e dei servizi, usare la funzionalità di contesto di autenticazione del motore di autenticazione di Microsoft Entra. Gli sviluppatori ora hanno la capacità di richiedere un'autenticazione avanzata avanzata, in modo selettivo, ad esempio l'autenticazione a più fattori dagli utenti finali dall'interno delle applicazioni. Questa funzionalità consente agli sviluppatori di creare esperienze utente più fluide per la maggior parte delle parti dell'applicazione, mentre l'accesso a operazioni e dati più sicuri rimane dietro controlli di autenticazione più avanzati.

Presentazione del problema

Gli amministratori IT e le autorità di regolamentazione spesso lottano tra bilanciare il bilanciamento della richiesta agli utenti con fattori aggiuntivi di autenticazione troppo spesso e ottenere una conformità adeguata di sicurezza e criteri per applicazioni e servizi in cui parti di essi contengono dati e operazioni sensibili. Può essere una scelta tra criteri sicuri che influiscono sulla produttività degli utenti quando accedono alla maggior parte dei dati e delle azioni o a un criterio che non è abbastanza forte per le risorse sensibili.

Quindi, cosa accade se le app fossero in grado di combinare entrambe, dove possono funzionare con una sicurezza relativamente minore e richieste meno frequenti per la maggior parte degli utenti e delle operazioni e tuttavia aumentare in modo condizionale il requisito di sicurezza quando gli utenti hanno eseguito l'accesso a parti più sensibili?

Scenari comuni

Ad esempio, mentre gli utenti potrebbero accedere a SharePoint usando l'autenticazione a più fattori, l'accesso alla raccolta siti in SharePoint contenente documenti sensibili può richiedere un dispositivo conforme e essere accessibile solo da intervalli IP attendibili.

Prerequisiti

Prima di tutto, l'app deve essere integrata con Microsoft Identity Platform usando i protocolli OpenID Connessione/ OAuth 2.0 per l'autenticazione e l'autorizzazione. È consigliabile usare le librerie di autenticazione di Microsoft Identity Platform per integrare e proteggere l'applicazione con Microsoft Entra ID. La documentazione di Microsoft Identity Platform è un buon punto di partenza per iniziare a imparare a integrare le app con Microsoft Identity Platform. Il supporto della funzionalità contesto di autenticazione condizionale è basato sulle estensioni del protocollo fornite dal protocollo OpenID standard del settore Connessione. Gli sviluppatori usano un valore di riferimentocontesto di autenticazione condizionale con il parametro Claims Request per consentire alle app di attivare e soddisfare i criteri.

In secondo luogo, l'accesso condizionale richiede la licenza Microsoft Entra ID P1. Altre informazioni sulle licenze sono disponibili nella pagina dei prezzi di Microsoft Entra.

Terzo, oggi è disponibile solo per le applicazioni che accedono agli utenti. Le applicazioni che eseguono l'autenticazione come se stesse non sono supportate. Usare la guida ai flussi di autenticazione e agli scenari dell'applicazione per informazioni sui tipi e i flussi di app di autenticazione supportati in Microsoft Identity Platform.

Procedura di integrazione

Una volta integrata l'applicazione usando i protocolli di autenticazione supportati e registrata in un tenant di Microsoft Entra con la funzionalità di accesso condizionale disponibile per l'uso, è possibile avviare il processo di integrazione di questa funzionalità nelle applicazioni che consentono agli utenti di accedere.

Nota

Una procedura dettagliata di questa funzionalità è disponibile anche come sessione registrata in Usare il contesto di autenticazione dell'accesso condizionale nell'app per l'autenticazione dettagliata.

Prima di tutto, dichiarare e rendere disponibili i contesti di autenticazione nel tenant. Per altre informazioni, vedere Configurare i contesti di autenticazione.

I valori C1-C99 sono disponibili per l'uso come ID contesto di autenticazione in un tenant. Alcuni esempi di contesto di autenticazione possono essere:

• C1 - Richiedere l'autenticazione avanzata
• C2 : richiedere dispositivi conformi
• C3 : richiedere posizioni attendibili

Creare o modificare i criteri di accesso condizionale per usare i contesti di autenticazione dell'accesso condizionale. I criteri di esempio possono essere:

• Tutti gli utenti che accedono a questa applicazione Web devono avere completato correttamente 2FA per l'ID contesto di autenticazione C1.
• Tutti gli utenti che accedono a questa applicazione Web devono avere completato correttamente 2FA e accedere all'app Web da un determinato intervallo di indirizzi IP per l'ID contesto di autenticazione C3.

Nota

I valori del contesto di autenticazione dell'accesso condizionale vengono dichiarati e gestiti separatamente dalle applicazioni. Non è consigliabile che le applicazioni prendano una dipendenza rigida da ID contesto di autenticazione. I criteri di accesso condizionale vengono in genere creati dagli amministratori IT perché hanno una migliore comprensione delle risorse disponibili per l'applicazione dei criteri. Ad esempio, per un tenant di Microsoft Entra, gli amministratori IT avrebbero la conoscenza del numero di utenti del tenant dotati di 2FA per l'autenticazione a più fattori e quindi possono garantire che i criteri di accesso condizionale che richiedono 2FA siano limitati a questi utenti dotati. Analogamente, se l'applicazione viene usata in più tenant, gli ID del contesto di autenticazione in uso potrebbero essere diversi e, in alcuni casi, non sono disponibili affatto.

In secondo luogo: gli sviluppatori di un'applicazione che prevede di usare il contesto di autenticazione dell'accesso condizionale sono invitati a fornire prima agli amministratori dell'applicazione o agli amministratori IT un mezzo per eseguire il mapping di potenziali azioni sensibili agli ID del contesto di autenticazione. I passaggi sono approssimativamente:

1. Azioni di identità nel codice che possono essere rese disponibili per eseguire il mapping rispetto agli ID contesto di autenticazione.
2. Creare una schermata nel portale di amministrazione dell'app (o una funzionalità equivalente) che gli amministratori IT possono usare per eseguire il mapping delle azioni sensibili rispetto a un ID contesto di autenticazione disponibile.
3. Vedere l'esempio di codice Usare il contesto di autenticazione dell'accesso condizionale per eseguire l'autenticazione dettagliata per un esempio su come viene eseguita.

Questi passaggi sono le modifiche che è necessario portare nella codebase. I passaggi in generale comprendono

• Eseguire una query su MS Graph per elencare tutti i contesti di autenticazione disponibili.
• Consentire agli amministratori IT di selezionare operazioni sensibili/con privilegi elevati e assegnarle ai contesti di autenticazione disponibili usando i criteri di accesso condizionale.
• Salvare queste informazioni di mapping nell'archivio database/locale.

Terzo: l'applicazione e, per questo esempio, si presuppone che si tratti di un'API Web, quindi deve valutare le chiamate rispetto al mapping salvato e generare di conseguenza problemi di attestazione per le app client. Per prepararsi a questa azione, è necessario eseguire i passaggi seguenti:

1. In un'operazione sensibile e protetta dal contesto di autenticazione, valutare i valori nell'attestazione acrs rispetto ai mapping dell'ID contesto di autenticazione salvati in precedenza e generare una richiesta di verifica delle attestazioni, come indicato nel frammento di codice seguente.

2. Il diagramma seguente illustra l'interazione tra l'utente, l'app client e l'API Web.

   

   Il frammento di codice seguente proviene dall'esempio di codice, Usare il contesto di autenticazione dell'accesso condizionale per eseguire l'autenticazione dettagliata. Primo metodo, CheckForRequiredAuthContext() nell'API

   • Controlla se l'azione dell'applicazione chiamata richiede l'autenticazione dettagliata. Ciò avviene controllando il database per un mapping salvato per questo metodo
   • Se questa azione richiede effettivamente un contesto di autenticazione con privilegi elevati, controlla l'attestazione acrs per un ID contesto di autenticazione esistente corrispondente.
   • Se non viene trovato un ID contesto di autenticazione corrispondente, viene generata una richiesta di attestazioni.

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

   Nota

   Il formato della richiesta di attestazioni è descritto nell'articolo Claims Challenge in Microsoft Identity Platform.

3. Nell'applicazione client intercettare la richiesta di attestazioni e reindirizzare l'utente all'ID Microsoft Entra per un'ulteriore valutazione dei criteri. Il frammento di codice seguente proviene dall'esempio di codice, Usare il contesto di autenticazione dell'accesso condizionale per eseguire l'autenticazione dettagliata.

   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;
   }
   

   Gestire l'eccezione nella chiamata all'API Web, se viene presentata una richiesta di verifica delle attestazioni, reindirizzare l'utente all'ID Microsoft Entra per un'ulteriore elaborazione.

   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. (Facoltativo) Dichiarare la funzionalità client. Le funzionalità client consentono ai provider di risorse (RP) come l'API Web precedente di rilevare se l'applicazione client chiamante comprende la richiesta di attestazioni e può quindi personalizzarne la risposta di conseguenza. Questa funzionalità può essere utile in cui non tutti i client API sono in grado di gestire i problemi di attestazione e alcuni meno recenti prevedono ancora una risposta diversa. Per altre informazioni, vedere la sezione Funzionalità client.

Avvertenze e consigli

Non impostare i valori del contesto di autenticazione hardcoded nell'app. Le app devono leggere e applicare il contesto di autenticazione usando le chiamate MS Graph. Questa procedura è fondamentale per le applicazioni multi-tenant. I valori del contesto di autenticazione variano tra i tenant di Microsoft Entra e non saranno disponibili nell'edizione Microsoft Entra ID Free. Per altre informazioni su come un'app deve eseguire query, impostare e usare il contesto di autenticazione nel codice, vedere l'esempio di codice Usare il contesto di autenticazione dell'accesso condizionale per eseguire l'autenticazione dettagliata come eseguire query su un'app, impostare e usare il contesto di autenticazione nel codice.

Non usare il contesto di autenticazione in cui l'app stessa sarà una destinazione dei criteri di accesso condizionale. La funzionalità funziona meglio quando parti dell'applicazione richiedono all'utente di soddisfare una barra di autenticazione superiore.

Esempi di codice

• Usare il contesto di autenticazione dell'accesso condizionale per eseguire l'autenticazione dettagliata per le operazioni con privilegi elevati in un'app Web
• Usare il contesto di autenticazione dell'accesso condizionale per eseguire l'autenticazione dettagliata per le operazioni con privilegi elevati in un'API Web
• Usare il contesto di autenticazione dell'accesso condizionale per eseguire l'autenticazione dettagliata per le operazioni con privilegi elevati in un'applicazione a pagina singola React e un'API Web Express

Contesto di autenticazione [ACR] nel comportamento previsto dell'accesso condizionale

Soddisfazione esplicita del contesto di autenticazione nelle richieste

Un client può richiedere in modo esplicito un token con un contesto di autenticazione (ACRS) tramite le attestazioni nel corpo della richiesta. Se è stato richiesto un registro Azure Container, l'accesso condizionale consentirà di emettere il token con il Registro Azure Container richiesto se sono state completate tutte le sfide.

Comportamento previsto quando un contesto di autenticazione non è protetto dall'accesso condizionale nel tenant

L'accesso condizionale può emettere un record di controllo di accesso in attestazioni di un token quando tutti i criteri di accesso condizionale assegnati al valore di Registro Azure Container sono stati soddisfatti. Se non viene assegnato alcun criterio di accesso condizionale a un valore ACRS, l'attestazione potrebbe essere ancora rilasciata, perché tutti i requisiti dei criteri sono stati soddisfatti.

Tabella di riepilogo per il comportamento previsto quando vengono richiesti in modo esplicito Registro Azure Container

Registro Azure Container richiesto	Criteri applicati	Controllo soddisfatto	Registro Azure Container aggiunto alle attestazioni
Sì	No	Sì	Sì
Sì	Sì	No	No
Sì	Sì	Sì	Sì
Sì	Nessun criterio configurato con Registro Azure Container	Sì	Sì

Soddisfazione implicita del contesto di autenticazione per valutazione opportunistica

Un provider di risorse può acconsentire esplicitamente all'attestazione facoltativa "acrs". L'accesso condizionale tenta di aggiungere Registro Azure Container alle attestazioni di token in modo opportunistico per evitare round trip per acquisire nuovi token all'ID Microsoft Entra. In tale valutazione, l'accesso condizionale verifica se i criteri che proteggono i problemi relativi al contesto di autenticazione sono già soddisfatti e aggiunge il record di controllo di accesso alle attestazioni del token, in tal caso.

Nota

Ogni tipo di token dovrà essere scelto singolarmente (token ID, token di accesso).

Se un provider di risorse non acconsente all'attestazione facoltativa "acrs", l'unico modo per ottenere un record di controllo di accesso nel token sarà chiedere esplicitamente tale richiesta in una richiesta di token. Non otterrà i vantaggi della valutazione opportunistica, pertanto ogni volta che l'ACRS richiesto non sarà presente nelle attestazioni del token, il provider di risorse richiederà al client di acquisire un nuovo token che lo contiene nelle attestazioni.

Comportamento previsto con il contesto di autenticazione e i controlli sessione per la valutazione opportunistica implicita di Registro Azure Container

Frequenza di accesso per intervallo

L'accesso condizionale considera "frequenza di accesso in base all'intervallo" come soddisfatto per la valutazione opportunistica di Registro Azure Container quando tutti i fattori di autenticazione presenti autenticano gli istantanei sono entro l'intervallo di frequenza di accesso. Nel caso in cui il primo istante di autenticazione del fattore non sia aggiornato o se il secondo fattore (MFA) è presente e il relativo istante di autenticazione non è aggiornato, la frequenza di accesso per intervallo non verrà soddisfatta e il record di controllo di accesso non verrà rilasciato nel token in modo opportunistico.

Cloud App Security (CAS)

L'accesso condizionale considererà il controllo sessione CAS soddisfatto per la valutazione opportunistica di Registro Azure Container, quando è stata stabilita una sessione CAS durante tale richiesta. Ad esempio, quando una richiesta viene inserita e tutti i criteri di accesso condizionale applicati e applicato una sessione cas, oltre a un criterio di accesso condizionale che richiede anche una sessione CAS, poiché verrà applicata la sessione CAS, che soddisfa il controllo sessione CAS per la valutazione opportunistica.

Comportamento previsto quando un tenant contiene criteri di accesso condizionale che proteggono il contesto di autenticazione

La tabella seguente mostrerà tutti i casi di angolo in cui Registro Azure Container viene aggiunto alle attestazioni del token dalla valutazione opportunistica.

Criterio A: Richiedere l'autenticazione a più fattori da tutti gli utenti, escluso l'utente "Ariel", quando si richiede "c1" acrs. Criterio B: Blocca tutti gli utenti, escluso l'utente "Jay", quando si chiede "c2" o "c3" acrs.

Flow	Registro Azure Container richiesto	Criteri applicati	Controllo soddisfatto	Registro Azure Container aggiunto alle attestazioni
Richieste di autorizzazione per un token di accesso	"c1"	None	Sì per "c1". No per "c2" e "c3"	"c1" (richiesta)
Richieste di autorizzazione per un token di accesso	"c2"	Criterio B	Bloccato dai criteri B	None
Richieste di autorizzazione per un token di accesso	None	None	Sì per "c1". No per "c2" e "c3"	"c1" (aggiunti opportunisticamente dal criterio A)
Jay richiede un token di accesso (senza MFA)	"c1"	Criterio A	No	None
Jay richiede un token di accesso (con MFA)	"c1"	Criterio A	Sì	"c1" (richiesto), "c2" (aggiunti opportunisticamente dal criterio B), "c3" (aggiunti opportunisticamente dal criterio B)
Jay richiede un token di accesso (senza MFA)	"c2"	None	Sì per "c2" e "c3". No per "c1"	"c2" (richiesto), "c3" (aggiunta opportunistica dal criterio B)
Jay richiede un token di accesso (con MFA)	"c2"	None	Sì per "c1", "c2" e "c3"	"c1" (miglior sforzo da A), "c2" (richiesto), "c3" (aggiunta opportunistica dal criterio B)
Jay richiede un token di accesso (con MFA)	None	None	Sì per "c1", "c2" e "c3"	"c1", "c2", "c3" tutti aggiunti opportunisticamente
Jay richiede un token di accesso (senza MFA)	None	None	Sì per "c2" e "c3". No per "c1"	"c2", "c3" tutti aggiunti opportunisticamente

Passaggi successivi

• Accesso condizionale granulare per dati e azioni sensibili (blog)
• Zero trust con Microsoft Identity Platform
• Compilazione di app pronte per Zero Trust con Microsoft Identity Platform
• Contesto di autenticazione dell'accesso condizionale
• tipo di risorsa authenticationContextClassReference - MS Graph
• Richieste di attestazioni, richieste di attestazioni e funzionalità client in Microsoft Identity Platform
• Uso del contesto di autenticazione con Microsoft Purview Information Protection e SharePoint
• Come usare le API abilitate per la valutazione dell'accesso continuo nelle applicazioni