Inicio de sesión único (SSO)¶

El SSO permite que las personas de tu organización entren en la consola con las credenciales de su proveedor de identidad (IdP). Se configura por inquilino, en Configuración › Seguridad y acceso › SSO, y lo configura el propio administrador del inquilino, sin pasar por soporte. Una vez activado, en la pantalla de acceso la persona escribe su correo y la consola la envía a su proveedor.

Qué admite¶

OpenID Connect (OIDC) y SAML 2.0. Cada inquilino tiene una única configuración de SSO, con uno de los dos protocolos.
Plantillas para Google Workspace, Microsoft Entra ID, Okta y OneLogin. Una plantilla solo rellena el formulario; después el proveedor funciona igual que uno escrito a mano. Cualquier otro proveedor que hable OIDC o SAML 2.0 se configura con Manual.
Cuando el acceso con SSO falla, la persona ve en la pantalla de acceso un mensaje que nombra el motivo (por ejemplo, dominio sin verificar o certificado caducado). Cuando el motivo es la cuenta (no existe, no pertenece a este inquilino o está desactivada), el mensaje es el mismo en los tres casos y le pide que hable con quien administra su organización. Si el motivo no es ninguno de los conocidos, aparece un mensaje genérico.

Quién puede configurarlo¶

Solo el Administrador del inquilino y el Administrador de organización. El Visor no ve esta pantalla y, si intenta usarla, la consola lo devuelve a su perfil. Los roles se explican en Roles y permisos.

Configurarlo paso a paso¶

Elige el protocolo y la plantilla.
- En OIDC indica la URL del emisor (la consola lee la configuración que el emisor publica y no acepta un emisor que no coincida con ella), el ID de cliente y el Secreto de cliente. El secreto se guarda cifrado y no se vuelve a mostrar; al editar, déjalo en blanco para conservar el actual.
- En SAML aporta los metadatos del IdP, bien como fichero XML, bien desde una URL (una sola de las dos fuentes). De ellos salen el identificador de la entidad, la URL de acceso y el certificado de firma.
Pega en tu proveedor los dos valores que muestra la consola: la URL de respuesta (ACS / callback) y el identificador del servicio (entity ID / audience).
Indica el dominio de correo de tu organización y, si hace falta, dominios adicionales (hasta 20 además del principal, uno por línea). Los subdominios no se incluyen solos. Un dominio que ya usa otro inquilino se rechaza.
Verifica el dominio por DNS. Pulsa Generar el registro y publica el registro TXT que aparece en el DNS de cada dominio permitido, con el nombre _hodeishield-sso.<dominio> y el mismo valor en todos. Después pulsa Comprobar ahora. El valor del registro caduca a los 7 días. Hasta que todos los dominios estén verificados nadie entra por SSO.

La verificación vale para el dominio y para el proveedor con el que la hiciste. Hay que generar un registro nuevo, verificar de nuevo y volver a activar el SSO (que se desactiva solo) cuando:
- añades o cambias un dominio (quitar uno no obliga a verificar los demás);
- cambias de proveedor de identidad: en OIDC, el emisor o los extremos que publica; en SAML, el identificador de la entidad o el certificado de firma, por ejemplo al subir metadatos nuevos.
Cambiar el nombre visible, la asignación de roles o el secreto de cliente no obliga a verificar de nuevo. 5. Prueba la conexión. Con Probar la conexión: - En OIDC, la consola vuelve a leer la configuración publicada por tu emisor y comprueba que responde. - En SAML no hay nada que llamar (el IdP solo habla con la consola enviando una aserción firmada), así que la prueba solo comprueba que el certificado de firma sigue en vigor. El resto exige un inicio de sesión real.

La consola guarda el resultado y la fecha de la última prueba, y los borra cada vez que guardas la configuración. 6. Activa el SSO con Activar el SSO. Solo se puede activar con el dominio verificado. Puedes desactivarlo cuando quieras. Eliminar la configuración devuelve a todo el mundo al acceso con contraseña y elimina los vínculos de las cuentas con ese proveedor (desde la versión 2.48.0).

Guardar la configuración, verificar el dominio, activar o desactivar el SSO y eliminarlo quedan registrados en el historial de auditoría. Un cambio de proveedor de identidad deja además su propia entrada.

Quién puede entrar¶

La consola rechaza el inicio de sesión por SSO cuando:

el SSO está configurado pero no activado;
el dominio no está verificado, o el correo no pertenece a los dominios autorizados (el dominio tiene que coincidir exactamente; el correo se compara sin distinguir mayúsculas de minúsculas);
el proveedor que firma el acceso no es el configurado;
el certificado SAML del IdP ha caducado;
la cuenta está desactivada o bloqueada, o su organización está inactiva (desactivar a una persona también corta su acceso por SSO);
la persona todavía no tiene cuenta en HodeiShield (el SSO no crea cuentas: invítala primero desde Equipo);
la cuenta existe pero no pertenece a este inquilino, aunque sea un administrador de organización.

Roles¶

Un directorio externo solo puede conceder los mismos dos roles que una invitación: Administrador del inquilino o Solo lectura. Nunca roles de organización ni de plataforma.

Rol por defecto. Es el que recibe quien no trae ningún grupo asignado. Por defecto es Solo lectura.
Asignación por grupo. Relaciona grupos de tu IdP con uno de los dos roles. La consola busca los grupos en las reclamaciones roles, groups, memberOf, Role y Group. Un rol fuera de esos dos se rechaza al guardar la asignación; no se rebaja en silencio. Si una persona trae varios grupos asignados, se aplica el primero que coincide, no el de mayor rol.
Los cambios de grupo llegan en el siguiente inicio de sesión, porque el rol se calcula en cada acceso.
La persona debe tener ya acceso a este inquilino. El SSO la hace entrar, pero nunca cambia el rol de quien tiene un rol de organización ni el de quien tiene acceso a más de un inquilino.

Caducidad del certificado SAML¶

En SAML, la firma del IdP se comprueba con un certificado que caduca.

La pantalla de SSO muestra un aviso cuando faltan 30 días o menos, y otro cuando ya ha caducado.
Una comprobación diaria deja además una entrada en el historial de auditoría de los inquilinos cuyo certificado caduca en esos 30 días o ya ha caducado. No se envía por correo: alguien tiene que mirar la pantalla o el historial.
Con el certificado caducado, nadie entra por SSO hasta que subas los metadatos nuevos. La prueba de conexión también informa de ello.
Un certificado nuevo cuenta como cambio de proveedor: después de subir los metadatos hay que verificar de nuevo el dominio y volver a activar el SSO (véase el paso 4).

MFA y SSO¶

Si tu inquilino exige MFA (en Configuración › Seguridad y acceso › Seguridad, véase políticas de seguridad del inquilino), una sesión creada por el SSO de ese inquilino queda exenta solo si el proveedor garantiza un segundo factor en ese inicio de sesión:

SAML: nunca queda exenta. La consola no lee del proveedor qué métodos usó la persona.
OIDC: queda exenta únicamente si el id_token de ese inicio de sesión incluye una reclamación amr que indica varios factores: mfa, otp, hwk, fido, o dos factores de distinto tipo (por ejemplo, contraseña y una clave de software). El id_token tiene que ser del inicio de sesión en curso (emitido como máximo 10 minutos antes).

Si la sesión no queda exenta, se aplica el segundo factor de la consola:

Si la persona ya tiene configurado un código TOTP en la consola, se le pide después del acceso por SSO. Esto ocurre aunque el inquilino no exija MFA.
Si no lo tiene y el inquilino exige MFA, la consola la lleva a configurarlo antes de seguir.

Lo que no hay hoy¶

El aprovisionamiento SCIM todavía no está disponible.
No hay un modo «solo SSO». El acceso con contraseña y segundo factor no se desactiva, de modo que una caída de tu proveedor no te deja fuera de la consola.