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

Artículo
01/11/2024

Los distintos usuarios de la misma aplicación pueden seguir recorridos de usuario diferentes 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 Validación de entradas de usuario mediante la directiva personalizada de Azure AD B2C, usamos un Precondition para determinar si debemos ejecutar o no un perfil técnico de validación basado en el valor de la notificación accountType .

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

Información general del escenario

En el artículo Validación de entradas de usuario mediante 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 para 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.

A flowchart of branching in user journey.

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 notificación.

Requisitos previos

Si todavía no tiene uno, cree un inquilino de Azure AD B2C vinculado a la suscripción de Azure.
Registre una aplicación web y habilite la concesión implícita del token de identificador. Para el URI de redirección, use https://jwt.ms.
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 Creación y ejecución sus propias directivas personalizadas.

Nota

Este artículo forma parte de la Serie de guías paso a paso para crear y ejecutar sus propias directivas personalizadas en Azure Active Directory B2C. Le recomendamos que empiece esta serie por el primer artículo.

Paso 1: declarar notificaciones

Un usuario que seleccione 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 archivo ContosoCustomPolicy.XML.

En la sección ClaimsSchema, declare las notificaciones accessCode y isValidAccessCode mediante el código siguiente:

    <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 las transformaciones de notificaciones

Busque el elemento ClaimsTransformations y agregue la siguiente transformación de notificaciones:

    <!---<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 perfil técnico autoafirmado UserInformationCollector para evitar que recopile el tipo de cuenta.

Busque el elemento ClaimsProviders 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 desde el perfil técnico AccessCodeInputCollector. El propio CheckAccessCodeViaClaimsTransformationChecker es de tipo Perfil técnico de transformación de notificaciones, que ejecuta las transformaciones de notificaciones que definimos en el paso 2.

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

Busque el elemento ClaimsProviders 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, AccountTypeInputCollector, que 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 perfil técnico autoafirmado UserInformationCollector recopile el tipo de cuenta, busque el perfil técnico autoafirmado UserInformationCollector 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: actualizar 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 perfil técnico AccessCodeInputCollector se activa si el usuario selecciona el tipo de cuenta 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: prueba de 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.ms y verá un token JWT descodificado.
Repita el paso 5, pero esta vez, seleccione Tipo de cuenta, seleccione Cuenta de empleado de Contoso y siga las indicaciones.

Pasos siguientes

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

A continuación, aprenda:

Share via