Configuración de un flujo de registro e inicio de sesión con una cuenta social mediante la directiva personalizada de Azure Active Directory B2C

Artigo
01/11/2024

En el artículo Configuración de un flujo de registro e inicio de sesión mediante la directiva personalizada de Azure Active Directory B2C, configuramos el flujo de inicio de sesión para una cuenta local mediante Azure Active Directory B2C (Azure AD B2C).

En este artículo, se agrega un flujo de inicio de sesión para una cuenta externa, como una cuenta social como Facebook. En este caso, Azure AD B2C permite a un usuario iniciar sesión en la aplicación con credenciales de un proveedor de identidades social externo (IdP).

En el caso de las cuentas locales, una cuenta de usuario se identifica de forma única mediante el objectIdatributo user. En el caso del IdP externo, se usa alternativeSecurityId el atributo user aunque todavía existe objectId.

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 Configuración de un flujo de registro e inicio de sesión para la cuenta local mediante la directiva personalizada de Azure Active Directory B2C. Este artículo forma parte de la Serie de guías paso a paso Cree y ejecute 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: Creación de una aplicación de Facebook

Siga los pasos descritos en Creación de una aplicación de Facebook para obtener el identificador de aplicación de Facebook y el secreto de la aplicación. Omita los requisitos previos y el restablecimiento de los pasos descritos en Configuración del registro y el inicio de sesión con una cuenta de Facebook.

Paso 2: Creación de una clave de directiva de Facebook

Siga los pasos descritos en Creación del almacén de claves de Facebook de una clave de directiva en el inquilino de Azure AD B2C. Omita los requisitos previos y el restablecimiento de los pasos descritos en Configuración del registro y el inicio de sesión con una cuenta de Facebook.

Para configurar el inicio de sesión con Facebook, debe realizar los pasos siguientes:

Declarar más notificaciones
Defina más transformaciones de notificaciones para ayudar con manipulaciones de notificaciones, como la creación de AlternativeSecurityId.
Configuración del proveedor de notificaciones de Facebook
Configure perfiles técnicos de Microsoft Entra para leer y escribir la cuenta de red social desde y en la base de datos de Microsoft Entra.
Configure un perfil técnico autoafirmado (para aceptar entradas adicionales del usuario o actualizar los detalles del usuario) y su definición de contenido.

Paso 3.1: Declarar más notificaciones

En el archivo ContosoCustomPolicy.XML, busque la sección ClaimsSchema y, a continuación, declare más notificaciones mediante el código siguiente:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="issuerUserId">
            <DisplayName>Username</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
            <UserInputType>TextBox</UserInputType>
            <Restriction>
                <Pattern RegularExpression="^[a-zA-Z0-9]+[a-zA-Z0-9_-]*$" HelpText="The username you provided is not valid. It must begin with an alphabet or number and can contain alphabets, numbers and the following symbols: _ -" />
            </Restriction>
        </ClaimType>
        
        <ClaimType Id="identityProvider">
            <DisplayName>Identity Provider</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
        </ClaimType>
        
        <ClaimType Id="authenticationSource">
            <DisplayName>AuthenticationSource</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Specifies whether the user was authenticated at Social IDP or local account.</UserHelpText>
        </ClaimType>  
        
        <ClaimType Id="upnUserName">
            <DisplayName>UPN User Name</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>The user name for creating user principal name.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="alternativeSecurityId">
            <DisplayName>AlternativeSecurityId</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
        </ClaimType>
        
        <ClaimType Id="mailNickName">
            <DisplayName>MailNickName</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Your mail nick name as stored in the Azure Active Directory.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="newUser">
            <DisplayName>User is new or not</DisplayName>
            <DataType>boolean</DataType>
            <UserHelpText/>
        </ClaimType>
    <!--</ClaimsSchema>-->

Paso 3.2: Definir las transformaciones de notificaciones

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

   <!--<ClaimsTransformations>-->
       ...
       <ClaimsTransformation Id="CreateRandomUPNUserName" TransformationMethod="CreateRandomString">
           <InputParameters>
               <InputParameter Id="randomGeneratorType" DataType="string" Value="GUID" />
           </InputParameters>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="outputClaim" />
           </OutputClaims>
       </ClaimsTransformation>
   
       <ClaimsTransformation Id="CreateAlternativeSecurityId" TransformationMethod="CreateAlternativeSecurityId">
           <InputClaims>
               <InputClaim ClaimTypeReferenceId="issuerUserId" TransformationClaimType="key" />
               <InputClaim ClaimTypeReferenceId="identityProvider" TransformationClaimType="identityProvider" />
           </InputClaims>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="alternativeSecurityId" TransformationClaimType="alternativeSecurityId" />
           </OutputClaims>
       </ClaimsTransformation>
       
       <ClaimsTransformation Id="CreateUserPrincipalName" TransformationMethod="FormatStringClaim">
           <InputClaims>
               <InputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="inputClaim" />
           </InputClaims>
           <InputParameters>
               <InputParameter Id="stringFormat" DataType="string" Value="cpim_{0}@{RelyingPartyTenantId}" />
           </InputParameters>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="userPrincipalName" TransformationClaimType="outputClaim" />
           </OutputClaims>
       </ClaimsTransformation>
   <!--</ClaimsTransformations>-->

Hemos definido tres transformaciones de notificaciones, que usamos para generar valores para las notificaciones alternativeSecurityId y userPrincipalName. Estas ClaimsTransformations se invocan en el perfil técnico de OAuth2 en el paso 3.3.

Paso 3.3: Configurar el proveedor de notificaciones de Facebook

Para permitir que los usuarios inicien sesión con una cuenta de Facebook, deberá definir la cuenta como el proveedor de notificaciones con el que Azure AD B2C pueda comunicarse mediante un punto de conexión. Puede definir una cuenta de Facebook como proveedor de notificaciones.

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

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <!-- The following Domain element allows this profile to be used if the request comes with domain_hint 
                    query string parameter, e.g. domain_hint=facebook.com  -->
            <Domain>facebook.com</Domain>
            <DisplayName>Facebook</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="Facebook-OAUTH">
                <!-- The text in the following DisplayName element is shown to the user on the claims provider 
                        selection screen. -->
                <DisplayName>Facebook</DisplayName>
                <Protocol Name="OAuth2" />
                <Metadata>
                    <Item Key="ProviderName">facebook</Item>
                    <Item Key="authorization_endpoint">https://www.facebook.com/dialog/oauth</Item>
                    <Item Key="AccessTokenEndpoint">https://graph.facebook.com/oauth/access_token</Item>
                    <Item Key="HttpBinding">GET</Item>
                    <Item Key="UsePolicyInRedirectUri">0</Item>                
                    <Item Key="client_id">facebook-app-id</Item>
                    <Item Key="scope">email public_profile</Item>
                    <Item Key="ClaimsEndpoint">https://graph.facebook.com/me?fields=id,first_name,last_name,name,email</Item>
                    <Item Key="AccessTokenResponseFormat">json</Item>
                </Metadata>
                <CryptographicKeys>
                    <Key Id="client_secret" StorageReferenceId="facebook-policy-key" />
                </CryptographicKeys>
                <InputClaims />
                <OutputClaims>
                    <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
                    <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
                    <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
                    <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
                    <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
                    <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="facebook.com" AlwaysUseDefaultValue="true" />
                    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
                </OutputClaims>
                <OutputClaimsTransformations>
                    <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
                    <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
                    <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
                </OutputClaimsTransformations>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Sustituya:

facebook-app-id con el valor de Facebook appID que obtuvo en el paso 1.
facebook-policy-key con el nombre de la clave de directiva de Facebook que obtuvo en el paso 2.

Observe las transformaciones de notificaciones que definimos en el paso 3.2 de la colección OutputClaimsTransformations.

Paso 3.4: Crear perfiles técnicos de Microsoft Entra

Al igual que en el inicio de sesión con una cuenta local, debe configurar los perfiles técnicos de Microsoft Entra, que se usan para conectarse al almacenamiento de Microsoft Entra ID, para almacenar o leer una cuenta de red social de usuario.

En el archivo ContosoCustomPolicy.XML, busque el perfil técnico AAD-UserUpdate y agregue un nuevo perfil técnico usando el código siguiente:

    <TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
        <DisplayName>Azure Active Directory technical profile for handling social accounts</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>
        </Metadata>        

        <CryptographicKeys>
            <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
        </CryptographicKeys>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <!-- Required claims -->
            <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
            <PersistedClaim ClaimTypeReferenceId="userPrincipalName" />
            <PersistedClaim ClaimTypeReferenceId="mailNickName" DefaultValue="unknown" />
            <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />

            <!-- Optional claims -->
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
        </OutputClaims>

    </TechnicalProfile>

Hemos agregado un nuevo perfil técnico de Microsoft Entra AAD-UserWriteUsingAlternativeSecurityId que escribe una nueva cuenta social en Microsoft Entra ID.

Reemplace B2C_1A_TokenSigningKeyContainer por la clave de firma de tokens que creó en Configuración de la firma.

En el archivo ContosoCustomPolicy.XML, agregue otro perfil técnico de Microsoft Entra después del perfil técnico AAD-UserWriteUsingAlternativeSecurityId mediante el código siguiente:

   <TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">
       <DisplayName>Azure Active Directory</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="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
       </Metadata>
       <CryptographicKeys>
           <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
           </CryptographicKeys>
       <InputClaims>
           <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />
       </InputClaims>
       <OutputClaims>
           <!-- Required claims -->
           <OutputClaim ClaimTypeReferenceId="objectId" />

           <!-- Optional claims -->
           <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
           <OutputClaim ClaimTypeReferenceId="displayName" />
           <OutputClaim ClaimTypeReferenceId="givenName" />
           <OutputClaim ClaimTypeReferenceId="surname" />
       </OutputClaims>
   </TechnicalProfile>

Hemos agregado un nuevo perfil técnico de Microsoft Entra AAD-UserReadUsingAlternativeSecurityId que escribe una nueva cuenta social en Microsoft Entra ID. Usa alternativeSecurityId como identificador único para la cuenta social.

Reemplace B2C_1A_TokenSigningKeyContainer por la clave de firma de tokens que creó en Configuración de la firma.

Paso 3.5: Configurar la definición de contenido

Después de que un usuario inicie sesión, puede recopilar información de ellos mediante un perfil técnico autoafirmado. Por lo tanto, debe configurar la definición de contenido para el perfil técnico autoafirmado.

En el archivo ContosoCustomPolicy.XML, busque el elemento ContentDefinitions y agregue una nueva definición de contenido de la colección ContentDefinitions mediante el código siguiente:

    <ContentDefinition Id="socialAccountsignupContentDefinition">
        <LoadUri>~/tenant/templates/AzureBlue/selfAsserted.cshtml</LoadUri>
        <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
        <DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.7</DataUri>
        <Metadata>
            <Item Key="DisplayName">Collect information from user page alongside those from social Idp.</Item>
        </Metadata>
    </ContentDefinition>

Usamos esta definición de contenido como metadatos en un perfil técnico autoafirmado en el paso siguiente (paso 3.6).

Paso 3.6: Configurar un perfil técnico autoafirmado

El perfil técnico autoafirmado que configure en este paso se usa para recopilar más información del usuario o actualizar información similar obtenida de la cuenta social.

En el archivo ContosoCustomPolicy.XML, busque la sección ClaimsProviders y agregue un nuevo proveedor de notificaciones mediante el código siguiente:

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <DisplayName>Self Asserted for social sign in</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="SelfAsserted-Social">
                    <DisplayName>Collect more info during social signup</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                    <Metadata>
                      <Item Key="ContentDefinitionReferenceId">socialAccountsignupContentDefinition</Item>
                    </Metadata>
                    <CryptographicKeys>
                      <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
                    </CryptographicKeys>
                    <InputClaims>
                      <!-- These claims ensure that any values retrieved in the previous steps (e.g. from an external IDP) are prefilled. 
                           Note that some of these claims may not have any value, for example, if the external IDP did not provide any of
                           these values, or if the claim did not appear in the OutputClaims section of the IDP.
                           In addition, if a claim is not in the InputClaims section, but it is in the OutputClaims section, then its
                           value will not be prefilled, but the user will still be prompted for it (with an empty value). -->
                      <InputClaim ClaimTypeReferenceId="displayName" />
                      <InputClaim ClaimTypeReferenceId="givenName" />
                      <InputClaim ClaimTypeReferenceId="surname" />
                    </InputClaims>
                    <!---User will be asked to input or update these values-->
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="displayName"/>
                        <DisplayClaim ClaimTypeReferenceId="givenName"/>
                        <DisplayClaim ClaimTypeReferenceId="surname"/>
                    </DisplayClaims>

                    <OutputClaims>
                      <!-- These claims are not shown to the user because their value is obtained through the "ValidationTechnicalProfiles"
                           referenced below, or a default value is assigned to the claim. A claim is only shown to the user to provide a 
                           value if its value cannot be obtained through any other means. -->
                      <OutputClaim ClaimTypeReferenceId="objectId" />
                      <OutputClaim ClaimTypeReferenceId="newUser" />
                      <!---<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />-->
          
                      <!-- Optional claims. These claims are collected from the user and can be modified. If a claim is to be persisted in the directory after having been 
                           collected from the user, it needs to be added as a PersistedClaim in the ValidationTechnicalProfile referenced below, i.e. 
                           in AAD-UserWriteUsingAlternativeSecurityId. -->
                      <OutputClaim ClaimTypeReferenceId="displayName" />
                      <OutputClaim ClaimTypeReferenceId="givenName" />
                      <OutputClaim ClaimTypeReferenceId="surname" />
                    </OutputClaims>
                    <ValidationTechnicalProfiles>
                      <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
                    </ValidationTechnicalProfiles>
                  </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

El proveedor de notificaciones que hemos agregado contiene un perfil técnico autoafirmado, SelfAsserted-Social. El perfil técnico autoafirmado usa el perfil técnico AAD-UserWriteUsingAlternativeSecurityId como perfil técnico de validación. Por lo tanto, el perfil técnico AAD-UserWriteUsingAlternativeSecurityId se ejecuta cuando el usuario selecciona el botón Continuar (consulte la captura de pantalla del paso 7).

Además, tenga en cuenta que hemos agregado la definición de contenido, socialAccountsignupContentDefinition, que hemos configurado en el paso 3.5 de la sección de metadatos.

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

En el ContosoCustomPolicy.XML archivo, busque el HelloWorldJourneyrecorrido del usuario y reemplace todos los pasos de orquestación por los pasos que se muestran en el código siguiente:

    <!--<OrchestrationSteps>-->
        ...
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
            </ClaimsProviderSelections>
        </OrchestrationStep>
    
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="FacebookExchange"
                    TechnicalProfileReferenceId="Facebook-OAUTH" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <!-- For social IDP authentication, attempt to find the user account in the
        directory. -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <!-- Show self-asserted page only if the directory does not have the user account
        already (i.e. we don't have an objectId).  -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    <!--</OrchestrationSteps>-->

En la orquestación, hemos usado hacer referencia a perfiles técnicos que permiten a un usuario iniciar sesión mediante una cuenta social.

Cuando se ejecuta la directiva personalizada:

Paso de orquestación 1: este paso incluye un elemento ClaimsProviderSelections, que enumera las opciones de inicio de sesión disponibles entre las que un usuario puede elegir. En este caso, solo tenemos una opción, FacebookExchange, por lo que cuando se ejecuta la directiva, los usuarios se dirigirán directamente a Facebook.com en el paso 2, como se muestra en el atributo TargetClaimsExchangeId.
Paso de orquestación 2: se ejecuta el perfil técnico Facebook-OAUTH, por lo que el usuario se redirige a Facebook para iniciar sesión.
Paso de orquestación 3: en el paso 3, el perfil técnico AAD-UserReadUsingAlternativeSecurityId se ejecuta para intentar leer la cuenta social de usuario del almacenamiento de Microsoft Entra ID. Si se encuentra la cuenta social, objectId se devuelve como una notificación de salida.
Paso de orquestación 4: este paso se ejecuta si el usuario aún no existe (objectId no existe). Muestra el formulario que recopila más información del usuario o actualiza información similar obtenida de la cuenta social.
Paso de orquestación 5: este paso se ejecuta si el usuario aún no existe (objectId no existe), por lo que el perfil técnico AAD-UserWriteUsingAlternativeSecurityId se ejecuta para escribir la cuenta social en Microsoft Entra ID.
Paso de orquestación 6: por último, el paso 6 ensambla y devuelve el token JWT al final de la ejecución de la directiva.

Paso 5: Actualización de notificaciones de salida de usuario de confianza

En el archivo ContosoCustomPolicy.XML, busque el elemento RelyingParty y reemplace toda la colección de notificaciones de salida por el código siguiente:

    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surname" />
    <OutputClaim ClaimTypeReferenceId="email" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
    <OutputClaim ClaimTypeReferenceId="identityProvider" />

Hemos agregado el proveedor de identidades (identityProvider) como una notificación de salida, por lo que se incluirá en el token JWT devuelto a la aplicación de usuario de confianza.

Paso 6: Cargar 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 Probar la directiva personalizada para probar la directiva personalizada.

Se le redirigirá a una página de inicio de sesión de Facebook. Escriba sus credenciales de Facebook y, a continuación, seleccione Iniciar sesión. Se le redirige directamente a Facebook, tal y como hemos establecido en nuestros pasos de orquestación, ya que no tenemos varias opciones de inicio de sesión entre las que elegir. Normalmente, en una aplicación, agregaría un botón como Iniciar sesión con Facebook, que, cuando se selecciona, ejecuta la directiva.

Si es la primera vez que se ejecuta esta directiva (la cuenta de red social aún no existe en el almacenamiento de Microsoft Entra), verá una captura de pantalla como la que se muestra a continuación. No verá esta pantalla en las ejecuciones de directivas posteriores, ya que la cuenta de red social ya existe en el almacenamiento de Microsoft Entra.

Escriba o actualice elNombre para mostrar, elNombre especificado y el Apellido y, a continuación, seleccione el botón Continuar.

Una vez finalizada la ejecución de la directiva, se le redirigirá a https://jwt.ms y verá un token JWT descodificado. Tiene un aspecto similar al siguiente fragmento de código de token JWT:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "pxLOMWFgP4T..."
}.{
   ...
  "acr": "b2c_1a_contosocustompolicy",
   ...
  "given_name": "Maurice",
  "family_name": "Paulet",
  "name": "Maurice Paulet",
  "email": "maurice.p@contoso.com",
  "idp": "facebook.com"
}.[Signature]

Observe que el proveedor de identidades, "idp": "facebook.com", se ha incluido en el token JWT.

En este artículo, nuestros pasos de orquestación del recorrido del usuario solo hacen referencia a perfiles técnicos que permiten a un usuario iniciar sesión con una cuenta social. Podemos modificar los pasos de orquestación para permitir que un usuario inicie sesión mediante una cuenta local o una cuenta social. Para ello, el primer elemento del paso de orquestación ClaimsProviderSelections enumera las opciones de inicio de sesión disponibles para el usuario.

Siga estos pasos para agregar una cuenta local y social combinada:

En el ContosoCustomPolicy.XML archivo, busque el AccountTypeInputCollector perfil técnico autoafirmado y agregue authenticationSource la notificación en su colección de notificaciones de salida mediante el código siguiente:
```
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />
```

En la sección UserJourneys, agregue un nuevo recorrido de usuario, LocalAndSocialSignInAndSignUp, mediante el código siguiente:

    <!--<UserJourneys>-->
        ...
        <UserJourney Id="LocalAndSocialSignInAndSignUp">
            <OrchestrationSteps>
                <!--Orchestration steps will be added here-->
            </OrchestrationSteps>
        </UserJourney>
    <!--</UserJourneys>-->

En el recorrido del usuario que ha creado, LocalAndSocialSignInAndSignUp, agregue los pasos de orquestación mediante el código siguiente:

    <!--<UserJourneys>
        ...
        <UserJourney Id="LocalAndSocialSignInAndSignUp">
            <OrchestrationSteps>-->
            <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
                <ClaimsProviderSelections>
                  <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
                  <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
                </ClaimsProviderSelections>
                <ClaimsExchanges>
                  <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
                </ClaimsExchanges>
            </OrchestrationStep>
            <!-- Check if the user has selected to sign in using one of the social providers -->
            <OrchestrationStep Order="2" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                        <Value>objectId</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
                    <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
                </ClaimsExchanges>
            </OrchestrationStep>

            <!--For Local sign in option start-->

            <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>work</Value>
                      <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>socialIdpAuthentication</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>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>socialIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
                </ClaimsExchanges>
            </OrchestrationStep>  

            <OrchestrationStep Order="5" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>socialIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
                </ClaimsExchanges>
            </OrchestrationStep>                
            <!--For Local sign in option end-->

            <!--For social sign in option start-->
            <!-- For social IDP authentication, attempt to find the user account in the
            directory. -->
            <OrchestrationStep Order="6" Type="ClaimsExchange">
               <Preconditions>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                    <Value>authenticationSource</Value>
                    <Value>localIdpAuthentication</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
               </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
                </ClaimsExchanges>
            </OrchestrationStep>

            <!-- Show self-asserted page only if the directory does not have the user account
            already (i.e. we do not have an objectId).  -->
            <OrchestrationStep Order="7" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                        <Value>objectId</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>localIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
                </ClaimsExchanges>
            </OrchestrationStep>

            <OrchestrationStep Order="8" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                        <Value>objectId</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>localIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
                </ClaimsExchanges>
            </OrchestrationStep>
            <!--For social sign in option end-->
            <OrchestrationStep Order="9" Type="ClaimsExchange">
                <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
                </ClaimsExchanges>          
            </OrchestrationStep>

            <OrchestrationStep Order="10" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
           <!-- </OrchestrationSteps>
        </UserJourney>
    </UserJourneys>-->

En el primer paso, especificamos las opciones que un usuario debe elegir en su recorrido: autenticación local o social. En los pasos siguientes, usamos condiciones previas para realizar un seguimiento de la opción que el usuario ha seleccionado o la fase del recorrido en el que está el usuario. Por ejemplo, usamos la notificación authenticationSource para diferenciar entre un recorrido de autenticación local y un recorrido de autenticación social.

En la sección RelyingParty, cambie DefaultUserJourneyReferenceId a LocalAndSocialSignInAndSignUp
Use el procedimiento del paso 6 y el paso 7 para cargar y ejecutar la directiva. Después de ejecutar la directiva, verá una pantalla similar a la siguiente captura de pantalla.

Puede observar que un usuario puede registrarse o iniciar sesión mediante una cuenta local o una cuenta social.

Pasos siguientes

Obtenga más información sobre cómo Definir un perfil técnico de OAuth2 en una directiva personalizada de Azure Active Directory B2C.

Compartir por

Requisitos previos

Paso 1: Creación de una aplicación de Facebook

Paso 2: Creación de una clave de directiva de Facebook

Paso 3.1: Declarar más notificaciones

Paso 3.2: Definir las transformaciones de notificaciones

Paso 3.3: Configurar el proveedor de notificaciones de Facebook

Paso 3.4: Crear perfiles técnicos de Microsoft Entra

Paso 3.5: Configurar la definición de contenido

Paso 3.6: Configurar un perfil técnico autoafirmado

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

Paso 5: Actualización de notificaciones de salida de usuario de confianza

Paso 6: Cargar la directiva

Paso 7: Prueba de la directiva

Pasos siguientes

Comentarios

Recursos adicionais

Compartir por

Requisitos previos

Paso 1: Creación de una aplicación de Facebook

Paso 2: Creación de una clave de directiva de Facebook

Paso 3: Configurar el inicio de sesión con Facebook

Paso 3.1: Declarar más notificaciones

Paso 3.2: Definir las transformaciones de notificaciones

Paso 3.3: Configurar el proveedor de notificaciones de Facebook

Paso 3.4: Crear perfiles técnicos de Microsoft Entra

Paso 3.5: Configurar la definición de contenido

Paso 3.6: Configurar un perfil técnico autoafirmado

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

Paso 5: Actualización de notificaciones de salida de usuario de confianza

Paso 6: Cargar la directiva

Paso 7: Prueba de la directiva

Inicio de sesión local y social combinado

Pasos siguientes

Comentarios

Recursos adicionais