Condividi tramite

Considerazioni sull'uso di Azure Active Directory B2C in un'architettura multi-tenant

  • Articolo

Azure Active Directory (Azure AD) B2C fornisce un'identità business-to-consumer come servizio. L'identità utente è in genere una delle considerazioni principali quando si progetta un'applicazione multi-tenant. La soluzione di gestione delle identità funge da gatekeeper per l'applicazione, assicurandosi che i tenant rimangano entro i limiti definiti dall'utente. Questo articolo descrive considerazioni e approcci per l'uso di Azure AD B2C in una soluzione multi-tenant.

Uno dei motivi più comuni per l'uso di Azure AD B2C consiste nell'abilitare la federazione delle identità per un'applicazione. La federazione delle identità è il processo di stabilire un trust tra due provider di identità in modo che gli utenti possano accedere con un account preesistente. Se si usa Azure AD B2C, è possibile implementare la federazione delle identità per consentire agli utenti di accedere usando i propri account di social networking o aziendali. Se si usa la federazione, gli utenti non devono creare un account locale separato specifico per l'applicazione.

Se non si ha familiarità con questo argomento, è consigliabile esaminare le risorse seguenti:

Nota

In questo articolo vengono illustrati due concetti denominati in modo simile: tenant dell'applicazione e tenant di Azure AD B2C.

Il termine tenant dell'applicazione viene usato per fare riferimento ai tenant, che potrebbero essere i clienti o i gruppi di utenti.

Azure AD B2C usa anche il concetto di tenant in riferimento alle singole directory e il termine multitenancy viene usato per fare riferimento alle interazioni tra più tenant di Azure AD B2C. Anche se i termini sono gli stessi, i concetti non sono. Quando si fa riferimento a un tenant di Azure AD B2C in questo articolo, viene usato il termine completo tenant di Azure AD B2C.

Identità nelle soluzioni multi-tenant

Nelle soluzioni multi-tenant, è comune combinare più servizi di gestione delle identità per ottenere diversi set di requisiti. Molte soluzioni hanno due set distinti di identità:

  • Identità dei clienti, che sono per gli account utente finale. Controllano il modo in cui gli utenti dei tenant ottengono l'accesso alle applicazioni.
  • Identità interne, che gestiscono il modo in cui il proprio team gestisce la soluzione.

Questi diversi tipi di identità usano in genere anche servizi di identità distinti. Azure AD B2C è un servizio CIAM (Customer Identity and Access Management) usato dagli utenti dei tenant per accedere alla soluzione. Microsoft Entra ID è un servizio di gestione delle identità e degli accessi (IAM) usato dall'utente e dal team per gestire le risorse di Azure e controllare l'applicazione.

Si consideri un esempio di soluzione multi-tenant creata da Fabrikam. La soluzione usa una combinazione dei due servizi per soddisfare i requisiti di Fabrikam:

  • Fabrikam implementa Azure AD B2C in modo che i clienti (tenant) dell'azienda possano accedere alle applicazioni.
  • I dipendenti di Fabrikam usano la directory Microsoft Entra dell'organizzazione per ottenere l'accesso alla propria soluzione per scopi di gestione e amministrazione. Usano le stesse identità usate per accedere ad altre risorse di Fabrikam, ad esempio Microsoft Office.

Il diagramma seguente illustra questo esempio:

Diagramma che illustra due applicazioni con due metodi di accesso.

Modelli di isolamento

Quando si usa Azure AD B2C, è necessario decidere come isolare gli account utente tra tenant applicazione diversi.

È necessario prendere in considerazione domande come:

  • È necessario eseguire la federazione degli accessi ai provider di identità del cliente? Ad esempio, è necessario abilitare la federazione per SAML, Microsoft Entra ID, provider di accesso social o altre origini?
  • L'utente o i tenant hanno requisiti di residenza dei dati?
  • L'utente deve accedere a più tenant dell'applicazione?
  • Sono necessarie autorizzazioni complesse e/o controllo degli accessi in base al ruolo?
  • Chi accede all'applicazione? Le diverse categorie di utenti sono spesso chiamate utenti utente.

La tabella seguente riepiloga le differenze tra i principali modelli di tenancy per Azure AD B2C:

Considerazione Tenant di Azure AD B2C condiviso Tenant di Azure AD B2C partizionato verticalmente Un tenant di Azure AD B2C per ogni tenant dell'applicazione
Isolamento dei dati I dati di ogni tenant dell'applicazione vengono archiviati in un singolo tenant di Azure AD B2C, ma possono essere accessibili solo dagli amministratori I dati di ogni tenant dell'applicazione vengono distribuiti tra diversi tenant di Azure AD B2C, ma sono accessibili solo dagli amministratori I dati di ogni tenant dell'applicazione vengono archiviati in un tenant di Azure AD B2C dedicato, ma è accessibile solo dagli amministratori
Complessità della distribuzione Basso Da medio a alto, a seconda della strategia di partizionamento Molto alto
Limiti da considerare Richieste per tenant di Azure AD B2C, richieste per indirizzo IP client Combinazione di richieste, numero di tenant di Azure AD B2C per sottoscrizione e numero di directory per un singolo utente, a seconda della strategia di partizionamento Numero di tenant di Azure AD B2C per sottoscrizione, numero massimo di directory per un singolo utente
Complessità operativa Basso Da medio a alto, a seconda della strategia di partizionamento Molto alto
Numero di tenant di Azure AD B2C necessari Uno Tra uno e n, a seconda della strategia di partizionamento n, dove n è il numero di tenant dell'applicazione
Scenario di esempio Si sta creando un'offerta SaaS per i consumer con requisiti di residenza dei dati bassi o senza requisiti di residenza dei dati, ad esempio un servizio di streaming di musica o video. Si sta creando un'offerta SaaS, ad esempio una contabilità e un record che mantiene l'applicazione per le aziende. È necessario supportare i requisiti di residenza dei dati o un numero elevato di provider di identità federati personalizzati. Si sta creando un'offerta SaaS, ad esempio un'applicazione per la gestione dei record per enti pubblici per le aziende. I clienti impongono un elevato livello di isolamento dei dati da altri tenant dell'applicazione.

Tenant di Azure AD B2C condiviso

In genere è più semplice gestire un singolo tenant di Azure AD B2C condiviso se i requisiti lo consentono. È necessario mantenere un solo tenant a lungo termine e questa opzione crea il sovraccarico più basso.

Nota

È consigliabile usare un tenant di Azure AD B2C condiviso per la maggior parte degli scenari.

È consigliabile prendere in considerazione un tenant di Azure AD B2C condiviso quando:

  • Non sono previsti requisiti di residenza dei dati o requisiti rigorosi di isolamento dei dati.
  • I requisiti dell'applicazione rientrano nei limiti del servizio Azure AD B2C.
  • Se si dispone di provider di identità federati, è possibile usare Individuazione area di autenticazione principale per selezionare automaticamente un provider per l'accesso di un utente oppure è accettabile che gli utenti selezionino manualmente uno da un elenco.
  • Si ha un'esperienza di accesso unificata per tutti i tenant dell'applicazione.
  • Gli utenti finali devono accedere a più tenant di applicazioni usando un singolo account.

Questo diagramma illustra il modello di tenant di Azure AD B2C condiviso:

Diagramma che mostra tre applicazioni che si connettono a un singolo tenant di Azure AD B2C condiviso.

Tenant di Azure AD B2C partizionati verticalmente

Il provisioning di tenant di Azure AD B2C partizionati verticalmente è una strategia progettata per ridurre al minimo, quando possibile, il numero di tenant di Azure AD B2C necessari. È un mezzo tra gli altri modelli di tenancy. Il partizionamento verticale offre maggiore flessibilità nella personalizzazione per tenant specifici quando necessario. Non crea tuttavia il sovraccarico operativo associato al provisioning di un tenant di Azure AD B2C per ogni tenant dell'applicazione.

I requisiti di distribuzione e manutenzione per questo modello di tenancy sono superiori a quelli di un singolo tenant di Azure AD B2C, ma sono inferiori a quelli che saranno se si usa un tenant di Azure AD B2C per ogni tenant dell'applicazione. È comunque necessario progettare e implementare una strategia di distribuzione e manutenzione per più tenant nell'ambiente.

Il partizionamento verticale è simile al modello di partizionamento orizzontale dei dati. Per partizionare verticalmente i tenant di Azure AD B2C, è necessario organizzare i tenant dell'applicazione in gruppi logici. Questa categorizzazione dei tenant è spesso detta strategia di partizionamento. La strategia di partizionamento deve essere basata su un fattore comune e stabile del tenant dell'applicazione, ad esempio l'area, le dimensioni o i requisiti personalizzati di un tenant dell'applicazione. Ad esempio, se l'obiettivo è quello di risolvere i requisiti di residenza dei dati, è possibile decidere di distribuire un tenant di Azure AD B2C per ogni area che ospita i tenant dell'applicazione. In alternativa, se si raggruppa per dimensione, è possibile decidere di individuare la maggior parte delle identità dei tenant dell'applicazione in un singolo tenant di Azure AD B2C, ma individuare i tenant delle applicazioni più grandi nei propri tenant di Azure AD B2C dedicati.

Importante

Evitare di basare la strategia di partizionamento su fattori che possono cambiare nel tempo, perché è difficile spostare gli utenti tra tenant di Azure AD B2C. Ad esempio, se si crea un'offerta SaaS con più SKU o livelli di prodotto, non è consigliabile partizionare gli utenti in base allo SKU selezionato, perché lo SKU potrebbe cambiare se il cliente aggiorna il prodotto.

È consigliabile effettuare il provisioning dei tenant di Azure AD B2C usando una strategia partizionata verticalmente se:

  • Sono previsti requisiti di residenza dei dati oppure è necessario separare gli utenti in base all'area geografica.
  • Si dispone di un numero elevato di provider di identità federati e non è possibile usare Individuazione area di autenticazione principale per selezionare automaticamente uno con cui un utente può accedere.
  • L'applicazione è o può essere consapevole della multi-tenancy e conosce il tenant di Azure AD B2C a cui gli utenti devono accedere.
  • Si ritiene che i tenant di applicazioni più grandi possano raggiungere i limiti di Azure AD B2C.
  • È disponibile una strategia a lungo termine per la distribuzione e la gestione di un numero medio-elevato di tenant di Azure AD B2C.
  • È disponibile una strategia per partizionare i tenant dell'applicazione tra una o più sottoscrizioni di Azure per funzionare entro il limite per il numero di tenant di Azure AD B2C che possono essere distribuiti in una sottoscrizione di Azure.

Il diagramma seguente illustra il modello di tenant di Azure AD B2C partizionato verticalmente:

Diagramma che mostra tre applicazioni. Due sono connessi a un tenant di Azure AD B2C condiviso. Il terzo è connesso al proprio tenant di Azure AD B2C.

Un tenant di Azure AD B2C per ogni tenant dell'applicazione

Se si effettua il provisioning di un tenant di Azure AD B2C per ogni tenant dell'applicazione, è possibile personalizzare molti fattori per ogni tenant. Tuttavia, questo approccio crea un aumento significativo del sovraccarico. È necessario sviluppare una strategia di distribuzione e manutenzione per un numero potenzialmente elevato di tenant di Azure AD B2C.

È anche necessario essere consapevoli dei limiti del servizio. Le sottoscrizioni di Azure consentono di distribuire solo un numero limitato di tenant di Azure AD B2C. Se è necessario distribuire più del limite consentito, è necessario prendere in considerazione una progettazione di sottoscrizione appropriata per poter bilanciare i tenant di Azure AD B2C tra più sottoscrizioni. Esistono anche altri limiti di Microsoft Entra, ad esempio il numero di directory a cui un singolo utente può creare e il numero di directory a cui un utente può appartenere.

Avviso

A causa della complessità di questo approccio, è consigliabile considerare prima gli altri modelli di isolamento. Questa opzione è inclusa qui per motivi di completezza, ma non è l'approccio giusto per la maggior parte dei casi d'uso.

Un malinteso comune consiste nel presupporre che, se si usa il modello Stamp di distribuzione, è necessario includere i servizi di identità in ogni timbro. Questo non è necessariamente vero e spesso è possibile usare un altro modello di isolamento. Esercizio di diligenza e giustificazione aziendale chiara se si usa questo modello di isolamento. Il sovraccarico di distribuzione e manutenzione è significativo.

È consigliabile prendere in considerazione il provisioning di un tenant di Azure AD B2C per ogni tenant dell'applicazione solo se:

  • Sono previsti rigorosi requisiti di isolamento dei dati per i tenant dell'applicazione.
  • È disponibile una strategia a lungo termine per la distribuzione e la gestione di un numero elevato di tenant di Azure AD B2C.
  • È disponibile una strategia per partizionare i clienti tra una o più sottoscrizioni di Azure per rispettare il limite di Azure AD B2C per ogni tenant della sottoscrizione.
  • L'applicazione è o può essere consapevole della multi-tenancy e conosce il tenant di Azure AD B2C a cui gli utenti devono accedere.
  • È necessario eseguire la configurazione personalizzata per ogni tenant dell'applicazione.
  • Gli utenti finali non devono accedere a più tenant di applicazioni tramite lo stesso account di accesso.

Il diagramma seguente illustra l'uso di un tenant di Azure AD B2C per ogni tenant dell'applicazione:

Diagramma che mostra tre applicazioni, ognuna delle quali si connette al proprio tenant di Azure AD B2C.

Federazione delle identità

È necessario configurare ogni provider di identità federato, tramite un flusso utente o in un criterio personalizzato. In genere, durante l'accesso, gli utenti selezionano il provider di identità da usare per l'autenticazione. Se si usa un modello di isolamento tenant condiviso o si dispone di un numero elevato di provider di identità federati, è consigliabile usare l'individuazione dell'area di autenticazione principale per selezionare automaticamente un provider di identità durante l'accesso.

È anche possibile usare la federazione delle identità come strumento per la gestione di più tenant di Azure AD B2C tramite la federazione tra i tenant di Azure AD B2C. In questo modo l'applicazione può considerare attendibile un singolo tenant di Azure AD B2C. L'applicazione non deve tenere presente che i clienti sono divisi tra più tenant di Azure AD B2C. Questo approccio viene usato più comunemente nel modello di isolamento partizionato verticalmente, quando gli utenti vengono partizionati in base all'area. Se si adotta questo approccio, è necessario prendere in considerazione alcune considerazioni. Per una panoramica di questo approccio, vedere Soluzioni di gestione delle identità globali.

Individuazione dell'area di autenticazione principale

Individuazione dell'area di autenticazione principale è il processo di selezione automatica di un provider di identità federato per l'evento di accesso di un utente. Se si seleziona automaticamente il provider di identità dell'utente, non è necessario richiedere all'utente di selezionare un provider.

L'individuazione dell'area di autenticazione principale è importante quando si usa un tenant di Azure AD B2C condiviso e si consente anche ai clienti di usare il proprio provider di identità federato. È possibile evitare una progettazione in cui un utente deve selezionare da un elenco di provider di identità. In questo modo si aggiunge complessità al processo di accesso. Inoltre, un utente potrebbe selezionare accidentalmente un provider non corretto, causando l'esito negativo del tentativo di accesso.

È possibile configurare l'individuazione dell'area di autenticazione principale in vari modi. L'approccio più comune consiste nell'usare il suffisso di dominio dell'indirizzo di posta elettronica dell'utente per determinare il provider di identità. Si supponga, ad esempio, che Northwind Traders sia un cliente della soluzione multi-tenant di Fabrikam. L'indirizzo user@northwindtraders.com di posta elettronica include il suffisso northwindtraders.comdi dominio , che può essere mappato al provider di identità federato northwind Traders.

Per altre informazioni, vedere Individuazione dell'area di autenticazione principale. Per un esempio di come implementare questo approccio in Azure AD B2C, vedere il repository GitHub degli esempi di Azure AD B2C.

Residenza dei dati

Quando si effettua il provisioning di un tenant di Azure AD B2C, si seleziona, ai fini della residenza dei dati, un'area in cui distribuire il tenant. Questa scelta è importante perché specifica l'area in cui risiedono i dati dei clienti quando sono inattivi. Se si hanno requisiti di residenza dei dati per un subset dei clienti, è consigliabile usare la strategia partizionata verticalmente.

Autorizzazione

Per una soluzione di identità avanzata, è necessario prendere in considerazione l'autorizzazione oltre all'autenticazione. Esistono diversi approcci all'uso di Microsoft Identity Platform per creare una strategia di autorizzazione per l'applicazione. L'esempio AppRoles illustra come usare i ruoli dell'app Azure AD B2C per implementare l'autorizzazione in un'applicazione. Descrive anche approcci di autorizzazione alternativi.

Non esiste un unico approccio all'autorizzazione ed è necessario considerare le esigenze dell'applicazione e dei clienti quando si decide un approccio.

Gestione

Quando si pianifica una distribuzione multi-tenant di Azure AD B2C, è necessario considerare la manutenzione a lungo termine delle risorse di Azure AD B2C. Un tenant di Azure AD B2C, come il tenant Microsoft Entra dell'organizzazione, è una risorsa che è necessario creare, gestire, gestire e proteggere. Anche se l'elenco seguente non è completo, è consigliabile considerare la manutenzione sostenuta in aree come le seguenti:

  • Governance del tenant. Chi gestisce il tenant di Azure AD B2C? Quali ruoli elevati hanno bisogno di questi amministratori? Come si configurano i criteri di accesso condizionale e MFA per gli amministratori? Come si monitora il tenant di Azure AD B2C a lungo termine?
  • Configurazione del percorso utente. Come si distribuiscono le modifiche al tenant o ai tenant di Azure AD B2C? Come si testano le modifiche ai flussi utente o ai criteri personalizzati prima di distribuirli?
  • Provider di identità federati. È necessario aggiungere o rimuovere provider di identità nel tempo? Se si consente a ognuno dei clienti di usare il proprio provider di identità, come è possibile gestirlo su larga scala?
  • Registrazioni app. Molte registrazioni dell'app Microsoft Entra usano un segreto client o un certificato per l'autenticazione. Come si ruotano questi segreti o certificati quando è necessario?
  • Chiavi dei criteri. Se si usano criteri personalizzati, come si ruotano le chiavi dei criteri quando è necessario?
  • Credenziali utente. Come si gestiscono le informazioni utente e le credenziali? Cosa accade se uno degli utenti è bloccato o dimentica una password e richiede l'intervento dell'amministratore o del servizio clienti?

Tenere presente che è necessario considerare queste domande per ogni tenant di Azure AD B2C distribuito. È anche consigliabile considerare il modo in cui i processi cambiano quando si hanno più tenant di Azure AD B2C da gestire. Ad esempio, la distribuzione manuale delle modifiche ai criteri personalizzati in un tenant di Azure AD B2C è semplice, ma la distribuzione manuale in cinque tenant richiede molto tempo e rischiosa.

Distribuzioni e DevOps

Un processo DevOps ben definito consente di ridurre al minimo il sovraccarico necessario per la gestione dei tenant di Azure AD B2C. È consigliabile implementare le procedure DevOps all'inizio del processo di sviluppo. Idealmente, è consigliabile provare ad automatizzare tutte o la maggior parte delle attività di manutenzione, inclusa la distribuzione di modifiche ai criteri personalizzati o ai flussi utente. È anche consigliabile pianificare la creazione di più tenant di Azure AD B2C per testare progressivamente le modifiche negli ambienti inferiori prima di distribuirle nei tenant di produzione. Le pipeline DevOps potrebbero eseguire queste attività di manutenzione. È possibile usare l'API Microsoft Graph per gestire a livello di codice i tenant di Azure AD B2C.

Per altre informazioni sulle distribuzioni automatizzate e sulla gestione di Azure AD B2C, vedere le risorse seguenti.

Importante

Alcuni degli endpoint usati per gestire Azure AD B2C a livello di codice non sono disponibili a livello generale. Le API nella versione beta di Microsoft Graph sono soggette a modifiche in qualsiasi momento e sono soggette a condizioni di servizio non definitive.

Confronto tra Microsoft Entra B2B e Azure AD B2C

Microsoft Entra B2B Collaboration è una funzionalità di Microsoft Entra per ID esterno che è possibile usare per invitare gli utenti guest nel tenant Microsoft Entra dell'organizzazione in modo da poter collaborare con loro. In genere, si usa collaborazione B2B quando è necessario concedere a un utente esterno, ad esempio un fornitore, l'accesso alle risorse nel tenant di Microsoft Entra.

Azure AD B2C è un prodotto unico a parte Microsoft Entra per ID esterno che offre un set di funzionalità diverso. Azure AD B2C deve essere usato dai clienti del prodotto. Il tenant di Azure AD B2C è distinto dal tenant Microsoft Entra dell'organizzazione.

A seconda degli scenari e degli utenti, potrebbe essere necessario usare Microsoft Entra B2B, Azure AD B2C o anche entrambi contemporaneamente. Ad esempio, se l'applicazione deve autenticare più tipi di utenti, ad esempio il personale dell'organizzazione, gli utenti che lavorano per un fornitore e i clienti, tutti all'interno della stessa app, è possibile usare Microsoft Entra B2B e Azure AD B2C insieme per soddisfare questo requisito.

Per altre informazioni, vedi:

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi