Condividi tramite

Creare una soluzione di identità globale con approccio basato su imbuto

  • Articolo

In questo articolo vengono descritti gli scenari per l'approccio di progettazione basato su imbuto. Prima di iniziare a progettare, è consigliabile esaminare le funzionalità e le prestazioni dell'approccio di progettazione basato su imbuto e area. Questo articolo aiuterà ulteriormente a determinare quale progettazione può adattarsi meglio per l'organizzazione.

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 singolo endpoint con cui connettersi

Casi d'uso per l'accesso all'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. Vengono forniti 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.

Screenshot che mostra il flusso di iscrizione dell'utente locale.

  1. Un utente dell'Europa, del Medio Oriente e dell'Africa (EMEA) tenta di iscriversi a myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, la gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant global funnel di Azure AD B2C. Questo tenant è configurato per reindirizzare a un tenant di Azure AD B2C a livello di area in base ai criteri definiti usando la federazione OpenId. Può trattarsi di una ricerca basata su Application clientId.

  3. 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.

  4. 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.

  5. Il tenant a livello di area rilascia un token al tenant di imbuto.

  6. Il tenant a imbuto genera un token all'applicazione.

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.

Screenshot che mostra il flusso di iscrizione dell'account esistente.

  1. Un utente dell'EMEA tenta di iscriversi alla myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, la gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant global funnel di Azure AD B2C. Questo tenant è configurato per reindirizzare a un tenant di Azure AD B2C a livello di area in base a alcuni criteri usando la federazione OpenId. Può trattarsi di una ricerca basata su Application clientId.

  3. 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.

  4. 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.

  5. 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.

Screenshot che mostra il flusso di accesso dell'utente locale.

  1. Un utente dell'EMEA tenta di accedere alla myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, la gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant globale a imbuto di Azure AD B2C. Questo tenant è configurato per reindirizzare a un tenant di Azure AD B2C a livello di area in base a alcuni criteri usando la federazione OpenId. Può trattarsi di una ricerca basata su application clientId.

  3. L'utente immette le credenziali nel tenant regionale.

  4. Il tenant a livello di area rilascia un token al tenant di imbuto.

  5. Il tenant a imbuto genera un token all'applicazione.

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.

Screenshot che mostra il flusso di accesso dell'utente in viaggio.

  1. Un utente di America del Nord (NOAM) tenta di accedere alle myapp.fr mentre sono in vacanza in Francia. Se l'utente non viene inviato all'istanza dell'applicazione locale, la gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant globale a imbuto di Azure AD B2C. Questo tenant è configurato per reindirizzare a un tenant di Azure AD B2C a livello di area in base a alcuni criteri usando la federazione OpenId. Può trattarsi di una ricerca basata su Application clientId.

  3. L'utente immette le credenziali nel tenant regionale.

  4. 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.

  5. Il messaggio di posta elettronica dell'utente si trova in cui è stato effettuato l'iscrizione nel tenant di Azure AD B2C noAM.

  6. 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.

  7. Il tenant a livello di area rilascia un token al tenant di imbuto.

  8. Il tenant a imbuto genera un token all'applicazione.

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.

Screenshot che mostra il flusso password dimenticato dall'utente locale.

  1. Un utente dell'EMEA tenta di accedere alla myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, la gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant globale a imbuto di Azure AD B2C. Questo tenant è configurato per reindirizzare a un tenant di Azure AD B2C a livello di area in base a alcuni criteri usando la federazione OpenId. Può trattarsi di una ricerca basata su application clientId.

  3. 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.

  4. Email ricerca viene eseguita per determinare il tenant a livello di area in cui è presente l'utente.

  5. L'utente fornisce una nuova password.

  6. La nuova password viene scritta nel tenant di Azure AD B2C EMEA.

  7. Il tenant a livello di area rilascia un token al tenant di imbuto.

  8. Il tenant a imbuto genera un token all'applicazione.

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.

Screenshot che mostra il flusso di password dimenticato dall'utente in viaggio.

  1. Un utente di NOAM tenta di accedere alla myapp.fr poiché sono in vacanza in Francia. Se l'utente non viene inviato all'istanza dell'applicazione locale, la gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant globale a imbuto di Azure AD B2C. Questo tenant è configurato per reindirizzare a un tenant di Azure AD B2C a livello di area in base a alcuni criteri usando la federazione OpenId. Può trattarsi di una ricerca basata su application clientId.

  3. 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.

  4. Email ricerca viene eseguita per determinare il tenant a livello di area in cui è presente l'utente.

  5. Il messaggio di posta elettronica viene trovato nel tenant NOAM Azure AD B2C. L'utente fornisce una nuova password.

  6. La nuova password viene scritta nel tenant NOAM di Azure AD B2C tramite una chiamata API Graph.

  7. Il tenant a livello di area rilascia un token al tenant a imbuto.

  8. Il tenant a imbuto rilascia un token all'applicazione.

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 ha registrato il proprio account.

Screenshot che mostra il flusso di modifica della password dell'utente locale.

  1. Un utente di EMEA tenta di modificare la password dopo l'accesso a myapp.fr.

  2. L'utente raggiunge il tenant a imbuto globale di Azure AD B2C. Questo tenant è configurato per il reindirizzamento a un tenant di Azure AD B2C a livello di area in base ad alcuni criteri che usano la federazione OpenId. Può trattarsi di una ricerca basata su application clientId.

  3. L'utente arriva al tenant EMEA di Azure AD B2C e il set di cookie Single-Sign On (SSO) consente all'utente di modificare immediatamente la password.

  4. La nuova password viene scritta nell'account utente nel tenant EMEA di Azure AD B2C.

  5. Il tenant a livello di area rilascia un token al tenant a imbuto.

  6. Il tenant a imbuto rilascia un token all'applicazione.

Modifica della password utente in viaggio

Questo caso d'uso illustra come un utente può modificare la password dopo aver effettuato l'accesso, lontano dall'area in cui ha registrato il proprio account.

Screenshot che mostra il flusso per la modifica della password utente in viaggio.

  1. Un utente di NOAM tenta di modificare la password dopo l'accesso a myapp.fr.

  2. L'utente raggiunge il tenant a imbuto globale di Azure AD B2C. Questo tenant è configurato per il reindirizzamento a un tenant di Azure AD B2C a livello di area in base ad alcuni criteri che usano la federazione OpenId. Può trattarsi di una ricerca basata su application clientId.

  3. L'utente arriva al tenant EMEA di Azure AD B2C e il set di cookie SSO consente all'utente di modificare immediatamente la password.

  4. Il messaggio di posta elettronica dell'utente si trova nel tenant NOAM dopo aver controllato la tabella di ricerca globale.

  5. La nuova password viene scritta nell'account utente nel tenant NOAM di Azure AD B2C da MS API Graph chiamata.

  6. Il tenant a livello di area rilascia un token al tenant a imbuto.

  7. Il tenant a imbuto rilascia un token all'applicazione.

Autenticazioni del provider di identità federate

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 può iscriversi al servizio dall'area locale usando un ID federato.

Screenshot che mostra il flusso per l'iscrizione all'ID federato.

  1. Un utente di EMEA tenta di iscriversi a myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, Gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant a imbuto globale di Azure AD B2C. Questo tenant è configurato per il reindirizzamento a un tenant di Azure AD B2C a livello di area in base ad alcuni criteri che usano la federazione OpenId. Può trattarsi di una ricerca basata su application clientId.

  3. L'utente sceglie di accedere con un provider di identità federato (IdP).

  4. 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.

  5. Scrivere l'account utente nel tenant EMEA di Azure AD B2C.

  6. Il tenant a livello di area rilascia un token al tenant a imbuto.

  7. Il tenant a imbuto rilascia un token all'applicazione.

Accesso utente federato locale

Questo caso d'uso illustra come un utente dell'area locale accede al servizio usando un ID federato.

Screenshot che mostra il flusso per l'accesso utente federato locale.

  1. Un utente di EMEA tenta di accedere al myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, Gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant a imbuto globale di Azure AD B2C. Questo tenant è configurato per il reindirizzamento a un tenant di Azure AD B2C a livello di area in base ad alcuni criteri che usano la federazione OpenId. Può trattarsi di una ricerca basata su Application clientId.

  3. L'utente sceglie di accedere con un provider di identità federato.

  4. Eseguire una ricerca nella tabella di ricerca globale e verificare che l'ID federato dell'utente sia registrato in EMEA.

  5. Il tenant a livello di area rilascia un token al tenant a imbuto.

  6. Il tenant a imbuto rilascia un token all'applicazione.

Accesso utente federato in viaggio

Questo caso d'uso illustra come un utente può accedere al proprio account con un IdP federato, mentre si trova lontano dall'area in cui si è connessi.

Screenshot che mostra il flusso per l'accesso utente federato in viaggio.

  1. Un utente di NOAM tenta di accedere al myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, Gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant a imbuto globale di Azure AD B2C. Questo tenant è configurato per il reindirizzamento a un tenant di Azure AD B2C a livello di area in base ad alcuni criteri che usano la federazione OpenId. Può trattarsi di una ricerca basata su Application clientId.

  3. 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.

  4. Eseguire una ricerca nella tabella di ricerca globale e determinare che l'ID federato dell'utente è registrato in NOAM.

  5. Leggere i dati dell'account dal tenant NOAM di Azure AD B2C usando MS API Graph.

  6. Il tenant a livello di area rilascia un token al tenant a imbuto.

  7. Il tenant a imbuto rilascia un token all'applicazione.

Collegamento dell'account con criteri di corrispondenza

Questo caso d'uso illustra come gli utenti sono in grado di eseguire il collegamento dell'account quando vengono soddisfatti i criteri corrispondenti. I criteri di corrispondenza sono in genere l'indirizzo di posta elettronica degli utenti. Quando i criteri corrispondenti di un accesso da un nuovo provider di identità hanno lo stesso valore per un account esistente in Azure AD B2C, il processo di collegamento dell'account può iniziare.

Screenshot che mostra il flusso per unire un account federato.

  1. Un utente di EMEA tenta di accedere al myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, Gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant a imbuto globale di Azure AD B2C. Questo tenant è configurato per il reindirizzamento a un tenant di Azure AD B2C a livello di area in base ad alcuni criteri che usano la federazione OpenId. Può trattarsi di una ricerca basata su Application clientId.

  3. L'utente sceglie di accedere con un provider di identità federato/provider di identità social.

  4. Viene eseguita una ricerca nella tabella di ricerca globale per l'ID restituito dal provider di identità federato.

  5. Se l'ID non esiste, ma il messaggio di posta elettronica dal provider di identità federato esiste in EMEA Azure AD B2C. Questo è un caso d'uso per il collegamento dell'account.

  6. 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.

  7. 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.

  8. Il tenant a livello di area rilascia un token al tenant a imbuto.

  9. Il tenant a imbuto rilascia un token all'applicazione.

Collegamento dell'account utente in viaggio con criteri di corrispondenza

Questo caso d'uso illustra in che modo gli utenti non locali sono in grado di eseguire il collegamento dell'account quando vengono soddisfatti i criteri corrispondenti. I criteri di corrispondenza sono in genere l'indirizzo di posta elettronica degli utenti. Quando i criteri corrispondenti di un accesso da un nuovo provider di identità hanno lo stesso valore per un account esistente in Azure AD B2C, il processo di collegamento dell'account può iniziare.

Screenshot che mostra il flusso per unire l'utente federato in viaggio.

  1. Un utente di NOAM tenta di accedere al myapp.fr. Se l'utente non viene inviato all'istanza dell'applicazione locale, Gestione traffico applica un reindirizzamento.

  2. L'utente raggiunge il tenant globale a imbuto di Azure AD B2C. Questo tenant è configurato per il reindirizzamento a un tenant di Azure AD B2C a livello di area in base ad alcuni criteri che usano la federazione OpenId. Può trattarsi di una ricerca basata su Application clientId.

  3. L'utente sceglie di accedere con un provider di identità federato/provider di identità social.

  4. Viene eseguita una ricerca nella tabella di ricerca globale per l'ID restituito dal provider di identità federato.

  5. Dove l'ID non esiste e il messaggio di posta elettronica dal provider di identità federato esiste in un'altra area. Si tratta di un caso d'uso di collegamento dell'account utente in viaggio.

  6. 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 dimostra che è proprietario 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.

  7. 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.

  8. Il tenant a livello di area rilascia un token al tenant a imbuto.

  9. Il tenant a imbuto rilascia un token all'applicazione.

Passaggi successivi