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

> Controle quién puede iniciar sesión o registrarse en EKB usando atributos de metadatos SAML.

Cuando un usuario inicia sesión a través de SAML SSO, EKB recibe atributos de metadatos SAML (por ejemplo, `department`, `group` o `role`). La funcionalidad de Controles de Acceso usa esos atributos para determinar si se permite a un usuario entrar a la aplicación.

<Note>
  Los Controles de Acceso y la Gestión Automatizada de Equipos son funcionalidades independientes, pero generalmente se usan juntas. Consulte [Asignación Automatizada de Equipos y Proyectos](/super-admin/sa-automated-management) para la guía complementaria.
</Note>

## Prerrequisitos

Antes de habilitar los controles de acceso:

* SAML SSO debe estar configurado y enviar atributos de metadatos al iniciar sesión
* La afirmación SAML debe incluir atributos estables para comparar

<Tip>
  Valide los nombres y valores de los atributos de algunos inicios de sesión SAML exitosos antes de habilitar cualquier restricción. La vista de usuarios del Super Admin muestra los metadatos SAML almacenados para cada usuario SSO — use esto como fuente de verdad al crear reglas.
</Tip>

## Modos de Acceso

Navegue a **Super Admin → Security & Access → Access Controls** para seleccionar un 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="Selección de Modo de Acceso" width="834" height="263" data-path="img/sa/access-mode.png" />

| Modo                          | Comportamiento                                                                                   |
| ----------------------------- | ------------------------------------------------------------------------------------------------ |
| **Allow Any New Users**       | Predeterminado. Se permiten registros por correo electrónico/contraseña, Google OAuth y SSO.     |
| **Restrict to SAML Metadata** | Solo se permiten usuarios SSO cuyos atributos SAML coincidan con al menos una regla configurada. |

## Cómo Funciona la Coincidencia de Reglas

Las reglas se definen por un **Nombre de Atributo** y uno o más **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="Reglas de Acceso SAML" width="1744" height="1038" data-path="img/sa/saml-access-rules-v2.png" />

### El modelo mental: todo es un conjunto

Una regla y un atributo de usuario entrante se reducen ambos a un **conjunto de tokens** y se comparan con semántica de subconjunto:

* Una regla coincide cuando sus tokens requeridos son un **subconjunto** de los tokens del usuario
* La lógica entre reglas es **OR** — cualquier coincidencia individual de regla otorga acceso
* Todas las comparaciones son **sin distinción de mayúsculas/minúsculas** e ignoran espacios al inicio/final

### Reglas con múltiples tokens (AND dentro de una regla)

Las comas en el campo **Valor(es) de Atributo** son separadores de tokens. La interfaz promueve cada entrada separada por comas en un chip; la regla requiere que **todos** los tokens listados estén presentes.

* `engineering` — requiere un token: el atributo del usuario debe contener `engineering`
* `Accounting, US` — requiere dos tokens: el atributo del usuario debe contener **ambos** `accounting` y `us`

### Manejo de diferentes formatos de transmisión SAML

Los atributos SAML pueden llegar en dos formatos:

**Multi-valor nativo** — el IdP envía múltiples elementos `<AttributeValue>` dentro de un `<Attribute>`:

```xml theme={null}
<Attribute Name="memberOf">
  <AttributeValue>Accounting</AttributeValue>
  <AttributeValue>US</AttributeValue>
</Attribute>
```

EKB siempre trata esto como un conjunto. No se necesita configuración adicional. Este es el formato preferido.

**Valor único con CSV** — el IdP envía un `<AttributeValue>` que contiene tokens separados por comas:

```xml theme={null}
<Attribute Name="memberOf">
  <AttributeValue>Accounting,US</AttributeValue>
</Attribute>
```

Esto es ambiguo (¿son dos grupos, o un valor literal que contiene una coma?). Use el toggle por regla para resolverlo:

| Toggle: "IdP packs multi-values into one string" | Comportamiento                                                          |
| ------------------------------------------------ | ----------------------------------------------------------------------- |
| **Off** (predeterminado)                         | La cadena del usuario se trata como un token literal                    |
| **On**                                           | La cadena del usuario se divide por comas y se compara como un conjunto |

<Note>
  Este toggle solo afecta cómo se interpreta el atributo del **usuario**. Las comas en el lado de la regla siempre son separadores de tokens sin importar la configuración.
</Note>

### Matriz de comportamiento de coincidencia

| Atributo del usuario (formato) | Toggle | Valor de regla | ¿Coincide? |
| ------------------------------ | ------ | -------------- | ---------- |
| nativo `["A","B","C"]`         | off    | `A`            | ✓          |
| nativo `["A","B","C"]`         | off    | `A, B`         | ✓          |
| único `"A,B,C"`                | off    | `A`            | ✗          |
| único `"A,B,C"`                | off    | `A, B`         | ✗          |
| único `"A,B,C"`                | on     | `A`            | ✓          |
| único `"A,B,C"`                | on     | `A, B`         | ✓          |
| único `"A"`                    | off    | `A`            | ✓          |

## Comportamiento Cuando el Modo Restringido está Activo

<AccordionGroup>
  <Accordion title="Qué se bloquea">
    * Nuevos registros por correo electrónico/contraseña
    * Nuevos registros por Google OAuth
    * Nuevos usuarios SSO cuyos atributos SAML no coincidan con ninguna regla
  </Accordion>

  <Accordion title="Qué sigue permitido">
    * Usuarios SSO existentes que coincidan con al menos una regla (se re-verifica en cada inicio de sesión)
    * Usuarios locales existentes iniciando sesión en cuentas existentes
    * Cuentas de Super Admin a través de SSO, incluso sin una regla coincidente (escapatoria intencional)
    * Claves API pertenecientes a Super Admins o claves a nivel de proyecto sin fila de usuario asociada
  </Accordion>
</AccordionGroup>

<Note>
  Las solicitudes de claves API de usuarios vinculados a SAML también se controlan en modo restringido. EKB verifica los metadatos SAML almacenados del usuario (de su último inicio de sesión SSO) contra las reglas de acceso antes de permitir acceso a la API.
</Note>

<Warning>
  **Comportamiento de apertura por fallo:** Si el modo restringido está activado pero no existen reglas de acceso SAML, EKB permite a todos los usuarios SSO. Esto previene el bloqueo accidental, pero siempre debe definir al menos una regla antes de habilitar la gobernanza estricta.
</Warning>

## Configurar Controles de Acceso

<Steps>
  <Step title="Abrir Controles de Acceso">
    Vaya a **Super Admin → Security & Access → Access Controls**.
  </Step>

  <Step title="Seleccionar Modo Restringido">
    Elija **Restrict to SAML Metadata**.
  </Step>

  <Step title="Agregar Reglas de Acceso SAML">
    Agregue una o más reglas bajo **SAML Access Rules**. Ejemplos:

    ```
    department = engineering
    memberOf = ekb-users
    memberOf = ekb-users, us   (requiere ambos tokens)
    ```

    Active el toggle **IdP packs multi-values into one string** si el atributo del lado del usuario llega como una sola cadena separada por comas.
  </Step>

  <Step title="Guardar y Validar">
    Guarde sus reglas y pruebe con cuentas SSO representativas antes de implementar ampliamente.
  </Step>
</Steps>

### Enfoque de Implementación Recomendado

1. Cree reglas mientras el modo sigue establecido en **Allow Any New Users**
2. Valide inspeccionando los metadatos SAML almacenados para cuentas SSO piloto en la vista de usuarios del Super Admin
3. Cambie a **Restrict to SAML Metadata**
4. Monitoree los inicios de sesión y los resultados de acceso denegado

## Lista de Verificación de Pruebas

Después de la configuración, verifique cada escenario:

* Un usuario SSO que **debe** ser permitido puede iniciar sesión
* Un usuario SSO que **no debe** ser permitido es redirigido a la experiencia de acceso denegado
* Los usuarios denegados ven la experiencia de acceso denegado esperada
* Al menos una regla válida está activa para evitar deriva de políticas

## Solución de Problemas

<AccordionGroup>
  <Accordion title="Usuario denegado inesperadamente">
    * Confirme que el modo de acceso no esté establecido accidentalmente como restringido
    * Verifique que la regla use el nombre de atributo correcto y el valor exacto esperado
    * Confirme que el IdP esté enviando ese atributo para ese usuario
    * Para reglas con múltiples tokens, cada token listado debe estar presente en el atributo del usuario — verifique los metadatos SAML almacenados en la vista de usuarios del Super Admin
    * Si el atributo llega como una cadena CSV única, confirme que **IdP packs multi-values into one string** esté habilitado en la regla
    * Verifique si el usuario está intentando iniciar sesión con correo electrónico/contraseña o Google OAuth mientras el modo restringido está activo
  </Accordion>

  <Accordion title="Super Admin bloqueado">
    Las cuentas de Super Admin siempre son permitidas a través de SSO incluso sin una regla coincidente. Si está bloqueado, inicie sesión a través de SSO usando una cuenta de Super Admin para recuperar el acceso.
  </Accordion>
</AccordionGroup>

## Guía Operativa

* Trate las reglas de acceso como **configuración sensible de seguridad**
* Use procesos de gestión de cambios para actualizaciones en producción
* Vuelva a probar después de cualquier cambio en las reclamaciones del IdP
* Revise periódicamente las reglas y elimine mapeos obsoletos
* Mantenga al menos una regla válida activa para prevenir estados de apertura por fallo no deseados