Linee guida per gli sviluppatori per l'accesso condizionale di Microsoft Entra

La funzionalità di accesso condizionale in Microsoft Entra ID è una delle opzioni disponibili per garantire la sicurezza dell'app e proteggere un servizio. L'accesso condizionale consente agli sviluppatori e ai clienti aziendali di proteggere i servizi in molti modi, tra cui:

• Autenticazione a più fattori
• Consentire solo ai dispositivi registrati in Intune di accedere a servizi specifici
• Limitare le posizioni utente e gli intervalli IP

Per altre informazioni sulle funzionalità di accesso condizionale complete, vedere l'articolo Cos'è l'accesso condizionale.

Per gli sviluppatori che creano app per Microsoft Entra ID, questo articolo illustra come è possibile usare l'accesso condizionale e si apprenderà anche l'impatto dell'accesso alle risorse su cui non si ha il controllo su che potrebbero essere applicati criteri di accesso condizionale. L'articolo analizza anche le implicazioni dell'accesso condizionale sul flusso on-behalf-of, sulle app Web, sull'accesso a Microsoft Graph e sulle chiamate alle API.

Si presuppone la conoscenza delle app single e multi-tenant e dei modelli di autenticazione comuni.

Qual è l'impatto dell'accesso condizionale su un'app?

Tipi di app interessati

Nella maggior parte dei casi, l'accesso condizionale non modifica il comportamento di un'app o richiede modifiche da parte dello sviluppatore. Solo in determinati casi quando un'app richiede indirettamente o in modo invisibile all'utente un token per un servizio, un'app richiede modifiche al codice per gestire le sfide di accesso condizionale. L'operazione può essere semplice quanto l'esecuzione di una richiesta di accesso interattiva.

In particolare per gli scenari seguenti è necessario un codice per gestire le problematiche relative all'accesso condizionale:

• App che eseguono il flusso On-Behalf-Of
• App che accedono a più servizi/risorse
• App a pagina singola che usano MSAL.js
• App Web che chiamano una risorsa

I criteri di accesso condizionale possono essere applicati all'app, ma anche a un'API Web a cui l'app accede. Per altre informazioni su come configurare un criterio di accesso condizionale, vedere Avvio rapido: Richiedere MFA per app specifiche con l'accesso condizionale di Microsoft Entra.

A seconda dello scenario, un cliente aziendale può applicare e rimuovere i criteri di accesso condizionale in qualsiasi momento. Affinché l'app continui a funzionare quando vengono applicati nuovi criteri, è necessario implementare la gestione delle richieste. Gli esempi seguenti illustrano la gestione delle richieste.

Esempio di accesso condizionale

In alcuni scenari è necessario modificare il codice per gestire l'accesso condizionale, mentre in altri il funzionamento rimane invariato. Di seguito sono illustrati alcuni scenari in cui viene usato l'accesso condizionale per eseguire l'autenticazione a più fattori, con informazioni dettagliate sulla differenza.

• Si sta creando un'app iOS a tenant singolo e si applicano criteri di accesso condizionale. L'app concede l'accesso a un utente e non richiede l'accesso a un'API. Quando l'utente accede, i criteri vengono richiamati automaticamente e l'utente deve eseguire l'autenticazione a più fattori (MFA).
• Si sta creando un'app nativa che usa un servizio di livello intermedio per accedere a un'API downstream. Un cliente aziendale dell'azienda che usa questa app applica i criteri all'API downstream. Quando un utente finale esegue l'accesso, l'app nativa richiede l'accesso al livello intermedio e invia il token. Il livello intermedio esegue il flusso On-Behalf-Of per richiedere l'accesso all'API downstream. A questo punto, il livello intermedio si trova di fronte a un problema di richieste. Il livello intermedio invia la richiesta all'app nativa, che deve essere conforme ai criteri di accesso condizionale.

Microsoft Graph

Microsoft Graph presenta alcune considerazioni speciali per la creazione di app in ambienti con accesso condizionale. In genere, i meccanismi di accesso condizionale si comportano nello stesso modo, ma i criteri visualizzati dagli utenti saranno basati sui dati sottostanti che l'app richiede dal grafico.

In particolare, tutti gli ambiti di Microsoft Graph rappresentano alcuni set di dati a cui possono essere applicati i criteri singolarmente. Poiché ai criteri di accesso condizionale vengono assegnati set di dati specifici, Microsoft Entra ID applica i criteri di accesso condizionale in base ai dati sottostanti a Graph, anziché a Graph stesso.

Ad esempio, se un'app richiede gli ambiti seguenti di Microsoft Graph,

scopes="ChannelMessages.Read.All Mail.Read"

Un'app può aspettarsi che gli utenti soddisfino tutti i criteri impostati in Teams ed Exchange. Alcuni ambiti possono eseguire il mapping in molteplici set di dati se viene concesso l'accesso.

Conformità ai criteri di accesso condizionale

Per diverse topologie di app, i criteri di accesso condizionale vengono valutati quando viene stabilita la sessione. Poiché i criteri di accesso condizionale operano a livello di app e servizi, il punto in corrispondenza del quale vengono richiamati dipende principalmente dallo scenario specifico.

Quando l'app tenta di accedere a un servizio con criteri di accesso condizionale, potrebbe riscontrare una richiesta di accesso condizionale. Questa richiesta di verifica viene codificata nel claims parametro fornito in una risposta da Microsoft Entra ID. Ecco un esempio del parametro della richiesta:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Gli sviluppatori possono affrontare questa sfida e aggiungerlo a una nuova richiesta all'ID Microsoft Entra. Quando viene passato questo stato, l'utente finale deve eseguire qualsiasi azione necessaria per la conformità ai criteri di accesso condizionale. Negli scenari seguenti vengono illustrate informazioni specifiche sull'errore e su come estrarre il parametro.

Scenari

Prerequisiti

L'accesso condizionale Microsoft Entra è una funzionalità inclusa in Microsoft Entra ID P1 o P2. Anche i clienti con licenze di Microsoft 365 Business possono accedere alle funzionalità di accesso condizionale.

Considerazioni per scenari specifici

Le informazioni seguenti si applicano solo a questi scenari di accesso condizionale:

• App che eseguono il flusso On-Behalf-Of
• App che accedono a più servizi/risorse
• App a pagina singola che usano MSAL.js

Le sezioni seguenti illustrano scenari comuni più complessi. Il concetto principale in relazione al funzionamento è che i criteri di accesso condizionale vengono valutati nel momento in cui viene richiesto il token per il servizio a cui i criteri sono applicati.

Scenario: App che esegue il flusso on-behalf-of

In questo scenario viene illustrato il caso in cui un'app nativa chiama un'API o un servizio Web. A sua volta, il servizio esegue il flusso "on-behalf-of" per chiamare un servizio downstream. In questo caso sono stati applicati criteri di accesso condizionale al servizio downstream (API Web 2) e viene usata un'app nativa invece di un'app demon/server.

La richiesta di token iniziale per l'API Web 1 non richiede all'utente finale l'autenticazione a più fattori perché l'API Web 1 potrebbe non sempre raggiungere l'API downstream. Quando l'API Web 1 tenta di richiedere un token per conto dell'utente per l'API Web 2, la richiesta ha esito negativo perché l'utente non ha eseguito l'accesso con l'autenticazione a più fattori.

Microsoft Entra ID restituisce una risposta HTTP con alcuni dati interessanti:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Nell'API Web 1 viene intercettato l'errore error=interaction_required e viene inviata nuovamente la richiesta claims all'app desktop. A questo punto, l'app desktop può chiamare di nuovo acquireToken() e aggiungere la richiesta claims come parametro di stringa di query aggiuntivo. Questa nuova richiesta richiede all'utente di eseguire l'autenticazione a più fattori e quindi inviare il nuovo token all'API Web 1 e completare il flusso on-behalf-of.

Per provare questo scenario, vedere l'esempio di codice .NET. Viene illustrato come passare la richiesta di attestazioni dall'API Web 1 all'app nativa e costruire una nuova richiesta all'interno dell'app client.

Scenario: App che accede a più servizi

In questo scenario viene illustrato il caso in cui un'app Web accede a due servizi di cui uno ha criteri di accesso condizionale assegnati. A seconda della logica dell'app, potrebbe esserci un percorso in cui l'app non richiede l'accesso a entrambi i servizi Web. In questo scenario, l'ordine in cui si richiede un token ha un ruolo importante nell'esperienza dell'utente finale.

Si supponga di avere i servizi Web A e B e che al servizio Web B siano applicati i criteri di accesso condizionale. Mentre la richiesta di autenticazione interattiva iniziale richiede il consenso per entrambi i servizi, i criteri di accesso condizionale non sono necessari in tutti i casi. Se l'app richiede un token per il servizio Web B, i criteri vengono richiamati e anche le richieste successive per il servizio Web A hanno esito positivo, come indicato di seguito.

In alternativa, se l'app richiede inizialmente un token per il servizio Web A, l'utente finale non richiama i criteri di accesso condizionale. In questo modo, lo sviluppatore dell'app può controllare l'esperienza dell'utente finale senza imporre che i criteri di accesso condizionale vengano richiamati in tutti i casi. Il caso difficile è se l'app richiede successivamente un token per il servizio Web B. A questo punto, l'utente finale deve rispettare i criteri di accesso condizionale. Quando l'app prova a eseguire acquireToken, può venire generato l'errore seguente (illustrato nel diagramma seguente):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Se l'app usa la libreria MSAL, in caso di errore di acquisizione del token viene sempre eseguito un nuovo tentativo in modo interattivo. Quando si verifica questa richiesta interattiva, l'utente finale ha la possibilità di rispettare l'accesso condizionale. Questo vale solo se la richiesta non è AcquireTokenSilentAsync o PromptBehavior.Never, nel qual caso l'app deve eseguire una richiesta AcquireToken interattiva per consentire all'utente finale di rispettare i criteri.

Scenario: app a pagina singola (SPA) con MSAL.js

In questo scenario viene illustrato il caso in cui si dispone di un'app a pagina singola che chiama un'API Web protetta dall'accesso condizionale usando MSAL.js. Si tratta di un'architettura semplice, ma ci sono alcuni aspetti da prendere in considerazione in caso di sviluppo incentrato sull'accesso condizionale.

In MSAL.js sono disponibili alcune funzioni che ottengono token: acquireTokenSilent(), acquireTokenPopup()e acquireTokenRedirect().

• acquireTokenSilent() può essere usato per ottenere automaticamente un token di accesso, ovvero non mostra l'interfaccia utente in alcuna circostanza.
• acquireTokenPopup() e acquireTokenRedirect() vengono entrambi usati per richiedere in modo interattivo un token per una risorsa, quindi l'interfaccia utente di accesso viene sempre visualizzata.

Quando un'app necessita di un token di accesso per chiamare un'API Web, viene eseguito un tentativo di chiamata a acquireTokenSilent(). Se il token è scaduto o è necessario rispettare i criteri di accesso condizionale, la funzione acquireToken ha esito negativo e l'app usa acquireTokenPopup() o acquireTokenRedirect().

Verrà ora esaminato un esempio con lo scenario di accesso condizionale. L'utente finale è appena arrivato nel sito e non ha una sessione. Si esegue una loginPopup() chiamata, si ottiene un token ID senza autenticazione a più fattori. L'utente preme quindi un pulsante che comporta una richiesta di dati dall'app a un'API Web. L'app tenta di eseguire una acquireTokenSilent() chiamata ma non riesce perché l'utente non ha ancora eseguito l'autenticazione a più fattori e deve essere conforme ai criteri di accesso condizionale.

Microsoft Entra ID invia la risposta HTTP seguente:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

L'app deve intercettare l'errore error=interaction_required. L'applicazione può quindi usare acquireTokenPopup() o acquireTokenRedirect() sulla stessa risorsa. L'utente deve eseguire un'autenticazione a più fattori. Dopo che l'utente ha completato l'autenticazione a più fattori, l'app viene rilasciato un nuovo token di accesso per la risorsa richiesta.

Per provare questo scenario, vedere l'esempio di codice react SPA che chiama Node.js'API Web usando l'esempio di codice on-behalf-of flow . Questo esempio di codice usa i criteri di accesso condizionale e l'API Web registrati in precedenza con un'applicazione a pagina singola React per illustrare questo scenario. Mostra come gestire correttamente la richiesta di attestazioni e ottenere un token di accesso che può essere usato per l'API Web.

Vedi anche

• Per altre informazioni sulle funzionalità, vedere Accesso condizionale in Microsoft Entra ID.
• Per altri esempi di codice di Microsoft Entra, vedi esempi.
• Per altre informazioni sugli SDK MSAL e accedere alla documentazione di riferimento, vedere la panoramica di Microsoft Authentication Library.
• Per altre informazioni sugli scenari multi-tenant, vedere Come accedere agli utenti usando il modello multi-tenant.
• Altre informazioni sull'accesso condizionale e sulla protezione dell'accesso alle app IoT.