Saltar a contenido

ADR-024 · Separación Authentik CIS ↔ illanes00 (cutoff path para escindir IdP)

Fecha: 2026-05-04 Source: /srv/projects/cis/cis-plan/DECISIONS.md (do not edit here — re-split desde la fuente)

Contexto

Hoy existe una sola instancia Authentik desplegada vía Docker en vps-dev (stack auth-server, auth-worker, auth-redis, auth-postgres, auth-outpost, 5 semanas uptime al momento de la auditoría). Esa instancia sirve simultáneamente a:

  • Productos personales: auth.illanes00.cl (apex), admin.illanes00.cl, sub-dominios *.illanes00.cl, productos cochid (scribe.illanes00.cl, congreso.cochid.cl, etc.), foresight, lepp, indieweb-ledcam.
  • Productos CIS: auth.innovacionsantiago.cl (canónico CIS hoy), partes de cis-platform, cis-claudia, cis-librospa, periodismo2, situacion.

La separación se materializa vía providers Authentik multi-tenant (cada producto tiene su provider OIDC con scope/audience propio), pero la infra subyacente (Docker stack + DB Postgres + Redis) es única y vive en vps-dev. Riesgo legal explícito: una persona jurídica (CIS SpA) opera con IdP que pertenece a una persona natural (Martín). Si Martín pierde acceso a vps-dev o decide apagarlo, todo el ecosistema CIS pierde SSO y los users de productos CIS no pueden autenticar.

Adicionalmente, ADR-028 estableció que cada user CIS tiene un authentik_uuid que bridges con cis_admin.usuarios.authentik_uuid. Si la instancia Authentik se reescinde, el bridge debe migrar consistentemente o los UUIDs cambiar (re-seed de la base de users CIS, invalidación de sesiones).

Alternativas consideradas

  1. (a) Statu quo: Authentik único, multi-tenant via providers
  2. Pro: cero esfuerzo técnico inmediato. Single-pane-of-glass para users.

  3. Contra: continuity risk en caso pérdida vps-dev. Riesgo legal: SpA depende de servicio bajo titularidad personal del CEO. No escala si entra cliente externo (multi-tenant whitelabel marketplace, Bloque LH).

  4. (b) Federación Authentik personal ↔ Authentik CIS

  5. Pro: separación legal limpia + SSO experience preserved (federation hop transparente).

  6. Contra: complejidad operativa (2 instancias Authentik, 2 DBs, federation cert rotation). Para 2026 prematuro.

  7. (c) Cutoff path documentado: hoy seguir con instancia única bajo licencia explícita; cuando trigger se active, ejecutar plan de salida ← propuesta

  8. Pro: balance esfuerzo/riesgo. La instancia única funciona hoy; el cutoff queda preparado para activarse cuando un trigger objetivo lo justifique. Permite invertir el esfuerzo de duplicación sólo cuando entrega valor real (cliente externo entra, o vps-dev se vuelve inestable).

  9. Contra: el "cuando" depende de juicio humano. Mitigación: triggers explícitos abajo + revisión trimestral en CHANNEL.

  10. (d) Migrar Authentik a vps-cis ahora (single-instance pero CIS-owned)

  11. Pro: clarifica titularidad inmediata.
  12. Contra: rompe SSO de productos personales (illanes00.*) — Martín pierde su SSO personal a menos que Martín se vuelva user-CIS, lo cual confunde el boundary legal. Reverso peor que statu quo.

Decisión: (c) — cutoff path documentado + licencia intra-company hasta trigger.

La instancia Authentik en vps-dev queda tratada explícitamente como activo licenciado por illanes00 (Martín persona natural) a CIS SpA, con las siguientes cláusulas implícitas:

  • Tipo de licencia: perpetua, gratuita, no-exclusiva.
  • Scope: providers OIDC sirviendo dominios *.innovacionsantiago.cl, *.circulodesantiago.cl, productos CIS hosteados en marketplace indieweb.cl.
  • SLA implícito: best-effort; Martín no garantiza uptime contractual a CIS. Continuity risk asumido por la SpA hasta cutoff.
  • Salida sin disrupción: si Martín decide retirar la licencia, debe dar aviso ≥30 días + cooperar en plan de salida (sección 3 abajo). El asset transferido durante el plan de salida (export users/groups/providers) queda como cesión gratuita a CIS (concordante ADR-023 §2).
  • Ownership de datos users: los users registrados como CIS-context (los que tienen mapping en cis_admin.usuarios) son propiedad CIS; los users registrados como illanes00-context (sin row en cis_admin.usuarios) son propiedad Martín. La distinción se materializa por groups Authentik: cis-staff, cis-collab, cis-superadmin son CIS; el resto, personal.

2. Triggers que activan el cutoff

Cualquiera de estos eventos dispara la ejecución del plan de salida (sección 3). El operador (Martín) decide cuál cuenta:

  • T1 · Cliente externo entra al marketplace whitelabel CIS (Bloque LH): si un cliente paga por usar la plataforma multi-tenant CIS, su data SSO no debe pasar por infra Martín. Cutoff obligatorio antes de signing del primer contrato.
  • T2 · vps-dev se vuelve inestable: ≥2 incidentes de downtime no programado >1 h en una ventana de 90 días.
  • T3 · Funding round CIS: cualquier inversión externa que requiera due diligence de propiedad de assets críticos. Cutoff antes de close.
  • T4 · Decisión estratégica Martín: separación voluntaria (ej. Martín deja de ser CEO de CIS, o quiere reducir surface de responsabilidad).
  • T5 · Auditoría externa SII / juzgado: si una autoridad pregunta por la cadena de custodia de identidades CIS, la respuesta "infra está en VPS personal del CEO" es insuficiente. Cutoff inmediato.

Revisión trimestral: entry en CHANNEL cada Q con check de los 5 triggers. Si alguno está cerca, escalar a decisión.

3. Plan de salida (cuando trigger activa)

Estimación: 4-8 horas de trabajo técnico + 1 día de comunicación a stakeholders. Pasos en orden:

  1. Provisión de instancia destino: levantar nuevo Docker stack Authentik en vps-cis (auth.cis.innovacionsantiago.cl o subdomain dedicado). DB Postgres dedicada (cis_authentik), Redis dedicado, outpost dedicado. Vault namespace cis-auth-prod con AUTHENTIK_SECRET_KEY, AUTHENTIK_POSTGRESQL__PASSWORD, etc.
  2. Backup full Authentik vps-dev: export de:
  3. Users con CIS-context: SELECT de Authentik DB filtered por groups cis-*. pg_dump schema auth_user.
  4. Groups: cis-superadmin, cis-staff, cis-collab, cis-readonly-contable, etc.
  5. Providers OIDC sirviendo dominios CIS: cis-platform, cis-claudia, cis-librospa, cis-usaia, periodismo2, situacion, marketplace indieweb.cl.
  6. Flows: cis-primary-auth, admin-password-emergency, recovery-flow. Configurados según ADR-014.
  7. Import a Authentik dedicado CIS: usar ak export blueprint + ak import blueprint con UUIDs preservados. Crítico — los authentik_uuid en cis_admin.usuarios deben matchear el destino (ADR-028).
  8. DNS cutover: bajar TTL de auth.innovacionsantiago.cl a 5 min ≥1 h antes; cambiar A record CF a 108.175.4.190 (vps-cis); subir TTL una vez estable. FES-gated (DNS apex CIS).
  9. Update providers OIDC en cada producto: cada servicio CIS (cis-platform, cis-claudia, etc.) tiene OIDC_ISSUER_URL en su .env. Cambiar de auth.illanes00.cl (vps-dev) → auth.innovacionsantiago.cl (vps-cis). Restart services. Vault sync.
  10. Invalidación de sesiones: sesiones Authentik vps-dev quedan inválidas tras cutover (issuer cambió). Comunicado pre-cutover a users CIS: "se invalidarán sesiones, re-login necesario".
  11. Re-login coordinado: ventana de 2 h donde los users CIS reciben email "re-login a productos CIS". Stakeholders externos (clientes whitelabel si aplica T1) reciben aviso ≥7 días pre-cutover.
  12. Verificación post-cutover: smoke test de OIDC handshake en cada producto CIS. Smoke test del authentik_uuid bridge (login + SELECT * FROM cis_admin.usuarios WHERE authentik_uuid = $1 retorna row).
  13. Decommission CIS providers en vps-dev: tras 7 días estables en vps-cis, eliminar providers CIS-context en vps-dev. Users con CIS-context permanecen en DB vps-dev como historial pero con is_active=False + group cis-deprecated.
  14. CHANNEL log: [authentik-cutoff] T<N> trigger · cutover OK · receipt <fes_id>.

4. Bridge authentik_uuid (ADR-028)

Cada user CIS tiene authentik_uuid en cis_admin.usuarios.authentik_uuid (UUIDv4). El cutoff debe preservar ese UUID — si cambia, todo el modelo de identidad (ADR-028 §usuarios) se rompe. Estrategia:

  • Export con UUID preservation: Authentik permite ak export users --preserve-uuid. Validar previo a cutover que esa flag existe en la versión deployada (Authentik 2024.x+ sí).
  • Backup de seguridad: pre-cutover, snapshot completo de cis_admin.usuarios vía pg_dump cis_admin -t usuarios. Si UUIDs no preservan, retrofit con script de mapping.
  • Verificación: post-cutover, query SELECT u.id, u.authentik_uuid, ak.uuid FROM cis_admin.usuarios u JOIN authentik.auth_user ak ON u.authentik_uuid = ak.uuid debe retornar 100% de rows con match.

5. Costo y operación

  • Esfuerzo técnico de cutoff: 4-8 h de un operador con acceso a vps-dev y vps-cis + FES gating en DNS apex y vault sets.
  • Comunicación stakeholders: 1 día (drafting + send + ventana de re-login).
  • Costo recurrente post-cutoff: instancia Authentik dedicada CIS ≈ 1 GB RAM + 2 GB disco + bandwidth marginal. Ya cabe en vps-cis (8 GB RAM, 240 GB NVMe).
  • Mantenimiento dual hasta cutoff: cero (instancia única). Post-cutoff: 2 instancias = 2x el work de upgrades, pero ambos en infra CIS controlada.

Consecuencias

  • Positivo: clarifica titularidad legal — el SSO de productos CIS pertenece a CIS post-cutoff, no a Martín persona natural. Cierra el riesgo de "SpA depende de infra personal del CEO".
  • Positivo: triggers explícitos eliminan ambigüedad — el cutoff no se ejecuta "cuando alguien acuerde" sino cuando un evento objetivo lo justifica. Permite no invertir el esfuerzo prematuramente.
  • Positivo: cláusula de salida sin disrupción protege a CIS si Martín retira la licencia voluntariamente.
  • Negativo: hasta cutoff, el riesgo de continuidad existe. Si vps-dev cae súbitamente sin tiempo de export, CIS pierde SSO con plan de recovery improvisado.
  • Riesgo · UUID preservation falla en cutoff: Authentik 2024.x soporta --preserve-uuid pero versiones futuras pueden cambiar la flag. Mitigación: pre-cutover, test en staging.
  • Riesgo · sesiones invalidadas durante T1 (cliente externo): si un cliente whitelabel está en sesión cuando se ejecuta cutoff, su workflow se rompe. Mitigación: cutoff en horario low-traffic + comunicado ≥7 días pre.
  • Compatibilidad con ADR-014: el flow cis-primary-auth (Google primary + email OTP fallback) se mantiene idéntico — sólo cambia la instancia que lo hostea. Re-seed de Google OAuth client config en CF si el callback URL cambia.
  • Compatibilidad con ADR-020 / ADR-028: authentik_uuid bridge preservado. JIT provisioning sigue funcionando porque el endpoint OIDC es el mismo formato (Authentik to Authentik).
  • Dependencia de ADR-026 (operations permission model): vault_set en cis-auth-prod y DNS apex changes son FES-gated. El operador del cutoff debe tener acceso a FES vía firmasydocumentos.cl.

TODOs internos

  1. Inventario de providers OIDC actuales: listar todos los providers en Authentik vps-dev clasificados por CIS-context vs personal-context. Output en cis-plan/inventories/authentik-providers-2026-05.md. Acción humana (Martín, ≤2 h).
  2. Inventario de groups: identificar todos los groups con prefix cis-* y validar mapping con cis_admin.usuarios.empresas_acceso.
  3. Test de export con preserve-uuid: en staging Authentik (no levantado hoy), probar export/import de un user dummy con UUID y validar match.
  4. Comunicación pre-trigger: redactar template de email "re-login a productos CIS" listo para enviar cuando T1-T5 active.
  5. Revisión trimestral: entry recurrente en CHANNEL cada Q con check de los 5 triggers. Si alguno está cerca de activarse, escalar a decisión humana.
  6. Cuando T1 active: pre-flight de cliente whitelabel — ¿requiere SLA de uptime contractual del IdP? Si sí, cutoff es bloqueante para signing.

Referencias

  • ADR-023 (política de migración illanes00 → CIS, marco general).
  • ADR-028 (modelo de identidad CIS, bridge authentik_uuid).
  • ADR-014 (Google primary + email OTP fallback, flow Authentik).
  • ADR-020 (cross-DB GRANT + JIT provisioning).
  • ADR-026 versión 2026-04-29 (FES-gated para vault sensible y DNS apex).
  • /srv/projects/cds/cis/cis-plan/AUDIT-VPSDEV-2026-04.md §Docker containers vps-dev (inventario actual stack auth-*).
  • CONSTITUTION.md §3 founder contribution + §4 IP.