Compartir a través de

Configurar Trusona Authentication Cloud con Azure Active Directory B2C

  • Artículo

En este tutorial de ejemplo, aprenderá a integrar la autenticación de Azure AD B2C con Trusona Authentication Cloud. Es un servicio basado en la nube que permite a los usuarios autenticarse con una experiencia "tap-and-go", sin necesidad de ninguna aplicación de autenticación móvil.

Entre las ventajas de integrar Trusona Authentication Cloud con Azure AD B2C, se incluyen las siguientes:

  • Autenticación sólida con una mejor experiencia de usuario

    • Usuarios más felices que compran más en línea
    • Menos bajas y abandonos, más ingresos
    • Mayor retención y valor vitalicio (LTV)

  • Menos gastos empresariales

    • Reducción de la toma y el uso compartido de cuentas
    • Reducción del fraude y de las acciones manuales de análisis del fraude
    • Reducción del gasto en subcontratación de revisiones manuales

  • Eliminación de contraseñas

    • No más restablecimientos de contraseña
    • Menos quejas en el centro de llamadas
    • Inicios de sesión rápidos, sencillos y sin complicaciones por medio de claves de paso

Prerrequisitos

Para empezar, necesitará lo siguiente:

Descripción del escenario

Estándar de WebAuthn: WebAuthn implementa los sistemas operativos y exploradores modernos para admitir la autenticación por medio de huella digital, Windows Hello o dispositivos FIDO externos, como USB, Bluetooth y OTP.

En este escenario, Trusona actúa como proveedor de identidades (IdP) para Azure AD B2C a fin de habilitar la autenticación sin contraseña. En la solución, se incluyen los componentes siguientes:

  • Una directiva combinada de registro e inicio de sesión de Azure AD B2C.
  • Trusona Authentication Cloud agregado a Azure AD B2C como IdP.

Screenshot shows Trusona architecture diagram.

Pasos Descripción
1. Un usuario intenta iniciar sesión en la aplicación web a través de su explorador.
2. La aplicación web le redirecciona a la directiva de registro e inicio de sesión de Azure AD B2C.
3. Azure AD B2C redirecciona al usuario para la autenticación al IdP Trusona Authentication Cloud, que usa OpenID Connect (OIDC).
4. Se muestra al usuario una página web de inicio de sesión que le solicita su nombre de usuario, por lo general, una dirección de correo electrónico.
5. El usuario escribe su dirección de correo electrónico y selecciona el botón Continuar. Si la cuenta del usuario no se encuentra en la nube de Trusona Authentication Cloud, se envía una respuesta al explorador que inicia un proceso de registro con WebAuthn en el dispositivo. De lo contrario, se envía una respuesta al explorador que inicia un proceso de autenticación con WebAuthn.
6. Se le pide al usuario que seleccione la credencial que va a usar. La clave de paso está asociada al dominio de la aplicación web o a una clave de seguridad de hardware. Después de que el usuario selecciona una credencial, el sistema operativo solicita al usuario que use sus huellas biométricas, un código de acceso o un PIN para confirmar su identidad. Esto desbloquea el entorno de ejecución de confianza o enclave seguro, que genera una aserción de autenticación firmada por la clave privada asociada a la credencial seleccionada.
7. La aserción de autenticación se devuelve al servicio en la nube de Trusona para su comprobación.
8. Después de la comprobación, Trusona Authentication Cloud (IdP) crea un token de id. de OIDC, y luego lo reenvía a Azure AD B2C (proveedor de servicios). Azure AD B2C valida la firma del token y el emisor con los valores del documento de detección de OpenID de Trusona. Estos detalles se han establecido durante la configuración del IdP. Tras la comprobación de la firma, Azure AD B2C emite un id_token de OIDC (según el ámbito) y redirecciona al usuario de nuevo a la aplicación que inicia el proceso por medio del token.
9. La aplicación web (o las bibliotecas de desarrollador que usa para implementar la autenticación) recupera el token y comprueba la autenticidad del token de Azure AD B2C. Si es válido, la aplicación extrae las notificaciones (atributos de usuario) y las pasa a la aplicación web que se va a usar.
10. A partir de esta comprobación, se le concede o deniega el acceso al usuario.

Paso 1: Incorporación con Trusona Authentication Cloud

  1. Inicie sesión en el portal de Trusona.

  2. En el panel de navegación de la izquierda, seleccione Configuración.

  3. En el menú Configuración, seleccione el control deslizante para Habilitar OIDC.

  4. Seleccione las entradas adecuadas y proporcione la dirección URL de redireccionamientohttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp.

  5. Genere una clave secreta y copie la clave para usarla en la configuración de Azure AD B2C.

    Nota

    1. El portal de Trusona admite el autoservicio de registro. Al registrarse, se le asignará una cuenta de Trusona con derechos de solo lectura. Después, Trusona le asignará a la cuenta correcta y elevará sus derechos de lectura y escritura en función de la directiva de control de acceso de la organización para los usuarios del portal.
    2. El nombre de dominio inicial de Microsoft Entra ID se usa como host de redireccionamiento de cliente.

    Screenshot shows Trusona Authentication Cloud portal settings.

Paso 2: Registro de una aplicación web en Azure AD B2C

Para que sus aplicaciones puedan interactuar con Azure AD B2C, deben estar registradas en el inquilino del cliente. Este tutorial muestra cómo registrar una aplicación web mediante Azure Portal. Con fines de prueba, como este tutorial, va a registrar https://jwt.ms, una aplicación web propiedad de Microsoft que muestra el contenido descodificado de un token (el contenido del token nunca sale del explorador). Para registrar una aplicación web en el inquilino de Azure AD B2C, use nuestra nueva experiencia unificada de registro de aplicaciones.

  1. Inicie sesión en Azure Portal.

  2. Si tiene acceso a varios inquilinos, seleccione el icono Configuración en el menú superior para cambiar a su inquilino de Azure AD B2C desde el menú Directorios y suscripciones.

  3. En Azure Portal, busque y seleccione Azure AD B2C.

  4. Seleccione Registros de aplicaciones y luego Nuevo registro.

  5. Escriba un Nombre para la aplicación. Por ejemplo, jwt ms.

  6. En Tipos de cuenta compatibles, seleccione Cuentas en cualquier proveedor de identidades o directorio de la organización (para autenticar usuarios con flujos de usuario) .

  7. En URI de redirección, seleccione Web y escriba https://jwt.ms en el cuadro de texto.

    El identificador URI de redireccionamiento es el punto de conexión al que el servidor de autorización (Azure AD B2C) envía al usuario. Después de completar su interacción con el usuario, se envía un token de acceso o un código de autorización tras una autorización correcta. En una aplicación de producción, suele ser un punto de conexión accesible públicamente donde se ejecuta la aplicación, como https://contoso.com/auth-response. Con fines de prueba como este tutorial, puede establecerlo en https://jwt.ms, una aplicación web propiedad de Microsoft que muestra el contenido descodificado de un token (el contenido del token nunca sale del explorador). Durante el desarrollo de aplicaciones, puede agregar el punto de conexión en el que la aplicación realiza escuchas localmente, como https://localhost:5000. Puede agregar y modificar los URI de redireccionamiento en las aplicaciones registradas en cualquier momento.

    Las siguientes restricciones se aplican a los URI de redireccionamiento:

    • La dirección URL de respuesta debe comenzar con el esquema https excepto en casos en los que se utilice una dirección URL de redireccionamiento localhost.
    • La dirección URL de respuesta distingue mayúsculas de minúsculas. Sus mayúsculas o minúsculas deben coincidir con las de la ruta de acceso de la dirección URL de la aplicación en ejecución. Por ejemplo, si la aplicación incluye .../abc/response-oidc como parte de su ruta de acceso, no especifique .../ABC/response-oidc en la dirección URL de respuesta. Dado que el explorador web tiene en cuenta las mayúsculas y minúsculas de la ruta de acceso, se pueden excluir las cookies asociadas con .../abc/response-oidc si se redirigen a la dirección URL .../ABC/response-oidc con mayúsculas y minúsculas no coincidentes.
    • La dirección URL de respuesta deberá incluir o excluir la barra diagonal final en función de si la aplicación la espera. Por ejemplo, https://contoso.com/auth-response y https://contoso.com/auth-response/ se pueden tratar como direcciones URL no coincidentes en la aplicación.

  8. En Permisos, active la casilla Conceda consentimiento del administrador a los permisos openid y offline_access.

  9. Seleccione Registrar.

Habilitación de la concesión implícita de tokens de identificador

Si registra esta aplicación y la configura con la aplicación https://jwt.ms/ para probar un flujo de usuario o una directiva personalizada, deberá habilitar el flujo de concesión implícita en el registro de la aplicación. Para ello, siga estos pasos:

  1. En el menú izquierdo, en Administrar, seleccione Autenticación.

  2. En Flujos de concesión implícita e híbridos, seleccione las casillas de verificación Tokens de id. (usados para flujos híbridos e implícitos).

  3. Seleccione Guardar.

Paso 3: Configuración de Trusona Authentication Cloud como IdP en Azure AD B2C

  1. Inicie sesión en Azure Portal como administrador global del inquilino de Azure AD B2C.

  2. Si tiene acceso a varios inquilinos, seleccione el icono Configuración en el menú superior para cambiar a su inquilino de Azure AD B2C desde el menú Directorios y suscripciones.

  3. Elija Todos los servicios en la esquina superior izquierda de Azure Portal, busque y seleccione Azure AD B2C.

  4. Vaya a Panel>Azure Active Directory B2C>Proveedores de identidad.

  5. Seleccione Proveedores de identidades.

  6. Seleccione Agregar.

Configurar un IdP

  1. Seleccione Tipo de proveedor de identidades>OpenID Connect (versión preliminar) .

  2. Rellene el formulario para configurar el IdP:

    Propiedad Value
    URL de metadatos https://authcloud.trusona.net/.well-known/openid-configuration
    Id. de cliente disponible en el portal de Trusona Authentication Cloud
    Secreto del cliente disponible en el portal de Trusona Authentication Cloud
    Ámbito Correo electrónico del perfil de OpenID
    Tipo de respuesta código
    Modo de respuesta form_post

  3. Seleccione Aceptar.

  4. Seleccione Asignar las notificaciones de este proveedor de identidades.

  5. Rellene el formulario para asignar el IdP:

    Propiedad Value
    UserID sub
    Nombre para mostrar nickname
    Nombre propio given_name
    Surname family_name
    Modo de respuesta email

  6. Seleccione Aceptar para completar la instalación del nuevo IdP de OIDC.

Paso 4: Creación de una directiva de flujo de usuario

Ahora debería ver a Trusona asignado como un nuevo proveedor de identidades de OpenID Connect dentro de sus IdP de B2C.

  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, seleccione una versión y, a continuación, seleccione Crear.

  4. Escriba un nombre para la directiva.

  5. En la sección Proveedores de identidades, seleccione el proveedor de identidades de Trusona Authentication Cloud recién creado.

    Nota:

    Dado que Trusona es intrínsecamente multifactor, es mejor dejar la autenticación multifactor deshabilitada.

  6. Seleccione Crear.

  7. En Atributos y notificaciones de usuario, haga clic en Mostrar más. En el formulario, seleccione al menos un atributo que haya especificado durante la instalación del proveedor de identidades en la sección anterior.

  8. Seleccione Aceptar.

Paso 5: Prueba del flujo de usuario

  1. Seleccione la directiva que ha creado.

  2. Seleccione Ejecutar flujo de usuario y, después, elija la configuración:

    a. Aplicación: seleccione la aplicación registrada, por ejemplo, jwt ms.

    b. URL de respuesta: seleccione la dirección URL de redireccionamiento, por ejemplo, https://jwt.ms.

  3. Seleccione Ejecutar flujo de usuario. Se le debería redireccionar a Trusona Authentication Cloud. Se muestra al usuario una página web de inicio de sesión que le solicita su nombre de usuario, por lo general, una dirección de correo electrónico. Si la cuenta del usuario no se encuentra en la nube de Trusona Authentication Cloud, se envía una respuesta al explorador que inicia un proceso de registro con WebAuthn en el dispositivo. De lo contrario, se envía una respuesta al explorador que inicia un proceso de autenticación con WebAuthn. Se le pide al usuario que seleccione la credencial que va a usar. La clave de paso está asociada al dominio de la aplicación web o a una clave de seguridad de hardware. Después de que el usuario selecciona una credencial, el sistema operativo solicita al usuario que use sus huellas biométricas, un código de acceso o un PIN para confirmar su identidad. Esto desbloquea el entorno de ejecución de confianza o enclave seguro, que genera una aserción de autenticación firmada por la clave privada asociada a la credencial seleccionada. Azure AD B2C valida la respuesta de autenticación de Trusona y emite un token de OIDC. Redirecciona al usuario de nuevo a la aplicación que inicia el proceso, por ejemplo, https://jwt.ms, que muestra el contenido del token devuelto por Azure AD B2C.

Paso 3: Creación de una clave de directiva de Trusona Authentication Cloud

Almacene el secreto de cliente que generó anteriormente en el paso 1 en el inquilino de Azure AD B2C.

  1. Inicie sesión en Azure Portal.

  2. Si tiene acceso a varios inquilinos, seleccione el icono Configuración en el menú superior para cambiar a su inquilino de Azure AD B2C desde el menú Directorios y suscripciones.

  3. Elija Todos los servicios en la esquina superior izquierda de Azure Portal, y busque y seleccione Azure AD B2C.

  4. En la página de introducción, seleccione Identity Experience Framework.

  5. Seleccione Claves de directiva y luego Agregar.

  6. En Opciones, elija Manual.

  7. Escriba un nombre para la clave de directiva. Por ejemplo, TrusonaTacClientSecret. Se agregará el prefijo B2C_1A_ automáticamente al nombre de la clave.

  8. En Secreto, escriba el secreto de cliente que haya registrado previamente.

  9. En Uso de claves, seleccione Signature.

  10. Seleccione Crear.

Paso 4: Configuración de Trusona Authentication Cloud como IdP

Sugerencia

En este momento, debe tener configurada la directiva de Azure AD B2C. Si no es así, consulte estas instrucciones sobre cómo configurar el inquilino de Azure AD B2C y las directivas.

Para permitir que los usuarios inicien sesión con Trusona Authentication Cloud, deberá definir Trusona como un proveedor de notificaciones con el que Azure AD B2C puede comunicarse mediante un punto de conexión. El punto de conexión proporciona un conjunto de notificaciones que Azure AD B2C usa para comprobar que un usuario específico se ha autenticado con una clave de paso o una clave de seguridad de hardware disponible en su dispositivo, lo que demuestra la identidad del usuario.

Siga estos pasos para agregar Trusona como proveedor de notificaciones:

  1. 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 archivo .zip o clone el repositorio:

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

    2. En todos los archivos del directorio LocalAccounts, reemplace la cadena yourtenant por el nombre de su inquilino de Azure AD B2C. Por ejemplo, si el nombre del inquilino de B2C es contoso, todas las instancias de yourtenant.onmicrosoft.com se convierten en contoso.onmicrosoft.com.

  2. Abra LocalAccounts/TrustFrameworkExtensions.xml.

  3. Busque el elemento ClaimsProviders. Si no existe, agréguelo debajo del elemento raíz, TrustFrameworkPolicy.

  4. Agregue un nuevo ClaimsProvider similar al que se muestra a continuación:

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</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="11111111-1111-1111-1111-111111111111"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
        <!-- The commented key 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>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </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://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

  1. Establezca client_id con el id. de aplicación de Trusona Authentication Cloud que ha registrado anteriormente en el paso 1.

  2. Actualice la sección client_secret con el nombre de la clave de directiva creada en el paso 3. Por ejemplo, B2C_1A_TrusonaTacClientSecret:

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

  3. Guarde los cambios.

Paso 5: Adición de un recorrido del usuario

En este momento, ya tiene configurado el IdP, pero todavía no está disponible en ninguna de las páginas de inicio de sesión. Si tiene su propio recorrido del usuario personalizado, continúe con el paso 6; de lo contrario, cree un duplicado de una plantilla de recorrido del usuario existente, como se indica a continuación:

  1. Abra el archivo LocalAccounts/TrustFrameworkBase.xml desde el paquete de iniciación.

  2. Busque y copie todo el contenido del elemento UserJourney que incluye Id=SignUpOrSignIn.

  3. Abra el LocalAccounts/TrustFrameworkExtensions.xml y localice el elemento UserJourneys. Si el elemento no existe, agréguelo.

  4. Pegue todo el contenido del elemento UserJourney que ha copiado como elemento secundario del elemento UserJourneys.

  5. Cambie el nombre de Id del recorrido del usuario. Por ejemplo: Id=TrusonaTacSUSI.

Paso 6: Adición del IdP a un recorrido del usuario

Ahora que tiene un recorrido del usuario, agregue el nuevo IdP a ese 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 contiene una lista de IdP con los que un usuario puede iniciar sesión. El orden de los elementos controla el orden de los botones de inicio de sesión que se presentan al usuario. Agregue un elemento XML ClaimsProviderSelection. Establezca el valor de TargetClaimsExchangeId en un nombre descriptivo, como TrusonaTacExchange.

  2. En el paso de orquestación siguiente, agregue un elemento ClaimsExchange. Establezca el id. en el valor del id. de intercambio de notificaciones de destino. Actualice el valor de TechnicalProfileReferenceId con el identificador del perfil técnico que creó anteriormente al agregar el proveedor de notificaciones, por ejemplo, TrusonaTAC-OpenIdConnect.

El archivo XML siguiente muestra los pasos de orquestación de un recorrido del usuario con el proveedor de identidades:

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <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="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <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 (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>

Más información sobre los recorridos del usuario.

Paso 7: 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 ejecuta Azure AD B2C. Busque el elemento DefaultUserJourney en el usuario de confianza. 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 Trusona Authentication Cloud, el ReferenceId está establecido en TrusonaTacSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <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>

Paso 8: Carga de la directiva personalizada

  1. Inicie sesión en Azure Portal.

  2. Si tiene acceso a varios inquilinos, seleccione el icono Configuración en el menú superior para cambiar a su inquilino de Azure AD B2C desde el menú Directorios y suscripciones.

  3. En Azure Portal, busque Azure AD B2C y selecciónelo.

  4. En Directivas, seleccione Identity Experience Framework.

  5. Seleccione Cargar directiva personalizada y, a continuación, cargue los dos archivos de directivas que ha cambiado, en el siguiente orden: la directiva de extensiones, por ejemplo TrustFrameworkExtensions.xml, luego la directiva de usuarios de confianza, como SignUpOrSignin.xml.

Paso 9: Prueba de la directiva personalizada

  1. En el inquilino de Azure AD B2C, en Directivas, seleccione Identity Experience Framework.

  2. En Directivas personalizadas, seleccione TrusonaTacSUSI.

  3. En Aplicación, seleccione la aplicación web que registró anteriormente como parte de los requisitos previos de este artículo. Por ejemplo, jwt ms. La dirección URL de respuesta debe mostrar https://jwt.ms.

  4. Seleccione Ejecutar ahora. El explorador debe redireccionarse a la página de inicio de sesión de Trusona Authentication Cloud.

  5. Se muestra una pantalla de inicio de sesión; en la parte inferior, debe haber un botón para usar la autenticación de Trusona Authentication Cloud.

  6. Se le debería redireccionar a Trusona Authentication Cloud. Se muestra al usuario una página web de inicio de sesión que le solicita su nombre de usuario, por lo general, una dirección de correo electrónico. Si la cuenta del usuario no se encuentra en la nube de Trusona Authentication Cloud, se envía una respuesta al explorador que inicia un proceso de registro con WebAuthn en el dispositivo. De lo contrario, se envía una respuesta al explorador que inicia un proceso de autenticación con WebAuthn. Se le pide al usuario que seleccione la credencial que va a usar. La clave de paso está asociada al dominio de la aplicación web o a una clave de seguridad de hardware. Después de que el usuario selecciona una credencial, el sistema operativo solicita al usuario que use sus huellas biométricas, un código de acceso o un PIN para confirmar su identidad. Esto desbloquea el entorno de ejecución de confianza o enclave seguro, que genera una aserción de autenticación firmada por la clave privada asociada a la credencial seleccionada.

  7. Si el proceso de inicio de sesión se completa correctamente, el explorador se redirige a https://jwt.ms, que muestra el contenido del token devuelto por Azure AD B2C.

Pasos siguientes

Para más información, consulte los artículos siguientes: