D4R Portal: admin real, login SSO y /status con Uptime Kuma

El portal en d4r.es ha evolucionado de una capa de navegación hacia un shell operativo real. Este post documenta los cambios que lo diferencian de la versión inicial: login SSO coherente, panel admin funcional sobre Authentik y Superset, y /status conectado a Uptime Kuma.

Login: de formulario fake a flujo SSO real

La versión anterior de /login mostraba un formulario de email y contraseña que no autenticaba nada. Era decorativo. La versión actual elimina ese formulario y presenta directamente el CTA que corresponde: Continuar con Authentik.

Los accesos secundarios (Google, SSO corporativo) apuntan a las URLs reales del flujo de Authentik:

• Google: https://auth.d4r.es/source/oauth/login/google/
• SSO genérico: https://auth.d4r.es/if/flow/default-authentication-flow/

Si Google devuelve Error 400: redirect_uri_mismatch, el problema está fuera del stack: hay que registrar https://auth.d4r.es/source/oauth/callback/google/ como URI autorizada en el cliente OAuth de Google Cloud Console. El 302 que emite Authentik ya es correcto.

Admin real: usuarios, grupos y apps sobre Authentik

El shell admin en /admin/* ya no trabaja con datos simulados. Lee y escribe contra Authentik via su API v3 y, cuando corresponde, sincroniza identidades en Fizzy y cuentas en Superset.

/admin/users

Lee usuarios reales desde el Postgres de Authentik. Muestra solo los grupos gestionados por D4R, filtrando grupos built-in de Authentik. Operaciones soportadas:

• Crear usuario con password temporal generada o explícita
• Activar y desactivar usuarios
• Regenerar password temporal
• Actualizar nombre visible
• Sincronizar grupos gestionados

Cuando se añade kanban-users a un usuario, el portal sincroniza automáticamente la Identity en Fizzy. Cuando se añade bi-users, aprovisiona una cuenta interna en Superset con rol Gamma. Si se retira bi-users, la cuenta de Superset queda desactivada.

/admin/groups y /admin/apps

/admin/groups lista solo los grupos operativos de D4R, sin exponer los grupos internos de Authentik. /admin/apps cruza las aplicaciones registradas en Authentik con el modelo de acceso del stack: host, grupo mínimo requerido y nota operativa.

Resolución de dominio sin contaminar con .env local

Un problema anterior: si el servidor tenía DOMAIN=localhost en .env, los enlaces del launcher apuntaban a subdominios de localhost en lugar de d4r.es. El portal ahora resuelve el dominio por request:

• Si el host del request es localhost o 127.0.0.1, genera enlaces *.localhost
• Si el host es d4r.es, genera enlaces *.d4r.es
• Si llega detrás de proxy con x-forwarded-host, usa ese valor

Esto desacopla completamente el comportamiento del portal del contenido del archivo .env del servidor.

/status conectado a Uptime Kuma

La ruta /status ya tiene a Uptime Kuma como fuente principal de datos. Lee los monitores del contenedor ops-uptime-kuma-1, toma el último heartbeat por monitor y muestra disponibilidad, latencia y mensaje operativo en tiempo real.

Los monitores base del stack D4R son:

api.d4r.es     auth.d4r.es    bi.d4r.es
blog.d4r.es    db.d4r.es      kanban.d4r.es
logs.d4r.es    minio.d4r.es   n8n.d4r.es
status.d4r.es  studio.d4r.es  traefik.d4r.es

Si Kuma no responde, /status cae al fallback de healthchecks HTTP directos. El comando make kuma-sync sincroniza o actualiza esos monitores en Kuma desde el repo.

Configuración Traefik

FastAPI expone dos routers distintos para d4r.es en 03-app.yml:

• portal-public — cubre /, /login y /static/* sin middleware Authentik
• portal-private — cubre /apps, /status, /profile y /admin/* con authentik@docker

Cuando infra-authentik-server-1 está arrancando, Traefik puede registrar middleware "authentik@docker" does not exist. El error es transitorio y desaparece en cuanto el contenedor de Authentik publica sus labels.