Compartir a través de

Creación de una solución de identidad global con un enfoque basado en regiones

Importante

A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para la compra por parte de nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.

En este artículo, se describen los escenarios para el enfoque de diseño basado en regiones. Antes de empezar a diseñar, se recomienda revisar las funcionalidades y el rendimiento del enfoque de diseño basado en embudo y región.

Los diseños tienen en cuenta:

  • Registro e inicio de sesión en la cuenta local
  • Registro e inicio de sesión de la cuenta federada
  • Autenticación de cuentas locales para usuarios que inician sesión desde fuera de su región de registro, soportada por la autenticación basada en API entre arrendatarios.
  • Autenticación de cuentas federadas para los usuarios que inician sesión desde fuera de su región registrada, compatibles con la búsqueda basada en la API entre inquilinos
  • Impide el registro desde varias regiones diferentes.
  • Las aplicaciones de cada región tienen un conjunto de puntos de conexión con los que conectarse

Autenticaciones de cuenta local

Los siguientes casos de uso son típicos en un entorno global de Azure AD B2C. Los casos de uso de la cuenta local también cubren las cuentas en las que viaja el usuario. Cada uno proporciona un diagrama y pasos de flujo de trabajo para cada caso de uso.

Registro de usuario local

En este caso de uso se muestra cómo un usuario de su país o región principal realiza un registro con una cuenta local de Azure AD B2C.

Captura de pantalla que muestra el flujo de registro del usuario local.

  1. El usuario de Europa, Oriente Medio y África (EMEA) intenta registrarse en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario intenta registrarse. El proceso de registro comprueba la tabla de búsqueda global para determinar si el usuario existe en cualquiera de los inquilinos regionales de Azure AD B2C.

  4. El usuario no se encuentra en la tabla de búsqueda global. La cuenta del usuario se escribe en Azure AD B2C y se crea un registro en la tabla de búsqueda global para realizar un seguimiento de la región en la que se registró el usuario.

  5. El inquilino regional devuelve un token a la aplicación.

Intentos de registro de usuario local existentes

En este caso de uso se muestra cómo un usuario vuelve a registrar el mismo correo electrónico desde su propio país o región, o una región diferente, está bloqueado.

Captura de pantalla que muestra el flujo de intento de registro del usuario local existente.

  1. El usuario de EMEA intenta registrarse en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario intenta registrarse. El proceso de registro comprueba la tabla de búsqueda global para determinar si el usuario existe en cualquiera de los inquilinos regionales de Azure AD B2C.

  4. El correo electrónico del usuario se encuentra en la tabla de búsqueda global, lo que indica que el usuario ha registrado este correo electrónico en la solución en algún momento anterior.

  5. Al usuario se le presenta un error que indica que su cuenta ya existe.

Inicio de sesión del usuario local

En este caso de uso se muestra cómo un usuario de su país o región principal realiza un inicio de sesión con una cuenta local de Azure AD B2C.

Captura de pantalla que muestra el flujo de inicio de sesión del usuario local.

  1. El usuario de EMEA intenta iniciar sesión en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario ingresa sus credenciales en la entidad regional.

  4. El inquilino regional devuelve un token a la aplicación.

  5. El usuario ha iniciado sesión en la aplicación.

Inicio de sesión del usuario que viaja

En este caso de uso se muestra cómo un usuario puede viajar entre regiones y mantener su perfil de usuario y sus credenciales almacenadas en su inquilino regional, respectivamente, para su registro.

Captura de pantalla que muestra el flujo de inicio de sesión del usuario que viaja.

  1. El usuario de Norteamérica (NOAM) intenta iniciar sesión en myapp.fr, ya que están de vacaciones en Francia. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario ingresa sus credenciales en la entidad regional.

  4. El inquilino regional realiza una búsqueda en la tabla de búsqueda global, ya que el correo electrónico del usuario no se encontró en el directorio de Azure AD B2C de EMEA.

  5. El correo electrónico del usuario se encuentra para que se haya registrado en el Inquilino de Azure AD B2C de NOAM.

  6. El tenant de Azure AD B2C de EMEA realiza un flujo ROPC de Microsoft Entra con el tenant de NOAM Azure AD B2C para verificar las credenciales.

    Nota:

    Esta llamada también capturará un token para que el usuario realice una llamada a Graph API. El inquilino de AZURE AD B2C de EMEA realiza una llamada de Graph API al inquilino de AZURE AD B2C de NOAM para capturar el perfil del usuario. Esta llamada se autentica mediante el token de acceso de Graph API adquirido en el último paso.

  7. El inquilino regional devuelve un token a la aplicación.

Contraseña olvidada del usuario local

En este caso de uso se muestra cómo un usuario puede restablecer su contraseña cuando se encuentra dentro de su país o región de origen.

Captura de pantalla que muestra el flujo de contraseña olvidado del usuario local.

  1. El usuario de EMEA intenta iniciar sesión en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino de EMEA Azure AD B2C y selecciona contraseña olvidada. El usuario escribe y comprueba su correo electrónico.

  3. La búsqueda de correo electrónico se realiza para determinar en qué entidad regional se encuentra el usuario.

  4. El usuario proporciona una nueva contraseña.

  5. La nueva contraseña se registra en la instancia de Azure AD B2C de EMEA.

  6. El inquilino regional devuelve un token a la aplicación.

Contraseña olvidada del usuario que viaja

En este caso de uso se muestra cómo un usuario puede restablecer su contraseña cuando viaja fuera de la región en la que registró su cuenta.

Captura de pantalla que muestra el flujo de contraseña olvidado del usuario que viaja.

  1. El usuario de NOAM intenta iniciar sesión en myapp.fr, ya que están de vacaciones en Francia. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino de EMEA Azure AD B2C y selecciona contraseña olvidada. El usuario escribe y comprueba su correo electrónico.

  3. La búsqueda de correo electrónico se realiza para determinar en qué entidad regional se encuentra el usuario.

  4. Se ha comprobado que el correo electrónico existe en el tenant NOAM de Azure AD B2C. El usuario proporciona una nueva contraseña.

  5. La nueva contraseña se escribe en el inquilino de Azure AD B2C de NOAM a través de una llamada a Graph API.

  6. El inquilino regional devuelve un token a la aplicación.

Cambio de contraseña de usuario local

En este caso de uso se muestra cómo un usuario puede cambiar su contraseña después de haber iniciado sesión en la región en la que registró su cuenta.

Captura de pantalla que muestra el flujo de cambio de contraseña del usuario local.

  1. El usuario de EMEA intenta cambiar la contraseña después de iniciar sesión en myapp.fr.

  2. El usuario llega al inquilino de EMEA Azure AD B2C y el conjunto de cookies Single-Sign On (SSO) permite al usuario cambiar su contraseña inmediatamente.

  3. La nueva contraseña se escribe en la cuenta de usuarios en el inquilino de Azure AD B2C de EMEA.

  4. El inquilino regional devuelve un token a la aplicación.

Cambio de contraseña de usuario de viaje

En este caso de uso se muestra cómo un usuario puede cambiar su contraseña una vez que haya iniciado sesión, fuera de la región en la que registró su cuenta.

Captura de pantalla que muestra el flujo de cambio de contraseña del usuario que viaja.

  1. Los usuarios de NOAM intentan seleccionar cambiar la contraseña después de iniciar sesión en myapp.fr.

  2. El usuario llega al inquilino de Emea Azure AD B2C y el conjunto de cookies de SSO permite al usuario cambiar su contraseña inmediatamente.

  3. Se ha encontrado que el correo electrónico del usuario está en el tenant NOAM después de comprobar la tabla de búsqueda global.

  4. La nueva contraseña se escribe en la cuenta del usuario en el tenant de Azure AD B2C de NOAM mediante una llamada a la API de MS Graph.

  5. El inquilino regional devuelve un token a la aplicación.

Autenticaciones de proveedores de identidad federada

Los siguientes casos de uso muestran ejemplos de uso del uso de identidades federadas para registrarse o iniciar sesión como cliente de Azure AD B2C.

Registro de identificador federado local

En este caso de uso se muestra cómo un usuario de su región local se registra en el servicio mediante un identificador federado.

Captura de pantalla que muestra el flujo de registro.

  1. El usuario de EMEA intenta registrarse en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario selecciona para iniciar sesión con un proveedor de identidades federado.

  4. Realice una búsqueda en la tabla de búsqueda global.

    • Si la vinculación de la cuenta está en el ámbito: continúe si el identificador de IdP federado ni el correo electrónico que devolvió el IdP federado no existe en la tabla de búsqueda.

    • Si la vinculación de la cuenta no está en el ámbito: puede continuar si el identificador del IdP que ha devuelto el IdP federado no existe en la tabla de búsqueda.

  5. Escriba la cuenta de usuarios en el inquilino de Azure AD B2C de EMEA.

  6. El inquilino regional devuelve un token a la aplicación.

Inicio de sesión de usuario federado local

En este caso de uso se muestra cómo un usuario de su región local inicia sesión en el servicio mediante un identificador federado.

Captura de pantalla que muestra el flujo de inicio de sesión.

  1. El usuario de EMEA intenta iniciar sesión en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario selecciona para iniciar sesión con un proveedor de identidades federado.

  4. Realice una búsqueda en la tabla de búsqueda global y confirme que el identificador federado del usuario está registrado en EMEA.

  5. El inquilino regional devuelve un token a la aplicación.

Inicio de sesión de usuario federado que viaja

En este escenario se muestra cómo un usuario ubicado fuera de la región desde la que se registró, realiza un inicio de sesión en el servicio mediante un IdP federado.

Captura de pantalla que muestra el flujo de inicio de sesión para usuarios que están de viaje.

  1. El usuario de NOAM intenta iniciar sesión en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario selecciona para iniciar sesión con un proveedor de identidades federado.

    Nota:

    Use el mismo id. de aplicación del registro de aplicaciones en el IdP social en todos los inquilinos regionales de Azure AD B2C. De esta manera se garantiza que el id. que devuelve el IdP social siempre es el mismo.

  4. Realice una búsqueda en la tabla de búsqueda global y determine que el identificador federado del usuario está registrado en NOAM.

  5. Lea los datos de la cuenta del inquilino de AZURE AD B2C de NOAM mediante MS Graph API.

  6. El inquilino regional devuelve un token a la aplicación.

Vinculación de cuentas con criterios de coincidencia

En este escenario se muestra cómo los usuarios podrán realizar la vinculación de cuentas cuando se cumpla un criterio coincidente (normalmente la dirección de correo electrónico).

Captura de pantalla que muestra el flujo de cuentas para unir o enlazar.

  1. El usuario de EMEA intenta iniciar sesión en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario selecciona iniciar sesión con un proveedor de identidades federado o un IdP social.

  4. Una búsqueda se realiza en la tabla de búsqueda global para el identificador devuelto por el IdP federado.

  5. Cuando el id. no existe, pero el correo electrónico del IdP federado existe en Azure AD B2C de EMEA, se trata de un escenario de vinculación de cuentas.

  6. Lea el usuario del directorio y determine qué métodos de autenticación están habilitados en la cuenta. Presentar una pantalla para que el usuario inicie sesión con un método de autenticación existente en esta cuenta.

  7. Una vez que el usuario demuestre que posee la cuenta en Azure AD B2C, agregue el nuevo identificador social a la cuenta existente y agregue el identificador social a la cuenta en la tabla de búsqueda global.

  8. El inquilino regional devuelve un token a la aplicación.

Vinculación de cuenta de usuario de viaje con criterios de coincidencia

En este escenario se muestra cómo los usuarios podrán realizar la vinculación de cuentas cuando estén fuera de la región.

Captura de pantalla que muestra el flujo para fusionar o vincular cuentas de usuarios viajeros.

  1. El usuario de NOAM intenta iniciar sesión en myapp.fr. Si al usuario no se le redirige a su nombre de host local, el administrador de tráfico forzará una redirección.

  2. El usuario llega al inquilino EMEA.

  3. El usuario selecciona iniciar sesión con un proveedor de identidades federado o un IdP social.

  4. Una búsqueda se realiza en la tabla de búsqueda global para el identificador devuelto por el IdP federado.

  5. Cuando el id. no existe y el correo electrónico del IdP federado existe en otra región, se trata de un escenario de vinculación de cuentas de usuario que está de viaje.

  6. Cree un enlace de id_token_hint que afirme las declaraciones de los usuarios actualmente recopiladas. Inicie un recorrido al inquilino de Azure AD B2C de NOAM mediante la federación. El usuario demostrará que posee la cuenta a través del inquilino de Azure AD B2C de NOAM.

    Nota:

    Este método se usa para volver a usar la lógica de vinculación de cuentas existente en el inquilino principal y reducir las llamadas API externas para manipular la colección de identidades. Aquí puede encontrar un ejemplo de directiva personalizada que usa id_token_hint.

  7. Una vez que el usuario demuestre que posee la cuenta en Azure AD B2C, agregue el nuevo identificador social a la cuenta existente realizando una llamada de Graph API al inquilino de NOAM Azure AD B2C. Agregue el identificador social a la cuenta en la tabla de búsqueda global.

  8. El inquilino regional devuelve un token a la aplicación.

Pasos siguientes