Gestión de usuarios con LDAP y SSO

Has llegado lejos. En el bloque anterior montaste Traefik como puerta de entrada, configuraste middlewares de seguridad, añadiste autenticación con BasicAuth y ForwardAuth, y desplegaste Authelia y Authentik como guardianes de tus aplicaciones. Pero hay un problema que quizá ya has empezado a notar. Tienes usuarios en Authelia. Tienes usuarios en Authentik. Tienes usuarios en Nextcloud, en Grafana, en Home Assistant. Cada servicio tiene su propia base de usuarios, su propio registro, su propio formulario de login. Si mañana entra una persona nueva en tu equipo, tienes que crearla en cinco sitios distintos. Si alguien se va, tienes que borrarla en cinco sitios distintos. Y la contraseña… bueno, cada uno gestiona las contraseñas por su cuenta.Esto no escala.

La solución es tener un directorio central de usuarios. Un solo lugar donde vivan todos los usuarios, sus grupos, sus datos de contacto. Y luego cada servicio consulta ese directorio para saber quién es quién. Ese directorio central es LDAP. Y el SSO (Single Sign-On) es la pieza que permite que, con un solo login, accedas a todos los servicios sin volver a identificarte.

En este capítulo vas a montar LLDAP, un servidor LDAP ligero y moderno, conectarlo con Authelia y Authentik, y configurar SSO con OIDC para que tus aplicaciones hablen directamente con tu proveedor de identidad. Un usuario, una contraseña, un punto de gestión. Todos los servicios.

¿Por qué gestionar usuarios de forma centralizada?

Pongamos números. Tienes cinco servicios: Nextcloud, Grafana, Home Assistant, Gitea y Jellyfin. Cada uno con su propio sistema de usuarios. Son cinco bases de datos de usuarios separadas. Si tienes tres personas en tu casa o en tu equipo, son quince cuentas que gestionar.

¿Qué pasa cuando alguien cambia su contraseña? Tiene que cambiarla en cinco sitios. ¿O cuando quieres aplicar una política de contraseñas fuertes? Tienes que configurarla en cinco servicios distintos. ¿O cuando alguien deja el equipo? Tienes que deshabilitar cinco cuentas.

Y el riesgo de seguridad es real. Cada servicio tiene su propio sistema de almacenamiento de contraseñas. Algunos usan bcrypt, otros usan SHA-256, otros ni siquiera hashean correctamente. Si uno de esos servicios tiene una vulnerabilidad y filtran la base de datos, las contraseñas de ese servicio están comprometidas.

Con un directorio central, todo eso desaparece.

Los usuarios se crean una vez en LDAP. Los grupos se definen una vez en LDAP. Las contraseñas se gestionan una vez en LDAP. Y cada servicio, en lugar de tener su propia base de usuarios, consulta LDAP para autenticar y autorizar.

El ecosistema: LDAP + SSO

LDAP resuelve el problema del directorio de usuarios. Pero no resuelve el problema de la sesión. Cuando entras en Nextcloud con LDAP, Nextcloud hace una consulta a LDAP para verificar tu contraseña, y luego crea su propia sesión. Si luego abres Grafana, tienes que volver a introducir tu contraseña.

Para eso está el SSO con OIDC (OpenID Connect). Con OIDC, un proveedor de identidad (Authelia, Authentik o Pocket ID) se encarga de autenticarte. Una vez que has iniciado sesión en el proveedor, todas las aplicaciones que confían en él te dejan entrar sin pedirte la contraseña otra vez.

La combinación ganadora es esta:

• LDAP como directorio central de usuarios y grupos.
• Authelia o Authentik como proveedor de identidad que consulta LDAP.
• OIDC como protocolo para que las aplicaciones hablen con el proveedor de identidad.

El usuario se crea una vez en LDAP. Inicia sesión una vez en Authelia o Authentik. Y accede a todos los servicios sin volver a autenticarse.

LDAP con LLDAP: el directorio ligero

LDAP suena a tecnología del siglo pasado. Y en parte lo es. El protocolo LDAP existe desde 1993. OpenLDAP, la implementación más conocida, es potente pero compleja. Su configuración es críptica, los archivos de esquema son difíciles de entender, y cualquier error te deja horas depurando.

Por suerte, existe LLDAP (Light LDAP).

LLDAP es un servidor LDAP moderno, escrito en Rust, con interfaz web, configuración sencilla y Docker Compose listo para usar. No necesitas aprender la sintaxis de OpenLDAP. No necesitas editar archivos de esquema. Todo se gestiona desde un navegador.

Instalación con Docker Compose y Traefik

Vamos a montar LLDAP detrás de Traefik, con HTTPS y tu dominio.

Primero, la estructura de directorios:

/home/lorenzo/docker/lldap/
├── docker-compose.yml
└── data/

La creas con:

mkdir -p /home/lorenzo/docker/lldap/data
cd /home/lorenzo/docker/lldap

LLDAP necesita una base de datos para almacenar los usuarios. Por defecto usa SQLite, que está bien para un servidor personal. Si necesitas PostgreSQL, también lo soporta, pero para este tutorial SQLite es más que suficiente.

Ahora el archivo docker-compose.yml:

services:
  lldap:
    image: lldap/lldap:latest
    container_name: lldap
    restart: unless-stopped
    volumes:
      - ./data:/data
    environment:
      - TZ=Europe/Madrid
      - LLDAP_LDAP_BASE_DN=dc=tudominio,dc=com
      - LLDAP_LDAP_USER_EMAIL=admin@tudominio.com
      - LLDAP_SERVER_KEY_SEED=genera-un-seed-aleatorio-aqui
      - LLDAP_LDAP_USER_PASS=contraseña-segura-del-admin
    networks:
      - traefik
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.lldap.rule=Host(`ldap.tudominio.com`)"
      - "traefik.http.routers.lldap.entrypoints=websecure"
      - "traefik.http.routers.lldap.tls=true"
      - "traefik.http.routers.lldap.tls.certresolver=letsencrypt"
      - "traefik.http.services.lldap.loadbalancer.server.port=17170"

networks:
  traefik:
    external: true

Fíjate en las variables de entorno:

• LLDAP_LDAP_BASE_DN: el dominio base de tu directorio LDAP. Sigue el formato dc=dominio,dc=tld. Si tu dominio es tudominio.com, pones dc=tudominio,dc=com.
• LLDAP_LDAP_USER_EMAIL: el email del administrador inicial.
• LLDAP_SERVER_KEY_SEED: una semilla para generar claves criptográficas. Genérala con openssl rand -base64 32.
• LLDAP_LDAP_USER_PASS: la contraseña del administrador inicial.

El puerto 17170 es el de la interfaz web. El servidor LDAP en sí escucha en el puerto 3890 dentro del contenedor, pero no lo expongas directamente (más adelante veremos cómo conectarlo a Authelia y Authentik por red interna).

Arrancas el contenedor:

docker compose up -d

Y en unos segundos tendrás LLDAP corriendo. Accede a https://ldap.tudominio.com e inicia sesión con admin@tudominio.com y la contraseña que configuraste.

Primer acceso a la interfaz web

La interfaz de LLDAP es limpia y minimalista. Nada de menús abarrotados. Te encuentras con:

• Users: lista de usuarios del directorio.
• Groups: lista de grupos.
• Settings: configuración del servidor LDAP.

Nada más crear el contenedor ya tienes dos usuarios: admin (el que creaste con el email) y lldap_admin (un admin técnico interno). Y un grupo: lldap_admin.

Tranquilo, no toques lldap_admin. Es interno.

Creación de usuarios y grupos en LLDAP

Vamos a crear los usuarios de tu infraestructura.

Crear un usuario

Desde la interfaz web, en la pestaña Users, haz clic en Add user.

Los campos que necesitas:

• Username: nombre corto, sin espacios. Por ejemplo: lorenzo, ana, marcos.
• Email: el correo electrónico del usuario.
• First name: nombre real.
• Last name: apellidos.
• Password: la contraseña inicial.
• Groups: grupos a los que pertenece (puedes dejarlo vacío y asignar después).

Cuando guardas, el usuario se crea en el directorio LDAP. Ya puedes usarlo para autenticarte en cualquier servicio que consulta este LDAP.

Crear un grupo

Los grupos te permiten organizar usuarios y aplicar permisos basados en pertenencia. Por ejemplo, puedes tener un grupo nextcloud_users para los usuarios que pueden acceder a Nextcloud, y un grupo grafana_admins para los que pueden administrar Grafana.

Desde la pestaña Groups, haz clic en Add group. Ponle un nombre descriptivo, como nextcloud_users o servicios_internos.

Luego, desde el perfil de cada usuario, puedes asignarlo a uno o varios grupos.

El árbol LDAP

Quizá te preguntes cómo se ve esto desde el lado del protocolo LDAP. LLDAP organiza los datos en una estructura de árbol:

dc=tudominio,dc=com
├── ou=people
│   ├── uid=lorenzo
│   ├── uid=ana
│   └── uid=marcos
└── ou=groups
    ├── cn=nextcloud_users
    └── cn=grafana_admins

Cada usuario tiene un DN (Distinguished Name) único: uid=lorenzo,ou=people,dc=tudominio,dc=com. Cada grupo tiene su propio DN: cn=nextcloud_users,ou=groups,dc=tudominio,dc=com.

Esto es importante porque cuando configures un servicio para que use LDAP, te pedirá el Base DN y a veces el Bind DN. Ya sabes de dónde salen.

Integración de LLDAP con Authelia como backend de usuarios

En el capítulo 9 configuraste Authelia con una base de usuarios local en users_database.yml. Eso está bien para uno o dos usuarios, pero si tienes más, mantener ese archivo YAML se vuelve tedioso.

Vamos a cambiar la configuración de Authelia para que use LLDAP como fuente de usuarios.

Configurar Authelia para LDAP

Editas tu configuration.yml de Authelia y modificas la sección authentication_backend:

authentication_backend:
  ldap:
    address: ldap://lldap:3890
    implementation: custom
    base_dn: dc=tudominio,dc=com
    additional_users_dn: ou=people
    users_filter: (&(|(uid={0})(mail={0}))(objectClass=inetOrgPerson))
    additional_groups_dn: ou=groups
    groups_filter: (member={dn})
    attributes:
      username: uid
      display_name: displayName
      mail: mail
      member_of: memberOf
      group_name: cn
    user:
      dn: uid=admin,ou=people,dc=tudominio,dc=com
      password: contraseña-segura-del-admin

Vamos por partes.

• address: la dirección del servidor LDAP. Usamos el nombre del contenedor lldap y el puerto 3890 (el interno, no el de la interfaz web). Como Authelia y LLDAP están en la misma red de Docker (traefik), se ven por nombre.
• implementation: custom porque LLDAP no es OpenLDAP ni Active Directory. Usa su propia implementación del protocolo.
• base_dn: el dominio base que configuraste en LLDAP.
• additional_users_dn: la unidad organizativa donde LLDAP guarda los usuarios (ou=people).
• users_filter: el filtro para buscar usuarios. Busca por uid o por mail, y solo usuarios con objectClass=inetOrgPerson.
• additional_groups_dn: la unidad organizativa de grupos (ou=groups).
• groups_filter: el filtro para saber a qué grupos pertenece un usuario.
• attributes: mapea los atributos de LDAP a los campos que Authelia entiende.
• user: las credenciales de la cuenta de servicio que Authelia usará para consultar LDAP. Usamos el admin de LLDAP.

Probar la integración

Reinicias Authelia:

cd /home/lorenzo/docker/authelia
docker compose restart authelia

Ahora, cuando intentes acceder a un servicio protegido por Authelia, en lugar de buscar el usuario en users_database.yml, lo buscará en LLDAP. Puedes probar con el usuario lorenzo que creaste antes.

Si funciona, has centralizado tus usuarios. Enhorabuena.

Integración de LLDAP con Authentik como backend de usuarios

Si en el capítulo 10 te decidiste por Authentik, la integración con LLDAP es igual de sencilla. Authentik tiene una fuente LDAP nativa.

Desde la interfaz web de Authentik, ve a Directory > Sources, haz clic en Create, y selecciona LDAP Source.

Los campos clave:

• Name: lldap-users
• Slug: lldap-users
• Server URI: ldap://lldap:3890
• Bind DN: uid=admin,ou=people,dc=tudominio,dc=com
• Bind Password: la contraseña del admin de LLDAP
• Base DN: dc=tudominio,dc=com
• User object filter: (objectClass=inetOrgPerson)
• Group object filter: (objectClass=groupOfUniqueNames)
• User search filter: (&(|(uid=%(search)s)(mail=%(search)s))(objectClass=inetOrgPerson))

Authentik sincronizará automáticamente los usuarios y grupos de LLDAP. Cada cierto tiempo, Authentik consulta LDAP, detecta cambios, y actualiza su propia base de datos. Los usuarios de LDAP aparecen en Authentik como si los hubieras creado allí.

Puedes forzar una sincronización manual desde la misma pantalla de la fuente LDAP, con el botón Sync.

¿Por qué usar Authentik con LLDAP?

Si Authentik ya tiene su propio sistema de usuarios, ¿para qué añadir LLDAP?

Buena pregunta. La respuesta es flexibilidad.

Authentik gestiona usuarios solo dentro de su ecosistema. Pero ¿y si tienes un servicio que no habla OIDC pero sí LDAP? Por ejemplo, una VPN como WireGuard con autenticación LDAP, o un servidor de correo, o un sistema de archivos en red. Esos servicios no pueden hablar con Authentik directamente. Pero sí pueden hablar con LLDAP.

Con LLDAP como directorio central y Authentik como proveedor de identidad, tienes lo mejor de ambos mundos. Los usuarios se crean en LLDAP, y Authentik los consume para SSO. Los servicios que solo hablan LDAP consultan LLDAP directamente. Todo desde un mismo punto de gestión.

Integración de LLDAP con servicios que soportan LDAP

No todos los servicios hablan OIDC. Muchos hablan LDAP directamente. Y con LLDAP puedes darles un directorio de usuarios sin necesidad de configurar nada más.

Nextcloud con LDAP

Nextcloud tiene una app oficial para integración LDAP. Se llama LDAP user and group backend.

La instalas desde la interfaz de apps de Nextcloud (está en la categoría Integration). Una vez instalada, ve a Settings > LDAP / AD Integration.

Los campos que necesitas:

• Server: ldap://lldap:3890
• Base DN: dc=tudominio,dc=com
• User DN: uid=admin,ou=people,dc=tudominio,dc=com
• Password: contraseña del admin de LLDAP
• User Display Name Field: displayName
• Base User Tree: ou=people,dc=todominio,dc=com
• User List Filter: (objectClass=inetOrgPerson)
• Login Filter: (&(|(uid=%uid)(mail=%uid))(objectClass=inetOrgPerson))
• Base Group Tree: ou=groups,dc=tudominio,dc=com
• Group Filter: (objectClass=groupOfUniqueNames)

Después de guardar, haz clic en Test Configuration y Verify Settings. Nextcloud te dirá si puede conectar con LDAP y cuántos usuarios y grupos ha encontrado.

Cuando todo esté correcto, los usuarios de LLDAP podrán iniciar sesión en Nextcloud con su usuario y contraseña de LDAP. Y los grupos de LLDAP se sincronizan como grupos de Nextcloud, lo que te permite asignar permisos basados en ellos.

Grafana con LDAP

Grafana también soporta LDAP de forma nativa. La configuración se hace en su archivo grafana.ini o mediante variables de entorno.

Si usas Docker, añades esto al docker-compose.yml de Grafana:

services:
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    environment:
      - GF_AUTH_LDAP_ENABLED=true
      - GF_AUTH_LDAP_CONFIG_FILE=/etc/grafana/ldap.toml
    volumes:
      - ./ldap.toml:/etc/grafana/ldap.toml

Y creas el archivo ldap.toml:

[[servers]]
host = "lldap"
port = 3890
use_ssl = false
start_tls = false
bind_dn = "uid=admin,ou=people,dc=tudominio,dc=com"
bind_password = "contraseña-segura-del-admin"
search_filter = "(uid=%s)"
search_base_dns = ["ou=people,dc=tudominio,dc=com"]

[servers.attributes]
name = "displayName"
surname = "sn"
username = "uid"
member_of = "memberOf"
email = "mail"

[[servers.group_mappings]]
group_dn = "cn=grafana_admins,ou=groups,dc=tudominio,dc=com"
org_role = "Admin"

[[servers.group_mappings]]
group_dn = "cn=grafana_editors,ou=groups,dc=tudominio,dc=com"
org_role = "Editor"

[[servers.group_mappings]]
group_dn = "cn=grafana_viewers,ou=groups,dc=tudominio,dc=com"
org_role = "Viewer"

Fíjate en los group_mappings. Aquí defines qué rol tiene cada grupo de LDAP en Grafana. Si un usuario pertenece a grafana_admins, será administrador en Grafana. Si pertenece a grafana_viewers, solo podrá ver dashboards.

Esto es muy potente. Creas los grupos en LLDAP, asignas usuarios, y Grafana aplica los permisos automáticamente.

SSO con OIDC: cómo funciona

Ya tienes el directorio central con LLDAP. Pero el SSO, el «login una vez y entra en todo», no lo resuelve LDAP. Lo resuelve OIDC.

OIDC (OpenID Connect) es un protocolo de autenticación que funciona sobre OAuth 2.0. Te permite iniciar sesión en un proveedor central y que ese proveedor comunique a las aplicaciones quién eres.

El flujo es así:

1. Abres Grafana en tu navegador.
2. Grafana no tiene formulario de login. Tiene un botón «Iniciar sesión con Authentik» (o Authelia, o Pocket ID).
3. Pulsas el botón. El navegador te redirige a la URL de tu proveedor de identidad.
4. Inicias sesión en el proveedor (usuario, contraseña, 2FA si aplica).
5. El proveedor genera un token ID (un JWT firmado) que contiene tu identidad.
6. El proveedor te redirige de vuelta a Grafana con el token.
7. Grafana verifica la firma del token, extrae tu identidad, y te deja entrar.

Y lo mejor: si ya tenías una sesión activa en el proveedor (porque antes habías entrado en Nextcloud), el paso 4 se salta. No te pide credenciales otra vez. Redirige directamente al paso 5.

Eso es el SSO.

Authelia como proveedor OIDC

Authelia, a partir de la versión 4.38, soporta OIDC. No es tan completo como Authentik, pero para la mayoría de casos es suficiente.

Para habilitar OIDC en Authelia, añades esto a tu configuration.yml:

identity_providers:
  oidc:
    hmac_secret: un-secreto-aleatorio-muy-largo
    issuer_private_keys:
      - key_id: default
        algorithm: RS256
        key: |
          -----BEGIN PRIVATE KEY-----
          ...tu clave privada RSA...
          -----END PRIVATE KEY-----
    clients:
      - client_id: grafana
        client_name: Grafana
        client_secret: $pbkdf2-sha512$...hash de la contraseña...
        public: false
        authorization_policy: two_factor
        redirect_uris:
          - https://grafana.tudominio.com/login/generic_oauth
        scopes:
          - openid
          - profile
          - email
          - groups
        userinfo_signed_response_alg: none

Generas el HMAC secret con:

openssl rand -base64 64

Y la clave privada RSA con:

openssl genrsa -out private.pem 2048

El client_secret debe ir hasheado con el mismo método que usas para las contraseñas de usuarios en Authelia. Puedes generarlo con el comando authelia crypto hash pbkdf2 o usar el hash de una contraseña que ya tengas.

Authentik como proveedor OIDC

Authentik ya viene preparado para OIDC de serie. En el capítulo 10 viste cómo crear proveedores OIDC desde la interfaz web. Es el método más directo.

Desde Applications > Providers, creas un proveedor OIDC. Los campos importantes:

• Name: oidc-grafana
• Authentication flow: default-authentication-flow
• Client ID: lo genera Authentik automáticamente.
• Client Secret: también lo genera Authentik.
• Redirect URIs: https://grafana.tudominio.com/login/generic_oauth
• Signing Key: la clave por defecto de Authentik.

Luego creas una aplicación que use ese proveedor, y ya tienes SSO para Grafana.

Pocket ID como proveedor OIDC

Si en el capítulo 8 viste Pocket ID y te gustó lo de los passkeys, también puedes usarlo como proveedor OIDC. Es más limitado (solo passkeys, sin contraseñas), pero para un servidor personal es una opción increíblemente segura.

La configuración es similar. En Pocket ID, desde el panel de administración, creas un cliente OIDC. Obtienes un Client ID y Client Secret, configuras las Redirect URIs, y ya.

Eso sí, ten en cuenta que Pocket ID no tiene integración LDAP. Sus usuarios son independientes. Si usas Pocket ID, los usuarios no vendrán de LLDAP.

Ejemplos prácticos de SSO con OIDC

Vamos a ver tres ejemplos concretos: Grafana, Nextcloud y Home Assistant. Son los servicios más comunes en un ecosistema self-hosted y los tres soportan OIDC.

Grafana con OIDC

Grafana tiene soporte nativo para OIDC (lo llama Generic OAuth). La configuración se hace vía variables de entorno.

Si usas Authentik como proveedor, añades esto al docker-compose.yml de Grafana:

services:
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    environment:
      - GF_AUTH_GENERIC_OAUTH_ENABLED=true
      - GF_AUTH_GENERIC_OAUTH_NAME=Authentik
      - GF_AUTH_GENERIC_OAUTH_CLIENT_ID=el-client-id-de-authentik
      - GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET=el-client-secret-de-authentik
      - GF_AUTH_GENERIC_OAUTH_SCOPES=openid profile email
      - GF_AUTH_GENERIC_OAUTH_AUTH_URL=https://auth.tudominio.com/application/o/authorize/
      - GF_AUTH_GENERIC_OAUTH_TOKEN_URL=https://auth.tudominio.com/application/o/token/
      - GF_AUTH_GENERIC_OAUTH_API_URL=https://auth.tudominio.com/application/o/userinfo/
      - GF_AUTH_GENERIC_OAUTH_SIGN_OUT_REDIRECT_URL=https://auth.tudominio.com
      - GF_AUTH_SIGNOUT_REDIRECT_URL=https://auth.tudominio.com

Si usas Authelia, las URLs cambian ligeramente:

      - GF_AUTH_GENERIC_OAUTH_AUTH_URL=https://auth.tudominio.com/api/oidc/authorization
      - GF_AUTH_GENERIC_OAUTH_TOKEN_URL=https://auth.tudominio.com/api/oidc/token
      - GF_AUTH_GENERIC_OAUTH_API_URL=https://auth.tudominio.com/api/oidc/userinfo

Reinicias Grafana y, al acceder a su URL, verás el botón «Iniciar sesión con Authentik» (o «Iniciar sesión con Authelia»). Lo pulsas, te redirige a tu proveedor, inicias sesión, y vuelves a Grafana autenticado.

Los usuarios de LDAP conectados a Authentik o Authelia pueden entrar sin necesidad de crearlos manualmente en Grafana.

Nextcloud con OIDC

Nextcloud también soporta OIDC, aunque la configuración es un poco menos directa que con Grafana. Necesitas la app OpenID Connect user backend del catálogo de apps de Nextcloud.

La instalas desde la interfaz de apps (búscala como «openid connect»). Luego, en Settings > OpenID Connect, añades un proveedor:

• Identifier: authentik (o el nombre que quieras)
• Client ID: el que te da Authentik o Authelia
• Client Secret: el secreto correspondiente
• Discovery URL: https://auth.tudominio.com/application/o/.well-known/openid-configuration (para Authentik) o https://auth.tudominio.com/.well-known/openid-configuration (para Authelia)
• Scope: openid profile email

La URL de discovery es importante. Nextcloud la usa para obtener automáticamente todas las URLs del proveedor OIDC (authorization, token, userinfo, etc.). Así no tienes que configurarlas una por una.

Cuando está configurado, en la página de login de Nextcloud aparece un botón «Iniciar sesión con Authentik». Lo pulsas, te autenticas en tu proveedor, y Nextcloud te crea una cuenta automáticamente si es la primera vez que entras.

Home Assistant con OIDC

Home Assistant ha añadido soporte para OIDC en versiones recientes (2024.6+). La configuración se hace en configuration.yaml:

homeassistant:
  auth_providers:
    - type: trusted_proxies
    - type: homeassistant
    - type: oidc
      client_id: el-client-id
      client_secret: el-client-secret
      discovery_url: >-
        https://auth.tudominio.com/application/o/.well-known/openid-configuration
      name: Authentik
      username_attribute: preferred_username
      id_token_algo: RS256

Ojo con el orden de auth_providers. Si pones trusted_proxies primero, Home Assistant permite la entrada sin autenticación a las IPs de confianza (como la red de Docker). Eso está bien para no tener que autenticarte dos veces si ya pasaste por Traefik.

El username_attribute le dice a Home Assistant qué campo del token OIDC usar como nombre de usuario. preferred_username suele ser el que viene de Authentik o Authelia.

Reinicias Home Assistant y, en la pantalla de login, verás el botón para iniciar sesión con tu proveedor OIDC.

Gestión de sesiones: duración, refresh y logout centralizado

El SSO mola hasta que tienes que gestionar sesiones. ¿Cuánto dura una sesión? ¿Qué pasa cuando cierras el navegador? ¿Cómo cierras sesión en todos los servicios a la vez?

Duración de sesión

Cada proveedor de identidad tiene su propia configuración de sesión.

En Authelia, se configura en configuration.yml:

session:
  name: authelia_session
  domain: tudominio.com
  same_site: lax
  expiration: 8h
  inactivity: 30m
  remember_me_duration: 30d

• expiration: la sesión caduca a las 8 horas, independientemente de la actividad.
• inactivity: si el usuario está inactivo 30 minutos, la sesión caduca.
• remember_me_duration: si el usuario marca «Recordarme», la sesión dura 30 días.

En Authentik, la configuración está en Flows & Stages > Stages > Authentication. Dentro del flujo de autenticación, puedes configurar:

• Duration: tiempo máximo de sesión (por defecto, 24 horas).
• Remember me duration: si el usuario marca recordar, cuánto dura (por defecto, 30 días).
• Revoke session on logout: si se revoca la sesión al cerrar sesión.

Refresh de tokens

Los tokens OIDC no son eternos. Tienen un tiempo de vida limitado. Cuando un token caduca, la aplicación necesita obtener uno nuevo mediante un token de refresh.

En Authelia, los tokens OIDC se configuran así:

identity_providers:
  oidc:
    access_token_lifespan: 1h
    refresh_token_lifespan: 24h
    id_token_lifespan: 1h

En Authentik, cada proveedor OIDC tiene su propia configuración de tiempos de vida:

• Access Token Valid until: tiempo de vida del token de acceso (por defecto, 5 minutos).
• Refresh Token Valid until: tiempo de vida del token de refresh (por defecto, 30 días).
• ID Token Valid until: tiempo de vida del token ID (por defecto, 5 minutos).

Los valores por defecto de Authentik son muy ajustados (5 minutos para tokens de acceso). Para un servidor personal puedes subirlos a 1 hora para el access token y 7 días para el refresh token. Así reduces las peticiones de refresh sin comprometer la seguridad.

Logout centralizado (SLO)

El Single Logout (SLO) es la capacidad de cerrar sesión en todos los servicios con un solo clic. Cuando cierras sesión en Authentik, Authentik notifica a todas las aplicaciones donde tienes sesión activa para que también cierren su sesión.

Authelia no soporta SLO formal. Cuando cierras sesión en Authelia, se destruye la cookie de sesión de Authelia, pero las aplicaciones que tienen su propia sesión (como Grafana o Nextcloud) no se enteran. Para cerrar sesión en ellas, tienes que cerrar la sesión manualmente en cada una o esperar a que caduquen sus tokens.

Authentik sí soporta SLO. Cuando configuras un proveedor OIDC en Authentik, puedes habilitar la opción Include SLO URL en la configuración del proveedor. Luego, en la aplicación, configuras la URL de logout para que apunte a Authentik. Cuando el usuario cierra sesión en Authentik, este envía una petición a todas las URLs de logout registradas.

Pongamos un ejemplo con Grafana. Además de la configuración OIDC que viste antes, añades:

      - GF_AUTH_GENERIC_OAUTH_LOGOUT_URL=https://auth.tudominio.com/application/o/authentik/end-session/

Cuando el usuario cierra sesión en Authentik, Authentik redirige al navegador a la URL de logout de Grafana, y Grafana cierra su propia sesión. El usuario vuelve a la pantalla de login sin sesiones activas en ningún servicio.

Estrategia recomendada

Para un servidor personal o familiar, mi recomendación es:

• Sesión de 8 horas con inactividad de 30 minutos.
• «Recordarme» para 30 días.
• Tokens de acceso de 1 hora.
• Tokens de refresh de 7 días.
• SLO activado si usas Authentik.

Para un equipo o producción, reduce los tiempos: sesión de 4 horas, inactividad de 15 minutos, tokens de acceso de 15 minutos, refresh de 24 horas. Y obliga a 2FA en todas las aplicaciones.

Verificación: probar login con LDAP y SSO

Has configurado muchas piezas. Ahora toca verificar que todo funciona.

Probar autenticación LDAP directa

Puedes probar la conexión LDAP directamente desde la línea de comandos con ldapsearch. Si no lo tienes instalado:

sudo apt install ldap-utils

Para probar la autenticación contra LLDAP:

ldapsearch -H ldap://127.0.0.1:3890 \
  -D "uid=admin,ou=people,dc=tudominio,dc=com" \
  -w "contraseña-segura-del-admin" \
  -b "dc=tudominio,dc=com" \
  "(objectClass=inetOrgPerson)"

Esto debería devolver todos los usuarios del directorio. Si ves los datos, LLDAP está funcionando correctamente.

Para probar la autenticación de un usuario concreto:

ldapsearch -H ldap://127.0.0.1:3890 \
  -D "uid=lorenzo,ou=people,dc=tudominio,dc=com" \
  -w "contraseña-de-lorenzo" \
  -b "dc=tudominio,dc=com" \
  "(uid=lorenzo)"

Si el comando devuelve los datos del usuario, la autenticación LDAP funciona. Si no, revisa la contraseña o que el usuario exista.

Probar SSO entre servicios

La prueba definitiva es el SSO entre dos servicios.

1. Abre una ventana de incógnito en tu navegador.
2. Accede a https://nextcloud.tudominio.com.
3. Haz clic en «Iniciar sesión con Authentik».
4. Te redirige a https://auth.tudominio.com. Inicias sesión con usuario y contraseña. Si tienes 2FA, también lo pasas.
5. Vuelves a Nextcloud, autenticado. Cierras la pestaña de Nextcloud.
6. Sin cerrar la ventana de incógnito, abre https://grafana.tudominio.com.
7. Haz clic en «Iniciar sesión con Authentik».
8. No te pide credenciales. Te redirige directamente a Grafana, ya autenticado.

Eso es SSO funcionando. Una sola autenticación, dos servicios.

Si también has configurado SLO:

1. Desde Grafana, cierra sesión.
2. Authentik cierra tu sesión central.
3. Abre Nextcloud. Te pide autenticarte de nuevo.

El círculo se cierra.

Probar fallos

También es importante probar los caminos de error.

• ¿Qué pasa si LLDAP se cae? Los servicios que usan LDAP directamente (Nextcloud, Grafana con LDAP) no podrán autenticar usuarios. Los servicios que usan OIDC (a través de Authentik) seguirán funcionando mientras los tokens no caduquen.
• ¿Qué pasa si Authentik se cae? Los servicios que usan OIDC no podrán autenticar nuevos usuarios. Los que ya tenían sesión seguirán funcionando hasta que caduque el token.
• ¿Qué pasa si un usuario no existe en LDAP pero sí en Authentik (porque lo creaste directamente)? Solo podrá acceder a servicios vía OIDC, no vía LDAP directo.

Estos escenarios te ayudan a entender la resiliencia de tu sistema y a decidir qué redundancia necesitas.

Resumen

En este capítulo has dado el salto de tener usuarios dispersos a tener un directorio central. Has visto el problema de gestionar N bases de usuarios distintas y cómo LDAP lo resuelve con un único punto de gestión. Has instalado LLDAP, un servidor LDAP moderno y ligero, con Docker Compose y Traefik. Has creado usuarios y grupos desde su interfaz web. Has conectado LLDAP con Authelia y Authentik como backend de usuarios. Has integrado LLDAP con servicios que hablan LDAP directamente, como Nextcloud y Grafana.

Luego has dado el salto al SSO con OIDC. Has entendido el flujo de autenticación: tú contra el proveedor de identidad, el proveedor contra las aplicaciones. Has configurado ejemplos prácticos con Grafana, Nextcloud y Home Assistant. Has aprendido a gestionar sesiones, tokens de refresh y logout centralizado.

Y has verificado que todo funciona con pruebas reales de login LDAP y SSO entre servicios. Tu infraestructura ya no tiene N bases de usuarios. Tiene una. Y esa es una de las decisiones de seguridad más importantes que puedes tomar.

En el próximo capítulo cerramos con un tema que muchos olvidan y que puede salvar tu servidor: la monitorización de accesos y detección de intrusiones. Porque la seguridad no termina cuando configuras las barreras. La seguridad es un proceso continuo de vigilancia.

---

Más información,

• Documentación de LLDAP: https://github.com/nitnelave/lldap
• Documentación de autenticación LDAP en Authelia: https://www.authelia.com/docs/configuration/first-factor/ldap/
• Documentación de OIDC Provider en Authelia: https://www.authelia.com/docs/configuration/identity-providers/open-id-connect/
• Documentación de Authentik: https://docs.goauthentik.io/
• Documentación de Pocket ID: https://pocket-id.org/docs
• Tutorial de Traefik v3 en atareao.es
• Documentación de SSO en Nextcloud: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/oauth2.html
• Documentación de OAuth/OIDC en Grafana: https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/generic-oauth/