Condividi tramite


Panoramica dei criteri personalizzati di Azure AD B2C

Importante

A partire dal 1° maggio 2025, Azure AD B2C non sarà più disponibile per l'acquisto per i nuovi clienti. Altre informazioni sono disponibili nelle domande frequenti.

I criteri personalizzati sono file di configurazione che definiscono il comportamento del tenant di Azure Active Directory B2C (Azure AD B2C). Mentre i flussi utente sono predefiniti nel portale di Azure AD B2C per le attività di identità più comuni, uno sviluppatore di identità può modificare i criteri personalizzati per completare molte attività diverse.

Un criterio personalizzato è completamente configurabile e basato su criteri. Un criterio personalizzato orchestra l'attendibilità tra le entità nei protocolli standard. Ad esempio, OpenID Connect, OAuth, SAML e alcuni non standard, ad esempio scambi di attestazioni basate su API REST da sistema a sistema. Il framework crea esperienze personalizzabili e intuitive per l'utente.

Un criterio personalizzato è rappresentato come uno o più file in formato XML, che si riferiscono 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

Lo starter pack di criteri personalizzati di Azure AD B2C include diversi criteri predefiniti per iniziare rapidamente. Ognuno di questi starter pack contiene il minor numero di profili tecnici e percorsi utente necessari per ottenere gli scenari descritti:

  • LocalAccounts : abilita solo l'uso di account locali.
  • SocialAccounts : abilita solo l'uso di account di social networking (o federati).
  • SocialAndLocalAccounts : consente l'uso di account locali e di social network. La maggior parte degli esempi fa riferimento a questo criterio.
  • SocialAndLocalAccountsWithMFA : abilita le opzioni di autenticazione social, locale e a più fattori.

Nel repository GitHub degli esempi di Azure AD B2C sono disponibili esempi per diversi percorsi utente e scenari CIAM personalizzati di Azure AD B2C avanzati. Ad esempio, miglioramenti dei criteri degli account locali, miglioramenti dei criteri degli account di social networking, miglioramenti dell'autenticazione a più fattori, miglioramenti dell'interfaccia utente, miglioramenti generici, migrazione delle app, migrazione degli utenti, accesso condizionale, test Web e CI/CD.

Informazioni sulle nozioni di base

Richieste di rimborso

Un claim fornisce l'archiviazione temporanea dei dati durante l'esecuzione di una policy di Azure AD B2C. Le affermazioni sono più simili a variabili in un linguaggio di programmazione. Può archiviare informazioni sull'utente, ad esempio nome, nome della famiglia o qualsiasi altra attestazione ottenuta dall'utente o da altri sistemi (scambi di attestazioni). Lo schema delle attestazioni è il luogo in cui si dichiarano le attestazioni.

Quando i criteri vengono eseguiti, Azure AD B2C invia e riceve le attestazioni da e verso parti interne ed esterne e quindi invia un sottoinsieme di queste attestazioni all'applicazione relying party come parte del token. Le attestazioni vengono usate in questi modi:

  • Viene salvata, letta o aggiornata una richiesta relativa all'oggetto utente della directory.
  • Una dichiarazione viene ricevuta da un fornitore di identità esterno.
  • Le attestazioni vengono inviate o ricevute usando un servizio API REST personalizzato.
  • I dati vengono raccolti come attestazioni dall'utente durante l'iscrizione o la modifica dei flussi del profilo.

Modifica delle attestazioni

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

Personalizzare e localizzare l'interfaccia utente

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

Per personalizzare l'interfaccia utente per il profilo tecnico autodichiarato, specifica un URL nell'elemento di definizione del contenuto che contenga contenuto HTML personalizzato. Nel profilo tecnico autodichiarato è indicato questo ID di definizione del contenuto.

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

Panoramica dei criteri del partner affidabile

Un'applicazione relying party, che nel protocollo SAML è nota come provider di servizi, chiama i criteri della relying party per eseguire un percorso utente specifico. La politica della relying party specifica il percorso utente da seguire e l'elenco delle attestazioni che il token include.

Diagramma che mostra il flusso di esecuzione dei criteri

Tutte le applicazioni relying party che usano gli stessi criteri ricevono le stesse attestazioni di token e l'utente esegue lo stesso percorso utente.

Percorsi utente

I percorsi utente consentono di definire la logica di business con il percorso attraverso il quale l'utente segue per ottenere l'accesso all'applicazione. L'utente viene guidato nel percorso utente per recuperare le dichiarazioni che devono essere presentate alla tua applicazione. Un percorso utente viene creato da una sequenza di passaggi di orchestrazione. Un utente deve raggiungere l'ultimo passaggio per acquisire un token.

Le seguenti istruzioni descrivono come aggiungere passaggi di orchestrazione alla policy del starter pack per account social e locale. Di seguito è riportato un esempio di chiamata API REST aggiunta.

percorso utente personalizzato

Passaggi di orchestrazione

Il passaggio di orchestrazione fa riferimento a un metodo che implementa lo scopo o la funzionalità previsti. Questo metodo è denominato profilo tecnico. Quando il percorso utente deve creare un ramo per rappresentare meglio la logica di business, il passaggio di orchestrazione fa riferimento al percorso secondario. Un percorso secondario contiene un proprio set di passaggi di orchestrazione.

Un utente deve raggiungere l'ultimo passaggio di orchestrazione nel percorso utente per acquisire un token. Ma gli utenti potrebbero non dover eseguire tutti i passaggi di orchestrazione. I passaggi di orchestrazione possono essere eseguiti in modo condizionale in base alle precondizioni definite nel passaggio di orchestrazione.

Al termine di un passaggio di orchestrazione, Azure AD B2C archivia le attestazioni restituite nel contenitore delle attestazioni. Le attestazioni nel contenitore delle attestazioni possono essere utilizzate da qualsiasi ulteriore procedura di orchestrazione nel percorso utente.

Il diagramma seguente mostra come i passaggi di orchestrazione del percorso utente possono accedere alla raccolta delle dichiarazioni.

Percorso utente di Azure AD B2C

Profilo tecnico

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

Tutti i tipi di profili tecnici condividono lo stesso concetto. Si inviano attestazioni di input, si esegue la trasformazione delle attestazioni e si comunica con l'entità configurata. Al termine del processo, il profilo tecnico restituisce le attestazioni di output nel contenitore delle attestazioni. Per altre informazioni, vedere Panoramica dei profili tecnici.

Profilo tecnico di convalida

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

Per convalidare l'input dell'utente, dal profilo tecnico autocertificato viene chiamato un profilo tecnico di convalida. 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. Il messaggio di errore viene visualizzato all'utente sullo schermo, consentendo all'utente di riprovare.

Il diagramma seguente illustra come Azure AD B2C usa un profilo tecnico di convalida per convalidare le credenziali utente.

Diagramma del profilo tecnico di convalida

Modello di ereditarietà

Ogni starter pack include i file seguenti:

  • File di base che contiene la maggior parte delle definizioni. Per facilitare 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.
  • File di localizzazione che contiene le stringhe di localizzazione. Questo file di criteri è derivato dal file di base. Usare questo file per adattarsi a lingue diverse in base alle esigenze dei clienti.
  • Un file di estensioni che contiene le modifiche di configurazione univoche per il tenant. Questo file di criteri è derivato dal file di localizzazione. Usare questo file per aggiungere nuove funzionalità o eseguire l'override delle funzionalità esistenti. Ad esempio, usare questo file per eseguire la federazione con i nuovi provider di identità.
  • Un file Relying Party (RP) che è il file dedicato a un singolo compito richiamato direttamente dall'applicazione di relying party, come le applicazioni web, mobili o desktop. Ogni attività specifica, ad esempio l'iscrizione, l'accesso o la modifica del profilo, richiede il proprio file di criteri del relying party (parte affidabile). Questo file di criteri è derivato dal file delle estensioni.

Il modello di ereditarietà è il seguente:

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

Il diagramma seguente illustra la relazione tra i file di criteri e le applicazioni di terze parti affidabili.

Diagramma che mostra il modello di ereditarietà dei criteri del framework di attendibilità

Materiale sussidiario e procedure consigliate

Procedure consigliate

All'interno di un criterio personalizzato di Azure AD B2C, è possibile integrare la propria logica di business per creare le esperienze utente necessarie ed estendere le funzionalità del servizio. Sono disponibili una serie di procedure consigliate e raccomandazioni per iniziare.

  • Creare la logica all'interno dei criteri di estensione o dei criteri di relying party. È possibile aggiungere nuovi elementi, che sostituiscono i criteri di base facendo riferimento allo stesso ID. Questo approccio consente di espandere il progetto semplificando l'aggiornamento dei criteri di base in un secondo momento se Microsoft rilascia nuovi pacchetti di avvio.
  • All'interno dei criteri di base, è consigliabile evitare di apportare modifiche. Quando necessario, apportare commenti in cui vengono apportate le modifiche.
  • Quando si modifica un elemento, ad esempio i metadati del profilo tecnico, evitare di copiare l'intero profilo tecnico dalla politica base. Copiare invece solo la sezione richiesta 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 di Microsoft Entra durante l'accesso al sistema, che può causare problemi di throttling.
  • Se la tua strategia ha dipendenze esterne, come ad esempio le API REST, assicurati che siano altamente disponibili.
  • Per un'esperienza utente migliore, assicurarsi che i modelli HTML personalizzati vengano distribuiti a livello globale usando la distribuzione di contenuti online. La rete per la distribuzione di contenuti di Azure consente di ridurre i tempi di caricamento, risparmiare larghezza di banda e migliorare la velocità di risposta.
  • Se si vuole apportare una modifica al percorso utente, copiare l'intero percorso utente dai criteri di base ai criteri di estensione. Specificare un ID percorso utente univoco per il percorso utente copiato. Quindi, nei criteri della relying party modificare l'elemento percorso utente predefinito in modo che punti al nuovo percorso utente.

Risoluzione dei problemi

Durante lo sviluppo con i criteri di Azure AD B2C, è possibile che si verifichino errori o eccezioni durante l'esecuzione del percorso utente. L'oggetto può essere analizzato usando Application Insights.

Integrazione continua

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

Prepara il tuo ambiente

Si inizia a usare i criteri personalizzati di Azure AD B2C:

  1. Creare un tenant di Azure AD B2C
  2. Registrare un'applicazione web usando il portale di Azure per poter testare la tua politica.
  3. Aggiungere le chiavi dei criteri necessarie e registrare le applicazioni Identity Experience Framework.
  4. Scarica il pacchetto di avvio dei criteri di Azure AD B2C e carica nel tuo tenant.
  5. Dopo aver caricato il pacchetto iniziale, prova i criteri di iscrizione o di accesso.
  6. È consigliabile 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 esplorare e modificare rapidamente i file XML dei criteri personalizzati di Azure AD B2C installando l'estensione Azure AD B2C per VS Code

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: