Panoramica dei criteri personalizzati Azure AD B2C

I criteri personalizzati sono file di configurazione che definiscono il comportamento del tenant di Azure Active Directory B2C (Azure AD B2C). Sebbene i flussi utente siano predefiniti nel portale Azure ad B2C per le attività di identità più comuni, i criteri personalizzati possono essere modificati completamente da uno sviluppatore di identità per completare diverse attività.

Un criterio personalizzato è completamente configurabile e basato sui criteri. Un criterio personalizzato gestisce l'attendibilità tra le entità nei protocolli standard. Ad esempio, OpenID Connect, OAuth, SAML e alcuni di quelli non standard, ad esempio scambi di attestazioni da sistema a sistema basati su API REST. Il Framework crea esperienze intuitive e con etichetta bianca.

Un criterio personalizzato è rappresentato come uno o più file in formato XML che fanno riferimento l'uno all'altro in una catena gerarchica. Gli elementi XML definiscono i blocchi predefiniti, l'interazione con l'utente e altre parti e la logica di business.

Pacchetto Starter per i criteri personalizzati

Azure AD B2C Starter Pack per criteri personalizzati è dotato di diversi criteri predefiniti che consentono di iniziare rapidamente. Ogni pacchetto Starter contiene il numero minimo di profili tecnici e percorsi utente necessario per conseguire gli scenari descritti:

  • LocalAccounts - Consente l'uso solo di account locali.
  • SocialAccounts - Consente l'uso solo di account di social networking (o federati).
  • SocialAndLocalAccounts - Consente sia l'uso di account locali che di account di social networking. La maggior parte degli esempi si riferiscono a questi criteri.
  • SocialAndLocalAccountsWithMFA - Consente l'uso di opzioni di social networking, locali e di autenticazione a più fattori.

Informazioni sulle nozioni di base

Attestazioni

Un'attestazione fornisce un'archiviazione temporanea dei dati durante l'esecuzione dei criteri di Azure AD B2C. Può archiviare informazioni relative all'utente, ad esempio nome, cognome o qualsiasi altra attestazione ottenuta dall'utente o da altri sistemi (scambi di attestazioni). Lo schema di attestazioni è la posizione in cui si dichiarano le attestazioni.

Quando il criterio viene eseguito, Azure AD B2C Invia e riceve attestazioni da e verso entità interne ed esterne e quindi Invia un subset di tali attestazioni all'applicazione relying party come parte del token. Le attestazioni vengono utilizzate nei modi seguenti:

  • Un'attestazione viene salvata, letta o aggiornata in base all'oggetto utente della directory.
  • Un'attestazione viene ricevuta da un provider di identità esterno.
  • Le attestazioni vengono inviate o ricevute usando un servizio API REST personalizzato.
  • I dati vengono raccolti come attestazioni dall'utente durante i flussi di iscrizione o di modifica del profilo.

Modifica delle attestazioni

Le trasformazioni delle attestazioni sono funzioni predefinite che possono essere usate per convertire un'attestazione specificata in un'altra, valutare un'attestazione o impostare un valore di attestazione. Ad esempio l'aggiunta di un elemento a una raccolta di stringhe, la modifica del case di una stringa o la valutazione di un'attestazione di data e ora. Una trasformazione delle attestazioni specifica un metodo Transform.

Personalizzare e localizzare l'interfaccia utente

Quando si desidera raccogliere informazioni dagli utenti presentando una pagina nel browser Web, usare il profilo tecnico autocertificato. È possibile modificare il profilo tecnico autocertificato per aggiungere attestazioni e personalizzare l'input dell'utente.

Per personalizzare l'interfaccia utente per il profilo tecnico autocertificato, è necessario specificare un URL nell'elemento di definizione del contenuto con contenuto HTML personalizzato. Nel profilo tecnico autocertificato puntare a questo ID definizione del contenuto.

Per personalizzare le stringhe specifiche della lingua, usare l'elemento Localization . Una definizione del contenuto può contenere un riferimento alla localizzazione che specifica un elenco di risorse localizzate da caricare. Azure AD B2C unisce elementi dell'interfaccia utente con il contenuto HTML caricato dall'URL e quindi mostra la pagina all'utente.

Panoramica dei criteri della relying party

Un'applicazione relying party, che nel protocollo SAML è nota come provider di servizi, chiama il criterio relying party per eseguire un percorso utente specifico. I criteri di relying party specificano il percorso utente da eseguire e l'elenco delle attestazioni incluse nel token.

Diagramma che mostra il flusso di esecuzione dei criteri

Tutte le applicazioni di relying party che usano lo stesso criterio riceveranno le stesse attestazioni del token e l'utente procede nello stesso percorso utente.

Percorsi utente

I percorsi utente consentono di definire la logica di business con il percorso attraverso il quale l'utente seguirà per accedere all'applicazione. L'utente viene sottoposto al percorso utente per recuperare le attestazioni da presentare all'applicazione. Un percorso utente è costituito da una sequenza di passaggi dell'orchestrazione. Un utente deve raggiungere l'ultimo passaggio per acquisire un token.

Le istruzioni seguenti descrivono come è possibile aggiungere passaggi di orchestrazione ai criteri di Starter Pack per gli account di social networking e locali . Di seguito è riportato un esempio di una chiamata API REST che è stata aggiunta.

percorso utente personalizzato

Passaggi dell'orchestrazione

Il passaggio dell'orchestrazione fa riferimento a un metodo che implementa la funzionalità o lo scopo designato. Questo metodo è denominato profilo tecnico. Quando il percorso utente richiede una diramazione per rappresentare meglio la logica di business, il passaggio dell'orchestrazione fa riferimento a subjourney. Un sub-Journey contiene un set di passaggi di orchestrazione.

Per acquisire un token, un utente deve raggiungere l'ultimo passaggio dell'orchestrazione nel percorso utente. Tuttavia, gli utenti potrebbero non dover attraversare tutti i passaggi dell'orchestrazione. I passaggi di orchestrazione possono essere eseguiti in modo condizionale in base alle precondizioni definite nel passaggio dell'orchestrazione.

Al termine di un passaggio di orchestrazione, Azure AD B2C archivia le attestazioni in output nell' elenco delle attestazioni. Le attestazioni nel contenitore delle attestazioni possono essere utilizzate da altri passaggi di orchestrazione nel percorso utente.

Nel diagramma seguente viene illustrato il modo in cui i passaggi dell'orchestrazione del percorso utente possono accedere all'elenco di attestazioni.

Percorso utente Azure AD B2C

Profilo tecnico

Un profilo tecnico fornisce un'interfaccia per comunicare con diversi tipi di entità. Un percorso utente combina la chiamata ai profili tecnici tramite i passaggi dell'orchestrazione per definire la logica di business.

Tutti i tipi di profili tecnici condividono lo stesso concetto. È possibile inviare attestazioni di input, eseguire la trasformazione delle attestazioni e comunicare con l'entità configurata. Al termine del processo, il profilo tecnico restituisce le attestazioni di output per il contenitore delle attestazioni. Per altre informazioni, vedere Cenni preliminari sui profili tecnici.

Profilo tecnico di convalida

Quando un utente interagisce con l'interfaccia utente, può essere opportuno convalidare i dati raccolti. Per interagire con l'utente, è necessario usare un profilo tecnico autocertificato .

Per convalidare l'input dell'utente, viene chiamato un profilo tecnico di convalida dal profilo tecnico autocertificato. Un profilo tecnico di convalida è un metodo per chiamare qualsiasi profilo tecnico non interattivo. In questo caso, il profilo tecnico può restituire attestazioni di output o un messaggio di errore. Viene eseguito il rendering del messaggio di errore all'utente sullo schermo, consentendo all'utente di riprovare.

Nel diagramma seguente viene illustrato il modo in cui Azure AD B2C utilizza un profilo tecnico di convalida per convalidare le credenziali utente.

Diagramma profilo tecnico di convalida

Modello di ereditarietà

Ogni Starter Pack include i file seguenti:

  • un file di base che contiene la maggior parte delle definizioni. Per semplificare la risoluzione dei problemi e la manutenzione a lungo termine dei criteri, provare a ridurre al minimo il numero di modifiche apportate a questo file.
  • Un file di estensioni che include le modifiche di configurazione univoche per il tenant. Questo file dei criteri è derivato dal file di base. Usare questo file per aggiungere nuove funzionalità o eseguire l'override delle funzionalità esistenti. Ad esempio, usare questo file per la federazione con nuovi provider di identità.
  • Un file Relying Party (RP) è l'unico file incentrato sulle attività che viene chiamato direttamente dell'applicazione relying party, come applicazioni Web, mobili o desktop. Ogni attività univoca, ad esempio iscrizione, accesso, reimpostazione della password o modifica del profilo, richiede un proprio file di criteri relying party. Il file dei criteri è derivato dal file delle estensioni.

Il modello di ereditarietà è come segue:

  • Il criterio figlio a qualsiasi livello può ereditare dal criterio padre ed estenderlo aggiungendo nuovi elementi.
  • Per scenari più complessi, è possibile aggiungere più livelli di ereditarietà, fino a 10 in totale.
  • È possibile aggiungere altri criteri di relying party. Ad esempio, eliminare il mio account, modificare un numero di telefono, SAML relying party Policy e altro ancora.

Il diagramma seguente mostra la relazione tra i file di criteri e le applicazioni relying party.

Diagramma che mostra il modello di ereditarietà dei criteri di Framework attendibilità

Materiale sussidiario e procedure consigliate

Procedure consigliate

All'interno di un Azure AD B2C criteri personalizzati, è possibile integrare la logica di business per creare le esperienze utente necessarie ed estendere le funzionalità del servizio. Per iniziare, abbiamo un set di procedure consigliate e consigli.

  • Creare la logica entro i criteri di estensione o relying party criterio. È possibile aggiungere nuovi elementi, che sostituiranno i criteri di base facendo riferimento allo stesso ID. In questo modo sarà possibile scalare verticalmente il progetto, rendendo più semplice l'aggiornamento dei criteri di base in un secondo momento se Microsoft rilascia nuovi Starter Pack.
  • All'interno dei criteri di base, è consigliabile evitare di apportare modifiche. Quando necessario, creare commenti in cui vengono apportate le modifiche.
  • Quando si esegue l'override di un elemento, ad esempio i metadati del profilo tecnico, evitare di copiare l'intero profilo tecnico dai criteri di base. Copiare invece solo la sezione obbligatoria dell'elemento. Vedere disabilitare la verifica della posta elettronica per un esempio di come apportare la modifica.
  • Per ridurre la duplicazione dei profili tecnici, in cui è condivisa la funzionalità di base, usare l' inclusione del profilo tecnico.
  • Evitare di scrivere nella directory Azure AD durante l'accesso, il che potrebbe causare problemi di limitazione delle richieste.
  • Se i criteri hanno dipendenze esterne, ad esempio le API REST, verificano che siano a disponibilità elevata.
  • Per migliorare l'esperienza utente, assicurarsi che i modelli HTML personalizzati siano distribuiti a livello globale tramite la distribuzione di contenuti online. La rete per la distribuzione di contenuti (CDN) di Azure consente di ridurre i tempi di caricamento, risparmiare larghezza di banda e migliorare la velocità di risposta.
  • Se si desidera apportare una modifica al percorso utente, copiare l'intero percorso utente dal criterio di base ai criteri di estensione. Fornire un ID del percorso utente univoco al percorso utente copiato. Quindi, nel criterio di relying partymodificare l'elemento percorso utente predefinito in modo che punti al nuovo percorso utente.

Risoluzione dei problemi

Quando si sviluppa con criteri di Azure AD B2C, è possibile che si verifichino errori o eccezioni durante l'esecuzione del percorso utente. L'oggetto può essere analizzato utilizzando Application Insights.

Integrazione continua

Usando una pipeline di integrazione e recapito continua configurata in Azure Pipelines, è possibile includere i Azure ad B2C criteri personalizzati nell' automazione del controllo del codice e della distribuzione del software. Quando si esegue la distribuzione in ambienti Azure AD B2C diversi, ad esempio sviluppo, test e produzione, è consigliabile rimuovere i processi manuali ed eseguire test automatizzati usando Azure Pipelines.

Preparare l'ambiente

Si inizia con Azure AD B2C criteri personalizzati:

  1. Creare un tenant di Azure AD B2C
  2. Registrare un'applicazione Web usando il portale di Azure per poter testare i criteri.
  3. Aggiungere le chiavi dei criteri necessarie e registrare le applicazioni del Framework dell'esperienza di identità.
  4. Ottenere lo Starter Pack per i criteri di Azure ad B2C e caricarlo nel tenant.
  5. Dopo aver caricato il pacchetto Starter, testare i criteri di iscrizione o di accesso.
  6. Si consiglia di scaricare e installare Visual Studio Code (vs code). Visual Studio Code è un editor di codice sorgente leggero ma potente, che viene eseguito sul desktop ed è disponibile per Windows, macOS e Linux. Con VS Code, è possibile spostarsi rapidamente e modificare i Azure AD B2C file XML dei criteri personalizzati installando l' estensione Azure ad B2C per vs code

Passaggi successivi

Dopo aver configurato e testato i criteri di Azure AD B2C, è possibile iniziare a personalizzare i criteri. Vedere gli articoli seguenti per informazioni su come: