Creación de bifurcaciones en el recorrido del usuario mediante la directiva personalizada de Azure Active Directory B2C

2025-05-06

Importante

A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para la compra por parte de nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.

Los distintos usuarios de la misma aplicación pueden seguir diferentes recorridos de usuario en función de los valores de los datos de una directiva personalizada. Las directivas personalizadas de Azure Active Directory B2C (Azure AD B2C) le permiten habilitar o deshabilitar condicionalmente un perfil técnico para lograr esta funcionalidad. Por ejemplo, en Validar entradas de usuario mediante la directiva personalizada de Azure AD B2C, utilizamos un Precondition para determinar si debemos ejecutar un perfil técnico de validación basado en el valor de la reclamación accountType.

Un perfil técnico también proporciona un EnabledForUserJourneys elemento que le permite especificar si se debe ejecutar o no un perfil técnico. El EnabledForUserJourneys elemento contiene uno de los cinco valores, incluido OnClaimsExistence, que se usa para especificar que un perfil técnico solo se debe ejecutar cuando existe una determinada reclamación especificada en los perfiles técnicos. Obtenga más información sobre el elemento EnabledForUserJourneys del perfil técnico.

Información general sobre el escenario

En el artículo Validación de entradas de usuario mediante el uso de la directiva personalizada de Azure AD B2C , un usuario introduce sus detalles en una sola pantalla. En este artículo, un usuario debe seleccionar primero su tipo de cuenta, Cuenta de empleado de Contoso o Cuenta personal. Un usuario que seleccione Cuenta de empleado de Contoso puede continuar para proporcionar más detalles. Sin embargo, un usuario que selecciona Cuenta personal debe proporcionar un código de acceso de invitación válido antes de poder continuar para proporcionar más detalles. Por lo tanto, los usuarios que usan el tipo de cuenta personal ven una interfaz de usuario adicional para completar su recorrido.

Diagrama de flujo de bifurcación en el recorrido del usuario.

En este artículo, aprenderá a usar el elemento EnabledForUserJourneys dentro de un perfil técnico para crear diferentes experiencias de usuario basadas en un valor de reclamación.

Prerrequisitos

Si aún no tiene una, cree un inquilino de Azure AD B2C que esté vinculado a su suscripción de Azure.
Registre una aplicación web.
Debe tener Visual Studio Code (VS Code) instalado en el equipo.
Complete los pasos descritos en Validación de entradas de usuario mediante la directiva personalizada de Azure AD B2C. Este artículo forma parte de la Serie de guías paso a paso para crear y ejecutar sus propias directivas personalizadas.

Nota:

Este artículo forma parte de la serie de guías paso a paso Crear y ejecutar sus propias directivas personalizadas en Azure Active Directory B2C. Se recomienda iniciar esta serie desde el primer artículo.

Paso 1: Declarar reclamaciones

Un usuario que selecciona Cuenta personal debe proporcionar un código de acceso válido. Por lo tanto, necesitamos una notificación para contener este valor:

En VS Code, abra el ContosoCustomPolicy.XML archivo.

En la sección ClaimsSchema, declare las reclamaciones accessCode e isValidAccessCode utilizando el siguiente código:

    <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>

Paso 2: Definición de transformaciones de reclamaciones

Busque el elemento ClaimsTransformations y agregue las siguientes transformaciones de afirmaciones:

    <!---<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>-->

Hemos definido dos transformaciones de notificaciones, CheckIfIsValidAccessCode y ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode usa el método de transformación CompareClaimToValue para comparar la entrada de código de acceso por parte del usuario con un valor estático 88888 (vamos a usar este valor para las pruebas) y asigna true o false a la notificación isValidAccessCode . ThrowIfIsNotValidAccessCode comprueba si dos valores booleanos de dos notificaciones son iguales y produce una excepción si no lo son.

Paso 3: Configurar o actualizar perfiles técnicos

Ahora necesita dos nuevos perfiles técnicos autoafirmados, uno para recopilar el tipo de cuenta y el otro para recopilar el código de acceso del usuario. También necesita un nuevo perfil técnico de tipo de transformación de notificaciones para validar el código de acceso del usuario mediante la ejecución de las transformaciones de notificaciones que definió en el paso 2. Ahora que recopilamos el tipo de cuenta en un perfil técnico autoafirmado diferente, es necesario actualizar el UserInformationCollector perfil técnico autoafirmado para evitar que recopile el tipo de cuenta.

Busque el ClaimsProviders elemento y agregue un nuevo proveedor de notificaciones mediante el código siguiente:

    <!--<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>-->

Hemos configurado dos perfiles técnicos, AccessCodeInputCollector y CheckAccessCodeViaClaimsTransformationChecker. Llamamos al perfil técnico CheckAccessCodeViaClaimsTransformationChecker como un perfil técnico de validación dentro del perfil técnico AccessCodeInputCollector. El propio CheckAccessCodeViaClaimsTransformationChecker es de tipo Claims Transformation technical Profile, que ejecuta las Claims Transformations que definimos en el paso 2.

AccessCodeInputCollector es un perfil técnico de Self-Asserted que se usa para recopilar un código de acceso del usuario. Incluye el elemento EnabledForUserJourneys que se establece en OnClaimsExistence. Su Metadata elemento incluye una afirmación (accountType) y su valor (personal), lo que activa este perfil técnico.

Busque el ClaimsProviders elemento y agregue un nuevo proveedor de notificaciones mediante el código siguiente:

    <!--<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>-->

Hemos configurado un perfil técnico autoafirmado, , AccountTypeInputCollectorque recopila el tipo de cuenta del usuario. Es el valor de los tipos de cuenta que determina si se debe activar el perfil técnico autoafirmado AccessCodeInputCollector.

Para evitar que el UserInformationCollector perfil técnico autoafirmado recopile el tipo de cuenta, busque el UserInformationCollector perfil técnico autoafirmado y, a continuación, haga lo siguiente:
1. Quite la notificación de presentación accountType, <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> de la DisplayClaims colección.
2. Quite la notificación de salida accountType, <OutputClaim ClaimTypeReferenceId="accountType"/> de la OutputClaims colección.

Paso 4: Actualización de los pasos de orquestación del recorrido del usuario

Ahora que ha configurado los perfiles técnicos, debe actualizar los pasos de orquestación del recorrido del usuario:

Busque el recorrido del usuario HelloWorldJourney y agregue reemplazar todos los pasos de orquestación por el código siguiente:

    <!--<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>-->

Los pasos de orquestación muestran que llamamos al perfil técnico en el orden que muestra el atributo Order de los pasos de orquestación. Sin embargo, el AccessCodeInputCollector perfil técnico se activa si el usuario selecciona el tipo de cuenta personal .

Paso 5: Carga del archivo de directiva personalizado

Siga los pasos descritos en Cargar archivo de directiva personalizado para cargar el archivo de directiva. Si va a cargar un archivo con el mismo nombre que el que ya está en el portal, asegúrese de seleccionar Sobrescribir la directiva personalizada si ya existe.

Paso 6: Probar la directiva personalizada

Siga los pasos descritos en Probar la directiva personalizada para probar la directiva personalizada:

En la primera pantalla, en Tipo de cuenta, seleccione Cuenta personal.
En Código de acceso, escriba 88888 y, a continuación, seleccione Continuar.
Escriba el resto de los detalles según sea necesario y, a continuación, seleccione Continuar. Una vez finalizada la ejecución de la directiva, se le redirigirá a https://jwt.msy verá un JWT descodificado.
Repita el paso 5, pero esta vez, seleccione Tipo de cuenta, seleccione Cuenta de empleado de Contoso y siga las indicaciones.

En el paso 3, habilitamos o deshabilitamos el perfil técnico mediante el EnabledForUserJourneys elemento . Como alternativa, puede usar Preconditions dentro de los pasos de orquestación del recorrido del usuario para ejecutar u omitir un paso de orquestación, como aprenderemos más adelante en esta serie.

A continuación, aprenda: