Migrar de Okta a FoxIDs

Traslada los inicios de sesión de Okta a FoxIDs con el enfoque adecuado al lugar donde se autentica cada grupo. Importa usuarios locales y permite que elijan una contraseña nueva o activa el acceso sin contraseña con códigos de un solo uso. Para los inicios de sesión sociales y empresariales, configura métodos de autenticación de FoxIDs que confíen en proveedores externos. Okta también puede seguir siendo proveedor de identidad mientras las aplicaciones pasan a FoxIDs.

Esta guía técnica abarca los usuarios de Okta Universal Directory, la configuración de aplicaciones y el mapeo de cuentas para Okta Identity Engine y Classic Engine.

Para importar usuarios locales, convierte la exportación de Okta revisada en un CSV y utiliza FoxIDs Seed Tool para cargar los usuarios en masa. Los ejemplos CSV siguientes muestran los campos de creación de contraseña y acceso sin contraseña.

Elige un enfoque para cada grupo:

Método	Requisitos	Primer inicio de sesión
Importar usuarios para crear una contraseña	Datos de usuario y una dirección de correo para crear la contraseña.	El usuario inicia sesión y establece una contraseña con un código por correo.
Migrar usuarios sin contraseña	Datos de usuario y un flujo adecuado por correo o SMS.	El usuario introduce un código de un solo uso y conserva una cuenta sin contraseña.
Migrar los inicios de sesión sociales y empresariales	Un método de autenticación de FoxIDs configurado para confiar en cada proveedor de identidad externo.	El usuario inicia sesión con su proveedor actual.
Conectar Active Directory directamente	Active Directory sigue validando las contraseñas de los usuarios.	El usuario inicia sesión con su contraseña de AD mediante FoxIDs Login.
Mantener Okta durante la transición	Una conexión OpenID Connect o SAML de FoxIDs a Okta.	El usuario se autentica en Okta con los métodos permitidos por sus políticas.

Preparar el destino y la aplicación

Un entorno de pruebas dedicado permite probar la migración con un grupo pequeño de usuarios antes de pasar a producción. Los pasos de configuración son:

Si quieres un dominio personalizado, configúralo y verifícalo en el inquilino antes de configurar aplicaciones y proveedores de identidad externos. Utiliza las URL de FoxIDs resultantes durante toda la migración. Cambiar el dominio más adelante requiere actualizar las configuraciones externas, incluidas las URL de autoridad o metadatos de las aplicaciones y las URL de devolución de llamada y cierre de sesión de los proveedores.
Cada entorno tiene un método de autenticación Login predeterminado llamado login. Personaliza su imagen de marca e interfaz de inicio de sesión para conseguir el aspecto deseado y ajusta sus opciones de inicio de sesión a los usuarios importados.
Crea los métodos de autenticación que conecten a los usuarios con sus proveedores externos, incluido Okta si sigue formando parte de la transición.
Configura la aplicación, sus URL de redirección permitidas, el comportamiento del cierre de sesión y las API que acepten sus tokens de acceso.

FoxIDs Cloud proporciona envío de correo electrónico y SMS para crear contraseñas, iniciar sesión sin contraseña y realizar autenticación multifactor (MFA), según el plan de FoxIDs Cloud seleccionado.

Configura los ajustes de MFA necesarios y cómo se inscribirán los usuarios. Las importaciones CSV descritas transfieren datos de usuario, no registros de Okta Verify, registros de dispositivos FastPass, claves de acceso ni otras inscripciones MFA. Los usuarios que se autentican localmente en FoxIDs registran los factores configurados. Los que siguen autenticándose mediante Okta pueden conservar sus registros allí.

La configuración de aplicaciones es un trabajo separado de la importación de usuarios. Revisa emisor, audiencia, ámbitos, reclamaciones y validación de tokens, además de dependencias del SDK de Okta o Sign-In Widget, inline hooks, reglas de grupos y asignaciones de aplicaciones. Recrea el comportamiento que requiere la aplicación. La guía general de migración aborda el inventario más amplio de aplicaciones y los pasos de despliegue.

Exportar un grupo definido de usuarios de Okta

Utiliza Okta Users API para obtener datos de usuario como JSON para su conversión. Selecciona la organización de origen y los usuarios o grupos que se migrarán. Sigue la URL rel="next" de la cabecera de respuesta Link hasta leer todas las páginas. La operación de listado normal omite los usuarios DEPROVISIONED; un filtro o búsqueda puede incluirlos. Los resultados de búsqueda tienen consistencia eventual, por lo que los cambios recientes pueden tardar en aparecer.

Conserva la organización de origen, el id de usuario, el status del ciclo de vida, los atributos profile necesarios y la información de credentials.provider. Distingue los usuarios gestionados por Okta, respaldados por directorios y federados. La configuración de proveedores y las reglas de enrutamiento ayudan a identificar dónde se autentican realmente.

Para una exportación basada en informes, el informe User Accounts ofrece CSV Export. Sus columnas aún requieren conversión al formato de FoxIDs Seed Tool. La API es útil cuando también se necesitan atributos personalizados o información del proveedor ausentes en el informe.

Exporta por separado la pertenencia a grupos y el acceso a aplicaciones cuando determinen permisos. Los informes de Okta Group Membership y User App Access describen esas relaciones; no todas están en el objeto profile del usuario.

Disponibilidad de contraseñas

Okta solo ofrece exportación de hashes de contraseñas para migrar a Auth0, sujeta a determinados criterios.

FoxIDs puede importar hashes de contraseñas compatibles cuando están disponibles.

Asignar datos de usuario y conservar las cuentas de las aplicaciones

FoxIDs crea su propio ID persistente para los usuarios locales importados. Importar el id de usuario de Okta como reclamación personalizada no lo convierte en el ID de FoxIDs ni conserva automáticamente el sujeto de la aplicación. Registra el sub de OpenID Connect o NameID de SAML real que usa cada aplicación, junto con la organización de origen y el ID de usuario.

Si la aplicación usa el ID de usuario de Okta como sub, impórtalo como reclamación personalizada, por ejemplo legacy_okta_user_id. En el método Login, configura una transformación de reclamaciones Map con acción Replace claim, reclamación de entrada legacy_okta_user_id y de salida sub. La aplicación recibe ese valor como sub mientras el ID persistente de FoxIDs permanece igual. Si utiliza otro valor de sujeto, conserva y asigna ese valor.

Las aplicaciones que identifican cuentas por emisor y sujeto también deben asociar el nuevo emisor de FoxIDs con las cuentas existentes. Para aplicaciones SAML, configura el NameID y formato necesarios en el registro de aplicación SAML. Un inicio de sesión de prueba muestra la identidad real recibida por la aplicación.

Mantén la correspondencia entre identidad de origen, nueva identidad de FoxIDs y cuenta existente de la aplicación. Las identidades usadas durante la transición deben resolver al mismo registro de cliente o empleado. Para accesos sociales y empresariales, incluye la identidad recibida directamente del proveedor; puede diferir del ID de usuario de Okta.

Para importar usuarios locales, utiliza la siguiente correspondencia:

Información de origen	Destino y decisión
`profile.email`	`Email`. Comprueba los duplicados después de eliminar espacios exteriores y convertir a minúsculas, incluidas las colisiones con usuarios existentes de FoxIDs.
`profile.login`	`Username` si se requiere iniciar sesión con nombre de usuario. Un nombre de inicio de sesión de Okta puede diferir del correo del usuario.
`profile.mobilePhone`	`Phone` cuando el número elegido se use para iniciar sesión por SMS. Utiliza formato internacional con prefijo de país.
Pruebas de verificación del correo y teléfono	`EmailVerified` y `PhoneVerified`. La presencia de un dato de contacto en el perfil no demuestra su verificación; utiliza `false` si el estado es desconocido.
`status`	`DisableAccount`. Mantén deshabilitados los usuarios suspendidos; omite los desaprovisionados o impórtalos deshabilitados si necesitas sus registros.
`id` de usuario y organización de origen	Conserva estos datos en la correspondencia de migración. Los ejemplos también guardan el ID en `legacy_okta_user_id`.
`profile.firstName`, `profile.lastName` y atributos personalizados necesarios	Asigna a las reclamaciones utilizadas por tus aplicaciones.
Pertenencia a grupos y asignaciones de aplicaciones	Recrea los roles y asignaciones de acceso necesarios en FoxIDs o en la aplicación.

Los estados del ciclo de vida de Okta son más detallados que el indicador de deshabilitación de FoxIDs. Los ejemplos habilitan usuarios seleccionados de cuentas ACTIVE y mantienen deshabilitadas las suspendidas. Estados como STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED y LOCKED_OUT requieren correspondencia explícita con el comportamiento previsto de activación, creación de contraseña o acceso.

Crea un método de autenticación de FoxIDs para cada proveedor social o empresarial conectado actualmente mediante Okta, estableciendo confianza directa con él. Los usuarios conservan sus cuentas y credenciales en el proveedor.

Identifica el proveedor de cada conexión. Usa la guía de integración correspondiente, como Google o Microsoft Entra ID, y selecciona el método compatible de OpenID Connect, SAML 2.0 o WS-Federation.
Registra o configura FoxIDs en el proveedor. Intercambia los ajustes del cliente o metadatos de federación y configura las URL de devolución de llamada y cierre de sesión indicadas en la guía. Conserva la conexión de Okta durante la transición.
Permite el nuevo método de autenticación en la aplicación de FoxIDs. Configura Home Realm Discovery para que los usuarios puedan seleccionar su proveedor o ser dirigidos a él mediante las reglas configuradas.
Asocia la identidad del proveedor con la cuenta existente de la aplicación. Si necesitas almacenar reclamaciones o asignaciones de acceso por usuario en FoxIDs, configura y aprovisiona usuarios externos.
Recrea las restricciones de acceso que antes aplicaba Okta, incluidas asignaciones de aplicaciones, usuarios suspendidos y MFA requerida.

El flujo esperado es aplicación → FoxIDs → proveedor de identidad externo → FoxIDs → aplicación. FoxIDs emite los tokens de la aplicación después de que el proveedor autentique al usuario.

Puedes probar cada conexión iniciando sesión desde la aplicación, seleccionando el proveedor y completando su flujo de inicio de sesión. Esto permite observar la MFA, la cuenta y los permisos en la aplicación y el comportamiento del cierre de sesión.

Migrar usuarios de Active Directory

Si Okta delega la autenticación con contraseña a Active Directory y AD sigue siendo el origen, FoxIDs puede conectarse directamente mediante Directory Connector para Active Directory. Configura el conector y el método Login según esa guía. FoxIDs sincroniza usuarios desde AD y valida las contraseñas contra AD, por lo que estos usuarios no necesitan importación CSV de contraseñas.

De forma predeterminada, FoxIDs guarda una copia local de la contraseña tras una validación correcta con Directory Connector. Esto permite pasar más adelante a autenticación local en FoxIDs desactivando el conector. Los usuarios cuyas contraseñas no se hayan capturado pueden usar la creación de contraseña. Consulta el comportamiento de contraseñas de Directory Connector para las opciones de configuración.

Un usuario de Okta procedente de AD no necesariamente sigue autenticándose contra AD: Okta puede migrar la autenticación con contraseña de AD a Okta. El conector directo se aplica cuando AD todavía conserva y valida la contraseña usada.

Migrar usuarios sin contraseña

Importa los usuarios como internos de FoxIDs sin contraseña y configura el inicio de sesión sin contraseña con un código por correo o SMS. El usuario introduce el código en la página que ya tiene abierta.

Esto supone un cambio de método de autenticación para los usuarios de Okta FastPass o passkeys. Los códigos por correo electrónico y SMS no ofrecen la misma resistencia al phishing que FastPass.

Activa el correo o teléfono como identificador de inicio de sesión en el método de autenticación FoxIDs Login y habilita Passwordless with email (one-time password) o Passwordless with SMS (one-time password) según corresponda.
Para un método dedicado a usuarios sin contraseña, selecciona Disable password authentication y desactiva la creación/restablecimiento de contraseña por correo y SMS.
Importa los usuarios omitiendo Password y todos los campos de hash. Mantén SetPasswordEmail, SetPasswordSms y ChangePassword en false. Conserva los estados asignados de verificación y deshabilitación y las reclamaciones necesarias.

Por ejemplo, este CSV de Seed Tool importa un usuario ficticio sin contraseña por correo cuyo estado anterior de verificación del correo se desconoce:

Email;EmailVerified;SetPasswordEmail;SetPasswordSms;ChangePassword;DisableAccount;Claims
alice@example.com;false;false;false;false;false;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"

Para usuarios de SMS, sustituye Email y EmailVerified por Phone y PhoneVerified con el número elegido y su estado de verificación conocido. Se aplica el mismo procedimiento de carga.

Puedes probar el flujo con un usuario de prueba importado introduciendo su correo o teléfono y el código recibido. Un código válido permite a un usuario habilitado continuar a través de la MFA requerida hasta la aplicación. Tras un acceso sin contraseña correcto, el usuario sigue sin contraseña.

Importar usuarios para crear una contraseña

Activa el inicio de sesión por correo, la autenticación con contraseña y la creación de contraseña por correo en el método FoxIDs Login. Los usuarios importados eligen una contraseña durante su primer inicio de sesión.

Migración con creación de contraseña: exportar y revisar datos de usuarios de Okta, importar usuarios sin contraseña y después iniciar sesión y establecer una contraseña con un código por correo.

La importación prepara las cuentas. La contraseña se crea cuando cada usuario inicia sesión, no durante la importación.

Convierte los registros revisados en un archivo UTF-8 para FoxIDs Seed Tool. Los encabezados distinguen mayúsculas y minúsculas y el separador es un punto y coma. Este ejemplo contiene usuarios ficticios cuyo estado anterior de verificación del correo se desconoce; la segunda cuenta permanece deshabilitada:

Email;EmailVerified;SetPasswordEmail;DisableAccount;RequireMultiFactor;Claims
alice@example.com;false;true;false;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"
suspended@example.com;false;true;true;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO002""]}]"

SetPasswordEmail=true selecciona la creación de contraseña con confirmación por correo. Omite Password y todas las columnas de hash. RequireMultiFactor=true es la política elegida en el ejemplo y requiere configurar los métodos de MFA correspondientes.

Entrega la reclamación de ejemplo legacy_okta_user_id solo a las aplicaciones que la necesiten, mediante su tratamiento configurado de reclamaciones.

Cargar usuarios y examinar el resultado

Utiliza este procedimiento para usuarios sin contraseña y usuarios que elegirán una contraseña en el primer inicio de sesión, con los campos adecuados al método seleccionado.

Seed Tool divide los campos por puntos y coma; los campos entre comillas no pueden contener puntos y coma ni saltos de línea. Utiliza las operaciones de usuarios de Control API si tus valores necesitan una representación de importación más completa.

Descarga y configura Seed Tool para el entorno previsto. Establece SeedSettings.UsersSvcPath en el archivo CSV convertido.
Ejecuta Seed Tool y selecciona U para cargar los usuarios en masa.
Registra los nuevos ID de usuario en la correspondencia de migración.

Puedes probar la carga con un CSV de pocos usuarios en un entorno de pruebas. Seed Tool informa de los recuentos de éxitos y errores. En FoxIDs Control puedes examinar los identificadores, estado de deshabilitación, reclamaciones e indicadores de creación de contraseña de los usuarios importados.

Seed Tool utiliza aprovisionamiento masivo, que puede sustituir usuarios existentes en lugar de fusionarlos. Repetir la carga puede eliminar credenciales y estado y crear nuevos ID de usuario. Ante una importación parcial, concilia el resultado antes de reintentar; utiliza actualizaciones específicas para cambios posteriores.

Para un usuario importado habilitado con SetPasswordEmail=true, el flujo esperado es:

El usuario abre la aplicación e inicia sesión mediante FoxIDs Login.
FoxIDs identifica al usuario por su dirección de correo y envía un código de confirmación.
El usuario envía el código y una contraseña nueva que cumple la política de FoxIDs.
FoxIDs verifica la dirección de correo, guarda la contraseña y borra los indicadores de creación de contraseña. El inicio de sesión continúa por los pasos de MFA requeridos antes de volver a la aplicación.

Importar un usuario no envía el correo de creación de contraseña. Los accesos posteriores con contraseña usan la nueva contraseña de FoxIDs. Si un usuario no puede recibir el código, el proceso de recuperación necesita otra forma de verificar su identidad.

Puedes explorar el flujo con un usuario de prueba siguiendo los pasos anteriores. Estos escenarios muestran los resultados esperados:

Escenario	Resultado esperado
Primer inicio de sesión y posteriores	Llega el correo; la creación se completa con un código válido y una contraseña conforme a la política; el siguiente inicio no repite la creación.
Código no válido o caducado	La creación de contraseña falla sin conceder acceso a la aplicación.
Cuenta deshabilitada	Ni la creación de contraseña ni el inicio de sesión habilitan la cuenta.
Cuenta y permisos	El usuario accede a la misma cuenta y datos de la aplicación con el acceso previsto.
MFA, acceso a API y cierre de sesión	Se aplica la MFA requerida; las API aceptan los tokens previstos y rechazan los no válidos; el cierre de sesión sigue el flujo configurado.

Mantener Okta durante la transición

FoxIDs puede confiar en Okta como proveedor externo mientras las aplicaciones pasan a FoxIDs. Los usuarios se autentican en Okta y FoxIDs emite tokens para la aplicación. Las contraseñas y autenticadores permanecen en Okta; no se copian a FoxIDs.

Para una conexión OpenID Connect:

Crea en Okta una integración de aplicación web OIDC para FoxIDs con Authorization Code Flow. Asigna los usuarios o grupos que iniciarán sesión mediante ella y configura su política de acceso.
Crea un método de autenticación OpenID Connect en FoxIDs. Establece Authority en el emisor de Okta elegido y configura el ID de cliente de Okta en Optional custom SP client ID, su secreto y el método correspondiente de autenticación del cliente en el endpoint de tokens.
Solicita los ámbitos profile y email según sea necesario; FoxIDs incluye openid. Selecciona Read claims from the UserInfo Endpoint instead of the access token or ID token en Show advanced para obtener las reclamaciones mediante UserInfo.
Registra la Redirect URL mostrada por FoxIDs como URI de redirección de inicio de sesión en Okta y configura la URI de redirección de cierre de sesión correspondiente cuando se utilice.
Permite el método de autenticación en la aplicación de FoxIDs y configura Home Realm Discovery para los usuarios que continúan mediante Okta.

El servidor de autorización de organización de Okta admite inicio de sesión OpenID Connect con un emisor como https://example.okta.com. Un servidor personalizado utiliza un emisor como https://example.okta.com/oauth2/default. Utiliza el emisor y la configuración de reclamaciones elegidos para la integración.

Otra opción es un método de autenticación SAML: crea una aplicación SAML en Okta para FoxIDs e intercambia metadatos y ajustes del proveedor de servicios y del proveedor de identidad.

Un inicio de sesión de prueba desde la aplicación muestra la política de autenticación de Okta, las reclamaciones, la correspondencia de cuentas y el cierre de sesión de la nueva conexión. Cuando los usuarios pasen a acceso local en FoxIDs o a proveedores conectados directamente, dirígelos a esos métodos. Mantener alineada la correspondencia de cuentas entre métodos permite seguir utilizando los mismos registros.

Desplegar y conservar una vía de reversión

La migración puede desplegarse por aplicación o grupo. Los usuarios pueden continuar mediante su URL habitual con el flujo configurado: creación de contraseña, código de un solo uso, contraseña del directorio o proveedor externo.

Concilia los usuarios creados, modificados, suspendidos o eliminados desde la exportación, incluidos los cambios de grupos y asignaciones de aplicaciones. Una breve congelación de cambios o conciliación controlada puede mantener alineados origen y destino durante el cambio. Las actualizaciones posteriores deben conservar las credenciales y el estado ya establecidos en FoxIDs.

Supervisa la entrega de correo y SMS, los errores de creación de contraseña, los fallos de inicio de sesión y los problemas de correspondencia de cuentas. La reversión depende de que siga disponible la configuración anterior de Okta. Puedes probar a restaurarla para una aplicación de prueba y observar el regreso al flujo de Okta.

Una contraseña establecida localmente en FoxIDs no se sincroniza de vuelta a Okta. Una reversión utiliza las credenciales que todavía conserva Okta o su proveedor conectado. Los usuarios creados solo en FoxIDs necesitan una vía de acceso si se requiere revertir. Cuando los usuarios y aplicaciones necesarios utilicen sus métodos de destino, puede retirarse la integración de Okta.