Creare una soluzione di identità globale con approccio basato sull'area
In questo articolo vengono descritti gli scenari per l'approccio di progettazione basato sull'area. Prima di iniziare a progettare, è consigliabile esaminare le funzionalità e le prestazioni dell'approccio di progettazione basato su imbuto e area.
Account di progettazione per:
- Iscrizione e accesso dell'account locale
- Iscrizione e accesso dell'account federato
- Autenticazione degli account locali per gli utenti che accedono dall'esterno dell'area registrata, supportati dall'autenticazione basata sull'API multi-tenant.
- Autenticazione degli account federati per gli utenti che accedono dall'esterno dell'area registrata, supportati dalla ricerca basata sull'API multi-tenant
- Impedisce l'iscrizione da più aree diverse
- Le applicazioni in ogni area hanno un set di endpoint da connettere
Autenticazione dell'account locale
I casi d'uso seguenti sono tipici in un ambiente Azure AD B2C globale. I casi d'uso dell'account locale coprono anche gli account in cui l'utente viaggia. Ognuno fornisce un diagramma e i passaggi del flusso di lavoro per ogni caso d'uso.
Iscrizione utente locale
In questo caso d'uso viene illustrato come un utente dal paese di origine/area geografica esegue l'iscrizione con un account locale di Azure AD B2C.
L'utente da Europa, Medio Oriente e Africa (EMEA) tenta di iscriversi alla myapp.fr. Se l'utente non viene inviato al nome host locale, la gestione traffico applica un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente tenta di iscriversi. Il processo di iscrizione controlla la tabella di ricerca globale per determinare se l'utente esiste in uno dei tenant di Azure AD B2C a livello di area.
L'utente non viene trovato nella tabella di ricerca globale. L'account dell'utente viene scritto in Azure AD B2C e viene creato un record nella tabella di ricerca globale per tenere traccia dell'area in cui l'utente ha effettuato l'iscrizione.
Il tenant a livello di area rilascia un token all'app.
Tentativi di iscrizione dell'utente locale esistenti
In questo caso d'uso viene illustrato come un utente riregistri lo stesso messaggio di posta elettronica dal proprio paese/area geografica o da un'area diversa, viene bloccato.
L'utente dell'EMEA tenta di iscriversi al myapp.fr. Se l'utente non viene inviato al nome host locale, la gestione traffico applica un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente tenta di iscriversi. Il processo di iscrizione controlla la tabella di ricerca globale per determinare se l'utente esiste in uno dei tenant di Azure AD B2C a livello di area.
Il messaggio di posta elettronica dell'utente viene trovato nella tabella di ricerca globale, che indica che l'utente ha registrato questo messaggio di posta elettronica nella soluzione in un determinato momento precedente.
L'utente viene visualizzato con un errore, che indica che esiste l'account.
Accesso utente locale
In questo caso d'uso viene illustrato come un utente dal paese di origine/area geografica esegue un accesso con un account locale di Azure AD B2C.
L'utente dell'EMEA tenta di accedere al myapp.fr. Se l'utente non viene inviato al nome host locale, la gestione traffico applica un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente immette le credenziali nel tenant regionale.
Il tenant a livello di area rilascia un token all'app.
L'utente ha eseguito l'accesso all'app.
Accesso utente in viaggio
In questo caso d'uso viene illustrato come un utente può viaggiare tra aree e mantenere il profilo utente e le credenziali archiviati nel tenant a livello di area rispettivamente per l'iscrizione.
L'utente da America del Nord (NOAM) tenta di accedere alla myapp.fr, poiché sono in vacanza in Francia. Se l'utente non viene inviato al nome host locale, la gestione traffico applica un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente immette le credenziali nel tenant regionale.
Il tenant a livello di area esegue una ricerca nella tabella di ricerca globale, poiché il messaggio di posta elettronica dell'utente non è stato trovato nella directory emea di Azure AD B2C.
Il messaggio di posta elettronica dell'utente si trova in cui è stato effettuato l'iscrizione nel tenant di Azure AD B2C noAM.
Il tenant di Azure AD B2C dell'AREA EMEA esegue un flusso ROPC Microsoft Entra nel tenant NOAM azure AD B2C per verificare le credenziali.
Nota
Questa chiamata recupera anche un token per l'utente per eseguire una chiamata API Graph. Il tenant di Azure AD B2C DELL'EMEA esegue una chiamata API Graph al tenant di Azure AD B2C NOAM per recuperare il profilo dell'utente. Questa chiamata viene autenticata dal token di accesso per API Graph acquisito nell'ultimo passaggio.
Il tenant a livello di area rilascia un'app di backup del token.
Password dimenticata dall'utente locale
Questo caso d'uso illustra come un utente può reimpostare la password quando si trovano all'interno del proprio paese/area geografica.
L'utente dell'EMEA tenta di accedere al myapp.fr. Se l'utente non viene inviato al nome host locale, la gestione traffico applica un reindirizzamento.
L'utente arriva al tenant di Azure AD B2C emea e seleziona la password dimenticata. L'utente immette e verifica il messaggio di posta elettronica.
Email ricerca viene eseguita per determinare il tenant a livello di area in cui è presente l'utente.
L'utente fornisce una nuova password.
La nuova password viene scritta nel tenant di Azure AD B2C EMEA.
Il tenant a livello di area rilascia un token all'app.
Utente in viaggio dimenticato password
Questo caso d'uso illustra come un utente può reimpostare la password quando viaggiano dall'area in cui hanno registrato il proprio account.
L'utente di NOAM tenta di accedere alla myapp.fr, poiché sono in vacanza in Francia. Se l'utente non viene inviato al nome host locale, la gestione traffico applica un reindirizzamento.
L'utente arriva al tenant di Azure AD B2C emea e seleziona la password dimenticata. L'utente immette e verifica il messaggio di posta elettronica.
Email ricerca viene eseguita per determinare il tenant a livello di area in cui è presente l'utente.
Il messaggio di posta elettronica viene trovato nel tenant NOAM Azure AD B2C. L'utente fornisce una nuova password.
La nuova password viene scritta nel tenant NOAM azure AD B2C tramite una chiamata API Graph.
Il tenant a livello di area rilascia un token all'app.
Modifica della password utente locale
Questo caso d'uso illustra come un utente può modificare la password dopo aver effettuato l'accesso all'area in cui hanno registrato il proprio account.
L'utente da EMEA tenta di modificare la password dopo l'accesso a myapp.fr.
L'utente arriva al tenant di Azure AD B2C emea e il cookie Single-Sign On (SSO) consente all'utente di modificare immediatamente la password.
La nuova password viene scritta nell'account degli utenti nel tenant di Azure AD B2C EMEA.
Il tenant a livello di area rilascia un token all'app.
Modifica della password utente in viaggio
Questo caso d'uso illustra come un utente può modificare la password dopo l'accesso, lontano dall'area in cui hanno registrato il proprio account.
Gli utenti di NOAM tentano di modificare la password dopo l'accesso a myapp.fr.
L'utente arriva al tenant di Azure AD B2C emea e il set di cookie SSO consente all'utente di modificare immediatamente la password.
Il messaggio di posta elettronica degli utenti viene trovato nel tenant NOAM dopo aver controllato la tabella di ricerca globale.
La nuova password viene scritta nell'account utenti nel tenant NOAM azure AD B2C da MS API Graph chiamata.
Il tenant a livello di area rilascia un token all'app.
Autenticazione del provider di identità federata
I casi d'uso seguenti mostrano esempi di uso di identità federate per iscriversi o accedere come client di Azure AD B2C.
Iscrizione all'ID federato locale
Questo caso d'uso illustra come un utente dell'area locale effettua l'iscrizione al servizio usando un ID federato.
L'utente di EMEA tenta di iscriversi al myapp.fr. Se l'utente non viene inviato al nome host locale, gestione traffico applicherrà un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente sceglie di accedere con un provider di identità federato.
Eseguire una ricerca nella tabella di ricerca globale.
Se il collegamento dell'account è nell'ambito: procedere se l'identificatore IdP federato o il messaggio di posta elettronica restituito dal provider di identità federato non esiste nella tabella di ricerca.
Se il collegamento dell'account non è incluso nell'ambito: procedere se l'identificatore IdP federato restituito dal provider di identità federato non esiste nella tabella di ricerca.
Scrivere l'account utente nel tenant EMEA di Azure AD B2C.
Il tenant a livello di area rilascia un token all'app.
Accesso utente federato locale
Questo caso d'uso illustra come un utente dell'area locale accede al servizio usando un ID federato.
L'utente di EMEA tenta di accedere al myapp.fr. Se l'utente non viene inviato al nome host locale, gestione traffico applicherrà un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente sceglie di accedere con un provider di identità federato.
Eseguire una ricerca nella tabella di ricerca globale e verificare che l'ID federato dell'utente sia registrato in EMEA.
Il tenant a livello di area rilascia un token all'app.
Accesso utente federato in viaggio
Questo scenario illustra come un utente che si trova dall'area da cui ha effettuato l'iscrizione, esegue un accesso al servizio usando un IdP federato.
L'utente di NOAM tenta di accedere al myapp.fr. Se l'utente non viene inviato al nome host locale, gestione traffico applicherrà un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente sceglie di accedere con un provider di identità federato.
Nota
Usare lo stesso ID app della registrazione dell'app nel provider di identità di social networking in tutti i tenant regionali di Azure AD B2C. Ciò garantisce che l'ID restituito dal Provider di identità social sia sempre lo stesso.
Eseguire una ricerca nella tabella di ricerca globale e determinare che l'ID federato dell'utente è registrato in NOAM.
Leggere i dati dell'account dal tenant NOAM di Azure AD B2C usando MS API Graph.
Il tenant a livello di area rilascia un token all'app.
Collegamento dell'account con criteri di corrispondenza
Questo scenario illustra come gli utenti potranno eseguire il collegamento degli account quando viene soddisfatto un criterio di corrispondenza (in genere l'indirizzo di posta elettronica).
L'utente di EMEA tenta di accedere al myapp.fr. Se l'utente non viene inviato al nome host locale, gestione traffico applicherrà un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente seleziona per accedere con un provider di identità federato/idP di social networking.
Viene eseguita una ricerca nella tabella di ricerca globale per l'ID restituito dal provider di identità federato.
Dove l'ID non esiste, ma il messaggio di posta elettronica dal provider di identità federato esiste in EMEA Azure AD B2C, si tratta di uno scenario di collegamento dell'account.
Leggere l'utente dalla directory e determinare quali metodi di autenticazione sono abilitati nell'account. Presentare una schermata per consentire all'utente di accedere con un metodo di autenticazione esistente in questo account.
Dopo che l'utente dimostra di essere proprietari dell'account in Azure AD B2C, aggiungere il nuovo ID di social networking all'account esistente e aggiungere l'ID social all'account nella tabella di ricerca globale.
Il tenant a livello di area rilascia un token all'app.
Collegamento dell'account utente in viaggio con criteri di corrispondenza
Questo scenario illustra come gli utenti potranno eseguire il collegamento degli account quando sono lontani dall'area.
L'utente di NOAM tenta di accedere al myapp.fr. Se l'utente non viene inviato al nome host locale, gestione traffico applicherrà un reindirizzamento.
L'utente arriva al tenant EMEA.
L'utente seleziona per accedere con un provider di identità federato/idP di social networking.
Viene eseguita una ricerca nella tabella di ricerca globale per l'ID restituito dal provider di identità federato.
Dove l'ID non esiste e il messaggio di posta elettronica dal provider di identità federato esiste in un'altra area, si tratta di uno scenario di collegamento dell'account utente in viaggio.
Creare un collegamento id_token_hint che asserisce le attestazioni attualmente raccolte dagli utenti. Eseguire il bootstrap di un percorso nel tenant NOAM di Azure AD B2C usando la federazione. L'utente dimostrerà di essere proprietari dell'account tramite il tenant NOAM di Azure AD B2C.
Nota
Questo metodo viene usato per riutilizzare la logica di collegamento dell'account esistente nel tenant home e ridurre le chiamate API esterne per modificare la raccolta delle identità. Un esempio di criteri personalizzati che usa id_token_hint è disponibile qui.
Dopo che l'utente dimostra di essere proprietari dell'account in Azure AD B2C, aggiungere il nuovo ID di social networking all'account esistente effettuando una chiamata API Graph al tenant NOAM di Azure AD B2C. Aggiungere l'ID social all'account nella tabella di ricerca globale.
Il tenant a livello di area rilascia un token all'app.