Creación y lectura de una cuenta de usuario mediante la directiva personalizada de Azure Active Directory B2C

Artículo
01/11/2024

Azure Active Directory B2C (Azure AD B2C) se basa en Microsoft Entra ID, por lo que usa el almacenamiento de Microsoft Entra ID para almacenar cuentas de usuario. El perfil de usuario del 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 usar 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á a configurar un conjunto de perfiles técnicos de Microsoft Entra ID para almacenar y leer una cuenta de usuario antes de que se devuelva un token de JWT.

Información general del escenario

En el artículo Llamada a una API de REST mediante la directiva personalizada de Azure Active Directory B2C, se recopila información del usuario, se validan los datos, se llama a una API de REST y, por último, se devuelve un JWT sin almacenar una cuenta de usuario. Es necesario almacenar la información del usuario para no perder la información una vez finalizada la ejecución de la directiva. En este caso, una vez recopilada y validada la información del usuario, esta tiene que guardarse en el almacenamiento de Azure AD B2C y, a continuación, hay que leerla antes de devolver el token de JWT. Este proceso se muestra al completo en el diagrama siguiente.

A flowchart of creating a user account in Azure AD.

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 que se indican en Llamada a una API de 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 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: Declaración de notificaciones

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

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

    <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 notificaciones userPrincipalName y passwordPolicies en el artículo Atributos de perfil de usuario.

Paso 2: Crear perfiles técnicos de Microsoft Entra ID

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 almacenamiento de Microsoft Entra ID.

En el archivo ContosoCustomPolicy.XML, 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 notificaciones que acaba de crear, agregue un perfil técnico de Microsoft Entra ID mediante el código siguiente:

    <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, Write. Obtenga más información sobre otras operaciones en un proveedor técnico de Microsoft Entra ID.
Notificaciones persistentes: el elemento PersistedClaims contiene todos los valores que se deben almacenar en el almacenamiento de Microsoft Entra ID.
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 clave que puede usar de forma única para identificar una cuenta de usuario.

En el archivo ContosoCustomPolicy.XML, busque el perfil técnico AAD-UserWrite y agregue un nuevo perfil técnico después del primero, con 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: Usar el perfil técnico de Microsoft Entra ID

Después de recopilar los detalles del usuario mediante el perfil técnico autoafirmado UserInformationCollector, es necesario escribir una cuenta de usuario en el almacenamiento de Microsoft Entra ID mediante el perfil técnico AAD-UserWrite. Para ello, use el perfil técnico AAD-UserWrite como perfil técnico de validación en el 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.

A continuación, tendrá que 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

Tendrá que usar el perfil técnico ClaimGenerator para ejecutar tres transformaciones de notificaciones: GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation y CreateMessageTransformation.

En el archivo ContosoCustomPolicy.XML, busque el perfil técnico ClaimGenerator 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 que se envía como notificación en el token de JWT. Por otro lado, el perfil técnico UserInputDisplayNameGenerator genera la notificación displayName. El valor de notificación displayName debe estar disponible antes de que el perfil técnico AAD-UserWrite escriba el registro de usuario en el almacenamiento de Microsoft Entra ID. En el nuevo código, se quita GenerateRandomObjectIdTransformation; a continuación, Microsoft Entra crea y devuelve objectId después de crear una cuenta, por lo que no es necesario generarla en la directiva.

En el archivo ContosoCustomPolicy.XML, busque el perfil técnico autoafirmado UserInformationCollector y 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="DisplayNameClaimGenerator"/>
            <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

Busque el recorrido del usuario HelloWorldJourney y reemplace 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="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 de orquestación 4, ejecute el perfil técnico AAD-UserRead para leer los detalles del usuario (que se incluirán en el token de JWT) de la cuenta de usuario que creó.

Puesto que 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 Carga del 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: Prueba de la directiva

Siga los pasos descritos en Prueba de la directiva personalizada para probar la directiva personalizada.

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

Inicie sesión en Azure Portal con permisos de administrador de roles con privilegios o de administrador global.
Si tiene acceso a varios inquilinos, seleccione el icono Configuración en el menú superior para cambiar al 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 es similar a la captura de pantalla siguiente:

En el perfil técnico AAD-UserWrite de Microsoft Entra ID, especifique si el usuario ya existe y se genera un mensaje de error.

Vuelva a probar la directiva personalizada con la misma dirección de correo electrónico. En lugar de ver que la directiva se ejecuta hasta el final para emitir un token de identificador, debería ver un mensaje de error similar a la captura de pantalla que tiene a continuación.

A screenshot of error as account already exists.

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 notificación de contraseña como un valor especial. Cuando recopila el valor de notificación de contraseña en el perfil técnico autoafirmado, ese valor solo está disponible dentro del mismo perfil técnico o en perfiles técnicos de validación a los que hace referencia ese mismo perfil técnico autoafirmado. Una vez completada la ejecución de ese perfil técnico autoafirmado y accede 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 son usuarios reales quienes crean las cuentas. También puede ayudar a los usuarios a asegurarse de que usan las direcciones de correo electrónico correctas para crear una cuenta.

La directiva personalizada de Azure AD B2C le proporciona una manera de comprobar la dirección de correo electrónico mediante el control de visualización de verificación. A continuación, envíe un código de verificación al correo electrónico. Una vez enviado el código, el usuario puede leer el mensaje, escribir el código de verificación en el control proporcionado por el control de pantalla y seleccionar el botón Comprobar código.

Un control de visualización es un elemento de la interfaz de usuario que tiene una funcionalidad especial e interactúa con el servicio en el entorno 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 entorno 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 notificaciones

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

Para declarar la notificación, vaya al archivo ContosoCustomPolicy.XML, busque el elemento ClaimsSchema y declare la notificació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>-->

Configuración de un perfil técnico de envío y comprobación de códigos

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 archivo ContosoCustomPolicy.XML, busque el elemento ClaimsProviders 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>

Verá que se han 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 sección InputClaims, mientras que AadSspr-VerifyCode comprueba el código. Especifique la acción que quiera realizar en los metadatos del perfil técnico.

Configuración de un control de pantalla

Debe configurar un control de pantalla para la comprobación de correos electrónicos y así poder comprobar los correos electrónicos 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 pantalla, siga estos pasos:

En el archivo ContosoCustomPolicy.XML, busque la sección BuildingBlocks y agregue un control de pantalla 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>-->

Se ha declarado el control de pantalla emailVerificationControl. Tenga en cuenta los elementos siguientes, ya que son importantes:

DisplayClaims: igual que sucede con un perfil técnico autoafirmado, esta sección especifica una colección de notificaciones que se recopilarán del usuario en el control de pantalla.
Acciones: este valor especifica el orden de las acciones que debe 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 perfil técnico AadSspr-SendCode, 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 y ejecutar la directiva. Esta vez, debe comprobar la dirección de correo electrónico antes de crear una cuenta de usuario.

Actualización de la cuenta de usuario mediante el perfil técnico de Microsoft Entra ID

Puede configurar un perfil técnico de Microsoft Entra ID para actualizar una cuenta de usuario en lugar de intentar crear una nueva. Para ello, establezca el perfil técnico de Microsoft Entra ID para crear un error si la cuenta de usuario especificada aún no existe en la colección Metadata mediante el código siguiente. La operación debe establecerse en Escritura:

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</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 será necesario que cree sus propios atributos para administrar un escenario concreto. Para ello, siga las instrucciones del artículo Definición de atributos personalizados en Azure Active Directory B2C.

Pasos siguientes

Obtenga información sobre la Configuración de 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ñas a la directiva personalizada.
Obtenga más información sobre el perfil técnico de Microsoft Entra ID.

Compartir vía