Verifica del framework di identità globale di Azure Active Directory B2C per la configurazione basata sull'area

Articolo
01/24/2024

Nella sezione seguente viene descritto come creare la prova delle implementazioni dei concetti per l'orchestrazione basata sull'area. I criteri personalizzati di Azure Active Directory B2C (Azure AD B2C) completati sono disponibili qui.

Approccio basato su area

Ogni tenant di Azure AD B2C a livello di area richiederà un criterio personalizzato di Azure AD B2C, che contiene le funzionalità seguenti:

Percorso di iscrizione:

Visualizzare una schermata per raccogliere il nome utente, la password e gli altri attributi dell'utente
Impedire l'iscrizione se l'utente esiste già eseguendo una query sulla tabella di mapping dell'area utente
Scrivere il profilo utente nel tenant locale
Scrivere il mapping di utenti da utente a area in una tabella di mapping
Rilasciare un token all'applicazione

Percorso di accesso:

Visualizzare la schermata nome utente e password
Eseguire una ricerca del nome utente e restituire la relativa area
Eseguire una verifica delle credenziali locali o una verifica delle credenziali tra tenant
Leggere il profilo utente dal tenant locale o tramite una chiamata tra tenant
Rilasciare un token all'applicazione

Percorso di reimpostazione della password:

Visualizzare una schermata per convalidare l'indirizzo di posta elettronica degli utenti tramite posta elettronica OTP
Eseguire una ricerca del nome utente e restituire la relativa area
Visualizzare una schermata per acquisire la nuova password
Scrivere la nuova password nel tenant locale o tramite una chiamata multi-tenant
Rilasciare un token all'applicazione

Il diagramma a blocchi seguente mostra la prova del concetto. Le indicazioni illustrano come configurare i tenant di Azure AD B2C. Il livello API esterno e la tabella ricerca distribuita geografica non sono incluse come parte di questa guida.

Screenshot che mostra il diagramma dei blocchi di approccio basato su area

Prerequisiti

Creare un tenant per ogni area aziendale richiede il supporto. È necessario almeno due tenant per questo concetto di prova.
Distribuire criteri personalizzati nei tenant.

Preparare il livello di archiviazione

È necessario un livello di archiviazione, che può archiviare i messaggi di posta elettronica, objectId e area degli utenti. In questo modo sarà possibile tenere traccia e eseguire query sulla posizione in cui l'utente ha effettuato l'iscrizione. È possibile usare una tabella di Archiviazione di Azure per rendere persistenti questi dati.

Preparare il livello API

Esistono più API usate come parte del concetto di prova per illustrare l'approccio basato sull'area.

Verificare se l'utente esiste già

Un'API viene usata durante l'iscrizione per determinare se l'utente esiste già in qualsiasi area.

La richiesta sarà la seguente:

POST /doesUserExistInLookupTable HTTP/1.1
Host: yourapi.com
Content-Type: application/json

{
  email: bob@contoso.com
}

La risposta deve essere un HTTP 200 se l'utente non esiste.
La risposta deve essere HTTP 409 se l'utente esiste.

Registrare il mapping delle aree degli utenti

Un'API viene usata durante l'iscrizione per registrare l'area in cui l'utente ha effettuato l'iscrizione.

La richiesta sarà la seguente:

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

La risposta deve essere un HTTP 200 se l'utente esiste.
La risposta deve essere HTTP 409 se l'utente esiste.

Restituire l'area in cui esiste l'utente

Un'API viene usata durante l'accesso per determinare in quale area l'utente ha effettuato l'iscrizione. Ciò indica se è necessario eseguire un'autenticazione multi-tenant.

La richiesta sarà la seguente:

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

La risposta deve essere un HTTP 200 con l'area e l'oggettoId registrati dagli utenti.

{
  "objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
  "region": "APAC"  
}

L'API deve rispondere con un HTTP 409 se l'utente non esiste o rileva un errore.

Scrivere password tra tenant

Un'API viene usata durante il flusso di reimpostazione della password per scrivere le nuove password degli utenti in un'area diversa in cui reimpostano la password.

La richiesta sarà la seguente:

POST /writePasswordCrossTenant HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
  "password": "some!strong123STRING"
}

La risposta deve essere http 200 se il processo ha esito positivo o HTTP 409 se si verifica un errore.

Configurazione di Azure AD B2C basata sull'area

Le sezioni seguenti preparano il tenant di Azure AD B2C per tenere traccia dell'area in cui l'utente ha effettuato l'iscrizione ed eseguire l'autenticazione tra tenant o le reimpostazioni delle password, se necessario.

Durante l'iscrizione, è necessario assicurarsi di verificare che l'utente non esista in alcun altro tenant e scrivere il mapping dell'area utente degli utenti in una tabella esterna.

Modificare il LocalAccountSignUpWithLogonEmail profilo tecnico nel starter pack B2C di Azure AD è il seguente:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
...
  <ValidationTechnicalProfiles>            
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-doesUserExistInLookupTable" />        
    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
    <ValidationTechnicalProfile ReferenceId="REST-writeUserToRegionMapping" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

I file ValidationTechnicalProfile eseguiranno la logica seguente:

Ottenere un token per chiamare gli endpoint API protetti usando il REST-getTokenforExternalApiCalls profilo tecnico.
- Seguire la documentazione qui per ottenere e proteggere l'API usando un token di connessione Microsoft Entra.

Verificare se l'utente esiste già nel mapping dell'area utente tramite l'endpoint dell'API REST esterno protetto:

Questa chiamata API viene eseguita prima di tutto l'iscrizione, è fondamentale assicurarsi che questa API disponga di meccanismi di bilanciamento del carico, resilienza e failover appropriati per soddisfare i requisiti di tempo di attività.

Un esempio di profilo tecnico per eseguire query su un mapping dell'area utente tramite un'API REST esterna è il seguente:

<TechnicalProfile Id="REST-doesUserExistInLookupTable ">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/doesUserExistInLookupTable</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Questa API deve rispondere con HTTP 409 se l'utente esiste, con un messaggio di errore appropriato da visualizzare sullo schermo. In caso contrario, rispondere con un HTTP 200 se l'utente non esiste.

Scrivere il mapping dell'area utente tramite l'endpoint dell'API REST esterno protetto

Questa chiamata API viene eseguita prima di tutto l'iscrizione, è fondamentale assicurarsi che questa API disponga di meccanismi di bilanciamento del carico, resilienza e failover appropriati per rispettare i requisiti di tempo di attività.
Un esempio di profilo tecnico per scrivere il mapping dell'area utente tramite un'API REST esterna è il seguente:

<TechnicalProfile Id="REST-writeUserToRegionMapping">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/writeUserToRegionMapping</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  <InputClaim ClaimTypeReferenceId="region" DefaultValue="EMEA" />
  <InputClaim ClaimTypeReferenceId="objectId" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
```

Durante l'accesso, è necessario determinare il percorso del profilo degli utenti e autenticarli nel tenant di Azure AD B2C in cui risiede il profilo.

Modificare il profilo tecnico nel starter pack di Azure AD B2C per eseguire la SelfAsserted-LocalAccountSignin-Email ricerca nell'area utente ed eseguire l'autenticazione tra tenant quando l'utente proviene da un'area diversa a quella del tenant raggiunto. Aggiornare il ValidationTechnicalProfiles valore come:

<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="login-NonInteractive">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
     <ValidationTechnicalProfile ReferenceId="REST-login-NonInteractive-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-fetchUserProfile-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

I file ValidationTechnicalProfile eseguiranno la logica seguente quando l'utente invia le proprie credenziali:

Ottenere un token per chiamare gli endpoint API protetti usando il REST-getTokenforExternalApiCalls profilo tecnico.
- Seguire la documentazione qui per ottenere e proteggere l'API usando un token di connessione Microsoft Entra.

Cercare il mapping dell'area utente tramite l'endpoint dell'API REST protetto

Questa chiamata API viene eseguita prima di tutto l'iscrizione, è fondamentale assicurarsi che questa API disponga di meccanismi di bilanciamento del carico, resilienza e failover appropriati per soddisfare i requisiti di tempo di attività.

Un esempio di profilo tecnico per eseguire query su un mapping dell'area utente tramite un'API REST esterna è il seguente:

<TechnicalProfile Id="REST-regionLookup">
  <DisplayName>User to Region lookup</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/userToRegionLookup</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="AllowInsecureAuthInProduction">false</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="user_region" PartnerClaimType="region" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Eseguire l'autenticazione dell'account locale tramite il profilo tecnico per gli utenti che hanno effettuato l'iscrizione login-NonInteractive in questo tenant. Si tratta del profilo tecnico predefinito trovato nel starter pack di Azure AD B2C.

In modo condizionale, eseguire un'autenticazione tra tenant tramite i REST-login-NonInteractive-[region] profili tecnici per ogni rispettiva area.

Ciò otterrà anche un token di API Graph MS dal tenant home degli utenti. Registrare una registrazione di un'applicazione app nativa in ogni tenant a livello di area con autorizzazioni per ms API Graph per l'autorizzazione user.readdelegata.

Un esempio di profilo tecnico per eseguire il mapping dell'area utente tramite un'API REST esterna è il seguente:

<TechnicalProfile Id="REST-login-NonInteractive-APAC">
  <DisplayName>non interactive authentication to APAC</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://login.microsoftonline.com/yourAPACb2ctenant.onmicrosoft.com/oauth2/v2.0/token</Item>
    <Item Key="AuthenticationType">None</Item>
    <Item Key="SendClaimsIn">Form</Item>
    <Item Key="AllowInsecureAuthInProduction">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="apac_client_id" PartnerClaimType="client_id" DefaultValue="cf3f6898-9a79-426a-ba16-10e1a377c843" />
    <InputClaim ClaimTypeReferenceId="ropc_grant_type" PartnerClaimType="grant_type" DefaultValue="password" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" />
    <InputClaim ClaimTypeReferenceId="password" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="https://graph.microsoft.com/.default" AlwaysUseDefaultValue="true" />
    <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" PartnerClaimType="access_token" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Sostituire <yourb2ctenant> nell'oggetto ServiceUrl con il tenant di cui è necessario eseguire la destinazione per l'autenticazione.
Usare la registrazione ApplicationId dell'applicazione per popolare l'attestazione DefaultValueapac_client_id di input.

Recupera in modo condizionale il profilo utente usando una chiamata API REST multi-tenant tramite i REST-fetchUserProfile-[region] profili tecnici per ogni area.

Un profilo tecnico di esempio per leggere il profilo dell'utente tramite MS API Graph è il seguente:

<TechnicalProfile Id="REST-fetchUserProfile-APAC">
  <DisplayName>fetch user profile cross tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://graph.microsoft.com/beta/me</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">graph_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="graph_bearerToken" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="id" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surName" />
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Configurazione dei criteri personalizzati per la reimpostazione della password

Durante la reimpostazione della password, è necessario determinare il percorso del profilo degli utenti e aggiornare la password nel tenant di Azure AD B2C in cui risiede il profilo utente.

Modificare il LocalAccountSignUpWithLogonEmail profilo tecnico nel starter pack di Azure AD B2C per eseguire la ricerca dell'area utente e aggiornare la password nel rispettivo tenant. Aggiornare il ValidationTechnicalProfiles valore come:

<TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
  <OutputClaims>
  ...
  <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" DefaultValue="EMEA"/>
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" />
  </ValidationTechnicalProfiles>
</TechnicalProfile>

I file ValidationTechnicalProfile eseguiranno la logica seguente quando l'utente invia un messaggio di posta elettronica verificato per aggiornare la password:

Ottenere un token per chiamare gli endpoint API protetti
Cercare il mapping dell'area utente tramite l'endpoint dell'API REST esterna protetta
- Questa chiamata API viene eseguita prima di tutti i tentativi di reimpostazione della password, è fondamentale assicurarsi che questa API disponga di meccanismi di bilanciamento del carico, resilienza e failover appropriati per soddisfare i requisiti di tempo di attività.

Modificare il LocalAccountWritePasswordUsingObjectId profilo tecnico per scrivere la nuova password nel tenant locale o in modo condizionale nel tenant tra aree.

<TechnicalProfile Id="LocalAccountWritePasswordUsingObjectId">
  ...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>EMEA</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-UserWritePasswordUsingObjectId-APAC">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>APAC</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
</TechnicalProfile>

ValidationTechnicalProfiles eseguirà la logica seguente quando l'utente invia una nuova password:

Scrivere la nuova password degli utenti nella directory se l'utente esiste nel tenant EMEA (questo tenant).

In modo condizionale, scrivere la nuova password nel profilo utente nell'area in cui risiede il profilo utente, usando una chiamata API REST.

<TechnicalProfile Id="REST-UserWritePasswordUsingObjectId-APAC">
  <DisplayName>Write password to APAC tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/writePasswordCrossTenant</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="DebugMode">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="objectId" />
    <InputClaim ClaimTypeReferenceId="newPassword" />
  </InputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Condividi tramite

Verifica del framework di identità globale di Azure Active Directory B2C per la configurazione basata sull'area

Approccio basato su area

Prerequisiti

Preparare il livello di archiviazione

Preparare il livello API

Verificare se l'utente esiste già

Registrare il mapping delle aree degli utenti

Restituire l'area in cui esiste l'utente

Scrivere password tra tenant

Configurazione di Azure AD B2C basata sull'area

Configurazione dei criteri personalizzati per la reimpostazione della password

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive

Condividi tramite

Verifica del framework di identità globale di Azure Active Directory B2C per la configurazione basata sull'area

Approccio basato su area

Prerequisiti

Preparare il livello di archiviazione

Preparare il livello API

Verificare se l'utente esiste già

Registrare il mapping delle aree degli utenti

Restituire l'area in cui esiste l'utente

Scrivere password tra tenant

Configurazione di Azure AD B2C basata sull'area

Iscriversi alla configurazione dei criteri personalizzati

Configurazione dei criteri personalizzati per l'accesso

Configurazione dei criteri personalizzati per la reimpostazione della password

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive