Compartir a través de


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

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 embudos y regiones.

Los diseños se encargan de:

  • Registrarse e iniciar sesión en la cuenta local
  • Registrarse e iniciar sesión en la cuenta federada
  • Autenticar cuentas locales para los usuarios que inician sesión desde fuera de su región registrada, que es compatible con la autenticación basada en la API entre inquilinos.
  • Autenticacar cuentas federadas para los usuarios que inician sesión desde fuera de su región registrada, que es compatible con la búsqueda basada en la API entre inquilinos
  • Impide el registro desde varias regiones diferentes
  • Las aplicaciones de cada región disponen de un conjunto de puntos de conexión para conectarse

Autenticaciones de la cuenta local

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

Registro de usuario local

En este caso de uso se muestra la manera en que un usuario de su país o región de origen realiza un registro con una cuenta local de Azure AD B2C.

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

  1. Los usuarios de Europa, Oriente Medio y África (EMEA) intentan registrarse en myapp.fr. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  2. El usuario llega al inquilino EMEA.

  3. El usuario intenta registrarse. En el proceso de registro se 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 de 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 usuarios locales existentes

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

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 el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  2. El usuario llega al inquilino EMEA.

  3. El usuario intenta registrarse. En el proceso de registro se 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 existe.

Inicio de sesión de usuario local

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

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

  1. El usuario de EMEA intenta registrarse en myapp.fr. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  2. El usuario llega al inquilino EMEA.

  3. El usuario introduce las credenciales en el inquilino 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 está de viaje

En este caso de uso se muestra la manera en que un usuario puede viajar entre regiones y mantener su perfil de usuario y credenciales almacenadas en el inquilino regional correspondiente a su registro.

Captura de pantalla que muestra el flujo de inicio de sesión del usuario que está de viaje.

  1. El usuario de Norteamérica (NOAM) intenta iniciar sesión en myapp.fr, ya que es un día festivo en Francia. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  2. El usuario llega al inquilino EMEA.

  3. El usuario introduce las credenciales en el inquilino 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 Azure AD B2C de EMEA.

  5. El correo electrónico del usuario se encuentra registrado en el inquilino de Azure AD B2C de NOAM.

  6. El inquilino de Azure AD B2C de EMEA realiza un flujo ROPC de Microsoft Entra contra el inquilino de AZURE AD B2C de NOAM para comprobar las credenciales.

    Nota:

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

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

El usuario local ha olvidado la contraseña

En este caso de uso se muestra la manera en que un usuario puede restablecer la contraseña cuando se encuentra en su país o región de origen.

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

  1. El usuario de EMEA intenta registrarse en myapp.fr. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

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

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

  4. El usuario proporciona una contraseña nueva.

  5. La contraseña nueva se escribe en el inquilino de Azure AD B2C de EMEA.

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

El usuario que está de viaje ha olvidado la contraseña

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

Captura de pantalla que muestra el flujo de contraseña olvidada del usuario que está de viaje.

  1. El usuario de NOAM intenta iniciar sesión en myapp.fr, ya que es un día festivo en Francia. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

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

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

  4. El correo electrónico existe en el inquilino de Azure AD B2C de Noam. El usuario proporciona una contraseña nueva.

  5. La nueva contraseña se escribe en el inquilino de Azure AD B2C de NOAM a través de una llamada 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 la manera en que un usuario puede cambiar la contraseña después de haber iniciado sesión en la región en la que registró la 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 Azure AD B2C de EMEA y el conjunto de cookies de inicio de sesión único (SSO) le permite cambiar la contraseña de inmediato.

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

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

Cambio de contraseña del usuario que está de viaje

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

Captura de pantalla que muestra el flujo de cambio de contraseña del usuario que está de viaje.

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

  2. El usuario llega al inquilino de Azure AD B2C de EMEA y el conjunto de cookies de inicio de sesión único le permite cambiar la contraseña de inmediato.

  3. El correo electrónico de los usuarios se encuentra en el inquilino de NOAM después de comprobar la tabla de búsqueda global.

  4. La nueva contraseña se escribe en la cuenta de usuarios del inquilino de Azure AD B2C de NOAM mediante la llamada MS Graph API.

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

Autenticaciones del proveedor de identidades federadas

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

Registro del id. federado local

En este caso de uso se muestra la manera en que un usuario de su región local se registra en el servicio mediante un id. federado.

Captura de pantalla que muestra el flujo de registro.

  1. El usuario de EMEA intenta registrarse en myapp.fr. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  2. El usuario llega al inquilino EMEA.

  3. El usuario opta por 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: puede continuar si el identificador del IdP federado o el correo electrónico que devolvió el IdP federado no existen 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 la manera en que un usuario de su región local inicia sesión en el servicio mediante un id. federado.

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

  1. El usuario de EMEA intenta registrarse en myapp.fr. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  2. El usuario llega al inquilino EMEA.

  3. El usuario opta por 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 id. 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 está de viaje

En este escenario se muestra la manera en que un usuario que se encuentra lejos 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 el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  2. El usuario llega al inquilino EMEA.

  3. El usuario opta por 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 id. federado del usuario está registrado en NOAM.

  5. Puede leer 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 la manera en que los usuarios pueden realizar la vinculación de cuentas cuando se cumpla un criterio de coincidencia (normalmente la dirección de correo electrónico).

Captura de pantalla que muestra el flujo de cuentas de combinación o vínculo.

  1. El usuario de EMEA intenta registrarse en myapp.fr. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  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. Se realiza una búsqueda en la tabla de búsqueda global del id. que ha devuelto 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 los métodos de autenticación que están habilitados en la cuenta. Muestre 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 id. social a la cuenta existente y el id. 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 cuentas de usuario que está de viaje con criterios de coincidencia

En este escenario se muestra la manera en que los usuarios pueden realizar la vinculación de cuentas cuando estén lejos de la región.

Captura de pantalla que muestra el flujo de combinación o vinculación de cuentas de usuarios que están de viaje.

  1. El usuario de NOAM intenta iniciar sesión en myapp.fr. Si el usuario no se envía a su nombre de host local, el administrador de tráfico aplicará un redireccionamiento.

  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. Se realiza una búsqueda en la tabla de búsqueda global del id. que ha devuelto 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 vínculo de id_token_hint que afirme las notificaciones que recopilan actualmente los usuarios. Inicie un recorrido en el 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 utilizar la lógica de vinculación de cuentas existente en el inquilino principal y reducir las llamadas API externas a fin de manipular la colección de identidades. Puede encontrar un ejemplo de directiva personalizada que usa id_token_hint aquí.

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

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

Pasos siguientes