Come consentire l'accesso a qualsiasi utente di Azure Active Directory (AD) usando il modello di applicazione multi-tenantHow to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern

Se si offre un'applicazione Software as a Service a molte organizzazioni, è possibile configurare l'applicazione in modo da consentire accessi da qualsiasi tenant di Azure AD.If you offer a Software as a Service application to many organizations, you can configure your application to accept sign-ins from any Azure AD tenant. In Azure AD questa configurazione viene definita impostazione dell'applicazione multi-tenant.In Azure AD, this configuration is called making your application multi-tenant. Gli utenti in qualsiasi tenant Azure AD saranno in grado di accedere all'applicazione dopo il consenso ad usare il loro account con l'applicazione.Users in any Azure AD tenant will be able to sign in to your application after consenting to use their account with your application.

Se si dispone di un'applicazione esistente che ha un proprio sistema di account, o supporta altri tipi di accesso da altri provider di cloud, l'aggiunta dell'accesso di Azure AD da un qualsiasi tenant è semplice.If you have an existing application that has its own account system, or supports other kinds of sign-in from other cloud providers, adding Azure AD sign-in from any tenant is simple. Registrare l'app, aggiungere il codice di accesso tramite OAuth2, OpenID Connect o SAML e inserire un pulsante "Accedi con Microsoft" all'applicazione.Just register your app, add sign-in code via OAuth2, OpenID Connect, or SAML, and put a "Sign In with Microsoft" button on your application. Fare clic sul pulsante seguente per ottenere altre informazioni sulla personalizzazione dell'applicazione.Click the following button to learn more about branding your application.

Pulsante AccediSign in button

Questo articolo presuppone che l'utente abbia già familiarità con la creazione di un'applicazione single-tenant per Azure AD.This article assumes you’re already familiar with building a single tenant application for Azure AD. In caso contrario, tornare alla home page della Guida per sviluppatori e provare una delle procedure di avvio rapido.If you’re not, head back up to the developer guide homepage and try one of our quick starts!

Quattro semplici passaggi consentono di convertire l'applicazione in un'applicazione multi-tenant di Azure AD:There are four simple steps to convert your application into an Azure AD multi-tenant app:

  1. Aggiornare la registrazione dell'applicazione in modo che sia multi-tenantUpdate your application registration to be multi-tenant
  2. Aggiornare il codice per l'invio delle richieste all'endpoint /commonUpdate your code to send requests to the /common endpoint
  3. Aggiornare il codice per gestire più valori dell'autorità di certificazioneUpdate your code to handle multiple issuer values
  4. Informarsi sul consenso dell'utente e dell'amministratore e apportare le modifiche appropriate al codiceUnderstand user and admin consent and make appropriate code changes

Esaminiamo in dettaglio ogni passaggio.Let’s look at each step in detail. È anche possibile passare direttamente a questo elenco di esempi multi-tenant.You can also jump straight to this list of multi-tenant samples.

Aggiornare la registrazione in modo che sia multi-tenantUpdate registration to be multi-tenant

Per impostazione predefinita, le registrazioni di API o app Web in Azure AD sono single-tenant.By default, web app/API registrations in Azure AD are single tenant. È possibile rendere la registrazione multi-tenant individuando l'opzione corrispondente nella pagina delle proprietà della registrazione dell'applicazione nel portale di Azure e impostandola su "Sì".You can make your registration multi-tenant by finding the “Multi-Tenanted” switch on the properties page of your application registration in the Azure portal and setting it to “Yes.”

Si noti anche che, per poter rendere un'applicazione multi-tenant in Azure AD, l'URI dell'ID app dell'applicazione deve essere univoco a livello globale.Also note, before an application can be made multi-tenant, Azure AD requires the App ID URI of the application to be globally unique. L'URI dell'ID App è uno dei modi in cui un'applicazione viene identificata nei messaggi di protocollo.The App ID URI is one of the ways an application is identified in protocol messages. Per un'applicazione single-tenant, è sufficiente che l'URI dell'ID App sia univoco all'interno del tenant.For a single tenant application, it is sufficient for the App ID URI to be unique within that tenant. Per un'applicazione multi-tenant, è necessario che sia univoco a livello globale in modo da Azure AD possa trovare l'applicazione in tutti i tenant.For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants. L'univocità globale viene applicata richiedendo che l'URI dell'ID App abbia un nome host corrispondente a un dominio verificato del tenant di Azure AD.Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified domain of the Azure AD tenant. Ad esempio, se il nome del tenant è contoso.onmicrosoft.com, l'URI ID app sarà https://contoso.onmicrosoft.com/myapp.For example, if the name of your tenant was contoso.onmicrosoft.com then a valid App ID URI would be https://contoso.onmicrosoft.com/myapp. Se il tenant ha un dominio verificato contoso.com, l'URI ID app valido sarà https://contoso.com/myapp.If your tenant had a verified domain of contoso.com, then a valid App ID URI would also be https://contoso.com/myapp. Se l'URI dell'ID App non segue questo modello, l'impostazione di un'applicazione come multi-tenant ha esito negativo.If the App ID URI doesn’t follow this pattern, setting an application as multi-tenant fails.

Per impostazione predefinita, le registrazioni client native sono multi-tenant.Native client registrations are multi-tenant by default. Non è necessario intraprendere alcuna azione per rendere multi-tenant una registrazione nativa dell'applicazione client.You don’t need to take any action to make a native client application registration multi-tenant.

Aggiornare il codice per l'invio delle richieste all'endpoint /commonUpdate your code to send requests to /common

In un'applicazione single-tenant le richieste di accesso vengono inviate all'endpoint di accesso del tenant.In a single tenant application, sign-in requests are sent to the tenant’s sign-in endpoint. Ad esempio, per contoso.onmicrosoft.com l'endpoint sarà:For example, for contoso.onmicrosoft.com the endpoint would be:

https://login.microsoftonline.com/contoso.onmicrosoft.com

Le richieste inviate all'endpoint del tenant possono eseguire l'accesso degli utenti (o guest) in questo tenant alle applicazioni in questo tenant.Requests sent to a tenant’s endpoint can sign in users (or guests) in that tenant to applications in that tenant. Con un'applicazione multi-tenant, l'applicazione non determina in anticipo il tenant di provienienza dell'utente, pertanto non è possibile inviare richieste all'endpoint del tenant.With a multi-tenant application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. Al contrario, le richieste vengono inviate a un endpoint che esegue il multiplexing tra tutti i tenant di Azure Active Directory:Instead, requests are sent to an endpoint that multiplexes across all Azure AD tenants:

https://login.microsoftonline.com/common

Quando Azure AD riceve una richiesta sull'endpoint /common, consente l'accesso dell'utente e quindi individua il tenant di provenienza dell'utente.When Azure AD receives a request on the /common endpoint, it signs the user in and as a consequence discovers which tenant the user is from. L'endpoint /common funziona con tutti i protocolli di autenticazione supportati da Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0 e WS-Federation.The /common endpoint works with all of the authentication protocols supported by Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation.

La risposta di accesso all'applicazione di accesso contiene un token che rappresenta l'utente.The sign-in response to the application then contains a token representing the user. Il valore dell'autorità di certificazione nel token indica a un'applicazione il tenant di provenienza dell'utente.The issuer value in the token tells an application what tenant the user is from. Quando l'endpoint /common restituisce una risposta, il valore dell'autorità di certificazione nel token corrisponde al tenant dell'utente.When a response returns from the /common endpoint, the issuer value in the token corresponds to the user’s tenant. È importante notare che l'endpoint /common non è un tenant o un'autorità di certificazione, ma è semplicemente un multiplexer.It’s important to note the /common endpoint is not a tenant and is not an issuer, it’s just a multiplexer. Quando si usa l'endpoint /common, è necessario aggiornare la logica dell'applicazione per la convalida dei token in modo da tenerne conto.When using /common, the logic in your application to validate tokens needs to be updated to take this into account.

Come indicato in precedenza, le applicazioni multi-tenant devono offrire anche un'esperienza di accesso coerente per gli utenti, adeguandosi alle linee guida di personalizzazione delle applicazioni di Azure AD.As mentioned earlier, multi-tenant applications should also provide a consistent sign-in experience for users, following the Azure AD application branding guidelines. Fare clic sul pulsante seguente per ottenere altre informazioni sulla personalizzazione dell'applicazione.Click the following button to learn more about branding your application.

Pulsante AccediSign in button

È ora possibile esaminare in modo più dettagliato l'uso dell'endpoint /common e l'implementazione del codice.Let’s take a look at the use of the /common endpoint and your code implementation in more detail.

Aggiornare il codice per gestire più valori dell'autorità di certificazioneUpdate your code to handle multiple issuer values

Le applicazioni Web e le API Web ricevono e convalidano i token da Azure AD.Web applications and web APIs receive and validate tokens from Azure AD.

Nota

Le applicazioni client native richiedono e ricevono i token da Azure AD e li inviano alle API in cui vengono convalidati.While native client applications request and receive tokens from Azure AD, they do so to send them to APIs, where they are validated. Le applicazioni native non convalidano i token e devono gestirli come opachi.Native applications do not validate tokens and must treat them as opaque.

Passiamo ora al modo in cui un'applicazione convalida i token ricevuti da Azure AD.Let’s look at how an application validates tokens it receives from Azure AD. Un'applicazione single-tenant prende in genere un valore dell'endpoint come:A single tenant application normally takes an endpoint value like:

https://login.microsoftonline.com/contoso.onmicrosoft.com

e lo usa per creare un URL di metadati, in questo caso OpenID Connect, come:and use it to construct a metadata URL (in this case, OpenID Connect) like:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

per scaricare due informazioni critiche che vengono usate per convalidare i token: il valore dell'autorità di certificazione e le chiavi di firma del tenant.to download two critical pieces of information that are used to validate tokens: the tenant’s signing keys and issuer value. Ogni tenant di Azure AD ha un valore univoco dell'autorità di certificazione del formato:Each Azure AD tenant has a unique issuer value of the form:

https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/

dove il valore GUID è la versione sicura di ridenominazione dell'ID tenant del tenant.where the GUID value is the rename-safe version of the tenant ID of the tenant. Se si fa clic sul collegamento dei metadati precedente per contoso.onmicrosoft.com, è possibile visualizzare il valore dell'autorità di certificazione nel documento.If you click on the preceding metadata link for contoso.onmicrosoft.com, you can see this issuer value in the document.

Quando un'applicazione single-tenant convalida un token, controlla la firma del token con le chiavi di firma del documento di metadati.When a single tenant application validates a token, it checks the signature of the token against the signing keys from the metadata document. Questo test consente di verificare che il valore dell'autorità di certificazione nel token corrisponda a quello che è stato trovato nel documento di metadati.This test allows it to make sure the issuer value in the token matches the one that was found in the metadata document.

Poiché l'endpoint /common non corrisponde a un tenant e non è un'autorità di certificazione, il valore dell'autorità di certificazione nei metadati per /common ha un URL basato su modello anziché un valore effettivo:Since the /common endpoint doesn’t correspond to a tenant and isn’t an issuer, when you examine the issuer value in the metadata for /common it has a templated URL instead of an actual value:

https://sts.windows.net/{tenantid}/

Un'applicazione multi-tenant non può quindi convalidare i token semplicemente confrontando il valore dell'autorità di certificazione nei metadati con il valore issuer nel token.Therefore, a multi-tenant application can’t validate tokens just by matching the issuer value in the metadata with the issuer value in the token. Un'applicazione multi-tenant richiede una logica per decidere quali valori di autorità di certificazione sono validi, in base alla parte ID del tenant del valore dell'autorità di certificazione.A multi-tenant application needs logic to decide which issuer values are valid and which are not, based on the tenant ID portion of the issuer value.

Se ad esempio un'applicazione multi-tenant consente l'accesso solo da tenant specifici che hanno eseguito l'accesso ai servizi, è necessario verificare il valore dell'autorità di certificazione o il valore di attestazione tid nel token per assicurarsi che sia incluso nel relativo elenco di sottoscrittori.For example, if a multi-tenant application only allows sign-in from specific tenants who have signed up for their service, then it must check either the issuer value or the tid claim value in the token to make sure that tenant is in their list of subscribers. Se un'applicazione multi-tenant gestisce solo persone e non adotta decisioni di accesso basate su tenant, è possibile ignorare il valore dell'autorità di certificazione.If a multi-tenant application only deals with individuals and doesn’t make any access decisions based on tenants, then it can ignore the issuer value altogether.

Negli esempi multi-tenant nella sezione Contenuti correlati alla fine di questo articolo la convalida dell'autorità di certificazione è disattivata per consentire l'accesso a qualsiasi tenant di Azure AD.In the multi-tenant samples in the Related Content section at the end of this article, issuer validation is disabled to enable any Azure AD tenant to sign in.

Esaminiamo l'esperienza utente per gli utenti che accedono ad applicazioni multi-tenant.Now let’s look at the user experience for users that are signing in to multi-tenant applications.

Per fare in modo che un utente possa accedere a un'applicazione in Azure AD, l'applicazione deve essere rappresentata nel tenant dell'utente.For a user to sign in to an application in Azure AD, the application must be represented in the user’s tenant. Ciò consente alle organizzazioni di eseguire operazioni come applicare criteri univoci quando gli utenti dal tenant accedono all'applicazione.This allows the organization to do things like apply unique policies when users from their tenant sign in to the application. Per un'applicazione single-tenant questa registrazione è semplice. È l'azione che viene eseguita quando si registra l'applicazione nel portale di Azure.For a single tenant application, this registration is simple; it’s the one that happens when you register the application in the Azure portal.

Per un'applicazione multi-tenant, la registrazione iniziale per l'applicazione si trova nel tenant di Azure AD usato dallo sviluppatore.For a multi-tenant application, the initial registration for the application lives in the Azure AD tenant used by the developer. Quando un utente di un tenant diverso accede all'applicazione per la prima volta, Azure AD richiede il consenso alle autorizzazioni richieste dall'applicazione.When a user from a different tenant signs in to the application for the first time, Azure AD asks them to consent to the permissions requested by the application. Se fornisce il consenso, viene creata una rappresentazione dell'applicazione denominata entità servizio nel tenant dell'utente ed è possibile procedere con l'accesso.If they consent, then a representation of the application called a service principal is created in the user’s tenant, and sign-in can continue. Viene anche creata una delega nella directory che registra il consenso dell'utente all'applicazione.A delegation is also created in the directory that records the user’s consent to the application. Vedere Oggetti applicazione e oggetti entità servizio per informazioni dettagliate sugli oggetti applicazione ed entità servizio dell'applicazione e su come interagiscono tra loro.See Application Objects and Service Principal Objects for details on the application's Application and ServicePrincipal objects, and how they relate to each other.

Consenso per l'app a livello singolo

Questa esperienza di consenso è interessata dalle autorizzazioni richieste dall'applicazione.This consent experience is affected by the permissions requested by the application. Azure AD supporta due tipi di autorizzazioni, delegate e solo app:Azure AD supports two kinds of permissions, app-only and delegated:

  • Un'autorizzazione delegata concede a un'applicazione la possibilità di agire come utente connesso per un sottoinsieme di operazioni che l'utente può eseguire.A delegated permission grants an application the ability to act as a signed in user for a subset of the things the user can do. Ad esempio, è possibile concedere a un'applicazione l'autorizzazione delegata per la lettura del calendario dell'utente connesso.For example, you can grant an application the delegated permission to read the signed in user’s calendar.
  • Un'autorizzazione solo app viene concessa direttamente all'identità dell'applicazione.An app-only permission is granted directly to the identity of the application. 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.For example, you can grant an application the app-only permission to read the list of users in a tenant, regardless of who is signed in to the application.

Alcune autorizzazioni possono essere concesse da un utente normale, mentre altre richiedono il consenso dell'amministratore tenant.Some permissions can be consented to by a regular user, while others require a tenant administrator’s consent.

Le autorizzazioni solo app richiedono il consenso dell'amministratore tenant.App-only permissions always require a tenant administrator’s consent. 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.If your application requests an app-only permission and a user tries to sign in to the application, an error message is displayed saying the user isn’t able to consent.

Alcune autorizzazioni delegate richiedono anche il consenso dell'amministratore tenant.Certain delegated permissions also require a tenant administrator’s consent. Ad esempio, il writeback in Azure AD come utente connesso richiede il consenso dell'amministratore tenant.For example, the ability to write back to Azure AD as the signed in user requires a tenant administrator’s consent. Come le autorizzazioni solo app, se un utente comune tenta di accedere a un'applicazione che richiede un'autorizzazione delegata per la quale è necessario il consenso dell'amministratore, viene visualizzato un errore nell'applicazione.Like app-only permissions, if an ordinary user tries to sign in to an application that requests a delegated permission that requires administrator consent, your application receives an error. 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.Whether or not a permission requires admin consent is determined by the developer that published the resource, and can be found in the documentation for the resource. Collegamenti ad argomenti che descrivono le autorizzazioni disponibili per le API Graph di Azure AD e API Graph di Microsoft sono disponibili nella sezione Contenuti correlati di questo articolo.Links to topics describing the available permissions for the Azure AD Graph API and Microsoft Graph API are in the Related Content section of this article.

Se l'applicazione usa autorizzazioni che richiedono il consenso dell'amministratore, è necessario che sia presente un movimento, ad esempio un pulsante o un collegamento, con cui l'amministratore può avviare l'azione.If your application uses permissions that require admin consent, you need to have a gesture such as a button or link where the admin can initiate the action. La richiesta inviata dall'applicazione per questa azione è una richiesta di autorizzazione OAuth2/OpenID Connect standard, ma che include anche il parametro prompt=admin_consent della stringa di query.The request your application sends for this action is a usual OAuth2/OpenID Connect authorization request, but that also includes the prompt=admin_consent query string parameter. Dopo che l'amministratore ha fornito il consenso e l'entità servizio è stata creata nel tenant del cliente, le successive richieste di accesso non richiedono il parametro prompt=admin_consent.Once the admin has consented and the service principal is created in the customer’s tenant, subsequent sign-in requests do not need the prompt=admin_consent parameter. 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.Since the administrator has decided the requested permissions are acceptable, no other users in the tenant are prompted for consent from that point forward.

Il parametro prompt=admin_consent può essere usato anche dalle applicazioni che richiedono autorizzazioni che non necessitano del consenso dell'amministratore.The prompt=admin_consent parameter can also be used by applications that request permissions that do not require admin consent. Questa operazione viene eseguita 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.This is done when the applicator requires an experience where the tenant admin “signs up” one time, and no other users are prompted for consent from that point on.

Se un'applicazione richiede l'autorizzazione dell'amministratore, e un amministratore accede ma il parametro prompt=admin_consent non viene inviato, l'amministratore concede correttamente il consenso all'applicazione solo per l'account utente.If an application requires admin consent, and an admin signs in but the prompt=admin_consent parameter is not sent, the admin successfully consents to the application only for their user account. Gli utenti normali non sono ancora in grado di eseguire l'accesso e fornire il consenso all'applicazione.Regular users are still not be able to sign in and consent to the application. Questa funzionalità è utile se si vuole assegnare all'amministratore tenant la possibilità di esplorare l'applicazione prima di consentire l'accesso ad altri utenti.This feature is useful if you want to give the tenant administrator the ability to explore your application before allowing other users access.

Un amministratore tenant può disabilitare la possibilità che gli utenti normali possano il consenso alle applicazioni.A tenant administrator can disable the ability for regular users to consent to applications. Se questa funzionalità è disabilitata, è necessario impostare il consenso dell'amministratore come obbligatorio sempre per l'applicazione nel tenant.If this capability is disabled, admin consent is always required for the application to be set up in the tenant. Se si vuole testare l'applicazione con il consenso dell'utente normale disabilitato, è possibile trovare l'opzione di configurazione nella sezione di configurazione del tenant di Azure AD del portale di Azure.If you want to test your application with regular user consent disabled, you can find the configuration switch in the Azure AD tenant configuration section of the Azure portal.

Nota

Alcune applicazioni offrono un'esperienza in cui gli utenti normali sono inizialmente in grado di fornire il consenso e successivamente l'applicazione può coinvolgere l'amministratore e richiedere le autorizzazioni che necessitano del consenso dell'amministratore.Some applications want an experience where regular users are able to consent initially, and later the application can involve the administrator and request permissions that require admin consent. Non è attualmente possibile eseguire questa operazione con una singola registrazione all'applicazione in Azure AD.There is no way to do this with a single application registration in Azure AD today. L'imminente endpoint del modello di distribuzione Resource Manager di Azure AD consente alle applicazioni di richiedere le autorizzazioni in fase di runtime, anziché al momento della registrazione, abilitando così questo scenario.The upcoming Azure AD Resource Manager deployment model endpoint allows applications to request permissions at runtime, instead of at registration time, which enables this scenario. Per altre informazioni, vedere la Guida per sviluppatori del modello di distribuzione Resource Manager di Azure AD.For more information, see the Azure AD App Model Resource Manager deployment model Developer Guide.

L'applicazione può avere più livelli, ognuno rappresentato dalla propria registrazione in Azure AD.Your application may have multiple tiers, each represented by its own registration in Azure AD. 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.For example, a native application that calls a web API, or a web application that calls a web API. In entrambi i casi, il client (app nativa o app Web) richiede le autorizzazioni per eseguire la chiamata alla risorsa (API Web).In both of these cases, the client (native app or web app) requests permissions to call the resource (web API). 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.For the client to be successfully consented into a customer’s tenant, all resources to which it requests permissions must already exist in the customer’s tenant. Se questa condizione non viene soddisfatta, Azure AD restituisce un errore indicante che prima deve essere aggiunta la risorsa.If this condition isn’t met, Azure AD returns an error that the resource must be added first.

Più livelli in un tenant singoloMultiple tiers in a single tenant

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.This can be a problem if your logical application consists of two or more application registrations, for example a separate client and resource. Come ottenere prima la risorsa nel tenant del cliente?How do you get the resource into the customer tenant first? Azure AD si occupa di questo caso, concedendo al client e alla risorsa l'autorizzazione in un unico passaggio.Azure AD covers this case by enabling client and resource to be consented in a single step. L'utente visualizza la somma totale delle autorizzazioni richieste dal client e dalla risorsa nella pagina del consenso.The user sees the sum total of the permissions requested by both the client and resource on the consent page. Per abilitare questo comportamento, la registrazione dell'applicazione della risorsa deve includere l'ID app del client come knownClientApplications nel manifesto dell'applicazione.To enable this behavior, the resource’s application registration must include the client’s App ID as a knownClientApplications in its application manifest. ad esempio:For example:

knownClientApplications": ["94da0930-763f-45c7-8d26-04d5938baab2"]

Questa proprietà può essere aggiornata tramite il manifesto dell'applicazione della risorsa.This property can be updated via the resource application’s manifest. Ciò viene illustrato in un client nativo multilivello che esegue la chiamata all'esempio di API Web nella sezione Contenuti correlati alla fine di questo articolo.This is demonstrated in a multi-tier native client calling web API sample in the Related Content section at the end of this article. Il diagramma seguente fornisce una panoramica del consenso per un'app multilivello registrata in un singolo tenant:The following diagram provides an overview of consent for a multi-tier app registered in a single tenant:

Consenso per l'app client nota multilivello

Più livelli in tenant multipliMultiple tiers in multiple tenants

Un caso simile si verifica se i diversi livelli di un'applicazione vengono registrati in tenant diversi.A similar case happens if the different tiers of an application are registered in different tenants. Ad esempio, si consideri il caso della creazione di un'applicazione client nativa che esegue la chiamata all'API di Office 365 Exchange Online.For example, consider the case of building a native client application that calls the Office 365 Exchange Online API. Per sviluppare l'applicazione nativa e successivamente eseguire l'applicazione nativa nel tenant del cliente, è necessario che sia presente l'entità servizio Exchange Online.To develop the native application, and later for the native application to run in a customer’s tenant, the Exchange Online service principal must be present. In questo caso lo sviluppatore e il cliente devono acquistare Exchange Online per creare l'entità servizio nei tenant.In this case, the developer and customer must purchase Exchange Online for the service principal to be created in their tenants.

Nel caso di un'API creata da un'organizzazione diversa da Microsoft, lo sviluppatore dell'API deve includere un modo che consenta ai clienti di fornire il consenso per l'applicazione nei tenant dei clienti.In the case of an API built by an organization other than Microsoft, the developer of the API needs to provide a way for their customers to consent the application into their customers' tenants. La progettazione consigliata è affinché lo sviluppatore di una terza parte compili l'API in modo tale che possa fungere anche da client Web per implementare l'iscrizione:The recommended design is for the 3rd party developer to build the API such that it can also function as a web client to implement sign-up :

  1. Seguire le sezioni precedenti per verificare che l'API implementi i requisiti del codice/registrazione dell'applicazione multi-tenantFollow the earlier sections to ensure the API implements the multi-tenant application registration/code requirements
  2. Oltre a esporre gli ambiti/ruoli dell'API, verificare che la registrazione comprenda l'autorizzazione di Azure AD "Accedi e leggi il profilo di un altro utente" (fornita per impostazione predefinita)In addition to exposing the API's scopes/roles, ensure the registration includes the "Sign in and read user profile" Azure AD permission (provided by default)
  3. Implementare una pagina di iscrizione/accesso nel client Web, seguendo le linee guida del consenso dell'amministratore descritte in precedenzaImplement a sign-in/sign-up page in the web client, following the admin consent guidance discussed earlier
  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 è in grado di ottenere i token per l'APIOnce the user consents to the application, the service principal and consent delegation links are created in their tenant, and the native application can get tokens for the API

Il diagramma seguente fornisce una panoramica del consenso per un'app multilivello registrata in diversi tenant:The following diagram provides an overview of consent for a multi-tier app registered in different tenants:

Consenso per l'app di terze parti multilivello

Gli utenti e gli amministratori possono revocare il consenso all'applicazione in qualsiasi momento:Users and administrators can revoke consent to your application at any time:

  • Gli utenti revocano l'accesso alle singole applicazioni rimuovendole dall'elenco Applicazioni riquadro di accesso.Users revoke access to individual applications by removing them from their Access Panel Applications list.
  • Gli amministratori revocano l'accesso alle applicazioni rimuovendole da Azure AD usando la sezione di gestione di Azure AD del portale di Azure.Administrators revoke access to applications by removing them from Azure AD using the Azure AD management section of the Azure portal.

Se un amministratore fornisce il consenso a un'applicazione per tutti gli utenti in un tenant, gli utenti non possono revocare l'accesso singolarmente.If an administrator consents to an application for all users in a tenant, users cannot revoke access individually. Solo l'amministratore può revocare l'accesso e soltanto per l'intera applicazione.Only the administrator can revoke access, and only for the whole application.

Il consenso è supportato in Azure AD tramite i protocolli OAuth, OpenID Connect, WS-Federation e SAML.Consent is supported in Azure AD via the OAuth, OpenID Connect, WS-Federation, and SAML protocols. I protocolli WS-Federation e SAML non supportano il parametro prompt=admin_consent e il consenso dell'amministratore è possibile solo tramite OAuth e OpenID Connect.The SAML and WS-Federation protocols do not support the prompt=admin_consent parameter, so admin consent is only possible via OAuth and OpenID Connect.

Applicazioni multi-tenant e memorizzazione nella cache dei token di accessoMulti-Tenant Applications and Caching Access Tokens

Le applicazioni multi-tenant possono anche ottenere i token di accesso per eseguire chiamate alle API protette da Azure AD.Multi-tenant applications can also get access tokens to call APIs that are protected by Azure AD. Un errore comune quando si usa Active Directory Authentication Library (ADAL) con un'applicazione multi-tenant è quello di richiedere inizialmente un token per un utente tramite /common, ricevere una risposta e quindi richiedere un token successivo per lo stesso utente usando sempre /common.A common error when using the Active Directory Authentication Library (ADAL) with a multi-tenant application, is to initially request a token for a user using /common, receive a response, then request a subsequent token for that same user also using /common. Poiché la risposta da Azure AD proviene da un tenant, non /common, la libreria ADAL memorizza nella cache il token come proveniente dal tenant.Since the response from Azure AD comes from a tenant, not /common, ADAL caches the token as being from the tenant. Nella chiamata successiva a /common per ottenere un token di accesso per l'utente non è presente la voce della cache e all'utente viene richiesto di accedere di nuovo.The subsequent call to /common to get an access token for the user misses the cache entry, and the user is prompted to sign in again. Per evitare questo errore della cache, assicurarsi che le chiamate successive per un utente già connesso vengano eseguite all'endpoint del tenant.To avoid missing the cache, make sure subsequent calls for an already signed in user are made to the tenant’s endpoint.

Passaggi successiviNext steps

Questo articolo illustra come compilare un'applicazione che consente a un utente di accedere da qualsiasi tenant Azure Active Directory.In this article, you learned how to build an application that can sign in a user from any Azure Active Directory tenant. Dopo aver abilitato l'accesso Single Sign-On tra l'app e Azure Active Directory, è anche possibile aggiornare l'applicazione per accedere alle API esposte dalle risorse di Microsoft, come Office 365.After enabling Single Sign-On between your app and Azure Active Directory, you can also update your application to access APIs exposed by Microsoft resources, like Office 365. Pertanto, è possibile offrire un'esperienza personalizzata nell'applicazione, ad esempio mostrando informazioni contestuali per gli utenti, ad esempio l'immagine del profilo o il successivo appuntamento nel calendario.So you can offer a personalized experience in your application, for example showing contextual information to the users, like their profile picture or their next calendar appointment. Per altre informazioni sulle chiamate API ai servizi di Azure Active Directory e Office 365 come Exchange, SharePoint, OneDrive, OneNote, pianificazione, Excel e altri ancora, visitare: API di Microsoft Graph.To learn more about making API calls to Azure Active Directory and Office 365 services like Exchange, SharePoint, OneDrive, OneNote, Planner, Excel, and more, visit: Microsoft Graph API.

Usare la sezione dei commenti seguente per fornire commenti e suggerimenti utili per migliorare e organizzare i contenuti disponibili.Use the following comments section to provide feedback and help us refine and shape our content.