Condividi tramite

Gestire l'accesso degli utenti in Azure Active Directory 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.

Questo articolo illustra come gestire l'accesso utente alle applicazioni usando Azure Active Directory B2C (Azure AD B2C). La gestione degli accessi nella tua applicazione include:

  • Identificazione dei minori e controllo dell'accesso utente all'applicazione.
  • Richiedere il consenso dei genitori per i minori per l'uso delle applicazioni.
  • Raccolta dei dati di nascita e paese/area geografica dagli utenti.
  • Acquisizione di un accordo sui termini di utilizzo e quindi limitazione dell'accesso.

Annotazioni

In Azure Active Directory B2C i criteri personalizzati sono stati progettati principalmente per far fronte a scenari complessi. Per la maggior parte degli scenari, è consigliabile usare i flussi utente predefiniti. In caso contrario, vedere Introduzione ai criteri personalizzati in Active Directory B2C.

Controllare l'accesso dei minori

Le applicazioni e le organizzazioni possono decidere di impedire ai minori di usare applicazioni e servizi che non sono destinati a questo gruppo di destinatari. In alternativa, le applicazioni e le organizzazioni possono decidere di accettare minori e successivamente gestire il consenso dei genitori e fornire esperienze consentite per i minori come stabilito dalle regole di business e consentite dalla normativa.

Se un utente viene identificato come minorenne, è possibile impostare il flusso utente in Azure AD B2C su una delle seguenti tre opzioni.

  • Inviare un JWT firmato id_token all'applicazione: l'utente è registrato nella directory e un token viene restituito all'applicazione. L'applicazione procede successivamente applicando le regole aziendali. Ad esempio, l'applicazione può procedere con un processo di consenso genitoriale. Per usare questo metodo, selezionare di ricevere le attestazioni ageGroup e consentProvidedForMinor dall'app.

  • Inviare un token JSON non firmato all'applicazione: Azure AD B2C notifica all'applicazione che l'utente è un minore e fornisce lo stato del consenso genitoriale dell'utente. L'applicazione procede successivamente applicando le regole aziendali. Un token JSON non completa un'autenticazione riuscita con l'applicazione. L'applicazione deve elaborare l'utente non autenticato in base alle attestazioni incluse nel token JSON, che può includere nome, posta elettronica, ageGroup e consentProvidedForMinor.

  • Blocca l'utente: se un utente è un minore e non è stato fornito il consenso dei genitori, Azure AD B2C può notificare all'utente che sono bloccati. Non viene rilasciato alcun token, l'accesso viene bloccato e l'account utente non viene creato durante un percorso di registrazione. Per implementare questa notifica, fornire una pagina di contenuto HTML/CSS adatta per informare l'utente e presentare le opzioni appropriate. Non sono necessarie ulteriori azioni da parte dell'applicazione per le nuove registrazioni.

A seconda della normativa dell'applicazione, potrebbe essere necessario concedere il consenso dei genitori da un utente verificato come adulto. Azure AD B2C non offre un'esperienza per verificare l'età di un individuo e quindi consentire a un adulto verificato di concedere il consenso dei genitori a un minore. Questa esperienza deve essere fornita dall'applicazione o da un altro provider di servizi.

Di seguito è riportato un esempio di flusso utente per la raccolta del consenso genitoriale:

  1. Un'operazione dell'API Microsoft Graph identifica l'utente come minore e restituisce i dati utente all'applicazione sotto forma di token JSON non firmato.

  2. L'applicazione elabora il token JSON e mostra una schermata al minore, notificando loro che è necessario il consenso dei genitori e richiedendo il consenso di un genitore online.

  3. Azure AD B2C mostra un percorso di accesso a cui l'utente può accedere normalmente e rilascia un token all'applicazione impostata per includere legalAgeGroupClassification = "minorWithParentalConsent". L'applicazione raccoglie l'indirizzo di posta elettronica del genitore e verifica che il genitore sia un adulto. A tale scopo, usa una fonte attendibile, ad esempio un ufficio id nazionale/regionale, la verifica della licenza o la prova della carta di credito. Se la verifica ha esito positivo, l'applicazione richiede al minore di accedere usando il flusso utente di Azure AD B2C. Se il consenso viene negato (ad esempio, se legalAgeGroupClassification = "minorWithoutParentalConsent"), Azure AD B2C restituisce un token JSON (non un account di accesso) all'applicazione per riavviare il processo di consenso. Facoltativamente, è possibile personalizzare il flusso utente in modo che un minore o un adulto possa ottenere nuovamente l'accesso all'account di un minore inviando un codice di registrazione all'indirizzo di posta elettronica del minore o all'indirizzo di posta elettronica dell'adulto su record.

  4. L'applicazione offre un'opzione al minore per revocare il consenso.

  5. Quando il minore o l'adulto revoca il consenso, l'API Microsoft Graph può essere usata per modificare consentProvidedForMinor in modo che venga negato. In alternativa, l'applicazione può scegliere di eliminare un minore il cui consenso è stato revocato. Facoltativamente, è possibile personalizzare il flusso utente in modo che il minore autenticato (o padre che usa l'account del minore) possa revocare il consenso. Azure AD B2C registra il consenso fornito per il minore come negato.

Per altre informazioni su legalAgeGroupClassification, consentProvidedForMinor e ageGroup, vedere Tipo di risorsa utente. Per altre informazioni sugli attributi personalizzati, vedere Usare attributi personalizzati per raccogliere informazioni sui consumer. Quando si indirizzano gli attributi estesi usando l'API Microsoft Graph, è necessario usare la versione lunga dell'attributo, ad esempio extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth: 2011-01-01T00:00:00Z.

Raccogliere i dati relativi alla data di nascita e al paese/area geografica

Le applicazioni possono basarsi su Azure AD B2C per raccogliere le informazioni sulla data di nascita (DOB) e sul paese/area geografica da tutti gli utenti durante la registrazione. Se queste informazioni non esistono già, l'applicazione può richiederla all'utente durante il successivo percorso di autenticazione (accesso). Gli utenti non possono continuare senza fornire le informazioni relative a DOB e paese/area geografica. Azure AD B2C usa le informazioni per determinare se l'utente è considerato un elemento secondario in base agli standard normativi del paese o dell'area geografica.

Un flusso utente personalizzato può raccogliere informazioni sulla data di nascita (DOB) e paese/area geografica e usare la trasformazione delle attestazioni di Azure AD B2C per determinare il gruppo di età (ageGroup) e salvare in modo permanente il risultato (o rendere persistenti direttamente le informazioni sulla data di nascita (DOB) e paese/area geografica) nella directory.

I passaggi seguenti illustrano la logica usata per calcolare ageGroup dalla data di nascita dell'utente:

  1. Provare a trovare il paese/area geografica in base al codice paese nell'elenco. Se il paese o l'area geografica non viene trovata, eseguire il fallback su Predefinito.

  2. Se il nodo MinorConsent è presente nell'elemento paese/area geografica:

    a) Calcolare la data in cui l'utente deve essere nato per essere considerato un adulto. Ad esempio, se la data corrente è il 14 marzo 2015 e MinorConsent è 18, la data di nascita non deve essere successiva al 14 marzo 2000.

    b. Confrontare la data di nascita minima con la data di nascita effettiva. Se la data di nascita minima è precedente alla data di nascita dell'utente, il calcolo restituisce Minor come calcolo del gruppo di età.

  3. Se il nodo MinorNoConsentRequired è presente nell'elemento country/region, ripetere i passaggi 2a e 2b usando il valore di MinorNoConsentRequired. L'output di 2b restituisce MinorNoConsentRequired se la data di nascita minima è precedente alla data di nascita dell'utente.

  4. Se nessun calcolo restituisce true, il calcolo restituisce Adult.

Se un'applicazione ha raccolto dati DOB o paese/area geografica in modo affidabile da altri metodi, l'applicazione può usare l'API Graph per aggiornare il record utente con queste informazioni. Per esempio:

  • Se un utente è noto come adulto, aggiornare l'attributo directory ageGroup con il valore Adult.
  • Se un utente è noto come minore, aggiornare l'attributo directory ageGroup con il valore Minor e impostare consentProvidedForMinor, in base alle esigenze.

Regole di calcolo secondarie

Il controllo dell'età prevede due valori di età: l'età che qualcuno non è più considerato un minore e l'età in cui un minore deve avere il consenso genitoriale. Nella tabella seguente sono elencate le regole di età usate per definire un minore e un minore che richiede il consenso.

Paese/area geografica Nome paese/area geografica Età del consenso dei minorenni Minore età
Predefinito Nessuno Nessuno 18
Æ Emirati Arabi Uniti Nessuno 21
A Austria 14 18
ESSERE Belgio 14 18
BG Bulgaria 16 18
BH Bahrein Nessuno 21
cm Camerun Nessuno 21
CY Cipro 16 18
CZ Repubblica Ceca 16 18
Germania Germania 16 18
DK Danimarca 16 18
EE Estonia 16 18
Ad esempio Egitto Nessuno 21
ES Spagna 13 18
FR Francia 16 18
GB Regno Unito 13 18
GR Grecia 16 18
HR Croazia 16 18
HU Ungheria 16 18
Internet Explorer Irlanda 13 18
TI Italia 16 18
KR Repubblica di Corea 14 18
LT Lituania 16 18
Lussemburgo Lussemburgo 16 18
LV Lettonia 16 18
MT Malta 16 18
NA Namibia Nessuno 21
Paesi Bassi Paesi Bassi 16 18
PL Polonia 13 18
PT Portogallo 16 18
RO Romania 16 18
SE Svezia 13 18
SG Singapore Nessuno 21
Sì Slovenia 16 18
SK Slovacchia 16 18
TD Ciad Nessuno 21
° Thailandia Nessuno 20
Taiwan Taiwan Nessuno 20
Stati Uniti Stati Uniti 13 18

Accettare l'accordo sulle condizioni d'uso

Quando sviluppi la tua applicazione, acquisisci in genere l'accettazione delle condizioni d'uso da parte degli utenti all'interno della tua applicazione senza, o con solo minore partecipazione della directory utente. È tuttavia possibile usare un flusso utente di Azure AD B2C per raccogliere l'accettazione delle condizioni per l'utilizzo di un utente, limitare l'accesso se non viene concessa l'accettazione e imporre l'accettazione delle modifiche future alle condizioni per l'utilizzo, in base alla data dell'accettazione più recente e alla data dell'ultima versione delle condizioni per l'utilizzo.

Le condizioni per l'utilizzo possono includere anche "Il consenso per condividere i dati con terze parti". A seconda delle normative locali e delle regole di business, è possibile raccogliere l'accettazione di entrambe le condizioni combinate di un utente oppure consentire all'utente di accettare una condizione e non l'altra.

I passaggi seguenti descrivono come gestire le condizioni per l'utilizzo:

  1. Registrare l'accettazione delle condizioni per l'utilizzo e la data di accettazione usando l'API Graph e gli attributi estesi. A tale scopo, è possibile usare sia i flussi utente predefiniti che i criteri personalizzati. È consigliabile creare e usare gli attributi extension_termsOfUseConsentDateTime e extension_termsOfUseConsentVersion .

  2. Creare una casella di controllo obbligatoria con etichetta "Accetta condizioni per l'utilizzo" e registrare il risultato durante l'iscrizione. A tale scopo, è possibile usare sia i flussi utente predefiniti che i criteri personalizzati.

  3. Azure AD B2C archivia le condizioni per l'utilizzo e l'accettazione dell'utente. È possibile usare l'API Graph per eseguire query sullo stato di qualsiasi utente leggendo l'attributo di estensione usato per registrare la risposta( ad esempio, leggere terminiOfUseTestUpdateDateTime). A tale scopo, è possibile usare sia i flussi utente predefiniti che i criteri personalizzati.

  4. Richiedere l'accettazione delle condizioni per l'utilizzo aggiornate confrontando la data di accettazione alla data dell'ultima versione delle condizioni per l'utilizzo. È possibile confrontare le date solo usando un flusso utente personalizzato. Usare l'attributo esteso extension_termsOfUseConsentDateTime e confrontare il valore con l'attestazione di termsOfUseTextUpdateDateTime. Se l'accettazione è obsoleta, forzare una nuova accettazione visualizzando una schermata autocertificata. In caso contrario, bloccare l'accesso usando la logica dei criteri.

  5. Richiedere l'accettazione delle condizioni per l'utilizzo aggiornate confrontando il numero di versione dell'accettazione con il numero di versione accettato più recente. È possibile confrontare i numeri di versione solo usando un flusso utente personalizzato. Usare l'attributo esteso extension_termsOfUseConsentDateTime e confrontare il valore con l'attestazione di extension_termsOfUseConsentVersion. Se l'accettazione è obsoleta, forzare una nuova accettazione visualizzando una schermata autocertificata. In caso contrario, bloccare l'accesso usando la logica dei criteri.

È possibile acquisire l'accettazione delle condizioni per l'utilizzo negli scenari seguenti:

  • Un nuovo utente sta eseguendo l'iscrizione. Vengono visualizzate le condizioni per l'utilizzo e il risultato dell'accettazione viene archiviato.
  • Un utente sta accedendo dopo aver già accettato le condizioni d'uso più recenti o attive. Le condizioni per l'utilizzo non vengono visualizzate.
  • Un utente sta tentando di accedere ma non ha ancora accettato le più recenti o attive condizioni d'uso. Vengono visualizzate le condizioni per l'utilizzo e il risultato dell'accettazione viene archiviato.
  • Un utente sta accedendo avendo già accettato una versione precedente delle condizioni d'uso, che ora sono state aggiornate all'ultima versione. Vengono visualizzate le condizioni per l'utilizzo e il risultato dell'accettazione viene archiviato.

L'immagine seguente mostra il flusso utente consigliato:

Diagramma di flusso che mostra il flusso utente di accettazione consigliato

Di seguito è riportato un esempio di condizioni per l'utilizzo basate su data in un'attestazione. Se l'attestazione extension_termsOfUseConsentDateTime è precedente a 2025-01-15T00:00:00, forzare una nuova accettazione controllando l'attestazione termsOfUseConsentRequired booleana e visualizzando una schermata autocertificata.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentDateTime" TransformationMethod="GetCurrentDateTime">
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="currentDateTime" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequired" TransformationMethod="IsTermsOfUseConsentRequired">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentDateTime" TransformationClaimType="termsOfUseConsentDateTime" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="termsOfUseTextUpdateDateTime" DataType="dateTime" Value="2025-01-15T00:00:00" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="result" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

Di seguito è riportato un esempio di consenso sui termini di utilizzo basati su versione in una dichiarazione. Se l'attestazione extension_termsOfUseConsentVersion non è uguale a V1, forzare una nuova accettazione controllando l'attestazione termsOfUseConsentRequired booleana e visualizzando una schermata autocertificata.

<ClaimsTransformations>
  <ClaimsTransformation Id="GetEmptyTermsOfUseConsentVersionForNewUser" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value=""/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="GetNewUserAgreeToTermsOfUseConsentVersion" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value="V1"/>
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  <ClaimsTransformation Id="IsTermsOfUseConsentRequiredForVersion" TransformationMethod="CompareClaimToValue">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_termsOfUseConsentVersion" TransformationClaimType="inputClaim1" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="compareTo" DataType="string" Value="V1" />
      <InputParameter Id="operator" DataType="string" Value="not equal" />
      <InputParameter Id="ignoreCase" DataType="string" Value="true" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="termsOfUseConsentRequired" TransformationClaimType="outputClaim" />
    </OutputClaims>
  </ClaimsTransformation>
</ClaimsTransformations>

Passaggi successivi