El inicio de sesión único responde a una pregunta de autenticación: ¿ha verificado Microsoft a este usuario según la política de la organización? No responde a todas las preguntas de autorización dentro de Odoo.
Un usuario autenticado podría necesitar acceso a ventas pero no a contabilidad, proyectos pero no nóminas, o un portal de clientes pero no a la interfaz interna. Esas decisiones siguen siendo responsabilidad de Odoo. Los grupos y roles de aplicación de Microsoft Entra pueden aportar entradas de confianza para hacerlas más coherentes.
Los grupos y los roles de aplicación cumplen funciones diferentes
Los grupos de Microsoft Entra pertenecen al inquilino. Pueden representar departamentos, funciones laborales, proyectos o límites de seguridad. Los roles de aplicación pertenecen a un registro de aplicación concreto y describen roles que son significativos para esa aplicación.
La documentación de roles de aplicación de Microsoft explica que los roles de aplicación pueden asignarse a usuarios o grupos. Cuando un usuario asignado inicia sesión, Entra puede incluir los roles concedidos en una reclamación de roles. Microsoft también indica que los roles de aplicación y los grupos no se excluyen mutuamente.
Esto ofrece al diseño de acceso de Odoo dos patrones principales:
- Mapear directamente los Object IDs de los grupos de seguridad estables de Entra a grupos seleccionados de Odoo.
- Definir roles de aplicación orientados a Odoo en la aplicación de Entra, asignar usuarios o grupos a esos roles y mapear los valores de rol resultantes a grupos de Odoo.
El mapeo directo funciona bien con grupos de seguridad gobernados. Los roles de aplicación pueden ofrecer un límite de aplicación más limpio porque su intención viaja con el registro de la aplicación en lugar de depender de nombres específicos del inquilino.
Empieza con el modelo de acceso real de Odoo
No empieces copiando todos los grupos de Microsoft a Odoo. Empieza con los permisos de Odoo que el negocio realmente necesita.
Enumera los grupos de Odoo que otorgan capacidades materiales. Para cada uno, documenta:
- El propósito empresarial del acceso.
- La persona responsable de aprobarlo.
- El grupo de Entra o rol de aplicación que representa la aprobación.
- Con qué rapidez debería llegar el cambio a Odoo y qué ocurre con una sesión activa tras la retirada.
Usa el principio de mínimo privilegio. Un grupo amplio de departamento puede ser conveniente, pero puede conceder más acceso a Odoo del que necesita cada miembro. Un grupo de seguridad o rol de aplicación más pequeño, específico de Odoo, suele ser más fácil de auditar.
Trata la vinculación de identidad como un control de seguridad
Muchos sistemas inicialmente emparejan una cuenta existente usando una dirección de correo electrónico. Esto es cómodo, especialmente cuando Odoo y Microsoft ya usan el mismo correo corporativo. No es una clave de identidad duradera.
Microsoft advierte en su referencia de reclamaciones del token ID que las direcciones de correo electrónico, los números de teléfono y los nombres principales de usuario pueden cambiar y pueden reutilizarse. Microsoft recomienda reclamaciones inmutables como sub u oid, con tid cuando se requiera contexto de inquilino, para una identificación fiable.
Un patrón más seguro es:
- Aceptar solo un inquilino esperado y una audiencia aprobada.
- Usar el correo electrónico para una coincidencia inicial controlada cuando proceda.
- Rechazar coincidencias ambiguas o duplicadas.
- Almacenar la identidad inmutable de Microsoft y los identificadores del inquilino después de vincular.
- Usar esos valores inmutables para futuros inicios de sesión.
Para el acceso multiinquilino, el contexto del inquilino es esencial. La misma persona puede tener distintos identificadores de objeto en distintos inquilinos, y el acceso de un inquilino no debe heredar en silencio permisos asociados a otro.
Entiende el caso de exceso de reclamaciones de grupo
Las reclamaciones de grupo son cómodas, pero no son ilimitadas. Microsoft documenta un límite de 200 Object IDs de grupo en un JWT. Cuando la pertenencia de un usuario supera el límite, Entra omite la lista normal de grupos y devuelve un indicador de exceso que dirige a la aplicación a consultar Microsoft Graph. Consulta la guía sobre exceso de grupos.
Esto importa si una integración anuncia el mapeo de grupos sin permisos elevados de Microsoft Graph API. Un usuario con una membresía de grupos extensa puede no recibir el conjunto esperado de reclamaciones de grupo.
Antes de confiar en el mapeo directo de grupos, confirma cómo se gestiona el exceso. Las opciones incluyen grupos más pequeños específicos de la aplicación, roles de aplicación, filtrado de reclamaciones o una consulta basada en Graph con consentimiento de mínimo privilegio.
La sincronización en el inicio de sesión no es aprovisionamiento en tiempo real
Un módulo de SSO puede comparar las reclamaciones actuales de Entra con los mapeos configurados de Odoo cuando un usuario inicia sesión. Eso es útil porque el acceso puede alinearse durante un evento normal de autenticación.
No es lo mismo que el aprovisionamiento continuo. Si un empleado es eliminado de un grupo de Entra mientras una sesión de Odoo está activa, esa sesión puede continuar hasta el cierre de sesión, la expiración o la aplicación de otro control de revocación. Si un exempleado nunca vuelve a iniciar sesión, un proceso de sincronización en el inicio de sesión no archiva por sí mismo la cuenta de Odoo.
Microsoft Entra ID Governance ofrece Lifecycle Workflows para procesos de incorporación, traslado y salida, incluido el deshabilitado de cuentas y la eliminación de asignaciones de acceso. Consulta la guía de Lifecycle Workflows. Estas capacidades requieren licencias de Microsoft Entra ID Governance o Microsoft Entra Suite.
La automatización del ciclo de vida puede mejorar el estado de la identidad de origen, pero sigue sin actualizar Odoo a menos que una integración consuma el cambio. Tu procedimiento de baja debe cubrir explícitamente la revocación de la sesión de Odoo y el estado de la cuenta.
Construye un modelo de mapeo auditable
Mantén comprensible el número de mapeos. Para cada grupo o rol, usa un identificador estable y una descripción legible. Registra por qué existe el acceso asociado a Odoo, quién lo aprobó y cuándo se revisó por última vez.
Prueba al menos estos casos:
- Usuario existente con un mapeo esperado.
- Usuario sin mapeo aprobado o con un inquilino no permitido.
- Usuario nuevo admitido para el primer inicio de sesión.
- Usuario eliminado de un grupo mapeado o con muchas pertenencias a grupos.
- Usuario renombrado cuya identidad inmutable no ha cambiado.
- Cuenta de Microsoft deshabilitada con una sesión de Odoo existente.
Los eventos de inicio de sesión deben ayudar a los administradores a diagnosticar los resultados de las reclamaciones y del mapeo sin exponer tokens, credenciales ni secretos. Los registros deben identificar la conexión y el resultado, pero los valores sensibles deben redactarse.
Combinar el mapeo con la política de autenticación
El mapeo de grupos y roles controla la autorización en Odoo. El Acceso Condicional de Microsoft Entra controla si Microsoft completará la autenticación en las condiciones actuales. Las dos capas se complementan.
Por ejemplo, un rol de aplicación de Entra puede asignarse a un grupo financiero de Odoo, mientras que Acceso Condicional exige una fortaleza de autenticación resistente a phishing para los usuarios asignados a ese rol. Lea cómo Microsoft Entra Acceso Condicional fortalece el inicio de sesión en Odoo para la parte de la política de autenticación.
Para clientes y partners, no reutilice automáticamente los mapeos de empleados. Un público distinto y un diseño orientado al portal pueden ser más seguros. Consulte Microsoft Entra External ID para clientes y partners de Odoo.
Mapee el acceso aprobado de Microsoft en Odoo 19
Nuestro módulo Microsoft Entra SSO para Odoo admite asignar los Object IDs de grupos de seguridad de Entra o roles de aplicación configurados a grupos de acceso de Odoo seleccionados. Puede sincronizar esos mapeos en el inicio de sesión, vincular una cuenta existente controlada y crear usuarios aprobados de la plantilla o del portal según el tipo de conexión.
El módulo no sustituye la gobernanza del acceso, la revocación de sesiones ni una estrategia documentada para excedentes. Revise la escala de sus grupos, los requisitos de vinculación de identidades y el modelo de permisos de Odoo antes de habilitar los mapeos. Si esas bases están claras, el módulo ofrece una forma guiada de conectarlas.