O login único responde a uma pergunta de autenticação: a Microsoft verificou este usuário de acordo com a política da organização? Ele não responde a todas as perguntas de autorização dentro do Odoo.
Um usuário autenticado pode precisar de acesso a vendas, mas não a contabilidade, projetos, mas não a folha de pagamento, ou a um portal do cliente, mas não à interface interna. Essas decisões continuam sendo responsabilidade do Odoo. Grupos do Microsoft Entra e funções de aplicativo podem fornecer entradas confiáveis para torná-las mais consistentes.
Grupos e funções de aplicativo servem a propósitos diferentes
Os grupos do Microsoft Entra pertencem ao tenant. Eles podem representar departamentos, funções de trabalho, projetos ou fronteiras de segurança. As funções de aplicativo pertencem a um registro de aplicativo específico e descrevem funções que são significativas para esse aplicativo.
A documentação de app roles da Microsoft explica que as funções de aplicativo podem ser atribuídas a usuários ou grupos. Quando um usuário atribuído faz login, o Entra pode incluir as funções concedidas em uma claim de roles. A Microsoft também afirma que funções de aplicativo e grupos não são mutuamente exclusivos.
Isso dá a um desenho de acesso do Odoo dois padrões principais:
- Mapear diretamente os Object IDs dos grupos de segurança estáveis do Entra para grupos selecionados do Odoo.
- Definir funções de aplicativo voltadas ao Odoo no aplicativo do Entra, atribuir usuários ou grupos a essas funções e mapear os valores resultantes das funções para grupos do Odoo.
O mapeamento direto funciona bem com grupos de segurança governados. As funções de aplicativo podem fornecer uma fronteira mais limpa para o aplicativo, porque sua intenção acompanha o registro do aplicativo em vez de depender de nomes específicos do tenant.
Comece pelo modelo real de acesso do Odoo
Não comece copiando todos os grupos da Microsoft para o Odoo. Comece com as permissões do Odoo de que o negócio realmente precisa.
Liste os grupos do Odoo que concedem capacidades relevantes. Para cada um, documente:
- A finalidade de negócio do acesso.
- A pessoa responsável por aprová-lo.
- O grupo do Entra ou a função de aplicativo que representa a aprovação.
- Quão rapidamente a mudança deve chegar ao Odoo e o que acontece a uma sessão ativa após a remoção.
Use o princípio do menor privilégio. Um grupo amplo de departamento pode ser conveniente, mas pode conceder mais acesso ao Odoo do que cada membro precisa. Um grupo de segurança menor, específico do Odoo, ou uma função de aplicativo, costuma ser mais fácil de auditar.
Trate a vinculação de identidade como um controle de segurança
Muitos sistemas inicialmente correspondem uma conta existente usando um endereço de e-mail. Isso é conveniente, especialmente quando o Odoo e a Microsoft já usam o mesmo e-mail corporativo. Não é uma chave de identidade durável.
A Microsoft alerta, em sua referência de claims do token de ID que endereços de e-mail, números de telefone e user principal names podem mudar e podem ser reutilizados. A Microsoft recomenda claims imutáveis como sub ou oid, com tid quando o contexto do tenant for necessário, para uma identificação confiável.
Um padrão mais seguro é:
- Permitir apenas um tenant esperado e um público aprovado.
- Usar o e-mail para uma correspondência inicial controlada, quando apropriado.
- Recusar correspondências ambíguas ou duplicadas.
- Armazenar a identidade Microsoft imutável e os identificadores do tenant após a vinculação.
- Usar esses valores imutáveis para logins futuros.
Para acesso multitenant, o contexto do tenant é essencial. A mesma pessoa pode ter identificadores de objeto diferentes em tenants diferentes, e o acesso de um tenant não deve herdar silenciosamente permissões associadas a outro.
Entenda o caso de excesso de claim de grupos
As claims de grupos são convenientes, mas não são ilimitadas. A Microsoft documenta um limite de 200 Object IDs de grupo em um JWT. Quando a associação de um usuário excede o limite, o Entra omite a lista normal de grupos e retorna um indicador de excesso que direciona o aplicativo a consultar o Microsoft Graph. Veja a orientação sobre excesso de grupos.
Isso importa se uma integração anuncia mapeamento de grupos sem permissões elevadas da Microsoft Graph API. Um usuário com associação extensa a grupos pode não receber o conjunto esperado de claims de grupo.
Antes de confiar no mapeamento direto de grupos, confirme como o excesso é tratado. As opções incluem grupos menores específicos do aplicativo, funções de aplicativo, filtragem de claims ou uma consulta baseada no Graph com consentimento de menor privilégio.
A sincronização no login não é provisionamento em tempo real
Um módulo de SSO pode comparar as claims atuais do Entra com os mapeamentos configurados do Odoo quando um usuário faz login. Isso é útil porque o acesso pode ser alinhado durante um evento normal de autenticação.
Isso não é o mesmo que provisionamento contínuo. Se um funcionário for removido de um grupo do Entra enquanto uma sessão do Odoo estiver ativa, essa sessão pode continuar até o logout, a expiração ou a aplicação de outro controle de revogação. Se um ex-funcionário nunca fizer login novamente, um processo de sincronização no login não arquiva a conta do Odoo por si só.
O Microsoft Entra ID Governance oferece Fluxos de Trabalho de Ciclo de Vida para processos de entrada, movimentação e saída, incluindo desativação de contas e remoção de atribuições de acesso. Veja a orientação sobre Lifecycle Workflows. Esses recursos exigem licenciamento do Microsoft Entra ID Governance ou do Microsoft Entra Suite.
A automação do ciclo de vida pode melhorar o estado da identidade de origem, mas ainda assim não atualiza o Odoo a menos que uma integração consuma a mudança. Seu procedimento de desligamento deve cobrir explicitamente a revogação da sessão do Odoo e o estado da conta.
Crie um modelo de mapeamento auditável
Mantenha o número de mapeamentos compreensível. Para cada grupo ou função, use um identificador estável e uma descrição legível por humanos. Registre por que o acesso associado ao Odoo existe, quem o aprovou e quando foi revisado pela última vez.
Teste pelo menos estes casos:
- Usuário existente com um mapeamento esperado.
- Usuário sem mapeamento aprovado ou com um tenant não permitido.
- Novo usuário admitido para o primeiro login.
- Usuário removido de um grupo mapeado ou com muitos pertencimentos a grupos.
- Usuário renomeado cuja identidade imutável não foi alterada.
- Conta Microsoft desabilitada com uma sessão do Odoo existente.
Os eventos de entrada devem ajudar os administradores a diagnosticar os resultados de reivindicações e mapeamentos sem expor tokens, credenciais ou segredos. Os registros devem identificar a conexão e o resultado, mas os valores sensíveis devem ser mascarados.
Combine o mapeamento com a política de autenticação
O controle de mapeamento de grupos e funções regula a autorização no Odoo. O Acesso Condicional do Microsoft Entra controla se a Microsoft concluirá a autenticação nas condições atuais. As duas camadas se complementam.
Por exemplo, uma função de aplicativo do Entra pode ser mapeada para um grupo financeiro do Odoo, enquanto o Acesso Condicional exige uma força de autenticação resistente a phishing para os usuários atribuídos a essa função. Leia como o Acesso Condicional do Microsoft Entra fortalece o início de sessão no Odoo para o lado da política de autenticação.
Para clientes e parceiros, não reutilize automaticamente os mapeamentos de funcionários. Um público separado e um design voltado para portal podem ser mais seguros. Veja Microsoft Entra External ID para clientes e parceiros do Odoo.
Mapeie o acesso Microsoft aprovado no Odoo 19
Nosso módulo Microsoft Entra SSO para Odoo oferece suporte ao mapeamento de IDs de Objeto de grupos de segurança do Entra configurados ou funções de aplicativo para grupos de acesso selecionados do Odoo. Ele pode sincronizar esses mapeamentos no início de sessão, vincular uma conta existente controlada e criar usuários aprovados da equipe ou do portal de acordo com o tipo de conexão.
O módulo não substitui a governança de acesso, a revogação de sessão ou uma estratégia documentada para excedentes. Revise a escala do seu grupo, os requisitos de vinculação de identidade e o modelo de permissões do Odoo antes de habilitar os mapeamentos. Se esses fundamentos estiverem claros, o módulo oferece uma forma orientada de conectá-los.