Creare la diramazione nel percorso utente usando criteri personalizzati di Azure Active Directory B2C

Articolo
01/11/2024

Diversi utenti della stessa app possono seguire percorsi utente diversi a seconda dei valori dei dati in un criterio personalizzato. I criteri personalizzati di Azure Active Directory B2C (Azure AD B2C) consentono di abilitare o disabilitare in modo condizionale un profilo tecnico per ottenere questa funzionalità. Ad esempio, in Convalidare gli input utente usando i criteri personalizzati di Azure AD B2C è stato usato per Precondition determinare se è necessario eseguire o meno un profilo tecnico di convalida in base al valore dell'attestazione accountType .

Un profilo tecnico fornisce anche un EnabledForUserJourneys elemento che consente di specificare se deve essere eseguito o meno un profilo tecnico. L'elemento EnabledForUserJourneys contiene uno dei cinque valori, tra cui OnClaimsExistence, che viene usato per specificare che un profilo tecnico deve essere eseguito solo quando esiste una determinata attestazione specificata nel profilo tecnico. Altre informazioni sull'elemento EnabledForUserJourneys del profilo tecnico.

Panoramica dello scenario

Nell'articolo Convalidare gli input utente usando i criteri personalizzati di Azure AD B2C, un utente inserisce i dettagli in un'unica schermata. In questo articolo, un utente deve prima selezionare il tipo di account, l'account dipendente Contoso o l'account personale. Un utente che seleziona l'account dipendente Contoso può continuare a fornire altri dettagli. Tuttavia, un utente che seleziona Account personale deve fornire un codice di accesso di invito valido prima di poter continuare a fornire ulteriori dettagli. Di conseguenza, gli utenti che usano il tipo di account personale vedono un'interfaccia utente aggiuntiva per completare il percorso.

A flowchart of branching in user journey.

Questo articolo illustra come usare EnabledForUserJourneys l'elemento all'interno di un profilo tecnico per creare esperienze utente diverse in base a un valore attestazione.

Prerequisiti

In assenza di un tenant, creare un tenant di Azure AD B2C collegato alla sottoscrizione di Azure.
Registrare un'applicazione Web e abilitare la concessione implicita del token ID. Per l'URI di reindirizzamento, usare https://jwt.ms.
Nel computer deve essere installato Visual Studio Code (VS Code ).
Completare i passaggi descritti in Convalidare gli input utente usando i criteri personalizzati di Azure AD B2C. Questo articolo fa parte della serie di procedure per creare ed eseguire criteri personalizzati.

Nota

Questo articolo fa parte della serie di procedure Creare ed eseguire criteri personalizzati in Azure Active Directory B2C. È consigliabile iniziare questa serie dal primo articolo.

Passaggio 1- Dichiarare attestazioni

Un utente che seleziona Account personale deve fornire un codice di accesso valido. È quindi necessaria un'attestazione per contenere questo valore:

In VS Code aprire il ContosoCustomPolicy.XML file.

ClaimsSchema Nella sezione dichiarare le attestazioni accessCode e isValidAccessCode usando il codice seguente:

    <ClaimType Id="accessCode">
        <DisplayName>Access Code</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Enter your invitation access code.</UserHelpText>
        <UserInputType>Password</UserInputType>
        <Restriction>
            <Pattern RegularExpression="[0-9][0-9][0-9][0-9][0-9]" HelpText="Please enter your invitation access code. It's a 5-digit number, something like 95765"/>
        </Restriction>
    </ClaimType>
    <ClaimType Id="isValidAccessCode">
        <DataType>boolean</DataType>
    </ClaimType>

Passaggio 2: Definire le trasformazioni delle attestazioni

Individuare l'elemento ClaimsTransformations e aggiungere le trasformazioni di attestazioni seguenti:

    <!---<ClaimsTransformations>-->
        <ClaimsTransformation Id="CheckIfIsValidAccessCode" TransformationMethod="CompareClaimToValue">
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="accessCode" TransformationClaimType="inputClaim1"/>
            </InputClaims>
            <InputParameters>
                <InputParameter Id="compareTo" DataType="string" Value="88888"/>
                <InputParameter Id="operator" DataType="string" Value="equal"/>
                <InputParameter Id="ignoreCase" DataType="string" Value="true"/>
            </InputParameters>
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="outputClaim"/>
            </OutputClaims>
        </ClaimsTransformation>
        <ClaimsTransformation Id="ThrowIfIsNotValidAccessCode" TransformationMethod="AssertBooleanClaimIsEqualToValue">
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="inputClaim"/>
            </InputClaims>
            <InputParameters>
                <InputParameter Id="valueToCompareTo" DataType="boolean" Value="true"/>
            </InputParameters>
        </ClaimsTransformation>
    <!---</ClaimsTransformations>-->

Sono stati definiti due trasformazioni di attestazioni, CheckIfIsValidAccessCode e ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode usa il metodo di trasformazione CompareClaimToValue per confrontare l'input del codice di accesso da parte dell'utente rispetto a un valore statico 88888 (usiamo questo valore per il test) e assegna o false a isValidAccessCode attestazionetrue. ThrowIfIsNotValidAccessCode controlla se due valori booleani di due attestazioni sono uguali e genera un'eccezione se non lo sono.

Passaggio 3- Configurare o aggiornare i profili tecnici

Sono ora necessari due nuovi profili tecnici autocertificati, uno per raccogliere il tipo di account e l'altro per raccogliere il codice di accesso dall'utente. È anche necessario un nuovo profilo tecnico del tipo di trasformazione delle attestazioni per convalidare il codice di accesso dell'utente eseguendo le trasformazioni delle attestazioni definite nel passaggio 2. Ora che si raccoglie il tipo di account in un profilo tecnico autocertificato diverso, è necessario aggiornare il UserInformationCollector profilo tecnico autocertificato per impedire la raccolta del tipo di account.

Individuare l'elemento ClaimsProviders e quindi aggiungere un nuovo provider di attestazioni usando il codice seguente:

    <!--<ClaimsProviders>-->
        <ClaimsProvider>
            <DisplayName>Technical Profiles to collect user's access code</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="AccessCodeInputCollector">
                    <DisplayName>Collect Access Code Input from user Technical Profile</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <Metadata>
                        <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item>
                        <Item Key="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">The access code is invalid.</Item>
                        <Item Key="ClaimTypeOnWhichToEnable">accountType</Item>
                        <Item Key="ClaimValueOnWhichToEnable">personal</Item>
                    </Metadata>
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="accessCode" Required="true"/>
                    </DisplayClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="accessCode"/>
                    </OutputClaims>
                    <ValidationTechnicalProfiles>
                        <ValidationTechnicalProfile ReferenceId="CheckAccessCodeViaClaimsTransformationChecker"/>
                    </ValidationTechnicalProfiles>
                    <EnabledForUserJourneys>OnClaimsExistence</EnabledForUserJourneys>
                </TechnicalProfile>
                <TechnicalProfile Id="CheckAccessCodeViaClaimsTransformationChecker">
                    <DisplayName>A Claims Transformations to check user's access code validity</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="isValidAccessCode"/>
                    </OutputClaims>
                    <OutputClaimsTransformations>
                        <OutputClaimsTransformation ReferenceId="CheckIfIsValidAccessCode"/>
                        <OutputClaimsTransformation ReferenceId="ThrowIfIsNotValidAccessCode"/>
                    </OutputClaimsTransformations>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Sono stati configurati due profili tecnici, AccessCodeInputCollector e CheckAccessCodeViaClaimsTransformationChecker. Chiamiamo il profilo tecnico CheckAccessCodeViaClaimsTransformationChecker come profilo tecnico di convalida dall'interno del profilo tecnico AccessCodeInputCollector . CheckAccessCodeViaClaimsTransformationChecker è di tipo Profilo tecnico della trasformazione delle attestazioni, che esegue le trasformazioni delle attestazioni definite nel passaggio 2.

AccessCodeInputCollector è un profilo tecnico autocertizionato usato per raccogliere un codice di accesso dall'utente. Include EnabledForUserJourneys l'elemento impostato su OnClaimsExistence. L'elemento Metadata include un'attestazione (accountType) e il relativo valore (personale) che attiva questo profilo tecnico.

Individuare l'elemento ClaimsProviders e quindi aggiungere un nuovo provider di attestazioni usando il codice seguente:

    <!--<ClaimsProviders>-->
        <ClaimsProvider>
            <DisplayName>Technical Profile to collect user's accountType</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="AccountTypeInputCollector">
                    <DisplayName>Collect User Input Technical Profile</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <Metadata>
                        <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item>
                    </Metadata>
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>
                    </DisplayClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="accountType"/>
                    </OutputClaims>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

È stato configurato un profilo tecnico autocertizionato, AccountTypeInputCollector, che raccoglie il tipo di account dell'utente. Si tratta del valore dei tipi di account che determina se il AccessCodeInputCollector profilo tecnico autocertificato deve essere attivato.

Per impedire al UserInformationCollector profilo tecnico autocertificato di raccogliere il tipo di account, individuare il UserInformationCollector profilo tecnico autocertificato e quindi:
1. Rimuovere l'attestazione accountType di visualizzazione dalla <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>DisplayClaims raccolta.
2. Rimuovere l'attestazione accountType di output, <OutputClaim ClaimTypeReferenceId="accountType"/>, dalla OutputClaims raccolta.

Passaggio 4- Aggiornare i passaggi di orchestrazione del percorso utente

Dopo aver configurato i profili tecnici, è necessario aggiornare i passaggi di orchestrazione del percorso utente:

Individuare il HelloWorldJourney percorso utente e aggiungere sostituire tutti i passaggi di orchestrazione con il codice seguente:

    <!--<OrchestrationSteps>-->
        <OrchestrationStep Order="1" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
            </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="ClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

I passaggi di orchestrazione mostrano che chiamiamo il profilo tecnico nell'ordine indicato dall'attributo dei passaggi Order di orchestrazione. Tuttavia, il AccessCodeInputCollector profilo tecnico viene attivato se l'utente seleziona il tipo di account personale.

Passaggio 5 - Caricare un file di criteri personalizzato

Seguire la procedura descritta in Caricare un file di criteri personalizzato per caricare il file dei criteri. Se si carica un file con lo stesso nome di quello già presente nel portale, assicurarsi di selezionare Sovrascrivi il criterio personalizzato, se già esistente.

Passaggio 6 - Testare i criteri personalizzati

Seguire la procedura descritta in Testare i criteri personalizzati per testare i criteri personalizzati:

Nella prima schermata, per Tipo di account, selezionare Account personale.
Per Codice di accesso immettere 88888 e quindi selezionare Continua.
Immettere il resto dei dettagli in base alle esigenze e quindi selezionare Continua. Al termine dell'esecuzione del criterio, si viene reindirizzati a https://jwt.mse viene visualizzato un token JWT decodificato.
Ripetere il passaggio 5, ma questa volta selezionare Tipo di account, selezionare Account dipendente Contoso e quindi seguire le istruzioni.

Passaggi successivi

Nel passaggio 3 viene abilitato o disabilitato il profilo tecnico usando l'elemento EnabledForUserJourneys . In alternativa, è possibile usare precondizioni all'interno dei passaggi di orchestrazione del percorso utente per eseguire o ignorare un passaggio di orchestrazione, come illustrato più avanti in questa serie.

A questo punto, vedere:

Informazioni sulle precondizioni dei passaggi di orchestrazione del percorso utente.
Come usare il file di schema TrustFrameworkPolicy per convalidare i file dei criteri di Azure AD B2C.

Condividi tramite