Una migración de contraseñas no es una copia de base de datos. Cuando se trasladan usuarios entre identity providers, a menudo la fuente no puede proporcionar una contraseña que el destino pueda reutilizar. Aunque una exportación contenga hashes de contraseñas, un hash generado para una plataforma no es automáticamente válido en otra.
En algunos casos, los usuarios pueden conservar su contraseña actual sin un restablecimiento forzado. El método seguro depende de lo que pueda exportar la fuente, de si puede validar contraseñas online, del tiempo que pueda seguir disponible y de si la migración puede vincular cada cuenta a un identificador de origen estable.
Este artículo ofrece un modelo de decisión para elegir entre una importación compatible, la validación gradual de contraseñas, la validación externa continuada y un restablecimiento controlado. Se centra en la ruta de las contraseñas. Los protocolos de aplicaciones, los claims, el registro de multi-factor authentication (MFA) y el plan completo de cut-over deben seguir tratándose como líneas de trabajo de migración relacionadas.
Empiece por la fuente, no por la experiencia de usuario deseada
«Sin restablecimiento de contraseña» es un resultado deseable, pero todavía no es un método de migración. Antes de elegir un enfoque, determine qué puede admitir realmente la fuente:
- ¿Puede exportar contraseñas en texto claro o una representación de contraseña que el destino admita expresamente?
- ¿Puede validar la contraseña actual de un usuario mediante una API de validación protegida?
- ¿Puede esa API seguir disponible, supervisada y soportada durante una migración gradual y la ventana de rollback?
- ¿Existe un identificador de usuario de origen estable e inmutable que permita vincular la misma cuenta cuando cambien los identificadores?
- ¿Pueden mantenerse coherentes los cambios y restablecimientos de contraseña mientras intervienen dos sistemas?
- ¿Permiten la política de seguridad, los contratos y la evaluación de riesgos importar o conservar material de contraseñas?
No utilice la dirección de correo electrónico, el número de teléfono o el nombre de usuario como única clave de migración. Esos identificadores pueden cambiar. Una vinculación incorrecta de cuentas es más grave que un restablecimiento porque puede asociar credenciales y acceso a la identidad equivocada.
Elija una de cuatro rutas para las contraseñas
Distintos grupos de usuarios pueden necesitar rutas diferentes. Por ejemplo, los empleados activos pueden migrar gradualmente mediante validación online, mientras que las cuentas externas inactivas reciben un restablecimiento cuando el usuario regresa.
| Capacidad y restricción de la fuente | Ruta defendible | Ventaja principal | Coste o riesgo principal |
|---|---|---|---|
| Hay contraseñas o una representación compatible con el destino disponibles y pueden tratarse de forma segura | Importación por lotes controlada | Los usuarios pueden autenticarse inmediatamente en el destino | La exportación, el transporte y el tratamiento del material de contraseñas amplían la frontera de seguridad |
| La fuente puede validar online las contraseñas existentes y seguir siendo autoritativa durante la transición | Migración gradual con Directory Connector | Los usuarios activos migran tras un inicio de sesión correcto sin un restablecimiento general | La fuente y el connector permanecen en la ruta de authentication de producción hasta el cut-over |
| Los usuarios ya están aprovisionados en FoxIDs y solo siguen siendo externas la validación de contraseñas, la comprobación de políticas o la notificación de cambios | External Password API | Mantiene una integración más limitada con el almacén de contraseñas o la política | No proporciona el mismo flujo de creación de usuarios y sincronización de perfiles que Directory Connector |
| No existe una importación compatible segura ni una validación online fiable | Restablecimiento de contraseña verificado | Establece una nueva contraseña de destino con una frontera de trust clara | La comunicación con los usuarios, los canales de recuperación y la capacidad de soporte se vuelven críticos |
Por tanto, la respuesta no es siempre «conservar» ni siempre «restablecer». Elija para cada grupo la ruta menos perjudicial que siga siendo defendible técnica y operativamente.
Migración gradual con Directory Connector
Directory Connector es el principal patrón de FoxIDs cuando un directorio existente o un repository personalizado debe seguir siendo autoritativo durante la transición.
Cuando un usuario inicia sesión con una contraseña, FoxIDs llama a la API del connector. Tras una validación correcta, FoxIDs crea o actualiza el usuario interno a partir de los identificadores, propiedades y claims devueltos. La respuesta incluye un directoryUserId estable que vincula al usuario de FoxIDs con la cuenta de origen, aunque después cambien su dirección de correo electrónico, número de teléfono o nombre de usuario.
Esto crea un flujo just-in-time práctico:
- El usuario inicia sesión en una aplicación a través de FoxIDs con el identificador y la contraseña existentes.
- FoxIDs pide al directorio de origen que valide la contraseña.
- El connector devuelve el identificador de origen estable y los datos de usuario aprobados.
- FoxIDs crea o actualiza el usuario interno y completa la authentication.
- El usuario puede seguir usando la contraseña existente mientras la fuente siga siendo autoritativa.
De forma predeterminada, FoxIDs también guarda una copia local de la contraseña tras una validación correcta del connector o una operación del ciclo de vida de la contraseña a través de este. Esa copia permite un cambio planificado posterior a la validación de contraseñas en FoxIDs sin restablecer la contraseña de todos los usuarios que hayan completado el flujo gradual.
La frontera es importante: mientras Directory Connector esté habilitado, el directorio externo seguirá siendo autoritativo. FoxIDs no utiliza el hash local guardado como fallback automático si el connector no está disponible. Una interrupción del connector es, por tanto, un fallo de la ruta de authentication, no una instrucción para eludir la fuente.
El selector de política de contraseñas que se muestra a continuación es una tercera decisión independiente. Controla si FoxIDs comprueba una contraseña propuesta con la política del entorno FoxIDs antes de llamar al connector. El directorio externo sigue siendo responsable de la contraseña y puede rechazarla según su propia política. Si se utilizan ambas comprobaciones, deben alinearse sus requisitos y las indicaciones para el usuario.
Defina los criterios de salida antes de habilitar el connector
Una migración gradual necesita una condición de finalización. Decida antes del despliegue:
- ¿Qué grupos de usuarios deben haber completado un inicio de sesión correcto antes del cut-over?
- ¿Cómo se tratarán las cuentas inactivas o las de usuarios que nunca regresen?
- ¿Cuánto tiempo deben seguir disponibles la fuente y el connector para realizar rollback?
- ¿Qué latencias y tasas de error del connector detendrán o revertirán el despliegue?
- ¿Cómo se investigarán los conflictos de identificadores, los claims ausentes y las cuentas de origen deshabilitadas o eliminadas?
- ¿Cuándo puede deshabilitarse el connector y FoxIDs pasar a ser autoritativo para las contraseñas?
Guardar una copia local es opcional. Desactívela cuando una política exija que la fuente siga siendo el único almacén de contraseñas, pero tenga en cuenta que esto elimina la ruta hacia un cambio posterior sin restablecimiento.
Cuándo External Password API es la opción más limitada
FoxIDs puede configurar un External Password API como comprobación de contraseñas para usuarios internos. Puede validar una contraseña actual, comprobar una nueva contraseña con una política externa, notificar a otro sistema los cambios de contraseña o combinar estas responsabilidades.
Utilice esta opción cuando los usuarios ya existan en FoxIDs y la necesidad restante se refiera específicamente al almacén o a la política de contraseñas. No la trate como sustituto de Directory Connector cuando la migración también requiera creación de usuarios just-in-time, una vinculación estable con un directorio externo, actualizaciones de perfil o gestión del ciclo de vida de cuentas externas.
Esta distinción mantiene explícita la frontera de integración: Directory Connector representa un directorio externo autoritativo. External Password API representa una dependencia externa para la validación, la política o las notificaciones de contraseñas de usuarios internos.
Cuándo se justifica la importación por lotes
La importación por lotes puede eliminar la dependencia en tiempo de ejecución respecto a la fuente, pero solo cuando la entrada sea adecuada para el destino y pueda protegerse durante toda la transferencia.
FoxIDs permite cargar usuarios internos con contraseñas conocidas, con hashes de contraseña precalculados compatibles con FoxIDs o sin contraseñas. Un hash de una plataforma de origen cualquiera no puede simplemente denominarse hash de FoxIDs. Confirme el algoritmo exacto, el salt y el formato de destino antes de decidir que un hash exportado puede reutilizarse.
Trate la exportación de contraseñas en texto claro como una decisión de seguridad, no como una comodidad. Limite el acceso, utilice una ruta de transferencia controlada, evite que las contraseñas lleguen a logs o archivos ordinarios del proyecto, verifique la eliminación del material temporal y documente quién aprobó la operación. Si ese tratamiento no puede justificarse, elija en su lugar validación online o restablecimiento.
Cuándo es más seguro restablecer la contraseña
Un restablecimiento no demuestra necesariamente que la migración haya fallado. Es la ruta honesta cuando conservar la contraseña existente debilitaría el destino o dependería de supuestos que el equipo no puede verificar.
Prefiera un restablecimiento controlado cuando:
- la fuente no pueda exportar una representación compatible ni validar online la contraseña actual;
- mover material de contraseñas genere una exposición inaceptable o un problema contractual;
- se sepa o sospeche que la contraseña de la fuente está comprometida;
- las cuentas no puedan correlacionarse con suficiente confianza con identidades de origen estables;
- la fuente no pueda seguir siendo fiable durante el periodo necesario de migración gradual y rollback; o
- conservar la contraseña antigua requiera controles más débiles en el destino.
Los usuarios de FoxIDs pueden cargarse sin contraseñas y se les puede pedir que establezcan una mediante un código de verificación enviado por correo electrónico o SMS. Esto solo es seguro cuando el identificador de recuperación pertenece al usuario previsto y el canal de entrega cumple los requisitos de riesgo de la organización. Pruebe códigos caducados, bandejas de entrada o números de teléfono inaccesibles, identificadores duplicados, cuentas bloqueadas y la escalación al soporte antes de un despliegue amplio.
Comunique el motivo y el momento antes de que los usuarios encuentren el restablecimiento. Separe la decisión de seguridad del plan de soporte: un diseño de restablecimiento sólido puede fallar operativamente si los canales de recuperación están obsoletos o el service desk no puede gestionar la carga inicial.
Exija evidencias antes del cut-over de contraseñas
Pruebe la ruta elegida en un entorno FoxIDs independiente y migre primero un grupo de usuarios controlado. Un inicio de sesión correcto es necesario, pero no suficiente.
| Área de decisión | Evidencia necesaria antes de un despliegue más amplio |
|---|---|
| Vinculación de identidad | Identificadores de origen estables, cambios de identificadores probados y tratamiento definido de duplicados o usuarios ausentes |
| Comportamiento de las contraseñas | Contraseñas aceptadas y rechazadas, flujo de contraseña caducada, cambio/restablecimiento y errores de política |
| Disponibilidad | Supervisión del connector o de la API de validación, timeouts, gestión de errores y responsable operativo designado |
| Migración de usuarios | Resultados del piloto para cuentas representativas activas, inactivas, deshabilitadas y restringidas |
| Seguridad | Tratamiento aprobado del material de contraseñas, secrets protegidos, logging de diagnóstico sin contraseñas y conservación de datos revisada |
| Cut-over | Criterios de salida por grupo, tratamiento de usuarios sin contraseña de destino guardada, condición de rollback y responsable de retirar la fuente |
Mantenga la fuente disponible hasta que haya migrado el grupo de usuarios requerido y se haya cerrado la ventana de rollback. No deshabilite el connector solo porque el piloto haya tenido éxito. Verifique la ruta de contraseñas de destino para el grupo que debe funcionar después del cut-over y conserve una ruta de restablecimiento controlada para el resto.
Cómo apoya FoxIDs la decisión
Utilice la documentación de migración para planificar conjuntamente aplicaciones, usuarios, contraseñas, cut-over y rollback. La documentación de Directory Connector, External Password API y carga de usuarios contiene los detalles exactos de implementación.
Si las capacidades de la fuente, los grupos de usuarios o los criterios de cut-over aún no están claros, FoxIDs Identity Migration explica cómo el equipo responsable de la plataforma puede ayudar a diseñar y ejecutar la migración.
Conclusión
Los usuarios solo pueden conservar una contraseña existente cuando la migración mantiene una ruta de validación fiable o establece de forma segura una contraseña de destino compatible. Directory Connector suele ofrecer la ruta gradual menos perjudicial, pero también mantiene la fuente en el flujo de authentication de producción hasta un cut-over deliberado.
Elija el restablecimiento cuando no puedan demostrarse la compatibilidad, la vinculación de identidad o el tratamiento seguro. La estrategia de contraseñas adecuada hace explícitos la fuente autoritativa, el comportamiento ante fallos, el impacto en el usuario y los criterios de salida antes de trasladar el tráfico de producción.