Los portales de Odoo ofrecen a clientes y partners acceso a documentos, transacciones y servicios relevantes. Eso plantea una cuestión de diseño de identidad: ¿deberían los usuarios externos compartir el directorio y el modelo de acceso de los empleados?
A veces, una cuenta de invitado empresarial en un tenant de trabajo es apropiada. A mayor escala, o cuando se requiere un inicio de sesión de cliente con marca y registro de autoservicio, Microsoft Entra External ID ofrece un modelo dedicado de gestión de identidad y acceso de clientes.
Conectar ese modelo con Odoo puede ayudar a establecer un límite más claro entre los usuarios internos y los usuarios del portal. Aun así, ese límite necesita admisión explícita, creación de cuentas y reglas de autorización de Odoo.
Los tenants de trabajo y los externos están diseñados para audiencias diferentes
Microsoft define un tenant de trabajo como el entorno para empleados, aplicaciones empresariales internas y recursos de la organización. También puede contener partners invitados y huéspedes. Un tenant externo es una configuración independiente para aplicaciones ofrecidas a consumidores y clientes empresariales. Microsoft describe la distinción en su guía de configuración de tenants.
Un tenant externo contiene su propio directorio de clientes y registros de aplicaciones. External ID añade registro de autoservicio, inicio de sesión, restablecimiento de contraseña, administración de cuentas y federación con proveedores de identidad. La descripción general de External ID explica este modelo dedicado.
Esta separación puede ayudar a una organización a evitar tratar a un cliente como a un empleado solo porque ambos necesiten acceso a un servicio de Odoo.
Elija la audiencia antes de configurar el inicio de sesión
Hay al menos tres audiencias distintas de Odoo a considerar:
Empleados y usuarios internos
Estos usuarios normalmente pertenecen al tenant de trabajo de la organización. Si se les da acceso a Odoo, por lo general necesitan cuentas internas de usuario de Odoo con grupos de acceso cuidadosamente asignados.
Personas de organizaciones partners aprobadas
Algunas empresas quieren usuarios de una lista definida de tenants de clientes o partners de Entra. Una conexión multi-tenant de trabajo con una allow-list exacta de tenants puede ser adecuada cuando todas las organizaciones son conocidas y el acceso está aprobado contractualmente.
La validación del tenant es fundamental. No basta con hacer coincidir solo un dominio de correo, porque los dominios y las direcciones de correo son modificables. Valide el tenant del token y los identificadores inmutables de sujeto u objeto según el diseño de la conexión.
Clientes y usuarios externos
Para aplicaciones orientadas al cliente, un tenant de External ID puede proporcionar un directorio y una experiencia de inicio de sesión separados. Las cuentas de Odoo creadas para esta audiencia normalmente deben ser usuarios del portal, no usuarios internos.
Estos modelos deben configurarse como conexiones separadas cuando sus reglas de admisión y de cuentas de Odoo sean diferentes. Una sola conexión amplia es más difícil de razonar y más fácil de configurar incorrectamente.
External ID admite un recorrido de inicio de sesión para clientes
Los flujos de usuario de External ID definen los métodos de autenticación de clientes y la información recopilada durante el registro. Un flujo se asocia a las aplicaciones registradas para habilitar el registro y el inicio de sesión. Microsoft lo documenta en añadir una aplicación a un flujo de usuario de External ID.
External ID puede admitir cuentas locales y federación con proveedores de identidad, incluidos Microsoft Entra ID y proveedores OpenID Connect personalizados. Los atributos integrados y personalizados se pueden recopilar durante el registro, como se describe en la guía de atributos de cliente de Microsoft.
Recopile solo la información que Odoo realmente necesita, y documente el propósito, la retención y el tratamiento de privacidad de cada atributo.
Los permisos predeterminados ayudan a preservar la separación
Microsoft indica que los usuarios de tenants externos comienzan con permisos predeterminados restringidos. Por lo general, pueden acceder a aplicaciones y administrar su propio perfil, pero no reciben amplios derechos de administración del directorio. Consulte los permisos predeterminados en tenants externos.
Ese límite del directorio no configura automáticamente los permisos del portal de Odoo. Odoo sigue controlando qué registros puede ver un usuario del portal mediante sus propios derechos de acceso y reglas de registro. Pruebe la experiencia del portal con registros de clientes representativos y con más de una compañía o cuenta para asegurarse de que los datos estén aislados correctamente.
No eleve a un nuevo usuario externo a usuario interno de Odoo a menos que exista un proceso empresarial separado y aprobado.
Use un flujo moderno y validado de OpenID Connect
Microsoft admite el flujo de autorización code flow de OAuth 2.0 con Proof Key for Code Exchange y OpenID Connect para aplicaciones web basadas en servidor. Su documentación del flujo de autorización code flow describe esa combinación admitida.
OIDC amplía OAuth 2.0 para la autenticación. Microsoft publica metadatos de descubrimiento, detalles de endpoint y claves públicas de firma. También recomienda validar el token devuelto y comprobar un nonce para reducir el riesgo de repetición. Consulte OpenID Connect en Microsoft identity platform.
Una integración segura debe validar el issuer, audience, signature, tenant context y nonce esperados. PKCE no sustituye la validación del token, la configuración exacta del callback, TLS ni la protección del client secret.
El inicio de sesión básico puede solicitar ámbitos estándar de OIDC como openid, profile y email. Microsoft señala que estos ámbitos están alojados en Microsoft Graph y recomienda solicitar solo los permisos que la aplicación necesite. Consulte ámbitos de Microsoft identity platform. Por tanto, una afirmación precisa del producto es "sin permisos de Microsoft Graph API de alto privilegio para el inicio de sesión estándar", en lugar de una afirmación general de que Graph no interviene.
Decida cómo llegarán los usuarios externos a Odoo
Antes de habilitar el primer inicio de sesión, defina:
- Si el autoservicio de registro está abierto o requiere aprobación.
- Qué tenants o proveedores de identidad están admitidos.
- Si se puede vincular una cuenta de portal de Odoo existente.
- Qué identificador inmutable de Microsoft se almacena después de enlazar.
- A qué empresa y contacto de Odoo pertenece el usuario.
- Qué grupos de portal y reglas de registro se aplican.
- Qué ocurre cuando se retira el acceso.
- Cómo se revoca una sesión activa de Odoo.
La creación automática de cuentas puede reducir la administración, pero solo debe producirse después de que la identidad cumpla las reglas de admisión de la conexión. Una autenticación correcta de Microsoft demuestra el control de la identidad aceptada. Por sí sola no demuestra que la persona deba ver los registros de Odoo de un cliente concreto.
Planifica la atención al cliente y la recuperación
Es posible que los usuarios externos no tengan un servicio de asistencia interno. Publica una vía de soporte e identifica quién gestiona la identidad. Prueba los escenarios de restablecimiento de contraseña, recuperación, eliminación del inquilino y cambio de correo electrónico. Mantén los eventos de diagnóstico útiles, pero anonimizados.
Si tu necesidad inmediata es el acceso de empleados, lee por qué deberías proteger tu instancia de Odoo con Microsoft SSO. Para los permisos internos, consulta centralizar el acceso a Odoo con grupos de Entra y roles de aplicación.
Conecta audiencias externas a Odoo 19
Nuestro módulo Microsoft Entra SSO for Odoo admite conexiones separadas para empleados, organizaciones aprobadas y audiencias de clientes de Microsoft Entra External ID. Las conexiones de External ID crean usuarios de portal de forma predeterminada, mientras que las conexiones de la plantilla crean usuarios internos. La configuración guiada valida la información de descubrimiento y las claves de firma, y después requiere una prueba interactiva antes de habilitar el inicio de sesión con Microsoft.
El módulo no decide quién debe ser admitido ni qué registros de clientes debe ver. Eso sigue siendo una decisión empresarial y de acceso en Odoo. Revisa el módulo si necesitas un puente controlado entre la identidad de cliente de Microsoft y un portal de Odoo 19, con gestión de cuentas específica por audiencia en lugar de una única ruta de inicio de sesión sin diferenciación.