Single sign-on

Delegue el inicio de sesión en la consola a un proveedor de identidad corporativo mediante SAML2, OIDC, OAuth2, CAS o Slack, y asigne los atributos del proveedor a los registros de usuario de aquí.

Qué es esto y cuándo usarlo

Con single sign-on, el proveedor de identidad autentica a la persona y la solución confía en la aserción que recibe de vuelta. Los usuarios llegan a la consola sin una contraseña aparte, y el segundo factor y las reglas de acceso condicional configuradas en el proveedor corporativo también se respetan en este inicio de sesión.

Úselo cuando la organización ya opere un proveedor de identidad: Entra ID (Azure AD)/ADFS, Okta, Keycloak, PingFederate, OneLogin, Google Workspace. Si lo que tiene es un directorio y no un proveedor de federación, consulte LDAP y Active Directory.

La solución actúa exclusivamente como Service Provider. Consume aserciones de un proveedor de identidad y no puede actuar como proveedor de identidad para otras aplicaciones.

Los métodos se habilitan por separado y conviven, de modo que una migración no tiene por qué ser un cambio de golpe: deje habilitados el inicio de sesión local y el método antiguo hasta comprobar el nuevo.

Qué método elegir

Método	Úselo para
SAML2	El estándar corporativo. Entra ID/ADFS, Okta, PingFederate, OneLogin
OIDC	SSO moderno sobre OAuth 2.0. Keycloak, Entra ID, Google Workspace, Okta
OAuth2	Un proveedor sin soporte de OIDC ni SAML, en el que usted conecta los endpoints a mano
CAS	Un despliegue CAS ya existente. Basado en tickets; se admite la versión 3
Slack	Equipos que ya trabajan en Slack. Requiere un Slack App

Antes de empezar

• El perfil SYSADMIN.

• Acceso administrativo al proveedor de identidad, o alguien que lo tenga: la configuración es simétrica y hay que hacer las dos mitades.

• La URL pública de esta instalación. La URL de callback a la que redirige el proveedor se deriva de ella, y una discrepancia es el primer fallo habitual.

• Para SAML2, el certificado del Service Provider que hay que subir y los metadatos del proveedor de identidad.

• Para OAuth2, los endpoints de autorización, token y userinfo.

• Para Slack, un Slack App con su Client ID y su Client Secret.

Pasos

1. Abra Configuración del sistema › Autenticación y seleccione el método.

2. Habilite el proveedor. Solo los proveedores habilitados aparecen en la pantalla de inicio de sesión.

3. Introduzca la configuración propia del proveedor:

   • SAML2: suba el certificado del SP y configure el lado del IdP.

   • OIDC: los datos del proveedor, además del Realm para Keycloak y el ajuste de sesión compartida.

   • OAuth2: los endpoints de autorización, token y userinfo, configurados manualmente.

   • CAS: el servidor CAS, con las URL que figuran más abajo.

   • Slack: el Client ID y el Client Secret del Slack App.

4. Defina el mapa de Atributos de usuario, el JSON que indica qué claim o atributo del proveedor alimenta username, name y email aquí. Véase Asignación de atributos.

5. Defina la Organización en la que se crean los usuarios del proveedor, si la creación de usuarios está habilitada. Eso decide en qué inquilino aterrizan.

6. Registre la URL de callback en el lado del proveedor, exactamente como la publica la solución.

7. Guarde y pruebe en una ventana privada del navegador, para no perder la sesión actual.

URL de servicio

Cada proveedor expone tres endpoints bajo el propio nombre de host de la instalación:

Finalidad	Ruta
Inicio de sesión	https://<your-server>/core/auth/<provider>/login/
Callback de inicio de sesión correcto	https://<your-server>/core/auth/<provider>/callback/
Cierre de sesión	https://<your-server>/core/auth/<provider>/logout/

<provider> es el nombre del propio método: cas, oauth2, y así sucesivamente. La URL de callback es la que hay que registrar en el proveedor de identidad.

Asignación de atributos

El mapa es JSON puro, y las claves de la derecha son como el proveedor llama a sus atributos. CAS publica nombres de atributo con prefijo:

{
  "cas:user": "username",
  "cas:fullname": "name",
  "cas:mail": "email"
}

Un proveedor OAuth2 que expone un claim de correo con alcance:

{
  "name": "user",
  "username": "name",
  "email": "user:email"
}

Tome los nombres de los atributos de la documentación del propio proveedor o de una aserción de prueba. Adivinar produce un inicio de sesión correcto y un registro de usuario con campos en blanco.

Lo que debería ver

La pantalla de inicio de sesión gana un botón para el proveedor. El inicio de sesión local sigue disponible salvo que lo deshabilite.

Cómo verificar que funcionó

1. En una ventana privada del navegador, abra la consola y elija el proveedor. Debería ser redirigido al proveedor de identidad, autenticarse allí y volver con la sesión iniciada.

2. Abra Usuarios › Usuarios y localice al usuario. La columna Origen debe mostrar el proveedor externo y no Local; de lo contrario, ha entrado en una cuenta local preexistente y no ha probado nada.

3. Compruebe Nombre y Correo electrónico en ese registro. Los campos en blanco significan que el mapa de atributos es incorrecto, aunque el inicio de sesión haya funcionado.

4. Confirme que el usuario aterrizó en la organización prevista.

5. Compruebe que la entrada queda registrada en el registro de auditoría con el proveedor como fuente de autenticación. Consulte Registro de auditoría.

6. Cierre la sesión y confirme que no vuelve a entrar en silencio: la URL de cierre de sesión forma parte de la configuración por una razón.

Errores comunes

Síntoma	Causa	Solución
El proveedor no aparece en la pantalla de inicio de sesión	Está configurado pero no habilitado	Marque la casilla de habilitación del proveedor
El proveedor de identidad rechaza la redirección	La URL de callback registrada allí no coincide con la publicada aquí	Registre exactamente la URL /core/auth/<provider>/callback/, con esquema y nombre de host
El acceso funciona pero el usuario no tiene nombre ni correo	El mapa de Atributos de usuario nombra claims que el proveedor no envía	Corrija el JSON contra una aserción real del proveedor
Los usuarios aparecen en el inquilino equivocado	La Organización del proveedor no es la que esperaba	Defínala antes del primer inicio de sesión; mover usuarios después es trabajo manual
Se queda fuera a mitad de la configuración	El único método habilitado es justo el que se está cambiando	Mantenga habilitado el inicio de sesión local hasta comprobar el SSO, y pruebe en una ventana privada
Al cerrar sesión vuelve directamente a la consola	La sesión del proveedor sigue abierta	Configure la URL de cierre de sesión para que la sesión también termine en el proveedor

Referencia de campos

Campos comunes a todos los proveedores:

Campo	Qué significa
Activar	Casilla por proveedor. Solo los proveedores habilitados aparecen en la pantalla de inicio de sesión
Atributos de usuario	Mapa JSON de los atributos del proveedor hacia username, name y email
Organización	El inquilino en el que se crean los usuarios del proveedor cuando la creación de usuarios está habilitada

Configuración propia documentada para cada método:

Método	Configuración
SAML2	Subida del certificado del Service Provider, más la configuración del IdP
OIDC	Datos del proveedor, Realm (para Keycloak) y control de sesión compartida
OAuth2	Endpoints de autorización, token y userinfo, introducidos manualmente
CAS	Servidor CAS, con las URL de inicio de sesión, callback y cierre de sesión. Admite la versión 3
Slack	Client ID y Client Secret de un Slack App

Páginas relacionadas

• LDAP y Active Directory: inicio de sesión por directorio y sincronización de usuarios

• Autenticación multifactor: un segundo factor aquí, o delegado al proveedor de identidad

• Usuarios y grupos: los registros que crea el SSO

• Políticas de inicio de sesión: cuándo y desde dónde se permite el acceso

• Roles y permisos: lo que un usuario puede hacer una vez dentro