Gerenciamento Automatizado

Coloque automaticamente usuários SSO na equipe e projetos corretos com base em seus atributos de metadados SAML.

Quando um usuário faz login por meio do SAML SSO, o Enterprise Knowledge pode avaliar seus atributos de metadados e atribuí-los automaticamente a uma equipe e, opcionalmente, a todos os projetos dentro dessa equipe — com a função apropriada.

O Gerenciamento Automatizado e os Controles de Acesso são recursos independentes, mas normalmente são usados em conjunto. Consulte Controles de Acesso SAML para o guia complementar.

​

Pré-requisitos

Antes de ativar o gerenciamento automatizado:

• O SAML SSO deve estar configurado e enviando atributos de metadados no login
• A asserção SAML deve incluir atributos estáveis para correspondência
• As equipes de destino já devem existir no EK; para instruções sobre como criar equipes, consulte Gerenciamento de Equipes

Valide os nomes e valores dos atributos a partir de alguns logins SSO bem-sucedidos antes de ativar a automação. A visualização de usuário do Super Admin exibe os metadados SAML armazenados para cada usuário SSO — use isso como fonte de verdade ao criar regras.

​

Estrutura das Regras

Navegue até Super Admin → Users & Workspaces → Teams → Automated Management para configurar regras. Cada regra inclui:

Campo	Obrigatório	Descrição
SAML Attribute Name	Sim	A chave do atributo da asserção SAML
Attribute Value(s)	Sim	Um ou mais tokens separados por vírgula — todos os tokens listados devem corresponder (lógica E)
Target Team	Sim	A equipe para atribuir o usuário
Default Team Membership Role	Opcional	Member (padrão) ou Admin
Auto-add to team projects	Opcional	Adiciona o usuário a todos os projetos não padrão na equipe
Default Project Role	Opcional	Admin, Editor ou Viewer
Forced continuous team reassignment	Opcional	Move usuários a cada login, não apenas no primeiro

Uma regra também pode conter:

• Conditional Team-Role Overrides — altera a função de membership da equipe com base em atributos SAML adicionais
• Conditional Project-Role Overrides — altera a função do projeto com base em atributos SAML adicionais (aplica-se apenas quando a adição automática está ativa)

​

Como Funciona a Correspondência de Regras

A correspondência de atributos usa o mesmo motor que os Controles de Acesso. Regras e atributos de usuário são ambos tratados como conjuntos de tokens e comparados com semântica de subconjunto — uma regra corresponde quando seus tokens obrigatórios são um subconjunto dos tokens do usuário.

• Vírgulas no Attribute Value(s) são separadores de tokens. Accounting, US requer que o usuário tenha ambos os tokens (lógica E dentro de uma regra).
• Especificidade é igual ao número de tokens que uma regra requer. Quando múltiplas regras correspondem, a mais específica (mais tokens) vence.

Não há critério de desempate entre regras de especificidade igual. Se duas regras empatam, o EK escolhe a criada primeiro e emite um log de WARNING listando os IDs das regras empatadas. Trate isso como um erro de configuração e reestruture as regras para eliminar a sobreposição.

​

Tratamento de diferentes formatos de transmissão SAML

Os atributos SAML podem chegar em dois formatos, e cada regra expõe um toggle para tratá-los:

Valor múltiplo nativo — o IdP envia múltiplos elementos <AttributeValue>. O EK sempre trata isso como um conjunto automaticamente.

Valor único com CSV — o IdP compacta os valores em uma única string separada por vírgula. Use o toggle por regra:

Toggle: “IdP packs multi-values into one string”	Comportamento
Desligado (padrão)	A string do usuário é tratada como um token literal
Ligado	A string do usuário é dividida por vírgulas e correspondida como um conjunto

Consulte Controles de Acesso SAML — Matriz de Comportamento de Correspondência para uma tabela de referência completa.

​

Comportamento de Atribuição de Equipe

A cada login SSO, o EK avalia as regras configuradas contra os metadados SAML do usuário e seleciona a regra correspondente mais específica.

Estado do Usuário	Resultado
Sem equipe ainda	Atribuído à equipe de destino
Já na equipe de destino	Sem alteração
Em uma equipe diferente	Movido apenas se Forced continuous team reassignment estiver ativo
Proprietário de uma equipe com múltiplos membros	Não é movido forçosamente (previne propriedade órfã)
Único membro/proprietário da sua equipe	Movido; a equipe agora vazia é excluída

Para o onboardamento inicial por SSO, a reatribuição é sempre forçada para estabelecer o posicionamento correto.

​

Função de Membership da Equipe

A função na qual um usuário é adicionado a uma equipe é resolvida nesta ordem:

1. Conditional Team-Role Override — o override mais específico na regra correspondente cujos tokens correspondem por subconjunto ao usuário
2. Default Team Membership Role — Member ou Admin conforme configurado na regra (padrão legado: Member)

As funções de equipe são aplicadas apenas no momento da adição. Se o usuário já estiver na equipe de destino, sua função existente é preservada — logins subsequentes não a alterarão. Promover ou rebaixar um membro existente requer uma ação explícita de administrador.

​

Conditional Team-Role Overrides

Cada override especifica um Attribute Name, Attribute Value(s), o toggle opcional is_csv_value, e uma Team Role (Member ou Admin). O override mais específico correspondente vence; empates geram um log de aviso.

​

Adição Automática a Projetos

Quando Auto-add to team projects está habilitado em uma regra, o EK adiciona o usuário a projetos não padrão na equipe de destino. O usuário é adicionado apenas a projetos dos quais ainda não é membro.

Prioridade de atribuição de função:

1. Conditional Project-Role Override correspondente (correspondência mais específica)
2. Default Project Role definido na regra da equipe

A atribuição de projeto é executada de forma assíncrona. O membership na equipe pode aparecer antes que todos os memberships de projeto sejam concluídos.

As funções de projeto são aplicadas apenas no momento da adição. Memberships de projeto existentes nunca são reavaliados ou alterados em logins subsequentes.

​

Conditional Project-Role Overrides

Os overrides de função permitem que uma função de projeto diferente seja atribuída com base em atributos SAML adicionais.

Exemplo:

• Regra da equipe: department = engineering, função padrão → Viewer
• Override de função: level = manager → Admin

Resultado:

• Todos os usuários de engineering são adicionados à equipe
• Usuários que também têm level = manager recebem Admin em projetos adicionados automaticamente
• Não-gerentes mantêm Viewer

Se múltiplos overrides de função condicionais puderem corresponder ao mesmo usuário, o mais específico (mais tokens) vence. Empates geram um log de aviso e recorrem ao override criado primeiro — reestruture os overrides para evitar empates.

​

Restrições de Reatribuição de Equipe

Encontrado em Super Admin → Teams → Automated Management → Team Reassignment Restrictions, essas configurações controlam o que acontece com os memberships de projeto quando um usuário muda entre equipes. Todas as três estão definidas como desligado por padrão (não destrutivo).

Configuração	Descrição
1. Remove user from old team’s projects	Alternador principal. Remove memberships de projeto antigos na reatribuição.
2. Projects owned by user follow them	Depende da configuração 1. Projetos proprietários são movidos para a nova equipe.
3. Remove old team members from followed projects	Depende das configurações 1 e 2. Limpa o acesso da equipe antiga em projetos movidos.

Na prática:

• Apenas configuração 1 — o usuário é removido dos projetos da equipe antiga; projetos proprietários permanecem na equipe antiga e a propriedade é transferida para o proprietário da equipe antiga
• Configurações 1 + 2 — os projetos que o usuário possui são movidos para a nova equipe; membros existentes desses projetos são mantidos
• Configurações 1 + 2 + 3 — membros da equipe antiga também são removidos dos projetos que foram movidos com o proprietário

Se a propriedade não puder ser transferida com segurança durante a reatribuição, o EK aplica salvaguardas para prevenir estados de propriedade quebrada.

​

Configurar Regras de Gerenciamento Automatizado

1. Abrir Gerenciamento Automatizado

   Vá para Super Admin → Users & Workspaces → Teams → Automated Management e clique em Add Rule.

2. Inserir critérios de correspondência SAML

   Forneça o SAML Attribute Name, Attribute Value(s) e Target Team.

   Para regras com múltiplos tokens, digite cada token e pressione vírgula para criar um chip (por exemplo, accounting + us para requerer ambos). Ative IdP packs multi-values into one string se necessário.

   
3. Definir função de membership da equipe

   Escolha um Default Team Membership Role (Member ou Admin) e opcionalmente adicione Conditional Team-Role Overrides para usuários que devem receber uma função de equipe diferente com base em atributos adicionais.

4. Configurar configurações opcionais

   Decida se habilitar Auto-add to team projects e/ou Forced continuous team reassignment.

5. Definir função do projeto (se adição automática estiver habilitada)

   Escolha um Default Project Role e opcionalmente adicione Conditional Project-Role Overrides.

6. Salvar e configurar restrições de reatribuição

   Salve a regra e, opcionalmente, configure Team Reassignment Restrictions para definir o comportamento quando usuários mudam de equipe.

7. Testar

   Teste com usuários SSO reais representando cada padrão de metadados esperado antes de habilitar em produção.

​

Melhores Práticas de Design de Regras

• Use atributos estáveis do provedor de identidade — evite valores voláteis ou frequentemente alterados
• Mantenha os nomes dos atributos consistentes com os nomes exatos dos claims SAML (sensíveis a maiúsculas/minúsculas no nível do claim em alguns IdPs)
• Prefira atributos SAML valor múltiplo nativo quando seu IdP os suporta — são inequívocos e não requerem o toggle is_csv_value
• Evite regras sobrepostas na mesma especificidade — se você vir um aviso de “Ambiguous match”, adicione mais tokens a uma regra para torná-la estritamente mais específica
• Comece com menor privilégio (Member função de equipe, Viewer função de projeto) e eleve apenas onde necessário via overrides condicionais
• Documente a propriedade das regras e agende revisões periódicas

​

Lista de Verificação de Testes

Após a configuração, verifique cada cenário:

• Usuários permitidos são posicionados na equipe correta com a função de equipe correta
• Overrides de função de equipe condicionais se aplicam aos usuários corretos
• A adição automática de projetos é concluída com a função correta (aguarde alguns segundos para o processamento assíncrono)
• Overrides de função de projeto condicionais se aplicam aos usuários corretos
• A reatribuição forçada funciona conforme o esperado (se habilitada)
• As configurações de restrição de reatribuição funcionam corretamente durante movimentação de equipe

​

Solução de Problemas

Usuário fez login mas não foi atribuído à equipe esperada

• Confirme que existe uma regra de atribuição de equipe correspondente
• Confirme que a equipe de destino ainda existe
• Verifique se os tokens de atributo/valor da regra são um subconjunto dos metadados SAML reais do usuário (verifique a visualização de usuário do Super Admin)
• Habilite Forced continuous team reassignment se o usuário já pertencer a outra equipe e precisar ser movido
• Se o usuário for o proprietário de uma equipe com múltiplos membros, ele não será movido automaticamente — isso é intencional
• Se os logs contiverem um aviso de Ambiguous match, duas regras empataram na mesma especificidade; reestruture para eliminar a sobreposição

Usuário atribuído à equipe, mas com a função de equipe errada

• Verifique se existe um Conditional Team-Role Override que corresponde ao usuário
• As funções de equipe são aplicadas apenas no momento da adição — se o usuário já estava na equipe antes do override ser adicionado, sua função existente é preservada; promova-o ou rebaixe-o manualmente
• Para empates entre overrides, verifique os logs e adicione mais tokens ao override pretendido para torná-lo estritamente mais específico

Usuário atribuído à equipe, mas não aos projetos

• Confirme que Auto-add to team projects está habilitado na regra correspondente
• Confirme que a equipe possui projetos não padrão
• Confirme que uma função de projeto válida (Admin, Editor ou Viewer) está definida
• Aguarde um breve atraso para o processamento assíncrono em segundo plano

Override de função não aplicado

• Confirme que o override de função está anexado à regra correta de atribuição de equipe
• Confirme que o atributo/valor adicional realmente existe nos metadados SAML do usuário
• Se a função padrão estiver sendo aplicada, nenhum override condicional correspondeu
• Se o atributo chegar como uma string única com CSV, confirme se IdP packs multi-values into one string está habilitado no override

Aviso "Ambiguous match" nos logs

Duas ou mais regras (ou overrides) de especificidade igual corresponderam ao mesmo usuário. O EK escolheu a criada primeiro deterministicamente, mas a configuração é frágil.

A linha do log lista os IDs das regras empatadas. Edite uma para adicionar mais tokens obrigatórios para torná-la estritamente mais específica, ou remova a sobreposição completamente.

​

Orientação Operacional

• Trate as regras de atribuição como configuração sensível à segurança
• Use processos de gestão de alterações para atualizações em produção
• Reteste após qualquer alteração de claim do IdP (por exemplo, alterar de CSV para valor múltiplo nativo, ou renomear um claim)
• Revise periodicamente as regras e remova mapeamentos obsoletos
• Inspecione os metadados SAML armazenados na visualização de usuário do Super Admin antes de criar novas regras