Saltar a contenido

ADR-003 — Autenticación de la consola: HTTP Basic stateless con usuarios en base

Status: accepted (discovery Q9, 2026-09-03)

Contexto

La consola tiene pocos usuarios internos del comercio en dos roles (ADMIN, OPERADOR). Vive detrás de un reverse proxy con TLS (ADR-001, INV-S05). El gestor del Sistema de Premios ya usa Basic stateless con un cliente axios que adjunta la credencial por request y maneja el 401.

Alternativas

  1. HTTP Basic stateless sobre HTTPS, usuarios en tabla Usuario con BCrypt. Sin sesiones ni tokens.
  2. Sesión con cookie HttpOnly, login por formulario y protección CSRF. Permite expirar y revocar; más piezas.
  3. JWT emitido por el backend. Revocación compleja para el tamaño del problema.

Decisión

Alternativa 1.

  • SecurityFilterChain stateless; UserDetailsService contra Usuario; BCryptPasswordEncoder (INV-S02).
  • Autorización por rol en cada endpoint de administración con @PreAuthorize; OPERADOR solo GET (INV-S04).
  • Primer usuario ADMIN sembrado al primer arranque desde la configuración externa (bc.admin.usuario, bc.admin.password); si la tabla ya tiene usuarios, no se toca.
  • Usuario inactivo: 401 inmediato. Cambio de contraseña desde la consola; el admin puede resetear la de otros.
  • Cabeceras de seguridad (CSP, Referrer-Policy, Permissions-Policy) como en el Sistema de Premios.
  • La API de resolución del gateway usa otro filtro (API key, INV-S01), en otra cadena de seguridad.

Consecuencias

  • ✅ Reuso del cliente axios y del authStore del Sistema de Premios; credenciales solo en memoria y sessionStorage.
  • ⚠️ Cerrar sesión es olvidar la credencial en el navegador; no hay revocación de sesión, sí desactivación del usuario.
  • ⚠️ La credencial viaja en cada request: exige TLS obligatorio en el proxy.

Plan de implementación

  • seguridad/ConsolaSecurityConfig.java, seguridad/ApiKeySecurityConfig.java (orden explícito de cadenas).
  • seguridad/UsuarioDetailsService.java, seguridad/AdminInicialSeeder.java.
  • Frontend: cliente API y store de auth portados del Sistema de Premios; menú y acciones ocultas para OPERADOR, pero la verificación real está en el servidor.

Verificación

  • Test: OPERADOR recibe 403 en cualquier POST/PUT/DELETE de administración (AC-21).
  • Test: usuario inactivo recibe 401 (AC-22).
  • Test: primer arranque siembra el admin; segundo arranque no lo duplica ni lo resetea (AC-23).
  • Test: la API de resolución rechaza credenciales Basic y solo acepta X-Api-Key.