SSO & SCIM. Enterprise identity, zero friction.

Elido utiliza WorkOS como broker de SSO y SCIM, que admite Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud y cualquier IdP compatible con SAML 2.0. También se admiten conexiones OIDC para proveedores como Google Workspace y Azure. Si su IdP no está en la lista estándar de WorkOS, el tipo de conexión 'Generic SAML' de WorkOS funciona con cualquier flujo SAML 2.0 iniciado por el SP. Contáctenos si necesita una conexión IdP específica que no figure en la lista.

El aprovisionamiento JIT (Just-in-Time) crea una cuenta de usuario en Elido en su primer inicio de sesión SSO — no se requiere aprovisionamiento previo. Es más sencillo de configurar pero no ofrece control sobre quién puede iniciar sesión (cualquier persona con una aserción SSO válida obtiene una cuenta). El aprovisionamiento SCIM otorga el control a su IdP: solo los usuarios del grupo aprovisionado pueden iniciar sesión, y las cuentas se crean antes del primer inicio de sesión. Para entornos empresariales donde el acceso debe ser pre-aprobado, se requiere SCIM. Cuando SCIM está activo, el aprovisionamiento JIT se deshabilita.

En la configuración de SSO del espacio de trabajo, usted mapea sus grupos de IdP a roles de Elido: por ejemplo, 'Grupo de Okta: Administradores de Elido' → 'Rol de Elido: Admin', 'Grupo de Okta: Miembros de Elido' → 'Rol de Elido: Member'. El rol de un usuario en Elido sigue su membresía de grupo en el IdP — si se mueven del grupo de Administradores al grupo de Miembros en Okta, su rol en Elido se degrada en la siguiente sincronización SCIM (normalmente en menos de 60 segundos). Un usuario en múltiples grupos adquiere el rol con mayores privilegios de los mapeos coincidentes.

El SSO se puede configurar como obligatorio (todos los usuarios deben iniciar sesión a través de SSO — el inicio de sesión con contraseña se deshabilita) u opcional (los usuarios pueden elegir SSO o correo electrónico + contraseña). En Business, la obligatoriedad se configura en los ajustes de SSO del espacio de trabajo. Una vez que es obligatorio, los usuarios que no tienen una identidad SSO activa quedan bloqueados — asegúrese de que el aprovisionamiento SCIM o JIT haya creado las cuentas antes de habilitar la obligatoriedad. Las cuentas de administrador pueden estar exentas de la obligatoriedad del SSO como mecanismo de emergencia; esto es configurable.

Cuando SCIM desactiva a un usuario, Elido suspende todas las claves de API creadas por ese usuario. Las claves suspendidas devuelven HTTP 401 en la autenticación. Las claves no se eliminan — permanecen visibles para los administradores del espacio de trabajo para fines de auditoría, con una etiqueta de estado 'suspendida — usuario dado de baja'. Si una cuenta de servicio estaba utilizando una clave de API personal (no una clave de servicio del espacio de trabajo), la suspensión de la clave interrumpirá esa integración — esto es intencionado. Para integraciones de producción, utilice claves de servicio a nivel de espacio de trabajo en lugar de claves de API de usuario.

El SSO y SCIM son funciones exclusivas de Business. Los espacios de trabajo Pro utilizan la autenticación integrada de Elido (correo electrónico + contraseña a través de Ory Kratos, OAuth opcional de Google/GitHub). Si el SSO es un requisito indispensable para su aprobación de compra, el plan Business es el punto de partida. Póngase en contacto con ventas para una prueba de Business si necesita evaluar el SSO antes de comprometerse.

Cada espacio de trabajo de Elido tiene su propia configuración de SSO — si gestiona múltiples espacios de trabajo (por ejemplo, por marca, por unidad de negocio), cada uno obtiene su propia conexión IdP y aprovisionamiento SCIM por separado. Los usuarios pueden ser miembros de múltiples espacios de trabajo con diferentes roles en cada uno; su identidad IdP es la misma, pero los mapeos de grupos a roles se evalúan por espacio de trabajo. Un grupo compartido de Okta puede mapearse como Admin en un espacio de trabajo y Member en otro.

Sí. Los intentos fallidos de SSO (aserción SAML no válida, sesión caducada, falta de cuenta SCIM cuando JIT está desactivado) se registran en el registro de auditoría del espacio de trabajo con el código de motivo. Esto es útil para diagnosticar por qué un usuario específico no puede iniciar sesión y para detectar sondeos de SSO por fuerza bruta. Los intentos fallidos desde direcciones IP que superan un umbral activan una alerta en el espacio de trabajo (configurable en los ajustes de seguridad del espacio de trabajo).