Configurare Trusona Authentication Cloud con Azure Active Directory B2C

Articolo
01/26/2024

Questa esercitazione di esempio descrive come integrare l'autenticazione di Azure AD B2C con Trusona Authentication Cloud. Si tratta di un servizio basato sul cloud che consente agli utenti di eseguire l'autenticazione con un'esperienza tap-and-go , senza la necessità di qualsiasi tipo di app di autenticazione per dispositivi mobili.

I vantaggi dell'integrazione di Trusona Authentication Cloud con Azure AD B2C includono:

Offrire un'autenticazione avanzata con un'esperienza utente migliore
- Utenti più felici che spendono più online
- Minore attrito e abbandono, aumento dei ricavi
- Conservazione superiore, valore di durata (LTV)
Costo inferiore per l'esecuzione dell'azienda
- Riduzione delle acquisizioni di account e condivisione degli account
- Riduzione delle frodi e meno azioni di analisi manuale delle frodi
- Riduzione della spesa per l'esternalizzazione delle revisioni manuali
Eliminare le password
- Nessuna reimpostazione della password
- Riduzione dei reclami del call center
- Accessi veloci, semplici e senza attrito con passkey

Prerequisiti

Per iniziare, è necessario:

Un account di valutazione di Trusona Authentication Cloud. Per richiedere un account, contattare Trusona.
Una sottoscrizione di Azure. Se non si possiede una sottoscrizione, è possibile ottenere un account gratuito.
Tenant di Azure AD B2C collegato alla sottoscrizione di Azure.

Completare i passaggi descritti nell'articolo Introduzione ai criteri personalizzati in Azure AD B2C.

Descrizione dello scenario

Web Authentication Standard : WebAuthn implementa sistemi operativi e browser moderni per supportare l'autenticazione tramite stampa tramite dita, Windows hello o dispositivi FIDO esterni, ad esempio USB, Bluetooth e OTP.

In questo scenario Trusona funge da provider di identità (IdP) per Azure AD B2C per abilitare l'autenticazione senza password. I componenti seguenti costituiscono la soluzione:

Criteri di accesso e iscrizione combinati di Azure AD B2C.
Trusona Authentication Cloud aggiunto ad Azure AD B2C come IdP.

Screenshot shows Trusona architecture diagram.

Passaggi	Descrizione
1.	Un utente tenta di accedere all'applicazione Web tramite il browser.
2.	L'applicazione Web reindirizza ai criteri di iscrizione e accesso di Azure AD B2C.
3.	Azure AD B2C reindirizza l'utente per l'autenticazione al provider di identità Trusona Authentication Cloud OpenID Connessione (OIDC).
4.	L'utente viene visualizzato con una pagina Web di accesso che richiede il proprio nome utente, in genere un indirizzo di posta elettronica.
5.	L'utente immette l'indirizzo di posta elettronica e seleziona il pulsante Continua . Se l'account dell'utente non viene trovato nel cloud Trusona Authentication, viene inviata una risposta al browser che avvia un processo di registrazione WebAuthn nel dispositivo. In caso contrario, viene inviata una risposta al browser che avvia un processo di autenticazione WebAuthn.
6.	All'utente viene chiesto di selezionare una credenziale da usare. La passkey è associata al dominio dell'applicazione Web o a una chiave di sicurezza hardware. Dopo che l'utente seleziona una credenziale, il sistema operativo richiede all'utente di usare un PIN, un passcode o un pin biometrico per confermare la propria identità. In questo modo viene sbloccato l'ambiente Secure Enclave/Trusted Execution, che genera un'asserzione di autenticazione firmata dalla chiave privata associata alla credenziale selezionata.
7.	L'asserzione di autenticazione viene restituita al servizio cloud Trusona per la verifica.
8.	Dopo la verifica, Trusona Authentication Cloud (IdP) crea un token ID OIDC e quindi lo inoltra ad Azure AD B2C (provider di servizi). Azure AD B2C convalida la firma del token e l'autorità emittente rispetto ai valori nel documento di individuazione OpenID di Trusona. Questi dettagli sono stati configurati durante l'installazione di IdP. Dopo la verifica, Azure AD B2C rilascia un id_token OIDC (a seconda dell'ambito) e reindirizza l'utente all'applicazione di avvio con il token.
9.	L'applicazione Web (o le librerie per sviluppatori che usa per implementare l'autenticazione) recupera il token e verifica l'autenticità del token di Azure AD B2C. In tal caso, estrae le attestazioni e le passa all'applicazione Web da utilizzare.
10.	Al momento della verifica, all'utente viene concesso o negato l'accesso.

Passaggio 1: Eseguire l'onboarding con Trusona Authentication Cloud

Accedere al portale trusona.
Nel pannello di spostamento a sinistra selezionare Impostazioni
Nel menu Impostazioni selezionare il dispositivo di scorrimento per Abilitare OIDC.
Selezionare gli input appropriati e specificare l'URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp di reindirizzamento.
Generare una chiave privata e copiare la chiave da usare nella configurazione di Azure AD B2C.
Nota
1. Il portale trusona supporta la registrazione self-service. Al momento della registrazione, l'utente verrà assegnato a un account Trusona con diritti di sola lettura. Successivamente, Trusona assegnerà l'account corretto ed eleva i diritti di lettura/scrittura in base ai criteri di controllo di accesso dell'organizzazione per gli utenti del portale.
2. Il nome di dominio iniziale dell'ID Microsoft Entra viene usato come host di reindirizzamento client.

Passaggio 2: Registrare un'applicazione Web in Azure AD B2C

Prima che le applicazioni possano interagire con Azure AD B2C, devono essere registrate nel tenant del cliente. Questa esercitazione illustra come registrare un'applicazione Web usando il portale di Azure. A scopo di test come questa esercitazione, si sta registrando https://jwt.ms, un'applicazione Web di proprietà di Microsoft che visualizza il contenuto decodificato di un token (il contenuto del token non lascia mai il browser). Per registrare un'applicazione Web nel tenant di Azure AD B2C, usare la nuova esperienza di registrazione unificata delle app.

Accedi al portale di Azure.
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.
Nel portale di Azure cercare e selezionare Azure AD B2C.
Selezionare Registrazioni app e quindi Nuova registrazione.
Immettere un nome per l'applicazione. Ad esempio, jwt ms.
Sotto Tipi di account supportati, seleziona Account in qualsiasi provider di identità o directory dell'organizzazione (per autenticare gli utenti con flussi utente).
In URI di reindirizzamento, selezionare Web, quindi immettere https://jwt.ms nella casella di testo URL.

L'URI di reindirizzamento è l'endpoint a cui il server di autorizzazione, Azure AD B2C in questo caso invia l'utente. Dopo aver completato l'interazione con l'utente, viene inviato un token di accesso o un codice di autorizzazione al termine dell'autorizzazione. In un'applicazione di produzione, si tratta in genere di un endpoint accessibile pubblicamente in cui l'app è in esecuzione, ad esempio https://contoso.com/auth-response. A scopo di test come questa esercitazione, è possibile impostarlo su https://jwt.ms, un'applicazione Web di proprietà di Microsoft che visualizza il contenuto decodificato di un token (il contenuto del token non lascia mai il browser). Durante lo sviluppo di app, è possibile aggiungere l'endpoint in cui l'applicazione è in ascolto localmente, ad esempio https://localhost:5000. È possibile aggiungere e modificare gli URI di reindirizzamento nelle applicazioni registrate in qualsiasi momento.

Agli URL di reindirizzamento si applicano le restrizioni seguenti:
- L'URL di risposta deve iniziare con lo schema https, a meno che non si usi un URL di reindirizzamento localhost.
- L'URL di risposta rileva la distinzione tra maiuscole e minuscole. Le maiuscole e le minuscole devono corrispondere a quelle nel percorso URL dell'applicazione in esecuzione. Ad esempio, se l'applicazione include come parte del percorso .../abc/response-oidc, non specificare .../ABC/response-oidc nell'URL di risposta. Poiché il Web browser rileva la distinzione tra maiuscole e minuscole nei percorsi, è possibile che i cookie associati a .../abc/response-oidc vengano esclusi se reindirizzati all'URL .../ABC/response-oidc senza la corrispondenza tra maiuscole e minuscole.
- L'URL di risposta deve includere o escludere la barra finale come previsto dall'applicazione. Ad esempio, https://contoso.com/auth-response e https://contoso.com/auth-response/ potrebbero essere considerati come URL non corrispondenti nell'applicazione.
In Autorizzazioni, selezionare la casella di controllo Concedere il consenso amministratore alle autorizzazioni OpenID e offline_access.
Selezionare Registra.

Abilitare la concessione implicita del token ID

Se si registra questa app e la si configura con https://jwt.ms/ l'app per testare un flusso utente o criteri personalizzati, è necessario abilitare il flusso di concessione implicita nella registrazione dell'app:

Nel menu a sinistra, in Gestisci, selezionare Autenticazione.
In Concessione implicita e flussi ibridi selezionare token ID (usati per flussi impliciti e ibridi).
Seleziona Salva.

Passaggio 3: Configurare Trusona Authentication Cloud come IdP in Azure AD B2C

Accedere al portale di Azure come amministratore globale del tenant di Azure AD B2C.
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.
Scegliere Tutti i servizi nell'angolo in alto a sinistra del portale di Azure, cercare Azure AD B2C e selezionarlo.
Passare a Dashboard Azure Active Directory B2C Identity providers (Provider>di identità B2C>di Azure Active Directory).
Selezionare Provider di identità.
Seleziona Aggiungi.

Configurare un Provider di identità

Selezionare Tipo di provider di>identità OpenID Connessione (anteprima).

Compilare il modulo per configurare il provider di identità:

Proprietà	valore
URL dei metadati	`https://authcloud.trusona.net/.well-known/openid-configuration`
ID client	disponibile nel portale di Trusona Authentication Cloud
Segreto client	disponibile nel portale di Trusona Authentication Cloud
Ambito	Indirizzo di posta elettronica del profilo OpenID
Tipo di risposta	codice
Modalità di risposta	form_post

Seleziona OK.
Selezionare Mappa le attestazioni del provider di identità.
Compilare il modulo per eseguire il mapping del provider di identità:

Proprietà valore

UserID secondario

Nome visualizzato nickname

Nome specificato given_name

Surname family_name

Modalità di risposta posta elettronica
Selezionare OK per completare la configurazione per il nuovo IdP OIDC.

Proprietà	valore
UserID	secondario
Nome visualizzato	nickname
Nome specificato	given_name
Surname	family_name
Modalità di risposta	posta elettronica

Passaggio 4: Creare un criterio del flusso utente

Verrà ora visualizzato Trusona come nuovo openID Connessione provider di identità elencato nei provider di identità B2C.

Nel tenant di Azure AD B2C, in Criteri selezionare Flussi utente.
Selezionare Nuovo flusso utente.
Selezionare Iscrizione e accesso, selezionare una versione e quindi selezionare Crea.
Immettere un nome per il criterio.
Nella sezione Provider di identità selezionare il provider di identità Trusona Authentication Cloud-Identity Provider appena creato.

Nota

Poiché Trusona è intrinsecamente a più fattori, è consigliabile lasciare disabilitata l'autenticazione a più fattori.
Seleziona Crea.
In Attributi utente e attestazioni scegliere Mostra altro. Nel modulo selezionare almeno un attributo specificato durante la configurazione del provider di identità nella sezione precedente.
Seleziona OK.

Passaggio 5: Testare il flusso utente

Selezionare il criterio creato.
Selezionare Esegui flusso utente e quindi selezionare le impostazioni:

a. Applicazione: selezionare l'app registrata, ad esempio jwt ms.

b. URL di risposta: selezionare l'URL di reindirizzamento, https://jwt.msad esempio .
Seleziona Esegui il flusso utente. Si dovrebbe essere reindirizzati al cloud Trusona Authentication. L'utente viene visualizzato con una pagina Web di accesso che richiede il proprio nome utente, in genere un indirizzo di posta elettronica. Se l'account dell'utente non viene trovato in Trusona Authentication Cloud, viene inviata una risposta al browser che avvia un processo di registrazione WebAuthn nel dispositivo. In caso contrario, viene inviata una risposta al browser che avvia un processo di autenticazione WebAuthn. All'utente viene chiesto di selezionare una credenziale da usare. La passkey è associata al dominio dell'applicazione Web o a una chiave di sicurezza hardware. Dopo che l'utente seleziona una credenziale, il sistema operativo richiede all'utente di usare un PIN, un passcode o un pin biometrico per confermare la propria identità. In questo modo viene sbloccato l'ambiente Secure Enclave/Trusted Execution, che genera un'asserzione di autenticazione firmata dalla chiave privata associata alla credenziale selezionata. Azure AD B2C convalida la risposta di autenticazione Trusona e rilascia un token OIDC. Reindirizza l'utente all'applicazione di avvio, https://jwt.msad esempio , che visualizza il contenuto del token restituito da Azure AD B2C.

Passaggio 3: Creare la chiave dei criteri cloud trusona authentication

Archiviare il segreto client generato in precedenza nel passaggio 1 nel tenant di Azure AD B2C.

Accedi al portale di Azure.
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.
Scegliere Tutti i servizi nell'angolo in alto a sinistra nel portale di Azure e quindi cercare e selezionare Azure AD B2C.
Nella pagina Panoramica selezionare Framework dell'esperienza di gestione delle identità.
Selezionare Chiavi dei criteri e quindi selezionare Aggiungi.
Per Opzioni scegliere Manuale.
Immettere un nome per la chiave dei criteri. Ad esempio, TrusonaTacClientSecret. Verrà aggiunto automaticamente il prefisso B2C_1A_ al nome della chiave.
In Segreto immettere il segreto client registrato in precedenza.
In Uso chiave selezionare Signature.
Seleziona Crea.

Passaggio 4: Configurare Trusona Authentication Cloud come Provider di identità

Suggerimento

A questo punto è necessario configurare i criteri di Azure AD B2C. In caso contrario, seguire le istruzioni su come configurare il tenant di Azure AD B2C e configurare i criteri.

Per consentire agli utenti di accedere usando Trusona Authentication Cloud, è necessario definire Trusona come provider di attestazioni con cui Azure AD B2C può comunicare tramite un endpoint. L'endpoint fornisce un set di attestazioni usate da Azure AD B2C per verificare che un utente specifico abbia eseguito l'autenticazione usando una passkey o una chiave di sicurezza hardware disponibile nel dispositivo, dimostrando l'identità dell'utente.

Usare la procedura seguente per aggiungere Trusona come provider di attestazioni:

Ottenere i pacchetti di avvio dei criteri personalizzati da GitHub, quindi aggiornare i file XML nello starter pack LocalAccounts con il nome del tenant di Azure AD B2C:
1. È possibile scaricare il file ZIP o clonare il repository:
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. In tutti i file nella directory LocalAccounts sostituire la stringa yourtenant con il nome del tenant di Azure AD B2C. Ad esempio, se il nome del tenant B2C è contoso, tutte le istanze di yourtenant.onmicrosoft.com diventano contoso.onmicrosoft.com.
Aprire il file LocalAccounts/TrustFrameworkExtensions.xml.
Trovare l'elemento ClaimsProviders. Se non esiste, aggiungerlo sotto l'elemento radice . TrustFrameworkPolicy
Aggiungere un nuovo ClaimsProvider simile a quello illustrato di seguito:

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
        <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
        <!-- trying to add additional claim-->
        <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
        <!-- The commented key 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>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Impostare client_id con l'ID applicazione Trusona Authentication Cloud registrato in precedenza nel passaggio 1.
Aggiornare client_secret sezione con il nome della chiave dei criteri creata nel passaggio 3. Ad esempio, B2C_1A_TrusonaTacClientSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
```
Salvare le modifiche.

Passaggio 5: Aggiungere un percorso utente

A questo punto, è stato configurato il provider di identità, ma non è ancora disponibile in nessuna delle pagine di accesso. Se il percorso utente personalizzato continua con il passaggio 6, in caso contrario, creare un duplicato di un percorso utente modello esistente come indicato di seguito:

Aprire il LocalAccounts/TrustFrameworkBase.xml file dallo starter pack.
Trovare e copiare l'intero contenuto dell'elemento UserJourney che include Id=SignUpOrSignIn.
Aprire e LocalAccounts/TrustFrameworkExtensions.xml trovare l'elemento UserJourneys . Se l'elemento non esiste, aggiungerne uno.
Incollare l'intero contenuto dell'elemento UserJourney copiato come figlio dell'elemento UserJourneys.
Rinominare l'oggetto Id del percorso utente. Ad esempio, Id=TrusonaTacSUSI.

Passaggio 6: Aggiungere il provider di identità a un percorso utente

Dopo aver creato un percorso utente, aggiungere il nuovo IdP al percorso utente.

Trovare l'elemento del passaggio di orchestrazione che include Type=CombinedSignInAndSignUpo 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, ad esempio TrusonaTacExchange.
Nel passaggio di orchestrazione successivo aggiungere un elemento ClaimsExchange . Impostare l'ID sul valore dell'ID dello scambio di attestazioni di destinazione. Aggiornare il valore di TechnicalProfileReferenceId all'ID del profilo tecnico creato in precedenza durante l'aggiunta del provider di attestazioni, TrusonaTAC-OpenIdConnectad esempio .

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

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Show self-asserted page only if the directory does not have the user account already (we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

Altre informazioni sui percorsi utente.

Passaggio 7: Configurare i criteri della relying party

Il criterio della relying party, ad esempio SignUpSignIn.xml, specifica il percorso utente 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 Trusona Authentication Cloud percorso utente, ReferenceId è impostato su TrusonaTacSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Passaggio 8: Caricare i criteri personalizzati

Accedi al portale di Azure.
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.
Nella portale di Azure cercare e selezionare Azure AD B2C.
In Criteri selezionare Framework dell'esperienza di gestione delle identità.
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.xmlSignUpOrSignin.xml.

Passaggio 9: Testare i criteri personalizzati

Nel tenant di Azure AD B2C, in Criteri selezionare Framework dell'esperienza di gestione delle identità.
In Criteri personalizzati selezionare TrusonaTacSUSI.
In Applicazione selezionare l'applicazione Web registrata in precedenza come parte dei prerequisiti di questo articolo. ad esempio jwt ms. L'URL di risposta dovrebbe mostrare https://jwt.ms.
Selezionare Esegui ora. Il browser deve essere reindirizzato alla pagina di accesso di Trusona Authentication Cloud.
Viene visualizzata una schermata di accesso; nella parte inferiore dovrebbe essere presente un pulsante per usare l'autenticazione cloud Trusona Authentication.
Si dovrebbe essere reindirizzati a Trusona Authentication Cloud. L'utente viene visualizzato con una pagina Web di accesso che richiede il proprio nome utente, in genere un indirizzo di posta elettronica. Se l'account dell'utente non viene trovato nel cloud Trusona Authentication, viene inviata una risposta al browser che avvia un processo di registrazione WebAuthn nel dispositivo. In caso contrario, viene inviata una risposta al browser che avvia un processo di autenticazione WebAuthn. All'utente viene chiesto di selezionare una credenziale da usare. La passkey è associata al dominio dell'applicazione Web o a una chiave di sicurezza hardware. Dopo che l'utente seleziona una credenziale, il sistema operativo richiede all'utente di usare un PIN, un passcode o un pin biometrico per confermare la propria identità. In questo modo viene sbloccato l'ambiente Secure Enclave/Trusted Execution, che genera un'asserzione di autenticazione firmata dalla chiave privata associata alla credenziale selezionata.
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

Per altre informazioni, vedere gli articoli seguenti:

Condividi tramite