Creación y lectura de una cuenta de 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 ser adquirido por nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.

Azure Active Directory B2C (Azure AD B2C) se basa en el identificador de Entra de Microsoft y, por tanto, usa el almacenamiento de identificadores de Microsoft Entra para almacenar cuentas de usuario. El perfil de usuario de directorio de Azure AD B2C incluye un conjunto integrado de atributos, como el nombre, el apellido, la ciudad, el código postal y el número de teléfono, pero puede ampliar el perfil de usuario con sus propios atributos personalizados sin necesidad de un almacén de datos externo.

La directiva personalizada puede conectarse al almacenamiento de Microsoft Entra ID mediante el perfil técnico de Microsoft Entra ID para almacenar, actualizar o eliminar información de usuario. En este artículo, aprenderá cómo configurar un conjunto de perfiles técnicos de Microsoft Entra ID para almacenar y leer una cuenta de usuario antes de devolver un JWT.

Información general sobre el escenario

En el artículo Llamar a una API REST mediante una directiva personalizada de Azure Active Directory B2C, recopilamos información del usuario, validamos los datos, llamamos a una API REST y, por último, devolvimos un JWT sin almacenar una cuenta de usuario. Debemos almacenar la información del usuario para que no pierdamos la información una vez finalizada la ejecución de la directiva. Esta vez, una vez que recopilamos la información del usuario y la validamos, es necesario almacenar la información de usuario en el almacenamiento de Azure AD B2C y, a continuación, leer antes de devolver el JWT. El proceso completo se muestra en el diagrama siguiente.

Diagrama de flujo de creación de una cuenta de usuario en Azure AD.

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 Llamada a una API REST mediante la directiva personalizada de Azure Active Directory 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

Debe declarar dos reclamaciones más, userPrincipalName y passwordPolicies:

En el archivo ContosoCustomPolicy.XML, busque el elemento ClaimsSchema y declare las reclamaciones userPrincipalName y passwordPolicies mediante el siguiente código:

    <ClaimType Id="userPrincipalName">
        <DisplayName>UserPrincipalName</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
    </ClaimType>
    <ClaimType Id="passwordPolicies">
        <DisplayName>Password Policies</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
    </ClaimType>

Obtenga más información sobre los usos de las userPrincipalName y passwordPolicies en el artículo Atributos de perfil de usuario.

Paso 2: Creación de perfiles técnicos de Id. de Entra de Microsoft

Debe configurar dos perfiles técnicos de Microsoft Entra ID. Un perfil técnico escribe los detalles del usuario en el almacenamiento de Microsoft Entra ID y el otro lee una cuenta de usuario del mismo almacenamiento.

En el ContosoCustomPolicy.XML archivo, busque el elemento ClaimsProviders y agregue un nuevo proveedor de notificaciones mediante el código siguiente. Este proveedor de notificaciones contiene los perfiles técnicos de Microsoft Entra ID:
```
    <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            
        </TechnicalProfiles>
    </ClaimsProvider>
```

En el proveedor de declaraciones que acaba de crear, agregue un perfil técnico de Microsoft Entra ID usando el siguiente código:

    <TechnicalProfile Id="AAD-UserWrite">
        <DisplayName>Write user information to AAD</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Write</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
            <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
            <PersistedClaim ClaimTypeReferenceId="displayName" />
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
            <PersistedClaim ClaimTypeReferenceId="password"/>
            <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        </OutputClaims>
    </TechnicalProfile>

Hemos agregado un nuevo perfil técnico de Microsoft Entra ID, AAD-UserWrite. Debe tomar nota de las siguientes partes importantes del perfil técnico:

Operación: la operación especifica la acción que se va a realizar, en este caso, Escribir. Obtenga más información sobre otras operaciones en un proveedor tecnológico de identificación de Microsoft Entra.
Notificaciones persistentes: el elemento PersistedClaims contiene todos los valores que se deben almacenar en el almacenamiento de identificadores de Entra de Microsoft.
InputClaims: el elemento InputClaims contiene una notificación, que se usa para buscar una cuenta en el directorio o crear una nueva. Debe haber exactamente un elemento de notificaciones de entrada en la colección de notificaciones de entrada para todos los perfiles técnicos de Microsoft Entra ID. Este perfil técnico usa la notificación de correo electrónico como identificador clave de la cuenta de usuario. Obtenga más información sobre otros identificadores de clave que puede usar de forma única para identificar una cuenta de usuario.

En el ContosoCustomPolicy.XML archivo, busque el AAD-UserWrite perfil técnico y agregue un nuevo perfil técnico después de él mediante el código siguiente:

    <TechnicalProfile Id="AAD-UserRead">
        <DisplayName>Read user from Azure AD storage</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName"/>
            <OutputClaim ClaimTypeReferenceId="surname"/>
            <OutputClaim ClaimTypeReferenceId="displayName"/>
        </OutputClaims>
    </TechnicalProfile>

Hemos agregado un nuevo perfil técnico de Microsoft Entra ID, AAD-UserRead. Asimismo, se ha configurado este perfil técnico para realizar una operación de lectura y devolver las notificaciones objectId, userPrincipalName, givenName, surname y displayName si se encuentra una cuenta de usuario con email en la sección InputClaim.

Paso 3: Usa el perfil técnico de Microsoft Entra ID

Una vez que recopilamos los detalles del usuario mediante el UserInformationCollector perfil técnico autoafirmado, es necesario registrar una cuenta de usuario en el almacenamiento de Microsoft Entra ID mediante el AAD-UserWrite perfil técnico. Para ello, utilice el perfil técnico AAD-UserWrite como perfil técnico de validación dentro del perfil técnico autoafirmado UserInformationCollector.

En el archivo ContosoCustomPolicy.XML, busque el perfil técnico UserInformationCollector y agregue el perfil técnico AAD-UserWrite como perfil técnico de validación en la colección ValidationTechnicalProfiles. Debe agregarlo después del perfil técnico de validación CheckCompanyDomain.

Se usará el perfil técnico AAD-UserRead en los pasos de orquestación del recorrido del usuario para leer los detalles del usuario antes de emitir un token de JWT.

Paso 4: Actualización del perfil técnico ClaimGenerator

Usamos el ClaimGenerator perfil técnico para ejecutar tres transformaciones de reclamaciones, GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation y CreateMessageTransformation.

En el ContosoCustomPolicy.XML archivo, busque el ClaimGenerator perfil técnico y reemplácelo por el código siguiente:

    <TechnicalProfile Id="UserInputMessageClaimGenerator">
        <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="message" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    <TechnicalProfile Id="UserInputDisplayNameGenerator">
        <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

Hemos dividido el perfil técnico en dos perfiles técnicos independientes. El perfil técnico UserInputMessageClaimGenerator genera el mensaje enviado como notificación en el JWT. El perfil técnico UserInputDisplayNameGenerator genera la displayName afirmación. El valor de reclamación displayName debe estar disponible antes de que el perfil técnico AAD-UserWrite registre al usuario en el almacenamiento de Microsoft Entra ID. En el nuevo código, eliminamos GenerateRandomObjectIdTransformation ya que objectId es creado y devuelto por Microsoft Entra ID después de que se crea una cuenta, por lo que no es necesario generarlo dentro de la política.

En el archivo ContosoCustomPolicy.XML, localice el perfil técnico autoafirmado UserInformationCollector y luego agregue el perfil técnico UserInputDisplayNameGenerator como perfil técnico de validación. Después de hacerlo, la colección UserInformationCollector del perfil técnico ValidationTechnicalProfiles debe ser similar al código siguiente:

    <!--<TechnicalProfile Id="UserInformationCollector">-->
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                        <Value>accountType</Value>
                        <Value>work</Value>
                        <Action>SkipThisValidationTechnicalProfile</Action>
                    </Precondition>
                </Preconditions>
            </ValidationTechnicalProfile>                        
            <ValidationTechnicalProfile ReferenceId="UserInputDisplayNameGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

Tiene que agregar el perfil técnico de validación antes de AAD-UserWrite, ya que el valor de la notificación displayName tiene que estar disponible antes de que el perfil técnico AAD-UserWrite escriba el registro de usuario en el almacenamiento de Microsoft Entra ID.

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

Localice su HelloWorldJourney ruta del usuario y reemplace todos los pasos de orquestación con 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="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

En el paso 4de orquestación , ejecutamos el AAD-UserRead perfil técnico para leer los detalles del usuario (que se incluirán en el JWT) de la cuenta de usuario creada.

Como no se almacena la notificación message, en el paso de orquestación 5, se ejecuta UserInputMessageClaimGenerator para generar la notificación message para agregarla en el token de JWT.

Paso 6: Carga de la directiva

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 7: Directiva de prueba

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

Una vez finalizada la ejecución de la directiva y reciba el token de identificador, compruebe que se ha creado el registro de usuario:

Inicie sesión en Azure Portal.
Si tiene acceso a varios inquilinos, seleccione el icono Configuración en el menú superior para cambiar a su inquilino de Azure AD B2C desde el menú Directorios y suscripciones.
En Servicios de Azure, seleccione Azure AD B2C. O bien, use el cuadro de búsqueda para buscar y seleccionar Azure AD B2C.
En Administrar, seleccione Usuarios.
Busque la cuenta de usuario que acaba de crear y selecciónela. El perfil de cuenta tiene un aspecto similar a la captura de pantalla siguiente:

En nuestro AAD-UserWrite perfil técnico de Id. de Entra de Microsoft, especificamos que si el usuario ya existe, generamos un mensaje de error.

Vuelve a probar tu política personalizada usando la misma dirección de correo electrónico. En lugar de que la directiva se ejecute completamente para emitir un token de ID, debería ver un mensaje de error parecido al de la siguiente captura de pantalla.

Recorte de pantalla del error ya que ya existe la cuenta.

Nota:

El valor de la notificación de contraseña es un fragmento de información muy importante, por lo que debe tener mucho cuidado al usarlo en la directiva personalizada. Por un motivo similar, Azure AD B2C trata el valor de la declaración de contraseña como un valor especial. Al recopilar el valor de reclamación de contraseña en el perfil técnico autoafirmado, ese valor solo está disponible dentro del mismo perfil técnico o dentro de perfiles técnicos de validación referenciados por ese mismo perfil técnico autoafirmado. Una vez completada la ejecución de ese perfil técnico autoafirmado y se mueve a otro perfil técnico, se pierde el valor.

Comprobación de la dirección de correo electrónico del usuario

Se recomienda comprobar el correo electrónico de un usuario antes de usarlo para crear una cuenta de usuario. Al comprobar las direcciones de correo electrónico, asegúrese de que los usuarios reales crean las cuentas. También ayudará a los usuarios a asegurarse de que usan sus direcciones de correo electrónico correctas para crear una cuenta.

La directiva personalizada de Azure AD B2C proporciona una manera de comprobar la dirección de correo electrónico mediante el control de visualización de verificación. Envía un código de verificación al correo electrónico. Una vez enviado el código, el usuario lee el mensaje, escribe el código de verificación en el control proporcionado por el control de visualización y selecciona el botón Comprobar código .

Un control de visualización es un elemento de interfaz de usuario que tiene una funcionalidad especial e interactúa con el servicio back-end de Azure Active Directory B2C (Azure AD B2C). Permite al usuario realizar acciones en la página que invocan un perfil técnico de validación en el back-end. Los controles de visualización se muestran en la página y se hace referencia a ellos mediante un perfil técnico de aserción automática.

Para agregar la comprobación de correo electrónico mediante un control de visualización, siga estos pasos:

Declaración de reclamación

Tiene que declarar una notificación que se usará para guardar el código de verificación.

Para declarar la reclamación, en el archivo ContosoCustomPolicy.XML, busque el elemento ClaimsSchema y declare la reclamación verificationCode mediante el código siguiente:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

Configura un perfil técnico para el envío y verificación del código

Azure AD B2C usa el perfil técnico SSPR de Microsoft Entra ID para comprobar una dirección de correo electrónico. Este perfil técnico puede generar y enviar un código a una dirección de correo electrónico o comprobar el código en función de cómo lo configure.

En el ContosoCustomPolicy.XML archivo, busque el ClaimsProviders elemento y agregue el proveedor de notificaciones mediante el código siguiente:

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

Hemos configurado dos perfiles técnicos AadSspr-SendCode y AadSspr-VerifyCode. AadSspr-SendCode genera y envía un código a la dirección de correo electrónico especificada en la InputClaims sección, mientras AadSspr-VerifyCode que comprueba el código. Especifique la acción que desea realizar en los metadatos del perfil técnico.

Configuración de un control de visualización

Debe configurar un control de visualización de verificación de correo electrónico para poder comprobar el correo electrónico de los usuarios. El control de visualización de la comprobación de correo electrónico que configure reemplazará la notificación de visualización de correo electrónico que use para recopilar el correo electrónico del usuario.

Para configurar un control de visualización, siga estos pasos:

En el ContosoCustomPolicy.XML archivo, busque la BuildingBlocks sección y agregue un control de presentación como elemento secundario mediante el código siguiente:

    <!--<BuildingBlocks>-->
        ....
        <DisplayControls>
            <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
              <DisplayClaims>
                <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
              </DisplayClaims>
              <OutputClaims></OutputClaims>
              <Actions>
                <Action Id="SendCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                  </ValidationClaimsExchange>
                </Action>
                <Action Id="VerifyCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                  </ValidationClaimsExchange>
                </Action>
              </Actions>
            </DisplayControl>
        </DisplayControls> 
    <!--</BuildingBlocks>-->

Hemos definido un control de visualización, emailVerificationControl. Tome nota de las siguientes partes importantes:

DisplayClaims - Al igual que en un perfil técnico autoafirmado, esta sección especifica una colección de declaraciones que se van a recopilar del usuario dentro del control de visualización.
Acciones : especifica el orden de las acciones que va a realizar el control de visualización. Cada acción hace referencia a un perfil técnico responsable de realizar las acciones. Por ejemplo, SendCode hace referencia al AadSspr-SendCode perfil técnico, que genera y envía un código a una dirección de correo electrónico.

En el archivo ContosoCustomPolicy.XML, busque el perfil técnico autoafirmado UserInformationCollector y reemplace la notificación de visualización de correo electrónico para mostrar el control de pantalla emailVerificationControl:

De:
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
A:
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
Use el procedimiento del paso 6 y el paso 7 para cargar el archivo de directiva y probarlo. Esta vez, debe comprobar la dirección de correo electrónico antes de crear una cuenta de usuario.

Actualizar cuenta de usuario mediante el perfil técnico de Microsoft Entra ID

Puede configurar un perfil técnico de Id. de Entra de Microsoft para actualizar una cuenta de usuario en lugar de intentar crear una nueva. Para ello, establezca el perfil técnico de Entra ID de Microsoft para generar un error mediante el siguiente código si la cuenta de usuario especificada no existe aún en la colección de metadatos. Además, quite la entrada de metadatos Key="UserMessageIfClaimsPrincipalAlreadyExists. La operación debe establecerse en Escritura:

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>

Uso de atributos personalizados

En este artículo, ha aprendido a almacenar los detalles del usuario mediante atributos de perfil de usuario integrados. Sin embargo, a menudo debe crear sus propios atributos personalizados para administrar su escenario específico. Para ello, siga las instrucciones del artículo Definición de atributos personalizados en Azure Active Directory B2C .

Aprenda a configurar un flujo de registro e inicio de sesión para una cuenta local mediante la directiva personalizada de Azure Active Directory B2C.
Obtenga información sobre cómo definir atributos personalizados en la directiva personalizada.
Obtenga información sobre cómo agregar la expiración de contraseña a la directiva personalizada.
Obtenga más información sobre el perfil técnico de Id. de Entra de Microsoft.