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.

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.

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.

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.

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.

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.

• 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.