Saltar al contenido principal
La gestión de perfiles en escenarios basados en Organizaciones suele ser igual que en otros escenarios de arquitectura. En nuestros escenarios de arquitectura, ofrecemos orientación general sobre la gestión de perfiles B2B, que le recomendamos revisar junto con la orientación que se proporciona aquí.
Antes de poder gestionar los roles asociados a un usuario, debe existir una cuenta de usuario en Auth0. Esto es así incluso si está usando la capacidad de roles de Auth0 Organizations asociada a la membresía. Sin embargo, a las cuentas de usuario que se aprovisionan mediante el flujo de trabajo de invitación de usuarios se les puede asignar un rol automáticamente como parte del proceso de invitación. Para obtener más detalles, consulte Invitar a miembros de la organización. Si está prerregistrando a un usuario mediante algún otro mecanismo, deberá almacenar la información de Role fuera de Auth0 y acceder a ella o copiarla mediante extensibilidad (por ejemplo, como parte de una Rule) durante la primera autenticación.
Su aplicación puede tener un conjunto específico de atributos de usuario asociados (por ejemplo, preferencias del usuario o información identificativa que utiliza para prestar un mejor servicio al cliente) para los que ofrece algún tipo de autogestión a los usuarios. Además, o como alternativa, puede ofrecer gestión de perfiles de autoservicio para atributos que normalmente mantiene el (IdP).
Práctica recomendadaEn escenarios relacionados con organizaciones, las direcciones de correo electrónico siempre deben verificarse. En consecuencia, debe proporcionar funcionalidad de autoservicio para la verificación del correo electrónico en los casos en que la dirección de correo electrónico de un usuario no pueda verificarse de otra manera. Para obtener más detalles, consulte Verificación de correo electrónico.

​
Conexión de base de datos

Auth0 le permite implementar la gestión de perfiles de autoservicio mediante la de Auth0. Si usa Organizaciones de Auth0 para proporcionar aprovisionamiento de usuarios basado en invitaciones, es probable que deba restringir los cambios en campos que normalmente controla su Tenant de Auth0 como Proveedor de identidad (IdP). Por ejemplo, le convendría restringir los cambios en la dirección de correo electrónico, ya que no querría que un usuario utilizara una dirección distinta de aquella a la que se envió su invitación. Restringir los cambios en el campo de dirección de correo electrónico evitaría que los correos específicos de la empresa se enviaran a direcciones de correo electrónico personales introducidas. Como alternativa, puede considerar ofrecer algunas opciones de autoservicio para los usuarios que se autentican mediante una Conexión de base de datos en Auth0. Es posible que quiera que los usuarios puedan:
  • cambiar su dirección de correo electrónico
  • cambiar cualquier número de teléfono asociado
  • cambiar su username
  • dar de baja sus cuentas como parte del cumplimiento normativo (como el GDPR)
  • realizar el cambio de contraseña, que normalmente recomendamos implementar mediante restablecimiento de contraseña y que, por lo general, aprovechará la marca específica de la organización descrita en Marca: página de restablecimiento de contraseña.
La funcionalidad de autoservicio normalmente debe implementarse y alojarse fuera de Auth0, y debe ser muy segura.

​
Conexión empresarial

Dado que el proveedor de identidad (IdP) ascendente normalmente administra los atributos del perfil de usuario gestionados por el IdP, es posible que la gestión de perfiles prácticamente no sea necesaria en este caso de uso. Sin embargo, si utiliza atributos de usuario específicos de la aplicación, es posible que aun así quiera ofrecer funciones de autoservicio. Además, casi con toda seguridad querrá ofrecer a una organización una forma de desaprovisionar usuarios de su Tenant de Auth0. Auth0 no se comunica con un IdP ascendente, salvo cuando expira la sesión de de Auth0. Como es probable que el tiempo que falta para que expire una sesión de SSO sea demasiado largo para la mayoría de los casos en los que se elimina a un usuario, un administrador de la organización necesitará una forma de bloquearlo o eliminarlo de manera independiente.

​
Conexión social

En el contexto de las conexiones sociales, la gestión de perfiles sigue un patrón similar al de una conexión empresarial, pero el IdP ascendente está asociado con el proveedor social en lugar de con una organización específica.

​
Administración

En determinadas situaciones, querrá dar a sus clientes acceso para gestionar las cuentas de usuario asociadas a su organización. Esto suele ocurrir en escenarios propios de un servicio de asistencia, en los que un operador puede actualizar la información del perfil en nombre de un usuario o ayudarle a desbloquear una cuenta. De forma predeterminada, Auth0 proporciona el , que se utiliza para la administración general de un Tenant de Auth0. Sin embargo, no querría dar a un cliente acceso al Dashboard de su Tenant de Auth0, ya que entonces podría administrar todos los usuarios de todas las organizaciones, lo cual no sería deseable.
Aunque el Dashboard del Tenant de Auth0 puede utilizarse para administrar cuentas de usuario, no ofrece aislamiento a nivel de organización. Dar a un cliente acceso a su Auth0 Dashboard le permite modificar usuarios de todas las organizaciones, lo cual no es deseable. El dashboard de administración delegada de Auth0 puede configurarse para proporcionar administración de cuentas de usuario con reconocimiento de Organizaciones de Auth0; sin embargo, no puede utilizarse para administrar la membresía ni las invitaciones de usuarios.
Si ya ofrece capacidades de tipo servicio de asistencia para sus clientes, puede usar Auth0 Management API para administrar cuentas de usuario en Auth0. Por ejemplo, Management API puede usarse para obtener los miembros de una organización y las organizaciones a las que pertenece un usuario. Si todavía no ofrece capacidades de servicio de asistencia, deberá desarrollar esta funcionalidad si la necesita.