Convertire l'app a tenant singolo in multi-tenant in MICROSOFT Entra ID

  • Articolo

Se si offre un'applicazione SaaS (Software as a Service) a molte organizzazioni, è possibile configurare l'applicazione per accettare gli accessi da qualsiasi tenant di Microsoft Entra convertendolo in multi-tenant. Gli utenti di qualsiasi tenant di Microsoft Entra potranno accedere all'applicazione dopo aver acconsentito all'uso del proprio account con l'applicazione.

Per le app esistenti con il proprio sistema di account (o altri accessi di altri provider di servizi cloud), è necessario aggiungere il codice di accesso tramite OAuth2, OpenID Connect o SAML e inserire un pulsante "Accedi con Microsoft" nell'applicazione.

In questa guida pratica si eseguiranno i quattro passaggi necessari per convertire un'app a tenant singolo in un'app multi-tenant Di Microsoft Entra:

  1. Aggiornare la registrazione dell'applicazione in modo che sia multi-tenant
  2. Aggiornare il codice per inviare richieste all'endpoint /common
  3. Aggiornare il codice per gestire più valori dell'autorità di certificazione
  4. Informarsi sul consenso dell'utente e dell'amministratore e apportare le modifiche appropriate al codice

Per provare a usare uno degli esempi, vedere Creare un'applicazione Web SaaS multi-tenant che chiama Microsoft Graph usando Microsoft Entra ID e OpenID Connect

Prerequisiti

Aggiornare la registrazione per essere multi-tenant

Per impostazione predefinita, le registrazioni di app Web/API in Microsoft Entra ID sono a tenant singolo al momento della creazione. Per impostare la registrazione multi-tenant, accedere all'interfaccia di amministrazione di Microsoft Entra e selezionare la registrazione dell'app da aggiornare. Con la registrazione dell'app aperta, selezionare il riquadro Autenticazione e passare alla sezione Tipi di account supportati. Modificare l'impostazione su Account in qualsiasi directory organizzativa.

Quando viene creata un'applicazione a tenant singolo nell'interfaccia di amministrazione di Microsoft Entra, uno degli elementi elencati nella pagina Panoramica è l'URI ID applicazione. Si tratta di uno dei modi in cui un'applicazione viene identificata nei messaggi di protocollo e può essere aggiunta in qualsiasi momento. L'URI ID app per le app a tenant singolo può essere univoco a livello globale all'interno di tale tenant. Al contrario, per le app multi-tenant deve essere univoco a livello globale in tutti i tenant, in modo da garantire che l'ID Microsoft Entra possa trovare l'app in tutti i tenant.

Ad esempio, se il nome del tenant era contoso.onmicrosoft.com un URI ID app valido sarà https://contoso.onmicrosoft.com/myapp. Se l'URI ID app non segue questo modello, l'impostazione di un'applicazione come multi-tenant ha esito negativo.

Aggiornare il codice per inviare richieste a /common

Con un'applicazione multi-tenant, l'applicazione non è in grado di indicare immediatamente da quale tenant proviene l'utente, quindi le richieste non possono essere inviate all'endpoint di un tenant. Le richieste vengono invece inviate a un endpoint comune (https://login.microsoftonline.com/common) che funge da hub centrale che gestisce le richieste in tutti i tenant di Microsoft Entra.

Aprire l'app nell'IDE e modificare il codice e modificare il valore per l'ID tenant in /common. Questo endpoint non è un tenant o un'autorità emittente stessa. Quando Microsoft Identity Platform riceve una richiesta nell'endpoint /common , firma l'utente, individuando quindi il tenant da cui proviene l'utente. Questo endpoint funziona con tutti i protocolli di autenticazione supportati dall'ID Microsoft Entra (OpenID Connect, OAuth 2.0, SAML 2.0, WS-Federation).

La risposta di accesso all'applicazione di accesso contiene un token che rappresenta l'utente. Il valore dell'autorità di certificazione nel token indica a un'applicazione il tenant di provenienza dell'utente. Quando viene restituita una risposta dall'endpoint /common , il valore dell'autorità emittente nel token corrisponde al tenant dell'utente.

Nota

Esistono, in realtà 2 autorità per le applicazioni multi-tenant:

  • https://login.microsoftonline.com/common per le applicazioni che elaborano gli account in qualsiasi directory organizzativa (qualsiasi directory Microsoft Entra) e account Microsoft personali (ad esempio Skype, XBox).
  • https://login.microsoftonline.com/organizations per le applicazioni che elaborano gli account in qualsiasi directory organizzativa (qualsiasi directory Microsoft Entra):

Le spiegazioni contenute in questo documento usano common. Ma è possibile sostituirlo organizations con se l'applicazione non supporta gli account personali Microsoft.

Aggiornare il codice per gestire più valori dell'autorità di certificazione

Le applicazioni Web e le API Web ricevono e convalidano i token da Microsoft Identity Platform. Le applicazioni client native non convalidano i token di accesso e devono considerarli opachi. Richiedono invece e ricevono token da Microsoft Identity Platform e lo inviano alle API, dove vengono convalidati.

Le applicazioni multi-tenant devono eseguire più controlli durante la convalida di un token. Un'applicazione multi-tenant è configurata per utilizzare i metadati delle chiavi dagli /organizations URL delle chiavi o /common . L'applicazione deve verificare che la issuer proprietà nei metadati pubblicati corrisponda all'attestazione iss nel token, oltre al consueto controllo che l'attestazione iss nel token contenga l'attestazione ID tenant (tid). Per altre informazioni, vedere Convalidare i token.

Affinché un utente possa accedere a un'applicazione in Microsoft Entra ID, l'applicazione deve essere rappresentata nel tenant dell'utente. Ciò consente alle organizzazioni di eseguire operazioni come applicare criteri univoci quando gli utenti dal tenant accedono all'applicazione. Per un'applicazione a tenant singolo, è possibile usare la registrazione tramite l'interfaccia di amministrazione di Microsoft Entra.

Per un'applicazione multi-tenant, la registrazione iniziale per l'applicazione risiede nel tenant di Microsoft Entra usato dallo sviluppatore. Quando un utente di un tenant diverso accede all'applicazione per la prima volta, Microsoft Entra ID chiede di fornire il consenso alle autorizzazioni richieste dall'applicazione. Se fornisce il consenso, viene creata una rappresentazione dell'applicazione denominata entità servizio nel tenant dell'utente ed è possibile procedere con l'accesso. Viene anche creata una delega nella directory che registra il consenso dell'utente all'applicazione. Per informazioni dettagliate sugli oggetti applicazione ed entità servizio dell'applicazione e su come interagiscono tra loro, vedere Oggetti applicazione e oggetti entità servizio.

Diagramma che illustra il consenso di un utente a un'app a livello singolo.

Questa esperienza di consenso è interessata dalle autorizzazioni richieste dall'applicazione. Microsoft Identity Platform supporta due tipi di autorizzazioni;

  • Delegato: questa autorizzazione concede a un'applicazione la possibilità di agire come utente connesso per un subset delle operazioni che l'utente può eseguire. Ad esempio, è possibile concedere a un'applicazione l'autorizzazione delegata per la lettura del calendario dell'utente connesso.
  • Solo app: questa autorizzazione viene concessa direttamente all'identità dell'applicazione. Ad esempio, è possibile concedere a un'applicazione l'autorizzazione solo app per leggere l'elenco di utenti in un tenant, indipendentemente dall'utente che ha eseguito l'accesso all'applicazione.

Alcune autorizzazioni possono essere concesse da un utente normale, mentre altre richiedono il consenso dell'amministratore tenant.

Per altre informazioni sul consenso dell'utente e dell'amministratore, vedere Configurare il flusso di lavoro di consenso amministratore.

Le autorizzazioni solo app richiedono il consenso dell'amministratore tenant. Se l'applicazione richiede un'autorizzazione solo per app e un utente tenta di accedere all'applicazione, viene visualizzato un messaggio di errore che informa che l'utente non è in grado di fornire il consenso.

Alcune autorizzazioni delegate richiedono anche il consenso dell'amministratore tenant. Ad esempio, la possibilità di eseguire il writeback in Microsoft Entra ID come utente connesso richiede il consenso di un amministratore tenant. Analogamente alle autorizzazioni solo app, se un utente ordinario tenta di accedere a un'applicazione che richiede un'autorizzazione delegata che richiede il consenso dell'amministratore, l'app riceve un errore. La richiesta del consenso di amministratore da parte di un'applicazione è determinata dallo sviluppatore che ha pubblicato la risorsa ed è presente nella documentazione per la risorsa. La documentazione delle autorizzazioni per l'API Microsoft Graph indica quali autorizzazioni richiedono il consenso amministratore.

Se l'applicazione usa autorizzazioni che richiedono il consenso dell'amministratore, è consigliabile aggiungere un pulsante o un collegamento in cui l'amministratore può avviare l'azione. La richiesta inviata dall'applicazione per questa azione è la richiesta di autorizzazione OAuth2/OpenID Connect standard, che include anche il parametro prompt=consent della stringa di query. Dopo che l'amministratore ha acconsentito e l'entità servizio viene creata nel tenant del cliente, le successive richieste di accesso non richiedono il prompt=consent parametro . Poiché l'amministratore ha deciso che le autorizzazioni richieste sono accettabili, a nessun altro utente nel tenant viene richiesto il consenso da questo punto in poi.

Un amministratore tenant può disabilitare la possibilità che gli utenti normali possano il consenso alle applicazioni. Se questa funzionalità è disabilitata, è necessario usare il consenso dell'amministratore come obbligatorio sempre per l'applicazione nel tenant. È possibile testare l'applicazione con il consenso dell'utente finale disabilitato nell'interfaccia di amministrazione di Microsoft Entra. In Applicazioni aziendali>Consenti e autorizzazioni selezionare l'opzione Non consentire il consenso dell'utente.

Il prompt=consent parametro può essere usato anche dalle applicazioni che richiedono autorizzazioni che non richiedono il consenso amministratore. Questo parametro viene usato, ad esempio, quando l'applicazione richiede un'esperienza in cui il tenant amministratore "si iscrive" una volta e a nessun altro utente viene richiesto il consenso da tale punto in poi.

Se un'applicazione richiede il consenso dell'amministratore e un amministratore accede senza che il parametro prompt=consent venga inviato, quando l'amministratore concede correttamente il consenso all'applicazione, il consenso sarà valido solo per l'account utente. Gli utenti normali non potranno ancora eseguire l'accesso o fornire il consenso all'applicazione. Questa funzionalità è utile se si vuole assegnare all'amministratore tenant la possibilità di esplorare l'applicazione prima di consentire l'accesso ad altri utenti.

L'applicazione può avere più livelli, ognuno rappresentato dalla propria registrazione nell'ID Microsoft Entra. Un esempio è un'applicazione nativa che esegue una chiamata a un'API Web o un'applicazione Web che esegue una chiamata a un'API Web. In entrambi i casi, il client (app nativa o app Web) richiede le autorizzazioni per eseguire la chiamata alla risorsa (API Web). Per fare in modo il client venga autorizzato correttamente nel tenant del cliente, tutte le risorse a cui richiede le autorizzazioni devono esistere già nel tenant del cliente. Se questa condizione non viene soddisfatta, Microsoft Entra ID restituisce un errore che indica che la risorsa deve essere aggiunta per prima.

Più livelli in un tenant singolo

Può trattarsi di un problema se l'applicazione logica è costituita da due o più registrazioni di applicazioni, ad esempio un client e una risorsa separati. Come si ottiene prima la risorsa nel tenant esterno? Microsoft Entra ID illustra questo caso abilitando il consenso del client e della risorsa in un unico passaggio. L'utente visualizza la somma totale delle autorizzazioni richieste dal client e dalla risorsa nella pagina del consenso. Per abilitare questo comportamento, la registrazione dell'applicazione della risorsa deve includere l'ID app del client come knownClientApplications nel manifesto dell'applicazione. Ad esempio:

"knownClientApplications": ["12ab34cd-56ef-78gh-90ij11kl12mn"]

Questo esempio è illustrato in un esempio di applicazione multi-tenant. Il diagramma seguente fornisce una panoramica del consenso per un'app multilivello registrata in un singolo tenant.

Diagramma che illustra il consenso all'app client nota multilivello.

Più livelli in tenant multipli

Un caso simile si verifica se i diversi livelli di un'applicazione vengono registrati in tenant diversi. Si consideri ad esempio il caso di compilazione di un'applicazione client nativa che chiama l'API di Exchange Online. Per sviluppare l'applicazione nativa e successivamente eseguire l'applicazione nativa nel tenant del cliente, è necessario che sia presente l'entità servizio Exchange Online. In questo caso lo sviluppatore e il cliente devono acquistare Exchange Online per creare l'entità servizio nei tenant.

Se si tratta di un'API creata da un'organizzazione diversa da Microsoft, lo sviluppatore dell'API deve fornire ai clienti un modo per fornire il consenso dell'applicazione nei tenant dei clienti. La progettazione consigliata è destinata allo sviluppatore di terze parti di compilare l'API in modo che possa funzionare anche come client Web per implementare l'iscrizione. A questo scopo, è necessario:

  1. Seguire le sezioni precedenti per assicurarsi che l'API implementi i requisiti di registrazione/codice dell'applicazione multi-tenant.
  2. Oltre a esporre gli ambiti/ruoli dell'API, assicurarsi che la registrazione includa l'autorizzazione "Accesso e lettura profilo utente" (fornita per impostazione predefinita).
  3. Implementare una pagina di iscrizione/accesso nel client Web e seguire le linee guida del consenso dell'amministratore.
  4. Quando l'utente acconsente all'applicazione, vengono creati i collegamenti all'entità servizio e alla delega di consenso nel tenant e l'applicazione nativa può ottenere i token per l'API.

Il diagramma seguente fornisce una panoramica del consenso per un'app multilivello registrata in diversi tenant.

Diagramma che illustra il consenso all'app multilivello multilivello.

Gli utenti e gli amministratori possono revocare il consenso all'applicazione in qualsiasi momento:

  • Gli utenti revocano l'accesso alle singole applicazioni rimuovendole dall'elenco Applicazioni riquadro di accesso.
  • Gli amministratori revocano l'accesso alle applicazioni rimuovendoli tramite la sezione Applicazioni aziendali dell'interfaccia di amministrazione di Microsoft Entra. Selezionare l'applicazione e passare alla scheda Autorizzazioni per revocare l'accesso.

Se un amministratore acconsente a un'applicazione per tutti gli utenti di un tenant, gli utenti non possono revocare l'accesso singolarmente. Solo l'amministratore può revocare l'accesso e soltanto per l'intera applicazione.

Applicazioni multi-tenant e memorizzazione nella cache dei token di accesso

Le applicazioni multi-tenant possono anche ottenere token di accesso per chiamare le API protette da Microsoft Entra ID. Un errore comune quando si usa Microsoft Authentication Library (MSAL) con un'applicazione multi-tenant consiste nel richiedere inizialmente un token per un utente usando /common, ricevere una risposta, quindi richiedere un token successivo per lo stesso utente usando /commonanche . Poiché la risposta da Microsoft Entra ID proviene da un tenant, non /common, MSAL memorizza nella cache il token come proveniente dal tenant. La chiamata successiva a per /common ottenere un token di accesso per l'utente perde la voce della cache e all'utente viene richiesto di eseguire di nuovo l'accesso. Per evitare questo errore della cache, assicurarsi che le chiamate successive per un utente già connesso vengano eseguite all'endpoint del tenant.

Vedi anche