Activar el modo de Compatibilidad de Alta Escala (HSC) con ID Externo

Se aplica a: Círculo verde con un símbolo de marca de verificación blanca que indica que el siguiente contenido se aplica a los inquilinos externos. Inquilinos externos (más información)

Habilite el modo de compatibilidad a gran escala (HSC) para realizar la transición de aplicaciones de Azure AD B2C a Id. externa de Microsoft Entra con una interrupción mínima al tiempo que se mantienen las credenciales de usuario B2C existentes. Los nuevos clientes que evalúan Id. externa de Microsoft Entra a escala deben consultar Planificación de la solución.

Si es un cliente de AD B2C de Azure y aún no ha revisado las opciones disponibles para la migración, consulte Planar la migración de Azure AD B2C a Id. externo.

En este artículo, aprenderá a:

  • Habilitación del modo HSC mediante Microsoft Graph
  • Revisión del esquema de identidad para la coexistencia
  • Integra y valida tus primeras aplicaciones en endpoints de ID externos
  • Despliegue de aplicaciones adicionales y preparación para la retirada de Azure AD B2C

Prerrequisitos

En este artículo se da por supuesto que ya ha elegido el enfoque de migración del modo de compatibilidad a gran escala (HSC). Si todavía tiene que decidir entre enfoques (modo estándar frente a HSC), comience con Planar la migración de Azure AD B2C a Id. externo.

Importante

Habilitar el modo HSC es un cambio significativo a nivel de inquilino y solo se puede revertir poniéndose en contacto con el Soporte técnico de Microsoft. Antes de llamar a la API de habilitación, confirme que ha revisado las limitaciones del modo HSC (incluidas las brechas de los proveedores de identidades sociales, las claves de acceso, la verificación de edad, la experiencia del portal de administración y el acceso condicional) y ha validado que se admiten los escenarios.

Antes de empezar, contacta con el equipo de tu cuenta de Microsoft o abre un ticket de soporte para solicitar la inclusión en el modo HSC. Este proceso puede tardar unos días en completarse. No puedes pasar a la Fase 1 hasta que tu inquilino esté autorizado a entrar en la lista.

Si el tenant de Azure AD B2C usa atributos personalizados, compruebe que todos los atributos personalizados tengan un valor de description no vacío antes de habilitar el modo HSC. La API Enable sincroniza los atributos personalizados con el contexto de ID externo y genera un error si algún atributo tiene una descripción nula o vacía. Para comprobar y corregir descripciones de atributos, consulte Error en la sincronización de atributos personalizados.

Fase 1: Habilitar el modo HSC

Una vez que tu inquilino esté permitido para el modo HSC, puedes activar el modo HSC llamando a la siguiente API de Microsoft Graph. La cuenta de llamada necesita el Policy.ReadWrite.AuthenticationFlows permiso:

POST: https://graph.microsoft.com/beta/policies/authenticationFlowsPolicy/externalIdHybridModeConfiguration
Cuerpo: {}

Importante

Después de habilitar el modo HSC, permita hasta 1 hora para que los cambios surtan efecto en todos los servicios antes de continuar con la fase 2. Si necesita deshabilitar el modo HSC, póngase en contacto con Microsoft soporte técnico.

Fase 2: Revisión de reclamaciones de tokens para la coexistencia

Durante la coexistencia, las aplicaciones autentican a los usuarios a través de puntos de conexión B2C o de identificador externo. Antes de migrar aplicaciones, revise cómo se generan las reclamaciones de token para evitar cambios disruptivos.

La mayoría de los inquilinos no necesitan realizar cambios en los datos de identidad. Sin embargo, si sus aplicaciones dependen de declaraciones específicas, (normalmente email o sub) verifiquen que esos atributos se rellenan y emiten correctamente. Las aplicaciones pueden fallar si faltan las reclamaciones esperadas o si se utilizan nombres de reclamación diferentes en el ID externo.

Escenarios comunes para comprobar

  • Aplicaciones que se basan en email o sub
  • Cuentas locales donde mail no está poblado
  • Reclamaciones que solo se rellenan mediante nombres de inicio de sesión o pólizas personalizadas

Importante

En External ID, la sub reclamación no se establece al mismo valor que oid. Si las aplicaciones dependen de que la reclamación sub coincida con la del usuario oid, solicite el ámbito profile para recuperar la reclamación oid y úsela como identificador de usuario estable en su lugar.

Antes de migrar aplicaciones, valida cómo se asignan los atributos a las reclamaciones del token usadas por tus aplicaciones. Puede configurar notificaciones opcionales mediante la personalización de notificaciones de JWT o usar extensiones personalizadas para agregar datos de usuario externos a tokens antes de emitirlos.

Si sus aplicaciones no dependen de reclamaciones de token específicas, continúe con la etapa 3.

Fase 3: Compilación de la primera aplicación de identificador externo (con usuarios B2C existentes)

Utiliza los siguientes pasos para crear y configurar una aplicación que utilice endpoints de ID externo mientras continúa usando la base de usuarios existente de Azure AD B2C. La autenticación nativa es opcional y solo se aplica a las aplicaciones que usan las API de autenticación nativas.

Registrar su aplicación

Siga las instrucciones de Registro de una aplicación para registrar la aplicación.

Al registrar una aplicación en tu tenant de ID externo, elige Cuentas soloen este directorio organizacional. Al registrar una aplicación en la entidad de B2C, elija Cuentas en cualquier directorio organizativo.

Nota:

Los registros de aplicaciones existentes de Azure AD B2C no se pueden reutilizar para los puntos de conexión de ID externo debido a diferencias en las propiedades de la aplicación, los requisitos de un solo inquilino y la compatibilidad con la autenticación nativa, lo que requiere el uso de registros de aplicaciones dedicados.

(Opcional) Autenticación nativa

Si usa la autenticación nativa, habilite esta opción siguiendo las instrucciones de Autenticación nativa.

Configuración de flujos de usuario

A continuación, cree un flujo de usuario de id. externo y asócielo a la aplicación. Puede usar microsoft Graph API para hacerlo. Para más información, consulte Creación de flujos de eventos de autenticación.

(Opcional) Configuración de un dominio de dirección URL personalizado y Azure Front Door

El identificador externo admite dominios de autenticación personalizados (por ejemplo, login.contoso.com) para mantener la personalización de marca y la coherencia. Dominios URL personalizados se implementan mediante un proxy inverso, como Azure Front Door, que enruta el tráfico del dominio personalizado a los puntos de conexión subyacentes del ID externo.

Importante

Al usar Azure Front Door, las reglas de enrutamiento deben definirse claramente para asegurarse de que el tráfico de autenticación se envía a la plataforma de identidad correcta. Azure Front Door enruta las solicitudes basadas en nombres de host y rutas de acceso, y cada dominio personalizado está asociado a un origen de back-end específico.

Si una aplicación necesita admitir el tráfico de autenticación para Azure AD B2C y Id. externa de Microsoft Entra al mismo tiempo, no se recomienda compartir el mismo dominio de autenticación personalizado. Dado que los métodos de enrutamiento de Azure Front Door pueden enrutar un dominio personalizado solo a un origen cada vez, este escenario normalmente requiere un dominio personalizado independiente para los puntos de conexión de External ID (por ejemplo, para B2C y login.contoso.com para External ID) para evitar conflictos de enrutamiento y mezcla indeseada de tráfico.

(Opcional) Adición de extensiones de autenticación personalizadas

Algunas aplicaciones requieren lógica ligera durante la autenticación, como la validación de atributos o el enriquecimiento de tokens. Las extensiones de autenticación personalizadas permiten invocar una API REST externa en puntos específicos del flujo de autenticación sin crear directivas personalizadas completas. Para obtener más información, consulte Custom authentication extensions (Extensiones de autenticación personalizadas ) y Custom extensions overview (Información general sobre las extensiones de autenticación personalizadas).

Fase 4: Validar escenarios de un extremo a otro

Antes de llevar a cabo el despliegue general, valide la aplicación con el ID externo habilitado en escenarios críticos de autenticación.

Validación recomendada

  • Inicie sesión en la nueva aplicación con credenciales B2C existentes.
  • Inspeccione el token emitido y compruebe:
    • oid permanece igual que B2C.
    • issuer y sub difieren de B2C.
  • Registra a un nuevo usuario en la nueva aplicación utilizando extremos de autenticación por ID externo (API de autenticación web o nativas).
  • Inicia sesión con el mismo usuario en una app B2C heredada y confirma lo mismo oid.
  • Después de la validación, use la nueva aplicación con flujos web hospedados y características de identificador externo.

Qué comprobar

  • Usuarios existentes y usuarios recién creados.
  • Reclamaciones de tokens consumidas por APIs de backend.
  • Registros de inicio de sesión y control de errores.

Fase 5: Expansión incremental de la adopción de aplicaciones y preparación para la retirada

Una vez validada la aplicación inicial:

  • Incorpore aplicaciones adicionales al External ID, de una en una.
  • Mantenga las aplicaciones restantes en Azure AD B2C hasta que estén listas.
  • Mantenga la coexistencia entre las aplicaciones B2C y ID externo según sea necesario.
  • Asegúrese de que todas las aplicaciones de Azure AD B2C se migren a Id. externa de Microsoft Entra antes de la retirada del servicio de Azure AD B2C.
  • Una vez que todas las aplicaciones se ejecutan en puntos de conexión de ID externo, no se requiere ninguna acción adicional.

Contenido relacionado

  • Last updated on