> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/administration/identities/sso.md).

# 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](/es/pam/administration/identities/ldap-and-ad.md).

{% hint style="warning" %}
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.
{% endhint %}

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](#asignacion-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:

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

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

```json
{
  "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](/es/pam/administration/audit/audit-trail.md).
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](/es/pam/administration/identities/ldap-and-ad.md): inicio de sesión por directorio y sincronización de usuarios
* [Autenticación multifactor](/es/pam/administration/identities/mfa.md): un segundo factor aquí, o delegado al proveedor de identidad
* [Usuarios y grupos](/es/pam/administration/identities/users-and-groups.md): los registros que crea el SSO
* [Políticas de inicio de sesión](/es/pam/administration/access/login-policies.md): cuándo y desde dónde se permite el acceso
* [Roles y permisos](/es/pam/administration/identities/roles.md): lo que un usuario puede hacer una vez dentro