Migración

La migración a FoxIDs normalmente combina la migración de aplicaciones, la migración de usuarios y una transición controlada entre la plataforma de identidad existente y FoxIDs. Planifique estos flujos de trabajo juntos para que los identificadores, las notificaciones, el comportamiento de autenticación y las opciones de reversión sigan siendo consistentes durante toda la transición.

Los inquilinos de FoxIDs admiten entornos separados. Utilice entornos de desarrollo, prueba, preparación y producción dedicados para configurar y validar flujos de migración en paralelo sin cambiar prematuramente el entorno de producción.

Evalúe la plataforma de identidad existente

Comience grabando:

Aplicaciones, APIs y entornos conectados a la plataforma existente.
Configuraciones de OpenID Connect, OAuth 2.0, SAML 2.0 y WS-Federation.
Proveedores de identidad, métodos de autenticación y requisitos de autenticación multifactor.
Identificadores de usuario, perfiles, reclamaciones, grupos, roles y asignaciones de acceso.
Opciones de almacenamiento, validación y restablecimiento de contraseñas disponibles en la plataforma de origen.
Certificados, metadatos, URL de redireccionamiento, comportamiento de cierre de sesión y duración de los tokens.
Requisitos de seguimiento, auditoría y reversión para la transición.

La fuente puede ser AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID u otro proveedor de identidad o repositorio de usuarios personalizado. La ruta de migración disponible depende de los protocolos, las capacidades de exportación y las opciones de validación de contraseña proporcionadas por esa fuente.

Migración de aplicaciones

Migre las aplicaciones por protocolo y entorno en lugar de tratar el patrimonio como una única transferencia.

Registre la aplicación en un entorno FoxIDs que no sea de producción.
Reproduzca los reclamaciones, alcances, identificadores, certificados y comportamiento de cierre de sesión requeridos.
Conecte el proveedor de identidad existente como método de autenticación cuando se requiera autenticación paralela.
Pruebe el flujo completo de inicio de sesión, token y cierre de sesión con integraciones y usuarios representativos.
Mueva un grupo controlado o una aplicación a la vez antes de una implementación más amplia.

FoxIDs puente de protocolo permite que una aplicación conserve su protocolo actual mientras cambia el lado del proveedor de identidad. Esto resulta útil cuando las aplicaciones OpenID Connect modernas y las aplicaciones SAML 2.0 o WS-Federation existentes deben funcionar durante el mismo período de migración.

Perfiles de usuario e identificadores

Decida qué identificador permanece estable antes de importar o crear usuarios. Las direcciones de correo electrónico, los números de teléfono y los nombres de usuario pueden cambiar, así que utilice un identificador de fuente estable donde la integración lo admita.

Asigne la información del usuario requerida después de la migración:

Propiedades del perfil de usuario e identificadores de inicio de sesión.
Reclamaciones utilizadas por aplicaciones y API.
Grupos, roles y asignaciones de acceso.
Requisitos de autenticación multifactor y enfoque de inscripción o recuperación después de la migración.
Cuentas deshabilitadas, eliminadas o restringidas de otro modo.

Utilice Subir muchos usuarios cuando los usuarios puedan exportarse e importarse en lotes. Utilice Directory Connector cuando un directorio existente o un repositorio personalizado deba seguir teniendo autoridad durante la transición. Para Active Directory, utilice Directory Connector for Active Directory.

Estrategia de contraseña

Elija la ruta de la contraseña según lo que la plataforma de origen pueda exponer o validar de forma segura:

Importe contraseñas o hashes de contraseñas admitidos solo cuando estén disponibles en un formato compatible y puedan manejarse de forma segura.
Valide la contraseña existente a través de Directory Connector mientras el directorio de origen sigue teniendo autoridad.
De forma predeterminada, FoxIDs guarda una copia de la contraseña local después de una validación exitosa de Directory Connector. Esto hace posible desactivar el conector más adelante y mover la validación de contraseña a FoxIDs sin forzar a cada usuario a realizar un reinicio.
Deshabilite la copia de contraseña local cuando la política requiera que el directorio externo siga siendo el único almacén de contraseñas.
Requerir el restablecimiento de la contraseña cuando importar o conservar la contraseña existente no sea técnicamente posible o cuando el restablecimiento sea la opción más segura.

Nunca asuma que las contraseñas se pueden transferir directamente desde un proveedor de identidad. Confirme el formato de exportación de la plataforma de origen, el algoritmo hash, la API de validación y las restricciones de seguridad antes de seleccionar el método de migración.

Migración gradual

Cuando el directorio de origen admite la validación en línea, los usuarios pueden crearse o actualizarse en FoxIDs en su primer inicio de sesión exitoso a través de Directory Connector. Esto admite una transición gradual sin necesidad de que todos los usuarios migren al mismo tiempo.

Mantenga la fuente disponible hasta que la población de usuarios requerida haya migrado y se haya cerrado la ventana de reversión. Supervise los inicios de sesión fallidos, los conflictos de identificadores, las reclamaciones faltantes y la disponibilidad del conector durante toda la transición.

Corte y reversión

Antes del corte de producción:

Completar pruebas de aceptación de usuarios y aplicaciones representativas.
Confirme certificados, metadatos, DNS, URL de redireccionamiento y rutas de firewall.
Defina el orden en el que se mueven las aplicaciones, API y grupos de usuarios.
Registre la configuración anterior y las condiciones que desencadenan la reversión.
Asegúrese de que el monitoreo y el registro cubran tanto los FoxIDs como los flujos restantes de la plataforma de origen.
Comunique el restablecimiento de contraseña o el comportamiento de inicio de sesión modificado antes de que afecte a los usuarios.

Una implementación por etapas limita la cantidad de aplicaciones y usuarios afectados por cada cambio. Mantener la reversión técnicamente posible hasta que se hayan verificado el comportamiento de producción, las reclamaciones y el acceso.