Condividi tramite


Configurare l'accesso per l'ID Microsoft Entra multi-tenant usando criteri personalizzati in Azure Active Directory B2C

Prima di iniziare, usare il selettore Scegli un tipo di criterio per scegliere il tipo di criterio che si sta configurando. Azure Active Directory B2C offre due metodi per definire il modo in cui gli utenti interagiscono con le applicazioni: tramite flussi utente predefiniti o tramite criteri personalizzati completamente configurabili. I passaggi necessari in questo articolo sono diversi per ogni metodo.

Questa funzionalità è disponibile solo per i criteri personalizzati. Per i passaggi di installazione, selezionare Criteri personalizzati nel selettore precedente.

Questo articolo illustra come abilitare l'accesso per gli utenti usando l'endpoint multi-tenant per Microsoft Entra ID. Consentire agli utenti di più tenant di Microsoft Entra di accedere usando Azure AD B2C, senza dover configurare un provider di identità per ogni tenant. Tuttavia, i membri guest di questi tenant non saranno in grado di accedere. A tale scopo, è necessario configurare singolarmente ogni tenant.

Prerequisiti

Nota

In questo articolo si presuppone che il pacchetto di avvio SocialAndLocalAccounts venga usato nei passaggi precedenti indicati nei prerequisiti.

Registrare un'app Microsoft Entra

Per abilitare l'accesso per gli utenti con un account Microsoft Entra in Azure Active Directory B2C (Azure AD B2C), è necessario creare un'applicazione nel portale di Azure. Per altre informazioni, vedere Registrare un'applicazione con Microsoft Identity Platform.

  1. Accedi al portale di Azure.

  2. Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant microsoft Entra ID dal menu Directory e sottoscrizioni.

  3. Scegliere Tutti i servizi nell'angolo in alto a sinistra nel portale di Azure e quindi cercare e selezionare Registrazioni per l'app.

  4. Seleziona Nuova registrazione.

  5. Immettere un nome per l'applicazione. Ad esempio, Azure AD B2C App.

  6. Selezionare Accounts in any organizational directory (Any Microsoft Entra directory – Multitenant) per questa applicazione.

  7. Per l'URI di reindirizzamento accettare il valore di Web e immettere l'URL seguente in tutte le lettere minuscole, dove your-B2C-tenant-name viene sostituito con il nome del tenant di Azure AD B2C.

    https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp
    

    Ad esempio, https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp.

    Se si usa un dominio personalizzato, immettere https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp. Sostituire your-domain-name con il dominio personalizzato e your-tenant-name con il nome del tenant.

  8. Selezionare Registra. Prendere nota del valore di ID applicazione (client), che sarà necessario in un passaggio successivo.

  9. Selezionare Certificati & segreti e quindi nuovo segreto client.

  10. Immettere una descrizione per il segreto, selezionare una scadenza e quindi selezionare Aggiungi. Registrare il valore del segreto da usare in un passaggio successivo.

Configurazione di attestazioni facoltative

Se si desidera ottenere le family_nameattestazioni e given_name dall'ID Microsoft Entra, è possibile configurare attestazioni facoltative per l'applicazione nel manifesto dell'interfaccia utente o dell'applicazione portale di Azure. Per altre informazioni, vedere Come fornire attestazioni facoltative all'app Microsoft Entra.

  1. Accedi al portale di Azure. Cercare e selezionare Microsoft Entra ID.
  2. Nella sezione Gestisci selezionare Registrazioni app.
  3. Selezionare l'applicazione per cui si vogliono configurare le attestazioni facoltative nell'elenco.
  4. Nella sezione Gestisci selezionare Configurazione del token.
  5. Seleziona Aggiungi un'attestazione facoltativa.
  6. Per Tipo di token selezionare ID.
  7. Selezionare le attestazioni facoltative da aggiungere, family_namee given_name.
  8. Seleziona Aggiungi. Se si attiva l'autorizzazione di posta elettronica di Microsoft Graph (richiesta per la visualizzazione delle attestazioni nel token) viene visualizzata, abilitarla e quindi selezionare di nuovo Aggiungi .

[Facoltativo] Verificare l'autenticità dell'app

La verifica dell'autore consente agli utenti di comprendere l'autenticità dell'app registrata. Un'app verificata significa che l'editore dell'app ha verificato la propria identità usando Microsoft Partner Network (MPN). Informazioni su come indicare che per un'app è stata eseguita la verifica dell'autore.

Creare una chiave dei criteri

È necessario archiviare la chiave dell'applicazione creata nel tenant di Azure AD B2C.

  1. Se si ha accesso a più tenant, selezionare l'icona Impostazioni nel menu in alto per passare al tenant di Azure AD B2C dal menu Directory e sottoscrizioni.
  2. Scegliere Tutti i servizi nell'angolo in alto a sinistra nel portale di Azure e quindi cercare e selezionare Azure AD B2C.
  3. In Criteri selezionare Identity Experience Framework.
  4. Selezionare Chiavi dei criteri e quindi Aggiungi.
  5. Per Opzioni scegliere Manual.
  6. Immettere un nome per la chiave dei criteri. Ad esempio, AADAppSecret. Il prefisso B2C_1A_ viene aggiunto automaticamente al nome della chiave al momento della creazione, quindi il relativo riferimento nel codice XML nella sezione seguente consiste nel B2C_1A_AADAppSecret.
  7. In Segreto immettere il segreto client registrato in precedenza.
  8. In Uso chiave selezionare Signature.
  9. Seleziona Crea.

Configurare l'ID Microsoft Entra come provider di identità

Per consentire agli utenti di accedere usando un account Microsoft Entra, è necessario definire Microsoft Entra ID come provider di attestazioni con cui Azure AD B2C può comunicare tramite un endpoint. L'endpoint offre un set di attestazioni che vengono usate da Azure AD B2C per verificare se un utente specifico è stato autenticato.

È possibile definire Microsoft Entra ID come provider di attestazioni aggiungendo Microsoft Entra ID all'elemento ClaimsProvider nel file di estensione del criterio.

  1. Aprire il file SocialAndLocalAccounts/TrustFrameworkExtensions.xml (vedere i file usati nei prerequisiti).

  2. Trovare l'elemento ClaimsProviders. Se non esiste, aggiungerlo nell'elemento radice.

  3. Aggiungere un nuovo ClaimsProvider come illustrato di seguito:

    <ClaimsProvider>
      <Domain>commonaad</Domain>
      <DisplayName>Common AAD</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="AADCommon-OpenIdConnect">
          <DisplayName>Multi-Tenant AAD</DisplayName>
          <Description>Login with your Contoso account</Description>
          <Protocol Name="OpenIdConnect"/>
          <Metadata>
            <Item Key="METADATA">https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration</Item>
            <!-- Update the Client ID below to the Application ID -->
            <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
            <Item Key="response_types">code</Item>
            <Item Key="scope">openid profile</Item>
            <Item Key="response_mode">form_post</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="DiscoverMetadataByTokenIssuer">true</Item>
            <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
            <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>
            <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to sign in. -->
            <!-- <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item> -->
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_AADAppSecret"/>
          </CryptographicKeys>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid"/>
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin"/>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
  4. Nell'elemento ClaimsProvider aggiornare il valore di Domain con un valore univoco che ne consenta la distinzione rispetto ad altri provider di identità.

  5. Nell'elemento TechnicalProfile aggiornare il valore per DisplayName, Multi-Tenant AADad esempio . Questo valore verrà visualizzato sul pulsante di accesso nella pagina di accesso.

  6. Impostare client_id sull'ID applicazione dell'applicazione multi-tenant Microsoft Entra registrata in precedenza.

  7. In CryptographicKeys aggiornare il valore di Archiviazione ReferenceId al nome della chiave dei criteri creata in precedenza. Ad esempio, B2C_1A_AADAppSecret.

Limita accesso

L'uso https://login.microsoftonline.com/ come valore per ValidTokenIssuerPrefixes consente a tutti gli utenti di Microsoft Entra di accedere all'applicazione. Aggiornare l'elenco di autorità emittenti di token valide e limitare l'accesso a un elenco specifico di utenti tenant di Microsoft Entra che possono accedere.

Per ottenere i valori, esaminare i metadati di individuazione Connessione OpenID per ognuno dei tenant di Microsoft Entra da cui si vuole accedere gli utenti. Il formato dell'URL dei metadati è simile a https://login.microsoftonline.com/your-tenant/v2.0/.well-known/openid-configuration, dove your-tenant è il nome del tenant di Microsoft Entra. Ad esempio:

https://login.microsoftonline.com/fabrikam.onmicrosoft.com/v2.0/.well-known/openid-configuration

Eseguire questi passaggi per ogni tenant di Microsoft Entra che deve essere usato per accedere:

  1. Aprire il browser e passare all'URL dei metadati Connessione OpenID per il tenant. Trovare l'oggetto e registrarne il issuer valore. Dovrebbe essere simile a https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/v2.0.
  2. Copiare e incollare il valore nella chiave ValidTokenIssuerPrefixes . Separare più emittenti con una virgola. Nell'esempio XML precedente ClaimsProvider viene visualizzato un esempio con due emittenti.

Aggiungere un percorso utente

A questo punto, il provider di identità è stato configurato, ma non è ancora disponibile in nessuna delle pagine di accesso. Se non si ha un percorso utente personalizzato, creare un duplicato di un percorso utente modello esistente, altrimenti continuare con il passaggio successivo.

  1. Aprire il file TrustFrameworkBase.xml dallo starter pack.
  2. Trovare e copiare l'intero contenuto dell'elemento UserJourney che include Id="SignUpOrSignIn".
  3. Aprire TrustFrameworkExtensions.xml e trovare l'elemento UserJourneys. Se l'elemento non esiste, aggiungerne uno.
  4. Incollare l'intero contenuto dell'elemento UserJourney copiato come figlio dell'elemento UserJourneys.
  5. Rinominare l'ID del percorso utente. Ad esempio, Id="CustomSignUpSignIn".

Aggiungere il provider di identità a un percorso utente

Dopo aver creato un percorso utente, aggiungere il nuovo provider di identità al percorso utente. Aggiungere prima un pulsante di accesso, quindi collegare il pulsante a un'azione. L'azione è il profilo tecnico creato in precedenza.

  1. Trovare l'elemento del passaggio di orchestrazione che include Type="CombinedSignInAndSignUp"o Type="ClaimsProviderSelection" nel percorso utente. In genere è il primo passaggio di orchestrazione. L'elemento ClaimsProviderSelections contiene un elenco di provider di identità con cui un utente può accedere. L'ordine degli elementi controlla l'ordine dei pulsanti di accesso presentati all'utente. Aggiungere un elemento XML ClaimsProviderSelection . Impostare il valore di TargetClaimsExchangeId su un nome descrittivo.

  2. Nel passaggio di orchestrazione successivo aggiungere un elemento ClaimsExchange . Impostare ID sul valore dell'ID di scambio di attestazioni di destinazione. Aggiornare il valore di TechnicalProfileReferenceId sull'ID del profilo tecnico creato in precedenza.

Il codice XML seguente illustra i primi due passaggi di orchestrazione di un percorso utente con il provider di identità:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="AzureADCommonExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="AzureADCommonExchange" TechnicalProfileReferenceId="AADCommon-OpenIdConnect" />
  </ClaimsExchanges>
</OrchestrationStep>

Configurare i criteri della relying party

I criteri della relying party, ad esempio SignUpSignIn.xml, specificano il percorso utente che verrà eseguito da Azure AD B2C. Trovare l'elemento DefaultUserJourney all'interno della relying party. Aggiornare ReferenceId in modo che corrisponda all'ID percorso utente in cui è stato aggiunto il provider di identità.

Nell'esempio seguente, per il CustomSignUpSignIn percorso utente, ReferenceId è impostato su CustomSignUpSignIn:

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Caricare il criterio personalizzati

  1. Accedi al portale di Azure.
  2. Selezionare l'icona Directory e sottoscrizione nella barra degli strumenti del portale e quindi la directory contenente il tenant di Azure AD B2C.
  3. Nel portale di Azure cercare e selezionare Azure AD B2C.
  4. In Criteri selezionare Identity Experience Framework.
  5. Selezionare Carica criteri personalizzati e quindi caricare i due file di criteri modificati, nell'ordine seguente: i criteri di estensione, ad esempio , quindi i criteri della relying party, ad esempio TrustFrameworkExtensions.xmlSignUpSignIn.xml.

Testare i criteri personalizzati

  1. Selezionare i criteri della relying party, ad esempio B2C_1A_signup_signin.
  2. In Applicazione selezionare un'applicazione Web registrata in precedenza. L'URL di risposta dovrebbe mostrare https://jwt.ms.
  3. Selezionare il pulsante Esegui adesso .
  4. Nella pagina di iscrizione o accesso selezionare Common Microsoft Entra ID (COMMON Microsoft Entra ID ) per accedere con l'account Microsoft Entra.

Per testare la funzionalità di accesso multi-tenant, eseguire gli ultimi due passaggi usando le credenziali per un utente che esiste in un altro tenant di Microsoft Entra. Copiare l'endpoint Esegui ora e aprirlo in una finestra del browser privato, ad esempio modalità in incognito in Google Chrome o in una finestra InPrivate in Microsoft Edge. L'apertura in una finestra del browser privato consente di testare il percorso utente completo senza usare le credenziali di Microsoft Entra attualmente memorizzate nella cache.

Se il processo di accesso ha esito positivo, il browser viene reindirizzato a https://jwt.ms, che visualizza il contenuto del token restituito da Azure AD B2C.

Passaggi successivi