> ## Documentation Index
> Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Controles de Acesso SAML

> Controle quem pode fazer login ou se registrar no EK usando atributos de metadados SAML.

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.

<Note>
  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](/super-admin/sa-automated-management) para o guia complementar.
</Note>

## 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

<Tip>
  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.
</Tip>

## Modos de Acesso

Navegue até **Super Admin → Security & Access → Access Controls** para selecionar um modo.

<img src="https://mintcdn.com/automationanywhere/P9UkIpAqpipG-xbe/img/sa/access-mode.png?fit=max&auto=format&n=P9UkIpAqpipG-xbe&q=85&s=221e1cef0569afded822f8a5d8115b26" alt="Seleção de Modo de Acesso" width="834" height="263" data-path="img/sa/access-mode.png" />

| Modo                          | Comportamento                                                                                            |
| ----------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Allow Any New Users**       | Padrão. Cadastros por e-mail/senha, Google OAuth e SSO são todos permitidos.                             |
| **Restrict to SAML Metadata** | Apenas 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**.

<img src="https://mintcdn.com/automationanywhere/AnqQHTb8za_1axzx/img/sa/saml-access-rules-v2.png?fit=max&auto=format&n=AnqQHTb8za_1axzx&q=85&s=0ff76c9da8d4c415e10bd1b8476cceee" alt="Regras de Acesso SAML" width="1744" height="1038" data-path="img/sa/saml-access-rules-v2.png" />

### 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>`:

```xml theme={null}
<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:

```xml theme={null}
<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                          |
| **Ligado**                                       | A string do usuário é dividida por vírgulas e correspondida como um conjunto |

<Note>
  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.
</Note>

### Matriz de comportamento de correspondência

| Atributo do usuário (formato de transmissão) | Toggle    | Valor da regra | Corresponde? |
| -------------------------------------------- | --------- | -------------- | ------------ |
| nativo `["A","B","C"]`                       | desligado | `A`            | ✓            |
| nativo `["A","B","C"]`                       | desligado | `A, B`         | ✓            |
| único `"A,B,C"`                              | desligado | `A`            | ✗            |
| único `"A,B,C"`                              | desligado | `A, B`         | ✗            |
| único `"A,B,C"`                              | ligado    | `A`            | ✓            |
| único `"A,B,C"`                              | ligado    | `A, B`         | ✓            |
| único `"A"`                                  | desligado | `A`            | ✓            |

## Comportamento Quando o Modo Restrito está Ativo

<AccordionGroup>
  <Accordion title="O que é bloqueado">
    * Novos cadastros por e-mail/senha
    * Novos cadastros por Google OAuth
    * Novos usuários SSO cujos atributos SAML não correspondem a nenhuma regra
  </Accordion>

  <Accordion title="O que ainda é permitido">
    * 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
  </Accordion>
</AccordionGroup>

<Note>
  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.
</Note>

<Warning>
  **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.
</Warning>

## Configurar Controles de Acesso

<Steps>
  <Step title="Abrir Controles de Acesso">
    Vá para **Super Admin → Security & Access → Access Controls**.
  </Step>

  <Step title="Selecionar Modo Restrito">
    Escolha **Restrict to SAML Metadata**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Salvar e Validar">
    Salve suas regras e teste com contas SSO representativas antes de implementar amplamente.
  </Step>
</Steps>

### 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

<AccordionGroup>
  <Accordion title="Usuário negado inesperadamente">
    * 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
  </Accordion>

  <Accordion title="Super Admin bloqueado">
    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.
  </Accordion>
</AccordionGroup>

## 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