Framework di identità globale di Azure Active Directory B2C
Azure Active Directory B2C è una soluzione CIAM (Customer Identity Access Management) in grado di supportare milioni di utenti e miliardi di autenticazioni al giorno. Si occupa degli aspetti di scalabilità e sicurezza della piattaforma di autenticazione, monitorando e gestendo automaticamente le minacce, ad esempio gli attacchi di tipo Denial of Service, password spraying o di forza bruta.
Azure Active Directory B2C (Azure AD B2C) è un servizio separato da Microsoft Entra ID. Si basa sulla stessa tecnologia dell'ID Microsoft Entra ma per uno scopo diverso. Consente alle aziende di creare applicazioni rivolte ai clienti e quindi consente l'iscrizione self-service alle applicazioni.
Azure AD B2C è un servizio distribuito a livello globale costituito da diversi componenti:
Directory
Quando si crea una soluzione Azure AD B2C, è necessario fornire una posizione per ospitare il servizio. Questa posizione riguarda solo l'area in cui verranno archiviati i dati del profilo utente, mentre il resto del servizio che elabora l'accesso viene eseguito a livello globale.
In genere si distribuisce un tenant B2C di Azure AD nell'area più vicina alla base utente. In questo modo è più semplice mantenere la conformità alle leggi di residenza dei dati, poiché il profilo utente viene replicato solo nell'area selezionata. Ciò offre anche prestazioni ottimali durante l'accesso, poiché le latenze di rete sono ottimizzate per l'archivio directory.
Quando la directory B2C di Azure AD richiede agli utenti del servizio in tutto il mondo, la struttura a livello di area rappresenta una sfida. È necessario determinare la posizione in cui creare il tenant di Azure AD B2C. Gli utenti esterni all'area selezionata potrebbero non essere conformi ai requisiti di residenza dei dati e possono anche riscontrare una maggiore latenza durante la verifica delle credenziali o la lettura dei dati del profilo utente.
Si consideri, ad esempio, un'applicazione che supporta gli utenti in Australia e America del Nord e la directory B2C di Azure AD viene creata nell'area America del Nord. Gli utenti che accedono dall'Australia possono affrontare tempi di elaborazione più lunghi per completare l'autenticazione.
Per soddisfare meglio i requisiti di residenza dei dati e attenuare i problemi di prestazioni, è necessario distribuire più tenant di Azure AD B2C. Inserendo un tenant in ogni area in cui opera l'azienda, le operazioni nella directory sono ottimizzate per latenza. Tuttavia, in questo modo, la soluzione crea altri sovraccarichi per configurare, gestire e proteggere queste risorse tenant sensibili in ogni area. Altri sovraccarichi includono:
Amministrazione tenant
Isolamento del tenant che comporta un'esperienza utente finale che non si sente globale
Fatturazione
Processi CI/CD per gestire criteri/registrazioni/chiavi dell'app
Questo documento propone architetture con Azure AD B2C che supportano meglio le soluzioni per i clienti che gestiscono gli utenti in tutto il mondo. Le soluzioni servono ai requisiti seguenti:
Gli utenti possono mantenere lo stesso set di credenziali, indipendentemente dalla posizione in cui accedono alle applicazioni.
Prestazioni e latenza coerenti indipendentemente dalla posizione in cui gli utenti eseguono l'autenticazione.
Semplifica la distribuzione di processi, framework o SDK ai team di sviluppatori con la configurazione minima possibile necessaria.
I profili utente possono essere mantenuti mentre gli utenti viaggiano in tutto il mondo. Ciò crea più valore nell'analisi generata dalle interazioni utente all'interno di qualsiasi servizio.
I dati utente del cliente vengono archiviati negli archivi dati a livello di area.
Di seguito sono riportati due approcci da considerare quando si implementa una piattaforma identity usando i tenant di Azure AD B2C per un modello di business globale.
Il primo approccio usa le aree geografiche come limite e applicazioni vengono configurate in modo specifico per l'area.
Il secondo approccio ha un limite globale per le applicazioni e usa un tenant di Azure AD B2C aggiuntivo per orchestrare l'interazione tra tenant a livello di area.
Orchestrazione tenant a livello di area
In questo modello le applicazioni sono ospitate per area o dispongono di configurazioni per area per connettersi a un tenant a livello di area. Le applicazioni inviano direttamente l'utente a un tenant specifico dell'area. La comunicazione tra tenant viene usata per eseguire l'autenticazione tra tenant o gli aggiornamenti del profilo tra tenant, quando l'utente potrebbe aver viaggiato in un'area diversa.
Orchestrazione del tenant a imbuto
In questo modello un tenant di Azure AD B2C incanala gli utenti in tenant di Azure AD B2C a livello di area. Il tenant a imbuto funziona come agente di orchestrazione di reindirizzamento ad altri tenant di Azure AD B2C. Questa operazione viene gestita da un componente distribuito a livello globale del servizio Azure AD B2C, pertanto le prestazioni non sono interessate. Questo reindirizzamento viene eseguito usando le federazione del provider di identità OpenId Connect.
La comunicazione tra tenant viene usata per eseguire l'autenticazione tra tenant o gli aggiornamenti del profilo tra tenant. Il tenant di imbuto fornisce applicazioni con cui comunicare un singolo endpoint.
L'architettura che si decide di modellare la soluzione dopo richiede scelte in base ai compromessi tra i due modelli descritti. Ad esempio, il modello a imbuto consente di mantenere una singola istanza di applicazioni. Nella sezione seguente vengono descritte le funzionalità, i criteri di selezione e le prestazioni che potrebbero influire sulla progettazione scelta.
Capacità e considerazioni
Nella tabella seguente vengono descritte le funzionalità fornite usando una progettazione basata su imbuto a livello di area:
| Funzionalità | Basato sull'area | Funnel basato su |
|---|---|---|
| Supporta l'iscrizione e l'accesso dell'account locale |
|
|
| Supporta l'iscrizione e l'accesso dell'account federato |
|
|
| Supporta l'autenticazione degli account locali per gli utenti che accedono dall'esterno dell'area registrata |
|
|
| Supporta l'autenticazione degli account federati per gli utenti che accedono dall'esterno dell'area registrata usando la ricerca basata su API multi-tenant |
|
|
| Impedisce l'iscrizione da più aree diverse |
|
|
| Le applicazioni in ogni area hanno un set di endpoint da connettere |
|
|
| Tutte le applicazioni si connettono a un singolo set di endpoint, indipendentemente dall'area ospitata |
|
|
| Supporta criteri di accesso condizionale con granularità fine. |
|
|
| Ottimizzato per i costi. |
|
In base alle funzionalità, le considerazioni seguenti devono essere prese in considerazione:
Quando si usa l'approccio basato sull'area, la considerazione principale è che l'approccio richiede che le applicazioni che si estendono su più aree abbiano le rispettive configurazioni per ogni tenant di Azure AD B2C a livello di area.
Quando si usa l'approccio basato su imbuto
C'è un costo del token doppio
È disponibile un reindirizzamento HTTP aggiuntivo introdotto
I domini personalizzati sono necessari in molti tenant
L'accesso condizionale viene applicato a livello di tenant, non a livello di applicazione
L'accesso Single Sign-Out tramite più IDP potrebbe presentare problemi
L'approccio scelto sarà basato sul numero di applicazioni ospitate e sui requisiti specifici per l'accesso alle applicazioni.
Prestazioni
Il vantaggio delle prestazioni dell'uso di più tenant, nella configurazione basata su imbuto o a livello di area, sarà un miglioramento rispetto all'uso di un singolo tenant di Azure AD B2C per le aziende operative a livello globale.
Quando si usa l'approccio basato su imbuto, il tenant di imbuto si trova in un'area specifica e serve gli utenti a livello globale. Poiché l'operazione di tenant a imbuto usa un componente globale del servizio Azure AD B2C, mantiene un livello coerente di prestazioni indipendentemente dalla posizione in cui gli utenti accedono.
Come illustrato nel diagramma precedente, il tenant di Azure AD B2C nell'approccio basato su imbuto utilizzerà solo il motore di criteri per eseguire il reindirizzamento ai tenant di Azure AD B2C a livello di area. Il componente motore di criteri B2C di Azure AD è distribuito a livello globale. Pertanto, il imbuto non è vincolato dal punto di vista delle prestazioni, indipendentemente dalla posizione in cui viene effettuato il provisioning del tenant di imbuto di Azure AD B2C. Una perdita di prestazioni viene rilevata a causa del reindirizzamento aggiuntivo tra i tenant di imbuto e di area nell'approccio basato su imbuto.
Nell'approccio basato su area, poiché ogni utente viene indirizzato al proprio azure AD B2C più locale, le prestazioni sono coerenti per tutti gli utenti che accedono.
I tenant regionali eseguono chiamate directory nell'archivio directory, ovvero l'unico componente a livello di area nelle architetture basate su imbuto e a livello regionale.
Viene rilevata una latenza aggiuntiva solo quando l'utente ha eseguito un'autenticazione in un'area diversa da cui hanno effettuato l'iscrizione. Questa operazione è dovuta al fatto che le chiamate verranno effettuate in diverse aree per raggiungere l'archivio directory in cui vive il proprio profilo per completare l'autenticazione.