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
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 |
- 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, USrequer 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.
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 |
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:- Conditional Team-Role Override — o override mais específico na regra correspondente cujos tokens correspondem por subconjunto ao usuário
- Default Team Membership Role —
MemberouAdminconforme 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 opcionalis_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:- Conditional Project-Role Override correspondente (correspondência mais específica)
- 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
- Todos os usuários de
engineeringsão adicionados à equipe - Usuários que também têm
level = managerrecebemAdminem 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. |
- 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
Configurar Regras de Gerenciamento Automatizado
Abrir Gerenciamento Automatizado
Vá para Super Admin → Users & Workspaces → Teams → Automated Management e clique em Add Rule.
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.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.Configurar configurações opcionais
Decida se habilitar Auto-add to team projects e/ou Forced continuous team reassignment.
Definir função do projeto (se adição automática estiver habilitada)
Escolha um Default Project Role e opcionalmente adicione Conditional Project-Role Overrides.
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.
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 (
Memberfunção de equipe,Viewerfunçã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
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
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
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,EditorouViewer) está definida - Aguarde um breve atraso para o processamento assíncrono em segundo plano
Override de função não aplicado
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
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