Funcionalidad y consideraciones sobre el aprovisionamiento de usuarios para su implementación de B2B IAM.
Es importante definir desde el principio cómo se registrarán los usuarios, ya que las decisiones que tome aquí influirán en muchas de las que deberá tomar más adelante. Hemos observado que existen varios patrones habituales sobre cómo se agregan los usuarios a su sistema, así como ciertos aspectos que conviene tener en cuenta al diseñar el flujo de trabajo.
Aunque Auth0 admite numerosos flujos de trabajo, los flujos web que usan Universal Login de Auth0 para el registro se consideran una práctica recomendada tanto del sector como de Auth0, ya que ofrecen una funcionalidad óptima y la mejor seguridad.
Auth0 admite el registro de usuarios a través de varios proveedores de identidad. Durante el registro, Auth0 aprovisiona el perfil del usuario para que contenga la información de su cuenta. Hay varios aspectos que se deben tener en cuenta al evaluar la funcionalidad y el flujo de trabajo:
¿Se agrega un usuario al dominio de su empresa o pertenece, o sigue perteneciendo, al dominio de su organización?
Si el usuario permanece en su propio dominio, ¿pertenece a una sola organización o puede pertenecer a varias organizaciones?
¿Cómo aprovisiona la propia organización en su sistema?
¿Debería usar Auth0 como almacén de identidades?
¿Puede usar su propio almacén de identidades heredado con Auth0?
¿Cómo migra las identidades de usuario desde su almacén de identidades a Auth0?
¿Pueden sus usuarios registrarse usando el de su organización?
¿Se puede invitar a sus usuarios o pueden autorregistrarse?
Una de las primeras decisiones que debe tomar al ofrecer su(s) servicio(s) a otras empresas es identificar a qué dominio pertenecen los usuarios. Según la respuesta a esa pregunta, puede adoptar distintos enfoques para aprovisionar a esos usuarios. Consulte Aprovisionamiento de usuarios de la organización para obtener más información. Una vez que sepa cómo quiere que las organizaciones estén representadas en su sistema, deberá considerar cómo va a aprovisionar la propia organización. Consulte Aprovisionamiento de organizaciones para obtener más información.Auth0 proporciona un almacén de identidades listo para usar que puede aprovechar para almacenar de forma segura las credenciales de los usuarios. Consulte Autorregistro para obtener más información. Si ya tiene un almacén de identidades heredado y desea descargar su gestión, las capacidades de Migración de usuarios le ofrecen varias opciones para hacerlo.Como alternativa, si debe mantener su almacén de identidades heredado —quizá porque tiene aplicaciones que aún no está listo para migrar o que no pueden migrarse—, puede usar la funcionalidad de proxy de almacén de identidades. Permitir que sus clientes usen un modelo de “traiga su propia identidad” también es una opción atractiva y, aunque observamos que nuestros clientes no suelen hacerlo al principio, puede usar la funcionalidad de Registro social para ofrecerlo.
Lo que deba hacer al aprovisionar una organización dependerá de cómo se representen las organizaciones en su sistema. Puede ser útil tomarse un momento para dar un paso atrás y considerar cómo interactuarán con sus aplicaciones los usuarios de esas organizaciones. Consulte Arquitectura de múltiples organizaciones para determinar cómo configurar las organizaciones para su sistema de IAM.Al aprovisionar organizaciones, debe tener en cuenta lo siguiente:
Deberá agregar la organización a la configuración de su propia aplicación y/o base de datos
Deberá realizar cambios en su configuración de Auth0. Esto incluirá algunas o todas las acciones siguientes:
En casos excepcionales: crear un inquilino único para la organización
Crear una nueva Organización en su Tenant de Auth0
Agregar una nueva conexión de base de datos para esa Organización (si tiene usuarios aislados por organización)
Habilitar la conexión de base de datos compartida existente para esa Organización (si comparte usuarios)
Agregar una conexión empresarial para esta Organización y habilitarla en la Organización
Esto implicará trabajar con la organización para actualizar su configuración actual o agregar configuración para su inquilino de Auth0 si no es una organización heredada.
Aprovisionar un administrador para la organización
También es posible que desee crear un portal de autoinscripción para sus Organizaciones. Esto permite que sus clientes creen la organización por sí mismos. Esto puede formar parte del Portal de administración de organizaciones.
Un portal de administración de organizaciones es un portal que permite a sus administradores crear, modificar y eliminar organizaciones. Estos administradores pueden ser empleados de su empresa o administradores de clientes. Hay varias tareas que deben realizarse tanto en su propio sistema como en su Tenant de Auth0. Es probable que este portal deba existir en su propio sistema para que tenga acceso a sus almacenes de datos y a su configuración. Sin embargo, Auth0 proporciona la Auth0 Management API para que pueda incorporar cambios en su Tenant de Auth0 al mismo tiempo que realiza los cambios en su propio sistema.Hay dos enfoques principales para crear una nueva organización. El que elija depende en gran medida de cuánto tiempo esté dispuesto a esperar para implementar una nueva organización.
Actualizaciones en vivo en su Tenant de Auth0: Si desea poder crear nuevas organizaciones en tiempo real, probablemente querrá realizar los cambios directamente en su Tenant de Auth0 mediante la Auth0 . Esto permite que los cambios se apliquen en tiempo real y que la incorporación de una nueva organización surta efecto de inmediato. En particular, si ofrece autoregistro para organizaciones, quizá le convenga optar por este enfoque.
Las actualizaciones en vivo sí implican algunas consideraciones. Hay ciertas operaciones que deben realizarse en serie para evitar problemas. Habilitar clientes en una conexión y agregar URL de callback a una aplicación son dos ejemplos. Cualquier operación en la Management API en la que deba recuperar una lista completa y volver a enviarla completa con un valor nuevo agregado debe realizarse en serie para evitar que dos operaciones paralelas sobrescriban uno de los valores.
Cambiar el repositorio y volver a implementar: Si está aprovechando Deploy CLI (o una CLI personalizada) como parte de su canalización de CI/CD, puede que prefiera enviar los cambios directamente a su repositorio y luego iniciar una nueva implementación. Esto puede llevar un poco más de tiempo, pero ofrece ventajas relacionadas con el historial de versiones y la posibilidad de revertir un cambio volviendo a implementar la versión anterior. También puede ser conveniente tener un repositorio independiente solo para los elementos que necesitan las organizaciones, para no tener que volver a implementar otros componentes comunes y correr el riesgo de cometer un error.
Además de alojar el Perfil de usuario, Auth0 también puede tanto actuar como proxy de su almacén de identidades heredado como proporcionar un reemplazo seguro alojado por Auth0. Ambas capacidades se admiten mediante el uso de Conexiones de base de datos de Auth0. Si decide usar Auth0 como reemplazo de su almacén de identidades heredado, puede migrar usuarios de una sola vez con la migración masiva o de forma progresiva con la migración automática.
Los clientes suelen optar por un enfoque de dos etapas para la migración de usuarios: primero usan la migración automática para migrar la mayor cantidad posible de usuarios y luego usan la migración masiva para los usuarios restantes. Consulte Escenarios de migración de usuarios para obtener más información.
Se prefiere la migración automática, ya que permite migrar a los usuarios de forma individual y también conservar sus contraseñas existentes en casi todas las situaciones. Para la migración masiva, recomendamos usar la Management API en lugar de la extensión User Import/Export en todos los casos salvo los más simples, ya que la Management API ofrece mayor flexibilidad y control.Con la migración masiva, los usuarios normalmente deben restablecer su contraseña una vez completada la migración, a menos que las contraseñas estén almacenadas con hash en su almacén de identidades heredado mediante uno de los algoritmos compatibles. En este caso, puede que pueda usar la migración masiva y conservar las contraseñas de los usuarios como parte del proceso, según el algoritmo y la cantidad de rondas de salt utilizadas. Consulte Ejemplos de esquema de base de datos para importación masiva para obtener más información.
La importación de contraseñas con hash depende de que el almacén de identidades de origen use implementaciones estándar de uno de los siguientes algoritmos: argon2, bcrypt, hmac, ldap, md4, md5, sha1, sha256, sha512, pbkdf2 y scrypt.
Las llamadas a la Management API están sujetas a la política de limitación de tasa de Auth0. Debe tener esto en cuenta y, para ayudarle, Auth0 generalmente recomienda usar el SDK de Auth0 adecuado para su entorno de desarrollo en lugar de llamar directamente a nuestras API.
Los tipos de conexión de base de datos de Auth0 también se pueden configurar para que actúen como proxy de un almacén de identidades existente (heredado). Si necesita mantener las identidades de usuario definidas en su propio almacén heredado —por ejemplo, si tiene una o más aplicaciones críticas para la empresa que no puede migrar a Auth0, pero que aún necesitan acceder a estas identidades—, puede integrar fácilmente ese almacén con Auth0. Consulte Autenticar usuarios con su base de datos para obtener más información.
Una organización debe corresponder directamente a uno de sus clientes o socios comerciales. Cada cliente o socio comercial con el que trabaja tiene usuarios que iniciarán sesión. A esos usuarios finales los llamamos “usuarios de la organización”. Existen dos enfoques distintos para almacenar los usuarios de su organización:
Aislados en la organización: Cada usuario pertenece exactamente a una organización. No tendría sentido que ese usuario formara parte de más de una organización y, aunque así fuera, tendría sentido que tuviera una “identidad” independiente para esa otra organización. Por ejemplo, un empleado minorista que trabaja a tiempo parcial en dos tiendas distintas tiene dos inicios de sesión diferentes, uno para cada tienda, aunque ambas usen la aplicación SaaS. Para obtener más información, consulte Aprovisionamiento de usuarios aislados en la organización.
Compartidos entre organizaciones: En un caso como este, los usuarios crean credenciales en su empresa o pueden acceder a instancias de su aplicación de otras organizaciones usando credenciales de su propia organización. Una forma sencilla de verlo es que un usuario puede estar autorizado para acceder a la instancia de la aplicación de más de una organización. Un usuario entendería que puede usar las mismas credenciales para acceder a ambas instancias de una aplicación. Por ejemplo, algunos médicos trabajan con varias clínicas y pueden necesitar iniciar sesión en cada clínica por separado con las mismas credenciales. Para obtener más información, consulte Aprovisionamiento de usuarios compartidos entre organizaciones.
Aprovisionamiento de usuarios aislados por organización
Aislar a los usuarios por organización puede crear una separación clara entre organizaciones. Si ningún usuario necesita acceder a más de una organización (o si prefiere obligarlos a crear varias cuentas), este es un enfoque atractivo.Debe aprovisionar a esos usuarios en el nivel del IdP. Cada una de las organizaciones tendrá su propio IdP para ello. Este IdP puede adoptar una de estas tres modalidades:
Su Tenant de Auth0 es el IdP: una Conexión de base de datos en su inquilino principal dedicada a esta organización.
Las organizaciones aportan su propio IdP: usted configura una Conexión empresarial para ellas.
Organizaciones con más de un IdP: usted habilita más de una Conexión empresarial, una Conexión social y también puede tener una única Conexión de base de datos. Cuando el usuario elija su organización e intente iniciar sesión, podrá elegir entre todas las conexiones que se hayan habilitado para esa organización.
Recomendamos usar Auth0 como IdP como punto de partida porque es sencillo implementar un flujo de invitación de usuarios. En comparación con otros flujos de invitación, lo único particular en este caso es que la persona que crea al usuario tendrá que seleccionar la organización de antemano, o bien el sistema forzará que la organización coincida con la del usuario que realiza la invitación (en situaciones en las que hay un administrador de la organización que pertenece únicamente a esa organización).
Aprovisionamiento de usuarios compartidos entre organizaciones
Al compartir usuarios entre organizaciones, necesitará una forma de autorizar el acceso. Como al autenticarse no sabrá a qué organización podría pertenecer un usuario, normalmente recomendamos almacenar a sus usuarios en un único dominio y luego determinar a qué organizaciones pueden acceder agregándolos como miembros de la organización. Por ello, el aprovisionamiento suele hacerse comenzando con un flujo de invitación de usuarios para la única conexión de base de datos, y luego se les agregará a la organización mediante la Management API. Después, puede usar la Management API para consultar a qué organizaciones pertenece el usuario si necesita ofrecerles una forma de cambiar de organización.
Auth0 no se comunicará con el IdP de origen si hay una sesión activa de con Auth0, a menos que lo fuerce con prompt=login. Si una de las organizaciones de sus clientes no puede gestionar el cierre de sesión de esos usuarios, es posible que esos usuarios sigan teniendo acceso después de haber sido dados de baja. Según el IdP, si Auth0 obtiene un token para su API, puede solicitar información sobre el usuario al IdP en una Rule para comprobar periódicamente si ese usuario debería seguir teniendo acceso o no. Si no dispone de esta capacidad, tendrá que proporcionar a las organizaciones de sus clientes una forma de bloquear o dar de baja usuarios en su sistema, ya sea mediante una llamada a la API o una interfaz de usuario.
En la mayoría de los escenarios B2B, solo determinadas personas pueden acceder a la aplicación. Por eso, suele ser más sencillo que un administrador aprovisione las cuentas de usuario en lugar de permitir que los usuarios se registren y que luego un administrador los apruebe. El aprovisionamiento también suele poder realizarse de forma automatizada cuando se agregan usuarios a un sistema centralizado.Hay tres perfiles distintos que podrían estar invitando usuarios:
Un administrador de su empresa puede crear los usuarios de cada organización.
Se puede asignar a un administrador de cada organización la tarea de crear usuarios.
Puede existir otro sistema responsable de crear usuarios, y ese sistema puede luego crear un usuario en Auth0. Independientemente de la , la técnica puede ser similar. El resto consiste en usar el modelo de autorización adecuado para la aplicación.
El enfoque recomendado para la invitación de usuarios es usar la funcionalidad de Organizations para lograrlo. Si no está utilizando la funcionalidad de Organizations para implementar invitaciones de usuarios y está creando su propia solución, es importante crear cada usuario con el parámetro user.email_verified establecido en false y una contraseña temporal aleatoria. La contraseña generada solo debe conocerla Auth0 y no debe almacenarse en ningún sistema externo ni facilitarse al usuario. Luego, use la Management API para enviar un correo electrónico al usuario con un enlace para restablecer su contraseña; incluso puede modificar la plantilla de correo electrónico en Auth0 para reflejar que esto también forma parte de un flujo de registro por invitación. Esto garantiza que la dirección de correo electrónico del usuario pertenezca al usuario que se está creando y que la única persona que conozca la contraseña sea el propio usuario.
Uno de los principios fundamentales de OIDC es que nadie, salvo el propio usuario, conoce nunca su contraseña. Si está implementando un flujo de invitación, haga que su sistema de backend genere una contraseña aleatoria y luego la descarte, y haga que el usuario restablezca su contraseña antes de iniciar sesión por primera vez. No cree una contraseña temporal ni se la entregue para que inicie sesión la primera vez.
El registro empresarial equivale a iniciar sesión mediante inicio de sesión empresarial; aquí no existe una distinción como tal, ya que la creación del perfil del usuario se produce automáticamente en el primer inicio de sesión empresarial.
Una ventaja importante de permitir que sus clientes usen su propio IdP es que pueden administrar a sus usuarios y asignar roles y acceso en su propio IdP, en lugar de obligarle a desarrollar esa administración para ellos. Definir el mapeo para esos clientes hará que esto sea mucho más fácil.
Si el mapeo no es suficiente y debe incluir metadatos en su sistema, tenga en cuenta que Auth0 no creará al usuario hasta que inicie sesión en el sistema por primera vez. Por lo tanto, deberá usar la extensibilidad de reglas para obtener la información inicial de otra fuente, o forzar a los usuarios a iniciar sesión por primera vez antes de poder agregar los metadatos.
Ofrecemos una guía de planificación en formato PDF que puede descargar y consultar para obtener más información sobre nuestras estrategias recomendadas.Guía de planificación del proyecto de B2B IAM
Arquitectura de múltiples organizaciones (multitenencia)
Muchas plataformas B2B implementan algún tipo de aislamiento o de marca para la organización de sus clientes, y esto puede añadir complejidad a cualquier sistema de gestión de identidades y accesos (IAM). Si este es su caso, le recomendamos que dedique algo de tiempo a leer nuestra guía y las prácticas recomendadas para este tipo de entorno.Arquitectura de múltiples organizaciones
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma