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

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.

En el artículo Creación y lectura de una cuenta de usuario mediante la directiva personalizada de Azure Active Directory B2C , un usuario crea una cuenta de usuario, pero no inicia sesión en ella.

En este artículo, aprenderá a escribir una directiva personalizada de Azure Active Directory B2C (Azure AD B2C) que permita a un usuario crear una cuenta local de Azure AD B2C o iniciar sesión en una. Una cuenta local hace referencia a una cuenta que se crea en el inquilino de Azure AD B2C cuando un usuario se registra en la aplicación.

Información general

Azure AD B2C usa el protocolo de autenticación OpenID Connect para comprobar las credenciales de usuario. En Azure AD B2C, se envían las credenciales de usuario junto con otra información a un punto de conexión seguro, que determina si las credenciales son válidas o no. En pocas palabras, al usar la implementación de OpenID Connect de Azure AD B2C, puede subcontratar el registro, el inicio de sesión y otras experiencias de administración de identidades en las aplicaciones web a Microsoft Entra ID.

La directiva personalizada de Azure AD B2C proporciona un perfil técnico de OpenID Connect, que se usa para realizar una llamada a un punto de conexión seguro de Microsoft. Obtenga más información sobre el perfil técnico de OpenID Connect.

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 Creación y lectura de una cuenta de usuario 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: Configuración del perfil técnico de OpenID Connect

Para configurar un perfil técnico de OpenID Connect, debe realizar tres pasos:

• Declarar más notificaciones.
• Registre aplicaciones en Azure Portal.
• Por último, configure el propio perfil técnico de OpenID Connect.

Paso 1.1: Declarar más reclamaciones

En el ContosoCustomPolicy.XML archivo, busque la sección ClaimsSchema y luego agregue más reclamaciones mediante el siguiente código:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="grant_type">
            <DisplayName>grant_type</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="scope">
            <DisplayName>scope</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="nca">
            <DisplayName>nca</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="client_id">
            <DisplayName>client_id</DisplayName>
            <DataType>string</DataType>
            <AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
            <UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="resource_id">
            <DisplayName>resource_id</DisplayName>
            <DataType>string</DataType>
            <AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
            <UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
        </ClaimType>
    <!--</ClaimsSchema>-->

Paso 1.2: Registro de aplicaciones de Identity Experience Framework

Azure AD B2C requiere que registre dos aplicaciones que usa para registrarse e iniciar sesión de usuarios con cuentas locales: IdentityExperienceFramework, una API web y ProxyIdentityExperienceFramework, una aplicación nativa con permiso delegado para la aplicación IdentityExperienceFramework.

Si aún no lo ha hecho, registre las siguientes aplicaciones. Para automatizar el tutorial siguiente, visite la aplicación de instalación de IEF y siga las instrucciones:

1. Siga los pasos descritos en Registro de la aplicación IdentityExperienceFramework para registrar la aplicación Identity Experience Framework. Copie el identificador de aplicación (cliente),appID, para el registro de la aplicación Identity Experience Framework para usarlo en el paso siguiente.

2. Siga los pasos descritos en Registro de la aplicación ProxyIdentityExperienceFramework para registrar la aplicación Proxy Identity Experience Framework. Copie el identificador de aplicación (cliente),proxyAppID, para el registro de la aplicación proxy Identity Experience Framework para usarlo en el paso siguiente.

Paso 1.3: Configuración del perfil técnico de OpenID Connect

En el ContosoCustomPolicy.XML archivo, busque la sección ClaimsProviders y agregue un elemento Proveedor de notificaciones que contenga el perfil técnico de OpenID Connect mediante el código siguiente:

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <DisplayName>OpenID Connect Technical Profiles</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="SignInUser">
                    <DisplayName>Sign in with Local Account</DisplayName>
                    <Protocol Name="OpenIdConnect" />
                    <Metadata>
                        <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We didn't find this account</Item>
                        <Item Key="UserMessageIfInvalidPassword">Your password or username is incorrect</Item>
                        <Item Key="UserMessageIfOldPasswordUsed">You've used an old password.</Item>
                        <Item Key="ProviderName">https://sts.windows.net/</Item>
                        <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
                        <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
                        <Item Key="response_types">id_token</Item>
                        <Item Key="response_mode">query</Item>
                        <Item Key="scope">email openid</Item>
                        <!-- Policy Engine Clients -->
                        <Item Key="UsePolicyInRedirectUri">false</Item>
                        <Item Key="HttpBinding">POST</Item>
                        <Item Key="client_id">proxyAppID</Item>
                        <Item Key="IdTokenAudience">appID</Item>
                    </Metadata>
                    <InputClaims>
                        <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="username" Required="true" />
                        <InputClaim ClaimTypeReferenceId="password" PartnerClaimType="password" Required="true" />
                        <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
                        <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
                        <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
                        <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="proxyAppID" />
                        <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="appID" />
                    </InputClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
                    </OutputClaims>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Reemplace ambas instancias de:

• appID con el identificador de aplicación (cliente) de la aplicación Identity Experience Framework que copió en el paso 1.2.

• proxyAppID con el identificador de aplicación (cliente) de la aplicación Proxy Identity Experience Framework que copió en el paso 1.2.

Paso 2: Configuración de la interfaz de usuario de inicio de sesión

Cuando se ejecuta la directiva, el usuario debe ver una interfaz de usuario que les permita iniciar sesión. La interfaz de usuario también tiene una opción para registrarse si aún no tienen una cuenta. Para ello, debe realizar dos pasos:

• Configure un perfil técnico autoafirmado, que muestra el formulario de inicio de sesión al usuario.
• Configure la definición de contenido para la interfaz de usuario de inicio de sesión.

Paso 2.1: Configuración de un perfil técnico de la interfaz de usuario de inicio de sesión

En el archivo ContosoCustomPolicy.XML, busque el perfil técnico SignInUser y agregue un perfil técnico de SelfAsserted después de él con el código siguiente:

    <TechnicalProfile Id="UserSignInCollector">
        <DisplayName>Local Account Signin</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="setting.operatingMode">Email</Item>
            <Item Key="SignUpTarget">AccountTypeInputCollectorClaimsExchange</Item>
        </Metadata>
        <DisplayClaims>
            <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
            <DisplayClaim ClaimTypeReferenceId="password" Required="true" />
        </DisplayClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="password"  />
            <OutputClaim ClaimTypeReferenceId="objectId" />
        </OutputClaims>
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="SignInUser" />
        </ValidationTechnicalProfiles>
    </TechnicalProfile>

Hemos agregado un perfil técnico de SelfAsserted, UserSignInCollector, que muestra el formulario de inicio de sesión al usuario. Hemos configurado el perfil técnico para recopilar la dirección de correo electrónico del usuario como su nombre de inicio de sesión, tal como se indica en los setting.operatingMode metadatos. El formulario de inicio de sesión incluye un vínculo de registro, que lleva al usuario a un formulario de registro, como se indica en los SignUpTarget metadatos. Verá cómo configuramos SignUpWithLogonEmailExchangeClaimsExchange en los pasos de orquestación.

Además, hemos agregado el perfil técnico de OpenID Connect SignInUser como ValidationTechnicalProfile. Por lo tanto, el perfil técnico SignInUser se ejecuta cuando el usuario selecciona el botón Iniciar sesión (consulte la captura de pantalla del paso 5).

En el paso siguiente (paso 2.2), configuramos una definición de contenido que usaremos en este perfil técnico de SelfAsserted.

Paso 2.2: Configuración de la definición de contenido de la interfaz de inicio de sesión

En el ContosoCustomPolicy.XML archivo, busque la sección ContentDefinitions y, a continuación, inicie sesión en Definición de contenido con el código siguiente:

    <!--<ContentDefinitions>-->
        ...
            <ContentDefinition Id="SignupOrSigninContentDefinition">
                <LoadUri>~/tenant/templates/AzureBlue/unified.cshtml</LoadUri>
                <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
                <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.7</DataUri>
                <Metadata>
                    <Item Key="DisplayName">Signin and Signup</Item>
                </Metadata>
            </ContentDefinition>
    <!--</ContentDefinitions>-->

Hemos configurado una definición de contenido para nuestro perfil técnico autoafirmado, SignupOrSigninContentDefinition. Podemos especificarlo en el perfil técnico mediante el elemento de metadatos o especificarlo cuando hacemos referencia al perfil técnico en los pasos de orquestación. Anteriormente, hemos aprendido a especificar una definición de contenido directamente en el perfil técnico autoafirmado, por lo que en este artículo, aprenderemos a especificarla cuando hagamos referencia al perfil técnico en los pasos de orquestación, paso 3.

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

En el ContosoCustomPolicy.XML archivo, busque el recorrido del usuario HelloWorldJourney y reemplace toda su colección de pasos de orquestación por el código siguiente:

    <!--<OrchestrationSteps>-->
        ...
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
            </ClaimsProviderSelections>
            <ClaimsExchanges>
                <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                  <Value>accountType</Value>
                  <Value>company</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>
        
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>  
      
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>                
        
        <OrchestrationStep Order="6" Type="ClaimsExchange">
            <ClaimsExchanges>
            <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>          
        </OrchestrationStep>                
        
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    <!--</OrchestrationSteps>-->

En los pasos de orquestación del dos al cinco, hemos usado condiciones previas para determinar si se debe ejecutar el paso de orquestación. Es necesario determinar si el usuario inicia sesión o se registra.

Cuando se ejecuta la directiva personalizada:

• Paso 1 de orquestación : muestra la página de inicio de sesión para que el usuario pueda iniciar sesión o seleccionar el vínculo Registrarse ahora . Observe que especificamos la definición de contenido que usa el perfil técnico autoafirmado UserSignInCollector para mostrar el formulario de inicio de sesión.

• Paso 2 de orquestación : este paso se ejecuta si el usuario se registra (objectId no existe), por lo que se muestra el formulario de selección de tipo de cuenta invocando el perfil técnico autoafirmado AccountTypeInputCollector .

• Paso 3 de orquestación : este paso se ejecuta si el usuario se registra (objectId no existe) y el usuario no selecciona una compañía accountType. Por lo tanto, tenemos que pedir al usuario que escriba un accessCode mediante la invocación del perfil técnico autoafirmado AccessCodeInputCollector .

• Paso 4 de orquestación : este paso se ejecuta si el usuario se registra (objectId no existe), por lo que se muestra el formulario de registro invocando el perfil técnico autoafirmado UserInformationCollector .

• Paso 5 de orquestación: este paso lee la información de la cuenta de Microsoft Entra ID (invocamos AAD-UserRead el perfil técnico de Microsoft Entra ID), por lo que se ejecuta independientemente de si un usuario se registra o inicia sesión.

• Paso 6 de orquestación : este paso invoca el perfil técnico UserInputMessageClaimGenerator para ensamblar el mensaje de saludo del usuario.

• Paso 7 de orquestación - Finalmente, el paso 8 ensambla y devuelve el JWT al final de la ejecución de la política.

Paso 4: Cargar 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 5: Directiva de prueba

Siga los pasos descritos en Probar la directiva personalizada para probar la directiva personalizada. Una vez que se ejecute la directiva, verá una interfaz similar a la captura de pantalla siguiente:

Para iniciar sesión, escriba la dirección de correo electrónico y la contraseña de una cuenta existente. Si aún no tiene una cuenta, debe seleccionar el vínculo Registrarse ahora para crear una nueva cuenta de usuario.

Contenido relacionado

• Aprenda a configurar un flujo de registro e inicio de sesión con una cuenta social mediante la directiva personalizada de Azure Active Directory B2C.

• Obtenga información sobre cómo quitar el vínculo de registro para que los usuarios puedan iniciar sesión.

• Obtenga más información sobre el perfil técnico de OpenID Connect.