====== 09 - Integración con Spring Security ======

El [[proyecto:08-login-jwt|hito 08]] autentica y protege a mano: lista de rutas en el filtro, comprobaciones sueltas. Este hito aplica el [[temario:07-spring-security|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 [[proyecto:08-login-jwt|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 [[proyecto:02-especificacion|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 [[temario:07-spring-security|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 [[proyecto:02-especificacion|especificación]].