Inicio de sesión único (SSO)#

Con el inicio de sesión único, los usuarios entran en Empowerment Center con la cuenta de su organización (Microsoft Entra ID, Keycloak, ADFS, Okta, Google Workspace…) en lugar de con una contraseña propia. ECenter admite proveedores OIDC (OpenID Connect) y SAML 2.0, varios a la vez.

Cómo funciona#

El proveedor de identidad solo dice quién es la persona. La cuenta, los roles y los privilegios son siempre los de ECenter:

Tiene que existir en ECenter un usuario habilitado con el mismo login que da el proveedor (sin distinguir mayúsculas). Si no existe, no hay sesión.
El SSO no da de alta usuarios ni les asigna roles. Para que el proveedor dé de alta, cambie y dé de baja usuarios automáticamente, use además SCIM.
Si el usuario de ECenter no tiene correo, se copia el que da el proveedor. Si ya tiene uno, no se toca. Si el del proveedor lo usa otro usuario, no se copia, se entra igual y queda en la auditoría.
El login con contraseña sigue disponible para los usuarios que la tienen. Un usuario sin contraseña solo entra con el proveedor.

Inicio de sesión único Ver a tamaño completo Ver a tamaño completo

La pantalla de entrada muestra un botón Continuar con … por proveedor, con el nombre que se le configure, y debajo el formulario de usuario y contraseña («o con su usuario de Empowerment Center»). Sin ningún proveedor configurado, solo pide usuario y contraseña.

La pantalla de entrada con el botón de un proveedor de identidad sobre el formulario de usuario y contraseña

Antes de empezar#

Acceso a la configuración del servidor: los proveedores se definen en el application.yml propio de la instalación (vea Configuración), no desde la aplicación. Hace falta reiniciar.
El proxy pasando al backend las cabeceras X-Forwarded-* (y, sin contenedores, SERVER_FORWARD_HEADERS_STRATEGY=framework): las direcciones de vuelta que se registran en el proveedor salen de la petición original que reconstruye el backend con ellas, no de ECENTER_PUBLIC_URL. La imagen del frontal ya manda al servidor las rutas del SSO (/oauth2/, /login/oauth2/, /saml2/ y /login/saml2/); un proxy propio tiene que hacer lo mismo (vea Instalación).
Permiso para registrar una aplicación en el proveedor de identidad.
Usuarios dados de alta en ECenter con el login que dará el proveedor, o el aprovisionamiento por SCIM.

Configurar un proveedor OIDC#

Registre ECenter como aplicación web en el proveedor, con esta dirección de redirección:
```
https://ecenter.example.org/login/oauth2/code/<id>
```
<id> es el nombre que dará al registro en ECenter (por ejemplo, empresa).
Anote el identificador de cliente, el secreto y la dirección del emisor (issuer).

Añada el registro al application.yml propio:

spring:
  security:
    oauth2:
      client:
        registration:
          empresa:
            client-id: ${OIDC_CLIENT_ID}
            client-secret: ${OIDC_CLIENT_SECRET}
            scope: openid,profile,email
            client-name: Cuenta de la empresa      # el texto del botón
        provider:
          empresa:
            issuer-uri: https://idp.example.org/...

Ponga el identificador y el secreto en el fichero de entorno (OIDC_CLIENT_ID, OIDC_CLIENT_SECRET), no en el application.yml.
Reinicie el servidor y compruebe que la pantalla de entrada muestra Continuar con Cuenta de la empresa.

Por defecto, el login de ECenter es el dato preferred_username del proveedor y el correo es email (solo si el proveedor no dice que no está verificado). Para cambiarlos, vea Opciones de ECenter por proveedor.

Configurar un proveedor SAML#

Añada el registro al application.yml propio, con un <id> (por ejemplo, adfs) y la dirección de los metadatos del proveedor:

spring:
  security:
    saml2:
      relyingparty:
        registration:
          adfs:
            entity-id: https://ecenter.example.org/saml2/service-provider-metadata/adfs
            assertingparty:
              metadata-uri: https://adfs.example.org/FederationMetadata/2007-06/FederationMetadata.xml
ecenter:
  security:
    sso:
      providers:
        adfs:
          name: Directorio corporativo   # SAML no tiene nombre propio: sin esto, el botón dice el id

Reinicie el servidor.
En el proveedor, dé de alta ECenter con sus metadatos, que publica en https://ecenter.example.org/saml2/service-provider-metadata/adfs. Si no puede importarlos, estos son los datos:

Dato Valor

Identificador (entity ID) El entity-id del registro

Servicio de consumo de aserciones (ACS) https://ecenter.example.org/login/saml2/sso/adfs
Configure qué dato envía el proveedor como NameID: por defecto, es el login de ECenter.

Si el proveedor exige que las peticiones vayan firmadas, añada al registro la clave y el certificado de ECenter (signing.credentials[0].private-key-location y signing.credentials[0].certificate-location, con rutas file: a ficheros montados en el servidor).

La respuesta de SAML llega desde el dominio del proveedor; ECenter guarda la petición en curso en su base de datos durante 10 minutos, así que funciona también con varias instancias.

Opciones de ECenter por proveedor#

Además del registro estándar, cada proveedor admite estas propiedades con el mismo <id>:

Propiedad	Por defecto	Qué hace
`ecenter.security.sso.providers.<id>.name`	El `client-name` (OIDC) o el id (SAML)	El texto del botón: Continuar con y este nombre.
`ecenter.security.sso.providers.<id>.login-attribute`	`preferred_username` (OIDC) o el NameID (SAML)	El dato del proveedor que se usa como login de ECenter.
`ecenter.security.sso.providers.<id>.email-attribute`	`email`	El dato del proveedor con el correo, que se copia si el usuario no tiene.
`ecenter.security.sso.providers.<id>.provider-logout`	`false`	Si Cerrar sesión cierra también la sesión del proveedor (vea abajo).

Una propiedad escrita sin valor es la de por defecto.

Ejemplos#

Microsoft Entra ID (OIDC)Keycloak (OIDC)Keycloak (SAML)

En el portal de Entra, registre una aplicación (plataforma web) con la dirección de redirección https://ecenter.example.org/login/oauth2/code/empresa, cree un secreto de cliente y anote el identificador del inquilino.

spring:
  security:
    oauth2:
      client:
        registration:
          empresa:
            client-id: ${OIDC_CLIENT_ID}
            client-secret: ${OIDC_CLIENT_SECRET}
            scope: openid,profile,email
            client-name: Cuenta de Microsoft
        provider:
          empresa:
            issuer-uri: https://login.microsoftonline.com/<inquilino>/v2.0

El preferred_username de Entra suele ser el nombre principal del usuario (maria.garcia@empresa.example): dé de alta a los usuarios de ECenter con ese login, o cambie login-attribute.

En el reino de Keycloak, cree un cliente OpenID Connect confidencial con Valid redirect URIs https://ecenter.example.org/login/oauth2/code/keycloak.

spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: ecenter
            client-secret: ${OIDC_CLIENT_SECRET}
            scope: openid,profile,email
            client-name: Keycloak
        provider:
          keycloak:
            issuer-uri: https://idp.example.org/realms/<reino>

El preferred_username es el nombre de usuario de Keycloak.

En el reino, cree un cliente SAML con Client ID igual al entity-id de ECenter, Valid redirect URIs con la dirección de ECenter y, en sus opciones, Force name ID format con el formato username, para que el NameID sea el nombre de usuario.

spring:
  security:
    saml2:
      relyingparty:
        registration:
          keycloak-saml:
            entity-id: ecenter-saml
            assertingparty:
              metadata-uri: https://idp.example.org/realms/<reino>/protocol/saml/descriptor
ecenter:
  security:
    sso:
      providers:
        keycloak-saml:
          name: Keycloak (SAML)

Cómo se enlaza cada usuario#

Al volver del proveedor, ECenter busca un usuario con el login que da el proveedor (el login-attribute), sin distinguir mayúsculas:

Resultado	Lo que ve el usuario
Existe y está habilitado	Entra con los roles y los privilegios de ese usuario de ECenter, tenga o no contraseña.
No existe, o no está habilitado	«El proveedor de identidad le ha reconocido, pero no tiene un usuario habilitado en Empowerment Center. Pida a un administrador que le dé de alta.» Queda en la auditoría como un intento fallido.
El proveedor falla o su respuesta no es válida	«No se pudo iniciar sesión con el proveedor de identidad. Inténtelo de nuevo.»

Para que un usuario que ya existía entre por SSO, su login tiene que coincidir con el dato del proveedor. Si no coincide, cámbielo con Cambiar login… en su detalle (vea Usuarios). Para que solo pueda entrar por SSO, no le ponga contraseña.

Importante

El login es lo que casa la cuenta del proveedor con la de ECenter. Quien puede cambiar logins decide quién entra en cada cuenta; por eso el login de un usuario con Administración del Sistema solo lo cambia quien también la tiene. Mantenga siempre algún administrador local con contraseña para poder entrar si el proveedor falla.

Cerrar sesión#

Por defecto, Cerrar sesión cierra solo la sesión de ECenter: la del proveedor sigue abierta y volver a entrar no pide la contraseña. En un puesto compartido conviene cerrar también la del proveedor. Se activa por proveedor:

ecenter:
  security:
    sso:
      providers:
        empresa:
          provider-logout: true

OIDCSAML

ECenter envía al usuario al servicio de cierre de sesión del proveedor (el end_session_endpoint que anuncia en su descubrimiento), que lo devuelve a https://ecenter.example.org/login. Registre esa dirección en el proveedor como dirección de vuelta tras cerrar la sesión: en Keycloak, Valid post logout redirect URIs; en Entra, entre las direcciones de redirección de la aplicación.

ECenter envía al proveedor una petición de cierre de sesión firmada. Hace falta:

spring:
  security:
    saml2:
      relyingparty:
        registration:
          adfs:
            signing.credentials[0].private-key-location: file:/etc/ecenter/saml/clave.pem
            signing.credentials[0].certificate-location: file:/etc/ecenter/saml/certificado.pem
            singlelogout.url: "{baseUrl}/login/saml2/slo/{registrationId}"
            singlelogout.response-url: "{baseUrl}/login/saml2/slo/{registrationId}"

En el proveedor, la dirección de cierre de sesión de ECenter es https://ecenter.example.org/login/saml2/slo/adfs (la anuncian sus metadatos). Si el proveedor recibe el cierre por un formulario, añada su origen a ECENTER_CSP_IDP_ORIGINS.

Al volver, la pantalla de entrada dice «Ha salido de Empowerment Center y de «…».». La sesión de ECenter se cierra siempre, aunque falle la del proveedor.

Una configuración a medias impide arrancar el servidor: provider-logout en un proveedor que no existe, en un OIDC que no anuncia servicio de cierre de sesión o en un SAML sin servicio de cierre de sesión en sus metadatos o sin credenciales de firma.

No se admite el cierre de sesión que inicia el proveedor (salir de otra aplicación y que se cierre ECenter): la sesión de ECenter sigue hasta que caduca o el usuario sale.

Problemas frecuentes#

Síntoma	Causa probable	Solución
No aparece el botón del proveedor	El registro no se ha leído: el `application.yml` no está montado o tiene un error.	Revise el fichero y el registro del servidor al arrancar.
El proveedor dice que la dirección de redirección no es válida	La dirección registrada no coincide con la que envía ECenter.	Compruebe que el proxy pasa las cabeceras `X-Forwarded-Proto` y `X-Forwarded-Host` (vea Instalación); registre exactamente `https://…/login/oauth2/code/<id>`.
«…no tiene un usuario habilitado en Empowerment Center…»	No hay usuario con ese login, o está inhabilitado o bloqueado.	Busque en la auditoría el login que llegó y dé de alta el usuario con ese login, o cambie `login-attribute`.
«No se pudo iniciar sesión con el proveedor de identidad…»	Respuesta no válida: firma, reloj desajustado, certificado caducado o metadatos cambiados.	Revise el registro del servidor y los metadatos del proveedor.
El usuario entra sin correo	El proveedor no envía el dato `email-attribute`, o lo usa otro usuario.	Configure el dato en el proveedor o ajuste `email-attribute`; si lo usa otro, la auditoría lo dice.

Véase también#

Aprovisionamiento por SCIM
Usuarios
Sesiones y entrada
Configuración
Integraciones: el MCP con la cuenta de la organización (OAuth)

Dato	Valor
Identificador (entity ID)	El `entity-id` del registro
Servicio de consumo de aserciones (ACS)	`https://ecenter.example.org/login/saml2/sso/adfs`