En esta publicación , analizaremos cómo lidiar con la migración de contraseñas hash de  su proveedor de identidad actual a  Azure AD B2C . L as migraciones de contraseñas en las que  tiene  acceso a las contraseñas de los usuarios en texto claro (¡aterrador!) o tiene  acceso al IDP heredado para la validación de credenciales en tiempo real  son problemas más simples de manejar. Entonces, en su lugar, profundicemos en  cómo  podría  abordar una situación en la que ha decidido separarse de su proveedor de identidad existente  y encontrarse con  una lista gigante  exportada de objetos  de usuario  con sus contraseñas hash y quizás salts.

Migración de objetos de usuario a Azure AD B2C

Antes de comenzar a migrar su lista de usuarios a  Azure AD B2C , deberá asegurarse de haber creado atributos equivalentes en el  repositorio de usuarios de B2C que coincida con el esquema de su lista de usuarios. Además de imitar su esquema, también deberá crear algunos atributos más:

  • ‘Usuario migrado’ – una marca que indica si la migración de un usuario en particular está completa
  • Sal  (opcional) – si el IDP heredado tenía sales separadas por contraseña, también deberá crear un atributo en B2C para almacenar la sal de la contraseña.   Esto incluye algunos esquemas que incluyen la sal dentro del hash de la contraseña.

Ahora que tiene el esquema configurado,  use MS Graph  para cargar de forma masiva su lista exportada en Azure AD B2C. Asegúrese de asignar el hash de la contraseña anterior para almacenarlo en el  atributo ‘contraseña’ encriptado  de B2C en  lugar de un atributo de extensión normal, ya que es menos seguro . B2C tiene su propio algoritmo hash que se ejecuta en cualquier cadena almacenada en el atributo de contraseña. Lo que esto significa es que después de la migración, B2C tiene un hash de un hash de las contraseñas de sus usuarios.

Ingeniería inversa de la API hash de contraseña

A continuación,  deberá   configurar una API que implemente el algoritmo hash heredado  . En la mayoría de los casos, podrá encontrar documentación que describa el algoritmo hash, la cantidad de iteraciones  para las que se ejecuta el algoritmo y las que utiliza su almacén de credenciales existente  . Con eso, debería poder tomar prestado un código de  https://github.com/topics/hashing-algorithms  e implementar  una instancia a escala de la nube de la API hash. La mayoría de los algoritmos hash que usan un salt tendrán el salt incrustado en la propia cadena de contraseña hash o estará disponible como un salt separado por objeto de usuario. Deberá probar su implementación de hash con algunas contraseñas de prueba para garantizar que la codificación de una cadena de contraseña conocida dé como resultado el mismo resultado tanto del sistema heredado como de su API de hash.

Actualizaciones de políticas B2C

Habiendo configurado los componentes básicos para esta migración, ahora es el momento de actualizar las políticas personalizadas de B2C para orquestar un viaje de usuario para  los usuarios que se están migrando.

Cuando un usuario ingresa su contraseña en su aplicación o sitio web,  su política deberá ejecutar la siguiente secuencia:

  1. Pase la contraseña de texto claro a la API hash y obtenga Hash (Old_PW)
  1. Valide Hash (Old_PW) con el valor almacenado en el atributo de contraseña de Azure AD B2C
  1. Si los valores coinciden, sobrescriba el atributo de contraseña de B2C que actualmente almacena Hash (Old_PW) con  la contraseña de texto sin cifrar del paso n.° 1.  Si los valores no coinciden, el usuario ha ingresado una contraseña incorrecta y puede devolverle un error.
  1. Alterne la  marca ‘Usuario migrado’  y borre los campos de valor de ‘Sal migrada’ para ese usuario.  Después  de completar  el paso n.º 3 y el paso n.º 4, no hay más reliquias del hash de contraseña heredado almacenado en el perfil de este usuario.

En los inicios de sesión de usuarios posteriores , su política puede buscar el indicador ‘Usuario migrado’, determinar que un usuario ya completó la migración y comparar su contraseña de texto sin cifrar directamente con la contraseña almacenada en B2C en lugar de invocar la API de hash de contraseña.

Reducción del tiempo de inactividad de la migración

Una última cosa a tener en cuenta es que si se trata de una migración masiva de usuarios  de varios millones de registros, la escritura de MS Graph en Azure AD B2C puede tardar varias horas. En promedio, puede esperar  escribir alrededor de 500 000 registros por hora. Si su migración lleva varias horas, existe una pequeña probabilidad de que sus clientes hayan cambiado sus contraseñas en el sistema heredado antes de que se complete su migración a Azure AD B2C. Programar una ventana de mantenimiento prolongada generalmente no es bueno para el negocio . En cambio, una buena opción a considerar será permitir que los usuarios inicien sesión en el sistema heredado durante el esfuerzo de migración principal y luego efectuar una ventana de mantenimiento mucho más corta durante la cual ejecuta una consulta delta en elconjunto de datos del sistema anterior para capturar solo los registros que se actualizaron y escribir los registros de usuario actualizados en Azure AD B2C antes de la transición.

Si tiene preguntas, comentarios o ideas interesantes sobre cómo ha abordado los patrones de migración en Azure AD B2C, deje una nota en los comentarios. ¡Nos encantaría saber de usted!