09 - Integración con Spring Security

El hito 08 autentica y protege a mano: lista de rutas en el filtro, comprobaciones sueltas. Este hito aplica el tema 07 — Integración con Spring Security: el flujo de autenticación no cambia; cambia quién construye y orquesta la maquinaria.

Pieza	Cambio en este hito
Filtro	El filtro de JWT pasa a la cadena de filtros de Spring Security
Autorización	Reglas declarativas por rutas; por método donde toque
Contraseñas	El hashing delega en Spring Security (`PasswordEncoder`), sin tocar el dominio
Errores	401 y 403 en el mismo formato `Problem` que el resto de la API

1. La cadena de filtros

Con la dependencia de Spring Security:

El filtro del hito 08 entra en la cadena de filtros: extrae y valida el token igual que antes, pero ahora deja la identidad en la maquinaria de autorización — las authorities derivadas del rol del claim — y el contexto, stateless, lo lleva la cadena.
La lista de rutas «a mano» desaparece: la matriz de autorización de la especificación se traduce a reglas declarativas — lectura de catálogos y productos pública, escritura de catálogos y productos solo ADMIN, pedidos autenticados, registro y login públicos.
Los controladores siguen recibiendo la identidad tal como en el hito 08. Es la medida de la migración: comportamiento idéntico con otra maquinaria.

2. La pertenencia del pedido

Que un pedido sea del comprador — o lo administre un ADMIN — no es un rol, es una regla de negocio del módulo de pedidos. La verificación declarativa por método de Spring Security la expresa como segunda verificación, con la Authentication que llega de la cadena; dónde colocarla exactamente lo decide cada quien. Al fallar, responde 403 — o 404, si se prefiere no delatar la existencia del pedido ajeno: la alternativa se discute en el tema y una de las dos, siempre coherente.

3. Contraseñas

El hashing pasa a la maquinaria de Spring Security: el dominio del módulo users no cambia de abstracción; la implementación pasa a producir y comprobar con el PasswordEncoder. El formato del hash se mantiene — la semilla y los usuarios ya registrados siguen autenticando.

4. Errores de seguridad

Los 401 y 403 de la cadena llegan con el mismo esquema Problem del contrato. Como los filtros, no pasan por los manejadores de la presentación: los prepara la propia configuración de la cadena — los componentes del tema 07.

5. Pruebas

Con MockMvc y el soporte de test de Spring Security:

Rutas públicas sin token → 200: lectura de catálogos y productos, registro, login.
Operación protegida sin token → 401; token caducado o mal firmado → 401.
Token de USER en escritura de catálogos o productos → 403; token de ADMIN → 201.
La pertenencia del pedido: el ajeno → 403 (o 404, según la decisión coherente del diseño); el propio → 200.
El flujo completo: registro → login → pedido → mis pedidos → cancelación, con el 401/403 en su punto exacto.
Regresión: toda la batería de hitos anteriores sigue verde — la tienda se comporta igual, con otra maquinaria de seguridad.

Comprobación

Ya no quedan reglas «a mano»: la seguridad es declarativa (rutas y métodos).
Un ADMIN gestiona catálogos y productos y un USER compra; los errores de seguridad llegan en formato Problem.
La semilla mantiene un ADMIN funcional y el registro crea siempre USER.
Todo lo de hitos anteriores sigue pasando.
Commit y tag hito-09.

A partir de aquí: los temas de eventos, logs y Lambda reutilizan los ganchos previstos en la especificación.