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.
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 entornoFRONTEND_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:Proveedor de Servicio (SP) — EKB
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.
Proveedor de Identidad (IdP) — Su Org
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.
acme.com), un Super Admin necesita completar ambos lados de este intercambio:
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.
@<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. |
Modo A — SSO de un solo clic (VITE_ALLOW_ONLY_SSO_LOGIN=true)
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 Para que esto funcione:
VITE_SSO_ENTERPRISE_ID y redirige inmediatamente a:VITE_SSO_ENTERPRISE_IDdebe 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).
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.Modo B — SSO con modal de correo electrónico (VITE_ALLOW_ONLY_SSO_LOGIN=false, predeterminado)
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:
- 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.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).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 |
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 queenterprise_id se resuelve a metadatos subidos, la autenticación procede como una secuencia de redirecciones del navegador:
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.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.IdP autentica al usuario
Su IdP maneja la autenticación — contraseña, MFA, certificado o lo que su organización haya configurado.
IdP → Backend
El IdP envía la respuesta SAML por POST al endpoint ACS del backend de EKB: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.
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.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.