Share via


Esperienza utente finale resiliente

L'esperienza utente finale di iscrizione e accesso è costituita dagli elementi seguenti:

  • Le interfacce con cui l'utente interagisce, ad esempio CSS, HTML e JavaScript

  • I flussi utente e i criteri personalizzati creati, ad esempio l'iscrizione, l'accesso e la modifica del profilo

  • Provider di identità (IDP) per l'applicazione, ad esempio nome utente/password dell'account locale, Outlook, Facebook e Google

Image shows end-user experience components

Scegliere tra il flusso utente e i criteri personalizzati

Per configurare le attività di identità più comuni, Azure AD B2C offre flussi utente configurabili predefiniti. È anche possibile creare criteri personalizzati che offrono la massima flessibilità. È tuttavia consigliabile usare criteri personalizzati solo per gestire scenari complessi.

Come decidere tra il flusso utente e i criteri personalizzati

Scegliere i flussi utente predefiniti se i requisiti aziendali possono essere soddisfatti da essi. Poiché microsoft è ampiamente testato, è possibile ridurre al minimo i test necessari per convalidare i flussi utente di identità, prestazioni o funzionalità a livello di criteri. È comunque necessario testare le applicazioni per funzionalità, prestazioni e scalabilità.

Se si scelgono criteri personalizzati a causa dei requisiti aziendali, assicurarsi di eseguire test a livello di criteri per funzionalità, prestazioni o scalabilità oltre ai test a livello di applicazione.

Vedere l'articolo che confronta i flussi utente e i criteri personalizzati per aiutarti a decidere.

Scegliere più PROVIDER di identità

Quando si usa un provider di identità esterno, ad esempio Facebook, assicurarsi di disporre di un piano di fallback nel caso in cui il provider esterno non sia più disponibile.

Come configurare più provider di identità

Come parte del processo di registrazione del provider di identità esterno, includere un'attestazione di identità verificata, ad esempio il numero di cellulare o l'indirizzo di posta elettronica dell'utente. Eseguire il commit delle attestazioni verificate nell'istanza di directory di Azure AD B2C sottostante. Se il provider esterno non è disponibile, ripristinare l'attestazione di identità verificata ed eseguire il fallback al numero di telefono come metodo di autenticazione. Un'altra opzione consiste nell'inviare all'utente un passcode monouso per consentire all'utente di accedere.

Seguire questa procedura per creare percorsi di autenticazione alternativi:

  1. Configurare i criteri di iscrizione per consentire l'iscrizione tramite l'account locale e gli IDP esterni.

  2. Configurare un criterio del profilo per consentire agli utenti di collegare l'altra identità al proprio account dopo l'accesso.

  3. Notificare e consentire agli utenti di passare a un provider di identità alternativo durante un'interruzione.

Disponibilità dell'autenticazione a più fattori

Quando si usa un servizio telefonico per Multi-Factor Authentication (MFA), assicurarsi di prendere in considerazione un provider di servizi alternativo. Il provider di servizi telefonici o telco locale può riscontrare interruzioni del servizio.

Come scegliere un'autenticazione a più fattori alternativa

Il servizio Azure AD B2C usa un provider MFA basato su telefono predefinito per distribuire passcode monouso basati sul tempo. È sotto forma di chiamata vocale e SMS al numero di telefono preregistrato dell'utente. Per diversi scenari sono disponibili i metodi alternativi seguenti:

Quando si usano i flussi utente, esistono due metodi per creare resilienza:

  • Modificare la configurazione del flusso utente: dopo aver rilevato un'interruzione nel recapito OTP basato sul telefono, modificare il metodo di recapito OTP da basato sul telefono a quello basato su posta elettronica e ridistribuire il flusso utente, lasciando invariate le applicazioni.

screenshot shows sign-in sign-up

  • Modificare le applicazioni: per ogni attività di identità, ad esempio l'iscrizione e l'accesso, definire due set di flussi utente. Configurare il primo set per l'uso di OTP basato sul telefono e il secondo su OTP basato su posta elettronica. Dopo aver rilevato un'interruzione del recapito OTP basato sul telefono, modificare e ridistribuire le applicazioni per passare dal primo set di flussi utente al secondo, lasciando invariati i flussi utente.

Quando si usano criteri personalizzati, esistono quattro metodi per creare resilienza. L'elenco seguente è nell'ordine di complessità e sarà necessario ridistribuire i criteri aggiornati.

  • Abilitare la selezione utente di OTP basato sul telefono o OTP basato su posta elettronica: esporre entrambe le opzioni agli utenti e consentire agli utenti di selezionare automaticamente una delle opzioni. Non è necessario apportare modifiche ai criteri o alle applicazioni.

  • Passaggio dinamico tra OTP basato sul telefono e OTP basato su posta elettronica: raccogliere informazioni sia sul telefono che sulla posta elettronica all'iscrizione. Definire i criteri personalizzati in anticipo per passare in modo condizionale durante un'interruzione del telefono, dal recapito OTP basato sul telefono al recapito OTP basato su posta elettronica. Non è necessario apportare modifiche ai criteri o alle applicazioni.

  • Usare un'app Authenticator: aggiornare i criteri personalizzati per usare un'app Authenticator. Se l'autenticazione a più fattori normale è basata su telefono o OTP basata su posta elettronica, ridistribuire i criteri personalizzati per passare all'uso dell'app Authenticator.

Nota

Gli utenti devono configurare l'integrazione dell'app Authenticator durante l'iscrizione.

  • Usare domande di sicurezza: se nessuno dei metodi precedenti è applicabile, implementare domande di sicurezza come backup. Configurare domande di sicurezza per gli utenti durante l'onboarding o la modifica del profilo e archiviare le risposte in un database separato diverso dalla directory. Questo metodo non soddisfa il requisito MFA di "qualcosa che hai", ad esempio telefono, ma offre un "elemento secondario che conosci".

Usare una rete per la distribuzione di contenuti (CDN)

Le reti per la distribuzione di contenuti (rete CDN) offrono prestazioni migliori e meno costose rispetto agli archivi BLOB per l'archiviazione dell'interfaccia utente personalizzata del flusso utente. Il contenuto della pagina Web viene distribuito più rapidamente da una rete distribuita geograficamente di server a disponibilità elevata.

Testare periodicamente la disponibilità del rete CDN e le prestazioni della distribuzione del contenuto tramite scenari end-to-end e test di carico. Se si prevede un aumento imminente a causa di un traffico promozionale o di festività, rivedere le stime per i test di carico.

Passaggi successivi