Pular para o conteúdo principal
Quando um usuário faz login por meio do SAML SSO, o EK recebe atributos de metadados SAML (por exemplo, department, group ou role). O recurso de Controles de Acesso utiliza esses atributos para determinar se um usuário tem permissão para acessar a aplicação.
Os Controles de Acesso e o Gerenciamento Automatizado de Equipes são recursos independentes, mas normalmente são usados em conjunto. Consulte Atribuição Automatizada de Equipes e Projetos para o guia complementar.

​
Pré-requisitos

Antes de ativar os controles de acesso:
  • 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
Valide os nomes e valores dos atributos a partir de alguns logins SSO bem-sucedidos antes de ativar qualquer restriçã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.

​
Modos de Acesso

Navegue até Super Admin → Security & Access → Access Controls para selecionar um modo. Seleção de Modo de Acesso
ModoComportamento
Allow Any New UsersPadrão. Cadastros por e-mail/senha, Google OAuth e SSO são todos permitidos.
Restrict to SAML MetadataApenas usuários SSO cujos atributos SAML correspondem a pelo menos uma regra configurada são permitidos.

​
Como Funciona a Correspondência de Regras

As regras são definidas por um Nome de Atributo e um ou mais Valores de Atributo. Regras de Acesso SAML

​
O modelo mental: tudo é um conjunto

Uma regra e um atributo de usuário recebido são ambos reduzidos a um conjunto 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
  • A lógica entre regras é OU — qualquer correspondência individual de regra concede acesso
  • Todas as comparações são insensíveis a maiúsculas/minúsculas e ignoram espaços em branco no início e no final

​
Regras com múltiplos tokens (E dentro de uma regra)

Vírgulas no campo Valor(es) de Atributo são separadores de tokens. A interface promove cada entrada separada por vírgula em um chip; a regra requer que todos os tokens listados estejam presentes.
  • engineering — requer um token: o atributo do usuário deve conter engineering
  • Accounting, US — requer dois tokens: o atributo do usuário deve conter ambos accounting e us

​
Tratamento de diferentes formatos de transmissão SAML

Os atributos SAML podem chegar em dois formatos: Valor múltiplo nativo — o IdP envia múltiplos elementos <AttributeValue> dentro de um <Attribute>: 
<Attribute Name="memberOf">
  <AttributeValue>Accounting</AttributeValue>
  <AttributeValue>US</AttributeValue>
</Attribute>
O EK sempre trata isso como um conjunto. Nenhuma configuração adicional necessária. Este é o formato preferido. Valor único com CSV — o IdP envia um <AttributeValue> contendo tokens separados por vírgula: 
<Attribute Name="memberOf">
  <AttributeValue>Accounting,US</AttributeValue>
</Attribute>
Isso é ambíguo (são dois grupos ou um valor literal contendo uma vírgula?). Use o toggle por regra para resolver:
Toggle: “IdP packs multi-values into one string”Comportamento
Desligado (padrão)A string do usuário é tratada como um token literal
LigadoA string do usuário é dividida por vírgulas e correspondida como um conjunto
Este toggle afeta apenas como o atributo do usuário é interpretado. Vírgulas no lado da regra são sempre separadores de tokens, independentemente disso.

​
Matriz de comportamento de correspondência

Atributo do usuário (formato de transmissão)ToggleValor da regraCorresponde?
nativo ["A","B","C"]desligadoA✓
nativo ["A","B","C"]desligadoA, B✓
único "A,B,C"desligadoA✗
único "A,B,C"desligadoA, B✗
único "A,B,C"ligadoA✓
único "A,B,C"ligadoA, B✓
único "A"desligadoA✓

​
Comportamento Quando o Modo Restrito está Ativo

  • Novos cadastros por e-mail/senha
  • Novos cadastros por Google OAuth
  • Novos usuários SSO cujos atributos SAML não correspondem a nenhuma regra
  • Usuários SSO existentes que correspondem a pelo menos uma regra (verificado novamente a cada login)
  • Usuários locais existentes fazendo login em contas existentes
  • Contas de Super Admin via SSO, mesmo sem uma regra correspondente (interrupção de emergência intencional)
  • Chaves de API pertencentes a Super Admins ou chaves de nível de projeto sem linha de usuário associada
Requisições de chave de API de usuários vinculados ao SAML também são controladas no modo restrito. O EK verifica os metadados SAML armazenados do usuário (do último login SSO) contra as regras de acesso antes de permitir o acesso à API.
Comportamento de falha aberta: Se o modo restrito estiver LIGADO mas não houver regras de acesso SAML, o EK permite todos os usuários SSO. Isso evita bloqueio acidental, mas você deve sempre definir pelo menos uma regra antes de ativar a governança estrita.

​
Configurar Controles de Acesso

1

Abrir Controles de Acesso

Vá para Super Admin → Security & Access → Access Controls.
2

Selecionar Modo Restrito

Escolha Restrict to SAML Metadata.
3

Adicionar Regras de Acesso SAML

Adicione uma ou mais regras em SAML Access Rules. Exemplos:
department = engineering
memberOf = ekb-users
memberOf = ekb-users, us   (requer ambos os tokens)
Ative o toggle IdP packs multi-values into one string se o atributo do lado do usuário chegar como uma única string separada por vírgula.
4

Salvar e Validar

Salve suas regras e teste com contas SSO representativas antes de implementar amplamente.

​
Abordagem Recomendada de Implementação

  1. Crie regras enquanto o modo ainda estiver definido como Allow Any New Users
  2. Valide inspecionando os metadados SAML armazenados para contas SSO piloto na visualização de usuário do Super Admin
  3. Mude para Restrict to SAML Metadata
  4. Monitore logins e resultados de acesso negado

​
Lista de Verificação de Testes

Após a configuração, verifique cada cenário:
  • Um usuário SSO que deve ser permitido pode fazer login
  • Um usuário SSO que não deve ser permitido é redirecionado para a experiência de acesso negado
  • Usuários negados veem a experiência de acesso negado esperada
  • Pelo menos uma regra válida está ativa para evitar deriva de política

​
Solução de Problemas

  • Confirme se o modo de acesso não está definido como restrito acidentalmente
  • Verifique se a regra usa o nome de atributo correto e o valor exato esperado
  • Confirme se o IdP está enviando esse atributo para esse usuário
  • Para regras com múltiplos tokens, cada token listado deve estar presente no atributo do usuário — verifique os metadados SAML armazenados na visualização de usuário do Super Admin
  • Se o atributo chegar como uma string única com CSV, confirme se IdP packs multi-values into one string está habilitado na regra
  • Verifique se o usuário está tentando login por e-mail/senha ou Google OAuth enquanto o modo restrito está ativo
Contas de Super Admin sempre são permitidas por SSO, mesmo sem uma regra correspondente. Se bloqueado, faça login via SSO usando uma conta de Super Admin para recuperar o acesso.

​
Orientação Operacional

  • Trate as regras de acesso 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
  • Revise periodicamente as regras e remova mapeamentos obsoletos
  • Mantenha pelo menos uma regra válida ativa para evitar estados de falha aberta não intencionais