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

# Cómo Funciona el SAML SSO en EKB

> Comprenda cómo EKB se integra con su Proveedor de Identidad para SAML 2.0 SSO antes de comenzar la configuración.

<Note>
  Esta guía está escrita para administradores de TI e identidad que gestionan una instancia on-premise de EKB. Cualquier referencia a "su IdP", "su administrador del IdP" o "su dominio de correo electrónico" se refiere a la infraestructura de su propia organización — no a lo que gestione Automation Anywhere.
</Note>

EKB admite **SAML 2.0 SSO** para implementaciones on-premise, permitiendo que sus usuarios inicien sesión a través del **Proveedor de Identidad (IdP)** existente de su organización. La configuración se realiza completamente a través del **Panel de Super Admin → pestaña SSO Metadata** — no se requieren cambios de código.

EKB funciona con cualquier **IdP SAML 2.0 compatible con estándares** — Okta, Azure AD / Entra ID, Ping, ADFS, OneLogin, Auth0, Keycloak, Google Workspace y otros. Una vez que sube los metadatos del IdP para un dominio de correo electrónico, EKB enrutará automáticamente SSO para cualquier usuario cuyo correo electrónico pertenezca a ese dominio.

## Comprender Sus Dos Nombres de Host de EKB

Una implementación on-premise de EKB tiene dos nombres de host con roles distintos:

* `<su-host-de-backend>` — maneja todo el tráfico SAML: metadatos SP, inicio de SSO y el endpoint ACS. **Este es el único host que su IdP necesita conocer.** *(Ejemplo: `ek-api.corp.acme.com`)*
* `<su-host-de-frontend>` — la interfaz web que sus usuarios abren en su navegador. EKB redirige a los usuarios aquí después de un inicio de sesión exitoso, configurado a través de la variable de entorno `FRONTEND_ROOT_URL`. **Este host nunca aparece en la configuración de su IdP.** *(Ejemplo: `ek.corp.acme.com`)*

## Cómo Funciona el SAML SSO en EKB

Configurar SAML SSO requiere un intercambio mutuo de confianza entre dos sistemas. Cada lado necesita conocer al otro antes de que pueda ocurrir cualquier autenticación:

<CardGroup cols={2}>
  <Card title="Proveedor de Servicio (SP) — EKB" icon="server">
    Su instancia on-premise de EKB. EKB publica metadatos SP para que su IdP sepa dónde enviar las respuestas SAML, qué formato NameID usar y qué certificado de firma confiar en las AuthnRequests.
  </Card>

  <Card title="Proveedor de Identidad (IdP) — Su Org" icon="shield-halved">
    El Okta, Entra ID, Ping, ADFS, etc. de su organización. Su IdP publica sus propios metadatos XML describiendo su emisor, endpoint SSO y certificado de firma — EKB necesita esto para validar las afirmaciones que su IdP retorna.
  </Card>
</CardGroup>

Para habilitar SSO para un dominio de correo electrónico (por ejemplo `acme.com`), un Super Admin necesita completar ambos lados de este intercambio:

<Steps>
  <Step title="Compartir los Metadatos SP con su IdP">
    Proporcione al administrador de su IdP los metadatos SP publicados por su instancia de EKB para que puedan registrar EKB como una aplicación SAML en su IdP.
  </Step>

  <Step title="Subir los Metadatos del IdP a EKB">
    Una vez creada la aplicación del IdP, suba el XML de metadatos resultante del IdP a EKB a través de **Super Admin → SSO Metadata**, asociado al dominio de correo electrónico con el que los iniciarán sesión.
  </Step>
</Steps>

Una vez que ambos lados estén en su lugar, cualquier usuario con un correo electrónico que termine en `@<dominio>` puede iniciar sesión en EKB a través de SAML SSO a través de su IdP corporativo.

## Cómo el Usuario Llega al Flujo SSO

La pantalla de inicio de sesión de EKB siempre muestra una opción "Sign in with SSO". Lo que sucede cuando un usuario hace clic en ella depende de dos variables de entorno del frontend incorporadas en la compilación de la interfaz web de EKB:

| Variable                    | Propósito                                                                                                        |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `VITE_ALLOW_ONLY_SSO_LOGIN` | Determina qué modo SSO usa la pantalla de inicio de sesión.                                                      |
| `VITE_SSO_ENTERPRISE_ID`    | Se usa solo en modo de un solo clic para especificar el dominio de correo electrónico contra el cual autenticar. |

<AccordionGroup>
  <Accordion title="Modo A — SSO de un solo clic (VITE_ALLOW_ONLY_SSO_LOGIN=true)">
    La pantalla de inicio de sesión muestra solo un botón de SSO — sin campos de correo electrónico o contraseña. Esta es la configuración típica para una implementación on-premise que sirve a un solo dominio de correo electrónico.

    Cuando el usuario hace clic en el botón, el frontend lee `VITE_SSO_ENTERPRISE_ID` y redirige inmediatamente a:

    ```
    https://<su-host-de-backend>/sso/login?enterprise_id=<VITE_SSO_ENTERPRISE_ID>&target_url=https://<su-host-de-frontend>/okta/authenticate
    ```

    Para que esto funcione:

    * `VITE_SSO_ENTERPRISE_ID` debe estar establecido en el frontend.
    * Su valor debe coincidir con un dominio que tenga metadatos del IdP subidos en la pestaña **SSO Metadata**.
    * Al subir metadatos, el **SSO Team Email Domain** debe coincidir exactamente con `VITE_SSO_ENTERPRISE_ID` (sin distinción de mayúsculas/minúsculas; los valores se normalizan a minúsculas al guardar).

    Si `VITE_SSO_ENTERPRISE_ID` no está establecido, el usuario ve *"Could not determine domain for SSO login"* y no puede proceder. Si está establecido pero no existen metadatos para ese dominio, la redirección se realiza pero SSO falla en el backend.
  </Accordion>

  <Accordion title="Modo B — SSO con modal de correo electrónico (VITE_ALLOW_ONLY_SSO_LOGIN=false, predeterminado)">
    La pantalla de inicio de sesión muestra controles de correo electrónico/contraseña y SSO juntos. Hacer clic en el botón de SSO abre un modal *"Enter your email"*. Después de que el usuario envía su correo electrónico, el frontend extrae el dominio y verifica con el backend si SSO está configurado para él a través de `POST https://<su-host-de-backend>/sso/verify_enterprise_id`.

    * Si **sí**, el frontend redirige a:
      ```
      https://<su-host-de-backend>/sso/login?enterprise_id=<dominio-de-email>&target_url=https://<su-host-de-frontend>/okta/authenticate
      ```
    * Si **no**, el usuario ve *"Your organization is not configured for SSO login. Please contact your administrator."*

    `VITE_SSO_ENTERPRISE_ID` no se usa en este modo. Múltiples dominios pueden coexistir — cada uno necesita sus propios metadatos del IdP subidos en la pestaña SSO Metadata.
  </Accordion>
</AccordionGroup>

<Info>
  Ambos modos usan el mismo endpoint backend `/sso/login` con el mismo parámetro `enterprise_id`. La única diferencia es si ese valor está codificado por una variable de entorno del frontend (Modo A) o se deriva del correo electrónico del usuario al iniciar sesión (Modo B).
</Info>

## Qué Hace el Backend con `enterprise_id`

Cuando el backend recibe `GET /sso/login?enterprise_id=acme.com`, busca los metadatos del IdP subidos para `acme.com` y construye una configuración SAML SP sobre la marcha:

| Parámetro                     | Valor                                                                                                                                                                              |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Entity ID**                 | `CUSTOM_ENTITY_ID_FOR_GENERIC_SSO` si se estableció en el momento del despliegue; de lo contrario se predetermina a `https://<su-host-de-backend>/user/generic/sso/saml/acs/admin` |
| **ACS endpoint**              | `https://<su-host-de-backend>/user/generic/sso/saml/acs/admin` (enlazamiento HTTP-POST)                                                                                            |
| **NameID format**             | `emailAddress`                                                                                                                                                                     |
| **Metadatos remotos del IdP** | Una URL firmada que apunta al XML subido en el almacenamiento                                                                                                                      |

Si no hay metadatos en archivo para el `enterprise_id` proporcionado, el backend no puede construir una configuración SAML SP y el intento de SSO falla.

## Cadena de Redirección a Nivel de Navegador

Una vez que `enterprise_id` se resuelve a metadatos subidos, la autenticación procede como una secuencia de redirecciones del navegador:

<Steps>
  <Step title="El usuario comienza en el frontend">
    El usuario abre EKB en `https://<su-host-de-frontend>` y hace clic en el botón de SSO.
  </Step>

  <Step title="Frontend → Backend">
    El frontend redirige el navegador al punto de entrada SSO del backend:

    ```
    GET https://<su-host-de-backend>/sso/login?enterprise_id=acme.com&target_url=https://<su-host-de-frontend>/okta/authenticate
    ```
  </Step>

  <Step title="Backend → IdP">
    El backend construye una AuthnRequest SAML a partir de los metadatos del IdP subidos para `acme.com` y redirige el navegador al endpoint SSO de su IdP.
  </Step>

  <Step title="IdP autentica al usuario">
    Su IdP maneja la autenticación — contraseña, MFA, certificado o lo que su organización haya configurado.
  </Step>

  <Step title="IdP → Backend">
    El IdP envía la respuesta SAML por POST al endpoint ACS del backend de EKB:

    ```
    POST https://<su-host-de-backend>/user/generic/sso/saml/acs/admin
    ```

    El backend valida la afirmación contra el certificado de firma del IdP de los metadatos subidos, luego inicia sesión al usuario en su cuenta de EKB existente o provisiona una nueva.
  </Step>

  <Step title="Backend → Frontend">
    El backend redirige el navegador del usuario de vuelta a EKB en `<su-host-de-frontend>`. La URL exacta está determinada por la variable de entorno `FRONTEND_ROOT_URL` en el backend — si esto está mal configurado, el usuario parecerá completar SSO exitosamente pero aterrizará en la página incorrecta.
  </Step>
</Steps>

<Note>
  El IdP solo interactúa con `<su-host-de-backend>`. El host del frontend aparece al principio del flujo (donde comienza el usuario) y al final (donde aterriza después del inicio de sesión) — nunca aparece en ninguna URL visible para el IdP.
</Note>

¿Listo para configurar SSO? Consulte la [Guía de Configuración de Metadatos SSO](/super-admin/sso/saml-sso-metadata-setup-guide) para instrucciones paso a paso.