Os portais do Odoo dão a clientes e parceiros acesso a documentos, transações e serviços relevantes. Isso gera uma questão de desenho de identidade: os usuários externos devem compartilhar o diretório de funcionários e o modelo de acesso?
Às vezes, uma conta de convidado em um tenant de workforce é apropriada. Em maior escala, ou quando é necessário um login de cliente com marca própria e registro de autoatendimento, o Microsoft Entra External ID oferece um modelo dedicado de gerenciamento de identidade e acesso para clientes.
Conectar esse modelo ao Odoo pode ajudar a manter uma separação mais clara entre usuários internos e usuários do portal. A separação ainda precisa de admissão explícita, criação de conta e regras de autorização do Odoo.
Tenants de workforce e externos são projetados para públicos diferentes
A Microsoft define um tenant de workforce como o ambiente para funcionários, aplicativos internos e recursos organizacionais. Ele também pode conter parceiros comerciais e convidados convidados. Um tenant externo é uma configuração separada para aplicativos oferecidos a consumidores e clientes empresariais. A Microsoft descreve essa distinção em suas orientações de configuração de tenant.
Um tenant externo contém seu próprio diretório de clientes e registros de aplicativos. O External ID adiciona registro de autoatendimento, login, redefinição de senha, gerenciamento de conta e federação com provedores de identidade. A visão geral do External ID explica esse modelo dedicado.
Essa separação pode ajudar uma organização a evitar tratar um cliente como funcionário só porque ambos precisam de acesso a um serviço do Odoo.
Escolha o público antes de configurar o login
Há pelo menos três públicos distintos do Odoo a considerar:
Funcionários e usuários internos
Esses usuários normalmente pertencem ao tenant de workforce da organização. Se forem admitidos no Odoo, geralmente precisam de contas internas de usuário do Odoo com grupos de acesso cuidadosamente mapeados.
Pessoas de organizações parceiras aprovadas
Algumas empresas querem usuários de uma lista definida de tenants de clientes ou parceiros do Entra. Uma conexão de workforce multilocatário com uma allow-list exata de tenants pode ser apropriada quando cada organização é conhecida e o acesso é aprovado contratualmente.
A validação do tenant é crítica. Corresponder apenas ao domínio de e-mail não é suficiente, porque domínios e endereços de e-mail podem ser alterados. Valide o tenant do token e os identificadores imutáveis de subject ou object de acordo com o desenho da conexão.
Clientes e usuários externos
Para aplicativos voltados ao cliente, um tenant do External ID pode fornecer um diretório e uma experiência de login separados. As contas do Odoo criadas para esse público normalmente devem ser usuários do portal, não usuários internos.
Esses modelos devem ser configurados como conexões separadas quando as regras de admissão e de conta do Odoo forem diferentes. Uma única conexão ampla é mais difícil de analisar e mais fácil de configurar incorretamente.
O External ID oferece suporte a uma jornada de login para clientes
Os fluxos de usuário do External ID definem métodos de autenticação do cliente e informações coletadas durante o cadastro. Um fluxo é associado a aplicativos registrados para ativar cadastro e login. A Microsoft documenta isso em adicionar um aplicativo a um fluxo de usuário do External ID.
O External ID pode oferecer suporte a contas locais e à federação com provedores de identidade, incluindo Microsoft Entra ID e provedores OpenID Connect personalizados. Atributos nativos e personalizados podem ser coletados durante o cadastro, conforme descrito na orientação de atributos do cliente da Microsoft.
Colete apenas as informações de que o Odoo realmente precisa e documente a finalidade, a retenção e o tratamento de privacidade de cada atributo.
Permissões padrão ajudam a preservar a separação
A Microsoft informa que usuários de tenant externo começam com permissões padrão restritas. Em geral, eles podem acessar aplicativos e gerenciar seu próprio perfil, mas não recebem amplos direitos de administração do diretório. Veja permissões padrão em tenants externos.
Esse limite de diretório não configura automaticamente as permissões do portal Odoo. O Odoo ainda controla quais registros um usuário do portal pode ver por meio de seus próprios direitos de acesso e regras de registro. Teste a experiência do portal com registros de clientes representativos e mais de uma empresa ou conta para garantir que os dados estejam isolados corretamente.
Não promova um novo usuário externo para usuário interno do Odoo, a menos que exista um processo de negócio separado e aprovado.
Use um fluxo moderno e validado de OpenID Connect
A Microsoft oferece suporte ao fluxo de código de autorização OAuth 2.0 com Proof Key for Code Exchange e OpenID Connect para aplicativos web baseados em servidor. A sua documentação do fluxo de código de autorização descreve essa combinação suportada.
OIDC amplia o OAuth 2.0 para autenticação. A Microsoft publica metadados de descoberta, detalhes de endpoint e chaves públicas de assinatura. Ela também recomenda validar o token retornado e verificar um nonce para reduzir o risco de replay. Veja OpenID Connect na plataforma de identidade da Microsoft.
Uma integração segura deve validar o issuer esperado, a audience, a assinatura, o contexto do tenant e o nonce. O PKCE não substitui a validação de token, a configuração exata do callback, o TLS ou a proteção do segredo do cliente.
O login básico pode solicitar escopos OIDC padrão como openid, profile e email. A Microsoft observa que esses escopos estão hospedados no Microsoft Graph e recomenda solicitar apenas as permissões de que o aplicativo precisa. Veja escopos da plataforma de identidade da Microsoft. Portanto, uma afirmação precisa do produto é "sem permissões de alta privilégio do Microsoft Graph API para login padrão", e não uma alegação genérica de que o Graph não está envolvido.
Decida como os usuários externos acessam o Odoo
Antes de habilitar o primeiro login, defina:
- Se o auto-registro está aberto ou se é necessária aprovação.
- Quais tenants ou provedores de identidade são admitidos.
- Se uma conta de portal Odoo existente pode ser vinculada.
- Qual identificador imutável da Microsoft é armazenado após a vinculação.
- A qual empresa do Odoo e qual registro de parceiro o usuário pertence.
- Quais grupos de portal e regras de registro se aplicam.
- O que acontece quando o acesso é revogado.
- Como uma sessão ativa do Odoo é revogada.
A criação automática de contas pode reduzir a administração, mas ela só deve ocorrer depois que a identidade atender às regras de admissão da conexão. Uma autenticação bem-sucedida da Microsoft comprova o controle da identidade aceita. Por si só, isso não prova que a pessoa deva ver os registros de um cliente específico no Odoo.
Planeje o suporte ao cliente e a recuperação
Usuários externos podem não ter uma central de ajuda interna. Publique um caminho de suporte e identifique quem gerencia a identidade. Teste os cenários de redefinição de senha, recuperação, remoção do locatário e alteração de e-mail. Mantenha os eventos de diagnóstico úteis, mas com os dados sensíveis ocultados.
Se sua necessidade imediata é acesso de funcionários, leia por que você deve proteger sua instância do Odoo com Microsoft SSO. Para permissões internas, veja centralizando o acesso ao Odoo com grupos do Entra e funções de aplicativo.
Conecte públicos externos ao Odoo 19
Nosso módulo Microsoft Entra SSO para Odoo oferece suporte a conexões separadas para funcionários, organizações aprovadas e públicos de clientes do Microsoft Entra External ID. As conexões do External ID criam usuários do portal por padrão, enquanto as conexões da força de trabalho criam usuários internos. A configuração guiada valida as informações de descoberta e as chaves de assinatura, depois exige um teste interativo antes que o login da Microsoft seja habilitado.
O módulo não decide quem deve ser admitido nem quais registros de clientes eles devem ver. Isso continua sendo uma decisão de negócios e de acesso do Odoo. Analise o módulo se você precisar de uma ponte controlada entre a identidade de cliente da Microsoft e um portal do Odoo 19, com tratamento de contas específico por público em vez de um único caminho de login sem distinção.