Puesta en marcha de authentik para proyectos internos

Este repositorio deja preparado todo lo necesario para que authentik actúe como proveedor SSO de los proyectos en /srv/projects. A continuación se describe el flujo recomendado para habilitar intranets protegidas, consolas de administración y emisión de JWT para APIs.

1. Variables de entorno y stack

  1. Copia compose/.env a un lugar seguro y revisa los nuevos parámetros añadidos (AUTHENTIK_HOST, AUTHENTIK_OUTPOST_TOKEN).
  2. Define AUTHENTIK_OUTPOST_TOKEN con el token del outpost (paso 3). Para iniciar mientras no exista puedes dejar changeme.
  3. Arranca la plataforma: docker compose -f compose/compose.yaml up -d.

Nota: el contenedor server expone la interfaz web por 127.0.0.1:9091 (lo consume Caddy) y el contenedor outpost expone 127.0.0.1:9092 para forward_auth.

2. Crear token del outpost y enlazarlo

  1. Accede a authentik (https://auth.illanes00.cl a través de Caddy) con un superusuario.
  2. Navega a Applications ▸ Outposts, crea un nuevo Outpost tipo Proxy llamado caddy-forward-auth y anótate el token que entrega.
  3. Actualiza AUTHENTIK_OUTPOST_TOKEN en compose/.env con ese valor y reinicia sólo el outpost: docker compose -f compose/compose.yaml up -d outpost.
  4. En la misma pantalla, asocia el Outpost a los proveedores que vayas creando (ver paso 4).

3. Importar grupos base y mapeo de JWT

El blueprint blueprints/10-groups-and-jwt.yaml crea los grupos básicos y añade un mapping para incluirlos en los tokens.

cd /srv/projects/auth
docker compose -f compose/compose.yaml exec -T server \
  ak blueprint apply -f - < blueprints/10-groups-and-jwt.yaml

Después de importarlo, asigna usuarios a los grupos desde Directory ▸ Groups.

4. Proteger intranets y consolas con Caddy

  1. Crea un Proxy Provider por cada sitio (ej. admin-illanes00) definiendo:

    • External host: URL pública (ej. https://admin.illanes00.cl).
    • Internal host: URL interna a la que Caddy hace proxy (ej. http://127.0.0.1:8102).
    • Authorization flow: default-provider-authorization-implicit-consent suele ser suficiente.
    • Outpost: selecciona caddy-forward-auth.

  2. En Applications crea las tarjetas correspondientes y dales acceso únicamente a los grupos relevantes (ej. grupo admin-illanes00).

  3. En Caddy utiliza el siguiente snippet de forward_auth (ya se expone en 127.0.0.1:9092):

    (authentik-forward) {
    forward_auth 127.0.0.1:9092 {
        uri /outpost.goauthentik.io/auth/caddy
        copy_headers X-authentik-username X-authentik-groups X-authentik-email
    }
}

  4. Aplícalo en cada bloque del sitio protegido:

    admin.illanes00.cl {
    import authentik-forward
    import illanes00-admin
}

  5. Reinicia Caddy tras los cambios.

5. Emisión de JWT para las APIs

  1. Crea una OAuth2/OpenID Provider llamada internal-api con:
    • Client Type: Confidential.
    • Client ID/Secret: valores que usará el gateway (recomiendo guardarlos en 1Password).
    • Redirect URIs: URLs de callback si usas authorization_code.
    • Signing Key: usa el certificado por defecto o carga uno propio.
    • Property mappings: incluye jwt-add-groups (del blueprint) además de los mappings estándar (openid, profile, email).
    • Scopes: habilita openid profile email y los que necesites (offline_access, etc.).
    • Grant types: añade client_credentials si necesitas tokens de servicio.
  2. Crea la aplicación Internal API y asígnala al provider anterior.
  3. Asocia el grupo api-clients y añade a él los servicios que deban recibir tokens.
  4. Desde tus APIs verifica el contenido del claim groups para autorizar acceso.

6. Referencias rápidas

  • Dashboard: https://auth.illanes00.cl/if/flow/.
  • Caddy snippet existente para authentik: deploy/caddy.conf.
  • Blueprint aplicado: blueprints/10-groups-and-jwt.yaml.
  • Token endpoint: https://auth.illanes00.cl/application/o/internal-api/token/.

Con estos pasos tendrás SSO unificado, portales de intranet bajo autenticación central y emisión controlada de JWT con información de grupos para las APIs.

7. Personalizar el login con IllanesID

  1. Los activos visuales están en volumes/media/public/custom.css y volumes/media/public/assets/illanesid-logo.svg. Cambia los colores o el SVG si necesitas otro look.

  2. El blueprint blueprints/20-brand-and-signup.yaml (copiado en /media/blueprints/20-brand-and-signup.yaml dentro del contenedor) actualiza el brand, agrega enlaces al pie de página y crea el flujo de registro illanesid-signup.

  3. Aplícalo desde la máquina host:

    docker compose -f compose/compose.yaml exec -T server \
  ak blueprint_shell <<'PY'
from authentik.blueprints.file import load
load("/media/blueprints/20-brand-and-signup.yaml").apply()
PY

  4. Tras aplicar, recarga la página (Ctrl+Shift+R) para invalidar el CSS en caché. Si no aparece el botón “Crear cuenta”, verifica que el blueprint haya quedado en estado applied (UI ▸ System ▸ Blueprints).

8. Provider internal-api

  1. Los objetos viven en blueprints/30-internal-api.yaml (también montado como /media/blueprints/30-internal-api.yaml dentro del contenedor). El blueprint crea:

    • Provider OAuth2/OpenID Illanes Internal API.
    • Aplicación Internal API asociada.
    • Binding automático al grupo api-clients para que sólo quienes estén en ese grupo puedan solicitar tokens.

  2. Aplícalo (o re-aplícalo si cambias redirect URIs) con:

    docker compose -f compose/compose.yaml exec -T server \
  ak blueprint_shell <<'PY'
from authentik.blueprints.file import load
load("/media/blueprints/30-internal-api.yaml").apply()
PY

  3. Credenciales generadas (guárdalas en 1Password):

    • client_id: il5s1kauue3gzzm3gd8z7u13
    • client_secret: w1Ok7nX7B-8AmygACAqsGYnYcpZRERcXtX7jJ0s2oS4eK5sOMpGQuPbj8J-fslu-

  4. Ajusta la URL de callback si tu gateway expone otra ruta (_redirect_uris en el blueprint). Tras editar, vuelve a aplicar el blueprint.

  5. Punto de token: https://auth.illanes00.cl/application/o/internal-api/token/. El claim groups del access token incluye los gupos gracias al mapping jwt-add-groups.