Share via

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

  • Artículo

Aprenda a integrar la autenticación Microsoft Entra ID (Azure AD B2C) con Asignio. Con esta integración, proporcione a los clientes una experiencia sin contraseña, biometría por software y autenticación multifactor. Asignio usa la firma de Asignio patentada y la verificación facial en tiempo real para la autenticación del usuario. La firma biométrica modificable ayuda a reducir el uso de contraseñas, el fraude, la suplantación de identidad y la reutilización de credenciales gracias a la autenticación por varios canales.

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 en este artículo son diferentes para cada método.

Más información:

Requisitos previos

Para las directivas personalizadas

Complete el Tutorial: 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 del usuario.
  • Aplicaciones web o móviles: para protegerse con MFA de Asignio
  • Aplicación web de Asignio: colección biométrica de firmas en el dispositivo táctil del usuario

En el diagrama siguiente se ilustra 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 web o móvil y, luego, inicia sesión o se registra.
  2. Azure AD B2C redirige al usuario a Asignio mediante una solicitud OpenID Connect (OIDC).
  3. Se redirige al usuario a la aplicación web de Asignio para el inicio de sesión biométrico. Si el usuario no ha registrado su firma de Asignio, puede usar una contraseña de un solo uso (OTP) por SMS 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 una firma de Asignio y la verificación facial o la verificación facial y de voz.
  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 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 procesa en el sitio de administración de partners de Asignio.

  1. Vaya a la página de administración de partners de Asignio en asignio.com para solicitar acceso a su organización.
  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 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 Asignio Partner Administration, genere un identificador de cliente y un secreto de cliente.
  5. Anote y almacene el id. de cliente y el secreto de cliente. Los usará más adelante. Asignio no almacena secretos de cliente.
  6. Escriba el identificador URI de redireccionamiento en el sitio al que se redirige al usuario después de la autenticación. Use el siguiente patrón de identificador URI.

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

  1. Carga un logotipo de la compañía. 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; después, pueden interactuar con Azure AD B2C.

Más información: Tipos de aplicaciones 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.

Registre una aplicación web y habilite la concesión implícita del token de identificador

Complete el Tutorial: Registro de una aplicación web en Azure Active Directory B2C

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

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

  1. Inicie sesión en Azure Portal como administrador global del inquilino de Azure AD B2C.
  2. Seleccione Directorios y suscripciones en la barra de herramientas de Azure Portal.
  3. En Configuración del portal | Directorios y suscripciones, en la lista Nombre del directorio, busque el directorio de 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ú de la izquierda, seleccione Proveedores de identidades.
  9. Seleccione Nuevo proveedor de OpenID Connect.
  10. Seleccione Tipo de proveedor de identidades>OpenID Connect.
  11. En Nombre, escriba el inicio de sesión de Asignio o un nombre de su preferencia.
  12. En Dirección URL de metadatos, escriba https://authorization.asignio.com/.well-known/openid-configuration.
  13. En Id. de cliente, escriba el id. de cliente que ha generado.
  14. En Secreto de cliente, escriba el secreto de cliente que ha generado.
  15. En Ámbito, use perfil de correo electrónico de openid.
  16. En Tipo de respuesta, seleccione código.
  17. En Modo de respuesta, seleccione consulta.
  18. En Sugerencia de dominio, use https://asignio.com.
  19. Seleccione 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. En Apellidos, use family_name.
  25. En Correo electrónico, use correo electrónico.
  26. Seleccione 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 el tipo de flujo de usuario de registro e inicio de sesión.
  4. Seleccione Versión recomendada.
  5. Seleccione Crear.
  6. Escriba un flujo de usuario Nombre, como AsignioSignupSignin.
  7. En Proveedores de identidades, en Cuentas locales, seleccione Ninguno. Esta acción deshabilita la autenticación con contraseña y correo electrónico.
  8. En Proveedores de identidades personalizados, seleccione el proveedor de identidades de Asignio creado.
  9. Seleccione 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 símbolo del sistema para autenticarse. Si no es así, proporcione el número de teléfono del dispositivo para autenticarse a través de una OTP por SMS. Use el vínculo para registrar la firma de Asignio.

  1. El explorador se redirige a https://jwt.ms. Aparece 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. En 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 de introducción, seleccione Identity Experience Framework.
  9. Seleccione Claves de directiva.
  10. Seleccione Agregar.
  11. En Opciones, seleccione Manual.
  12. Escriba un Nombre de clave de directiva para la clave de directiva. El prefijo B2C_1A_ se agrega al nombre de la clave.
  13. En Secreto, escriba el secreto de cliente que ha anotado.
  14. En Uso de claves, seleccione Firma.
  15. Seleccione 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 notificaciones que Azure AD B2C usa para comprobar la autenticación de usuario mediante un identificador digital en su dispositivo.

Adición de Asignio como proveedor de notificaciones

Obtenga los paquetes de inicio de directivas personalizadas en GitHub y, luego, actualice los archivos XML del paquete de inicio LocalAccounts con el nombre del inquilino de Azure AD B2C:

  1. Descargue el 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 de inquilino de Azure AD B2C.

  3. Abra el archivo LocalAccounts/ TrustFrameworkExtensions.xml.

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

  5. Agregue una nueva instancia de 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">00000000-0000-0000-0000-000000000000</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
         <Item Key="11111111-1111-1111-1111-111111111111"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
         <Item Key="22222222-2222-2222-2222-222222222222"></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/11111111-1111-1111-1111-111111111111</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 id. de aplicación de Asignio que ha anotado.

  7. Actualice la sección client_secret con la clave de directiva que ha creado. 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 archivo LocalAccounts/ TrustFrameworkExtensions.xml.
  5. Busque el elemento UserJourneys. Si no hay ninguno, agregue uno.
  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

Agregue el nuevo proveedor de identidades al recorrido 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 los que los usuarios inician sesión. El orden de los elementos determina 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 del identificador del perfil técnico que creó anteriormente.

El archivo XML siguiente 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. En 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 directivas que ha cambiado, por el siguiente orden:
  • La directiva 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 ha registrado. 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 ella. Si no es así, proporcione el número de teléfono del dispositivo para autenticarse a través de una OTP por SMS. Use el vínculo para registrar la firma de Asignio.

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

Pasos siguientes