Compartir a través de

Configuración de Asignio con Azure Active Directory B2C para la autenticación multifactor

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.

Aprenda a integrar la autenticación de Microsoft Entra ID (Azure AD B2C) con Asignio. Con esta integración, proporcione a los clientes una experiencia de autenticación sin contraseña, con biometría suave y multifactor. Asignio usa la firma Asignio patentada y la comprobación facial activa para la autenticación de usuario. La firma biométrica modificable ayuda a reducir las contraseñas, el fraude, la suplantación de identidad y la reutilización de credenciales a través de la autenticación omnicanal.

Antes de empezar

Elija un selector de tipos de directiva para indicar la configuración del tipo de directiva. Azure AD B2C tiene dos métodos para definir cómo interactúan los usuarios con las aplicaciones:

  • Flujos de usuario predefinidos
  • Directivas personalizadas configurables

Los pasos de este artículo difieren para cada método.

Aprende más:

Prerrequisitos

Para las directivas personalizadas

Tutorial completo: Creación de flujos de usuario y directivas personalizadas en Azure AD B2C

Descripción del escenario

Esta integración incluye los siguientes componentes:

  • Azure AD B2C : servidor de autorización que comprueba las credenciales de usuario
  • Aplicaciones web o móviles : para proteger con Asignio MFA
  • Aplicación web de Asignio : recopilación biométrica de firma en el dispositivo táctil del usuario

En el diagrama siguiente se muestra la implementación.

Diagrama que muestra la arquitectura de implementación.

  1. El usuario abre la página de inicio de sesión de Azure AD B2C en su aplicación móvil o web y, a continuación, inicia sesión o se registra.
  2. Azure AD B2C redirige al usuario a Asignio mediante una solicitud de OpenID Connect (OIDC).
  3. El usuario se redirige a la aplicación web de Asignio para el inicio de sesión biométrico. Si el usuario no registró su firma Asignio, puede usar un SMS One-Time-Password (OTP) para autenticarse. Después de la autenticación, el usuario recibe un vínculo de registro para crear su firma de Asignio.
  4. El usuario se autentica con la firma de Asignio y la verificación facial, o la voz y la verificación facial.
  5. La respuesta del desafío va a Asignio.
  6. Asignio devuelve la respuesta de OIDC al inicio de sesión de Azure AD B2C.
  7. Azure AD B2C envía una solicitud de comprobación de autenticación a Asignio para confirmar la recepción de los datos de autenticación.
  8. Al usuario se le concede o se deniega el acceso a la aplicación.

Configuración de una aplicación con Asignio

La configuración de una aplicación con Asignio se realiza a través del sitio de administración de socios de Asignio.

  1. Para solicitar acceso a su organización, vaya a la página de administración de partners de Asignio en asignio.com.
  2. Con las credenciales, inicie sesión en la página de administración de partners de Asignio.
  3. Cree un registro para la aplicación de Azure AD B2C mediante el inquilino de Azure AD B2C. Cuando se usa Azure AD B2C con Asignio, Azure AD B2C administra las aplicaciones conectadas. Las aplicaciones de Asignio representan aplicaciones en Azure Portal.
  4. En el sitio de Administración de partners de Asignio, genere un identificador de cliente y un secreto de cliente.
  5. Anote y almacene el identificador de cliente y el secreto de cliente. Los usará más adelante. Asignio no almacena secretos de cliente.
  6. Escriba el URI de redireccionamiento en el sitio al que se devuelve el usuario después de la autenticación. Use el siguiente patrón de URI.

[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp].

  1. Cargue un logotipo de la empresa. Aparece en la autenticación de Asignio cuando los usuarios inician sesión.

Registro de una aplicación web en Azure AD B2C

Registre las aplicaciones en un inquilino que administre y, a continuación, puede interactuar con Azure AD B2C.

Más información: Tipos de aplicación que se pueden usar en Active Directory B2C

En este tutorial, va a registrar https://jwt.ms, una aplicación web de Microsoft con contenido de token descodificado que no sale del explorador.

Registro de una aplicación web

Complete los pasos descritos en Tutorial: Registro de una aplicación web en el artículo de Azure Active Directory B2C .

Configuración de Asignio como proveedor de identidades en Azure AD B2C

Para seguir las instrucciones siguientes, use el tenant de Microsoft Entra con la suscripción de Azure.

  1. Inicie sesión en Azure Portal como al menos el administrador de directivas de IEF de B2C del inquilino de Azure AD B2C.
  2. En la barra de herramientas de Azure Portal, seleccione Directorios y suscripciones.
  3. Configuración del portal | Directorios y suscripciones, en la lista Nombre del directorio, busque el directorio Microsoft Entra.
  4. Seleccione Cambiar.
  5. En la esquina superior izquierda de Azure Portal, seleccione Todos los servicios.
  6. Busque y seleccione Azure AD B2C.
  7. En Azure Portal, busque y seleccione Azure AD B2C.
  8. En el menú izquierdo, seleccione Proveedores de identidades.
  9. Seleccione Nuevo proveedor de OpenID Connect.
  10. Seleccione Tipo de proveedor de identidad>OpenID Connect.
  11. En el campo de Nombre, escriba el identificador de Asignio o un nombre que elija.
  12. En URL de los metadatos, escriba https://authorization.asignio.com/.well-known/openid-configuration.
  13. En Id. de cliente, escriba el identificador de cliente que generó.
  14. En Secreto de cliente, escriba el secreto de cliente que generó.
  15. En Ámbito, use perfil de correo electrónico de openid.
  16. Para Tipo de respuesta, use código.
  17. Para el modo de respuesta, use la consulta.
  18. En Sugerencia de dominio, use https://asignio.com.
  19. Selecciona Aceptar.
  20. Seleccione Asignar las notificaciones de este proveedor de identidades.
  21. En Id. de usuario, use sub.
  22. En Nombre para mostrar, use nombre.
  23. En Nombre propio, use given_name.
  24. Para Apellidos, utilice nombre_de_familia.
  25. En Correo electrónico, use correo electrónico.
  26. Haga clic en Guardar.

Creación de una directiva de flujo de usuario

  1. En el inquilino de Azure AD B2C, en Directivas, seleccione Flujos de usuario.
  2. Seleccione Nuevo flujo de usuario.
  3. Seleccione Registrarse e iniciar sesión en el tipo de flujo de usuario.
  4. Seleccione Versión recomendada.
  5. Selecciona Crear.
  6. Escriba un nombre de flujo de usuario, como AsignioSignupSignin.
  7. En Proveedores de identidades, en Cuentas locales, seleccione Ninguno. Esta acción deshabilita la autenticación de correo electrónico y contraseña.
  8. En Proveedores de identidades personalizados, seleccione el proveedor de identidades de Asignio creado.
  9. Selecciona Crear.

Prueba del flujo de usuario

  1. En el inquilino de Azure AD B2C, seleccione Flujos de usuario.
  2. Seleccione el flujo de usuario creado.
  3. En Aplicación, seleccione la aplicación web que registró. La dirección URL de respuesta es https://jwt.ms.
  4. Seleccione Ejecutar flujo de usuario.
  5. El explorador se redirige a la página de inicio de sesión de Asignio.
  6. Aparece una pantalla de inicio de sesión.
  7. En la parte inferior, seleccione autenticación de Asignio.

Si tiene una firma de Asignio, complete el aviso para autenticarse. Si no es así, proporcione el número de teléfono del dispositivo para autenticarse a través de SMS OTP. Use el vínculo para registrar la firma de Asignio.

  1. El explorador se redirige a https://jwt.ms. Aparecerá el contenido del token devuelto por Azure AD B2C.

Creación de una clave de directiva de Asignio

  1. Almacene el secreto de cliente generado en el inquilino de Azure AD B2C.
  2. Inicie sesión en Azure Portal.
  3. En la barra de herramientas del portal, seleccione directorios y suscripciones.
  4. Configuración del portal | Directorios y suscripciones, en la lista Nombre del directorio, busque el directorio de Azure AD B2C.
  5. Seleccione Cambiar.
  6. En la esquina superior izquierda de Azure Portal, seleccione Todos los servicios.
  7. Busque y seleccione Azure AD B2C.
  8. En la página Información general, seleccione Identity Experience Framework.
  9. Seleccione Claves de directiva.
  10. Selecciona Agregar.
  11. En Opciones, seleccione Manual.
  12. Escriba un Nombre de clave de directiva para la clave de directiva. El prefijo B2C_1A_ se anexa al nombre de clave.
  13. En Secreto, escriba el secreto de cliente que anotó.
  14. En Uso de claves, seleccione Firma.
  15. Selecciona Crear.

Configuración de Asignio como proveedor de identidades

Sugerencia

Antes de comenzar, asegúrese de que la directiva de Azure AD B2C está configurada. Si no es así, siga las instrucciones del paquete de inicio de directivas personalizadas.

Para que los usuarios inicien sesión con Asignio, defina Asignio como un proveedor de notificaciones con el que Azure AD B2C se comunica mediante un punto de conexión. El punto de conexión proporciona declaraciones que Azure AD B2C usa para verificar la autenticación del usuario mediante el identificador digital en el dispositivo.

Añadir Asignio como proveedor de reclamaciones

Obtenga los paquetes de inicio de directivas personalizados de GitHub y, a continuación, actualice los archivos XML en el paquete de inicio LocalAccounts con el nombre del cliente de Azure AD B2C.

  1. Descargue el archivo zip active-directory-b2c-custom-policy-starterpack o clone el repositorio:

        git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

  2. En los archivos del directorio LocalAccounts , reemplace la cadena yourtenant por el nombre del inquilino de Azure AD B2C.

  3. Abra el LocalAccounts/ TrustFrameworkExtensions.xml.

  4. Busque el elemento ClaimsProviders. Si no hay ninguna, agréguela en el elemento raíz, TrustFrameworkPolicy.

  5. Agregue un nuevo ClaimsProvider similar al ejemplo siguiente:

     <ClaimsProvider>
   <Domain>contoso.com</Domain>
   <DisplayName>Asignio</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="Asignio-Oauth2">
       <DisplayName>Asignio</DisplayName>
       <Description>Login with your Asignio account</Description>
       <Protocol Name="OAuth2" />
       <Metadata>
         <Item Key="ProviderName">authorization.asignio.com</Item>
         <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
         <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
         <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
         <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
         <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="scope">openid profile email</Item>
         <Item Key="UsePolicyInRedirectUri">0</Item>
         <!-- Update the Client ID below to the Asignio Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
         <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
         <Item Key="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></Item>
         <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
         <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
         <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to     sign in. -->
         <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
       </Metadata>
       <CryptographicKeys>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
       </CryptographicKeys>
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
         <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
         <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
         <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
         <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
         <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
         <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
         <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
       </OutputClaims>
       <OutputClaimsTransformations>
         <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
         <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
         <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
         <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
       </OutputClaimsTransformations>
       <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
     </TechnicalProfile>
   </TechnicalProfiles>
 </ClaimsProvider>

  6. Establezca client_id con el identificador de aplicación de Asignio que anotó.

  7. Actualice client_secret sección con la clave de directiva que creó. Por ejemplo, B2C_1A_AsignioSecret:

    <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />

  8. Guarde los cambios.

Adición de un recorrido del usuario

El proveedor de identidades no está en las páginas de inicio de sesión.

  1. Si tiene un recorrido del usuario personalizado, continúe con Configurar la directiva de usuario de confianza; de lo contrario, copie una plantilla de recorrido del usuario:
  2. En el paquete de inicio, abra el archivo LocalAccounts/ TrustFrameworkBase.xml.
  3. Busque y copie el contenido del elemento UserJourney que incluye Id=SignUpOrSignIn.
  4. Abra el LocalAccounts/ TrustFrameworkExtensions.xml.
  5. Busque el elemento UserJourneys . Si no hay ninguna, agregue una.
  6. Pegue el contenido del elemento UserJourney como elemento secundario del elemento UserJourneys.]
  7. Cambie el nombre del identificador de recorrido del usuario. Por ejemplo: Id=AsignioSUSI.

Más información: Recorridos del usuario

Adición del proveedor de identidades a un recorrido del usuario

Añade el nuevo proveedor de identidades a la experiencia del usuario.

  1. Busque el elemento del paso de orquestación que incluye Type=CombinedSignInAndSignUp o Type=ClaimsProviderSelectionen el recorrido del usuario. Normalmente es el primer paso de orquestación. El elemento ClaimsProviderSelections tiene una lista de proveedores de identidades con la que los usuarios inician sesión. El orden de los elementos controla el orden de los botones de inicio de sesión.
  2. Agregue un elemento XML ClaimsProviderSelection.
  3. Establezca el valor de TargetClaimsExchangeId en un nombre descriptivo.
  4. Agregue un elemento ClaimsExchange .
  5. Establezca el id. en el valor del id. de intercambio de notificaciones de destino.
  6. Actualice el valor de TechnicalProfileReferenceId al identificador del perfil técnico que creó.

El siguiente XML muestra la orquestación del recorrido del usuario con el proveedor de identidades.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </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="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </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). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <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>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent            in the token. -->
        <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="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" 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="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

Configuración de la directiva de usuario de confianza

La directiva de usuario de confianza, por ejemplo SignUpSignIn.xml, especifica el recorrido del usuario que ejecutará Azure AD B2C.

  1. En el usuario de confianza, busque el elemento DefaultUserJourney.
  2. Actualice ReferenceId para que coincida con el identificador del recorrido del usuario, en el que agregó el proveedor de identidades.

En el ejemplo siguiente, para el recorrido de usuario AsignioSUSI, el ReferenceId está establecido en AsignioSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Carga de la directiva personalizada

  1. Inicie sesión en Azure Portal.
  2. En la barra de herramientas del portal, seleccione directorios y suscripciones.
  3. Configuración del portal | Directorios y suscripciones, en la lista Nombre del directorio, busque el directorio de Azure AD B2C.
  4. Seleccione Cambiar.
  5. En Azure Portal, busque y seleccione Azure AD B2C.
  6. En Directivas, seleccione Identity Experience Framework.
  7. Seleccione Cargar directiva personalizada.
  8. Cargue los dos archivos de directiva que ha cambiado en el orden siguiente:
  • Política de extensión, por ejemplo TrustFrameworkExtensions.xml
  • A continuación, la directiva de usuario de confianza, por ejemplo SignUpOrSignin.xml

Prueba de la directiva personalizada

  1. En el inquilino de Azure AD B2C, en Directivas, seleccione Identity Experience Framework.
  2. En Directivas personalizadas, seleccione AsignioSUSI.
  3. En Aplicación, seleccione la aplicación web que registró. La dirección URL de respuesta es https://jwt.ms.
  4. Seleccione Ejecutar ahora.
  5. El explorador se redirige a la página de inicio de sesión de Asignio.
  6. Aparece una pantalla de inicio de sesión.
  7. En la parte inferior, seleccione autenticación de Asignio.

Si tiene una firma de Asignio, se le pedirá que se autentique con la firma de Asignio. Si no es así, proporcione el número de teléfono del dispositivo para autenticarse a través de SMS OTP. Use el vínculo para registrar la firma de Asignio.

  1. El explorador se redirige a https://jwt.ms. Aparecerá el contenido del token devuelto por Azure AD B2C.

Pasos siguientes

  • Last updated on