spring cloud - tutorial - Zuul-autenticación de la puerta de enlace de API
spring-cloud-starter-netflix-zuul (2)
Quiero presentar Zuul a través de Spring Cloud como una puerta de enlace API frente a algunos servicios.
Tengo algunas dudas de diseño en torno a la autenticación. La autenticación sería manejada por Spring Security, que viene antes de Zuul en la cadena de filtros de servlets.
Mi preocupación:
El Gateway se sentaría frente a muchos servicios.
Algunos servicios pueden exponer puntos finales que no requieren autenticación
algunos servicios pueden exponer puntos finales que necesitan un ID de sesión y otros con un token ", un valor opaco arbitrario (por ejemplo, descargar un archivo si conoce una url" difícil de adivinar ") En la API Gateway / Spring Security puede configurar todos los puntos finales con sus requisitos de autenticación específicos.
En términos de gestión de la puerta de enlace API:
- ¿cómo hacer cumplir los equipos de servicio reales para proporcionar la configuración requerida por servicio posterior?
- ¿Cómo permite cambios frecuentes de configuración de autenticación en la puerta de enlace (según las necesidades del servicio) sin tener que detener la puerta de enlace completa?
Gracias adrian
- El Gateway se sentaría frente a muchos servicios.
¿Cuál es la preocupación aquí?
- Algunos servicios pueden exponer puntos finales que no requieren autenticación
Spring Security tiene una regla de acceso permitAll()
- algunos servicios pueden exponer puntos finales que necesitan un ID de sesión y otros con un token ", un valor opaco arbitrario (por ejemplo, descargar un archivo si conoce una url" difícil de adivinar ") En la API Gateway / Spring Security puede configurar todos los puntos finales con sus requisitos de autenticación específicos.
Tu proxy Zuul puede tener sesiones. Si está utilizando Spring Security OAuth 2.0, puede usar ResourceServerSecurityConfigurer#stateless(false) y activar sesiones con HttpSecurity#sessionManagement().sessionCreationPolicy(...) para crear sesiones cada vez que reciba un token de acceso válido. Se colocará una cookie JSESSIONID en la respuesta HTTP.
- ¿cómo hacer cumplir los equipos de servicio reales para proporcionar la configuración requerida por servicio posterior?
No estoy seguro de entender la pregunta aquí, ¿no desea aplicar restricciones de seguridad en el nivel de la puerta de enlace API (proxy de zuul)? ¿O está intentando tener "controles de seguridad" tanto en el proxy como en la aplicación de destino?
- ¿Cómo permite cambios frecuentes de configuración de autenticación en la puerta de enlace (según las necesidades del servicio) sin tener que detener la puerta de enlace completa?
Zuul le permite agregar ZuulRoute s dinámicamente en tiempo de ejecución, si lo usa como una biblioteca independiente. Envuelto en Spring Security, cuyo contexto se inicializa una vez en el momento del inicio ... Dudo que pueda modificar fácilmente la configuración de seguridad en tiempo de ejecución.
EDITE siguiendo las precisiones del OP en los comentarios : Si sus equipos deben ser responsables de sus reglas de seguridad, tener una puerta de enlace centralizada es una contradicción de diseño.
Mi interpretación de la filosofía del microservicio es que cada aplicación es independiente y está a cargo de su alcance funcional completo, y el control de seguridad / acceso es parte de ella. Puede verificar fácilmente los tokens en el nivel de la aplicación (ya sea haciendo una llamada al servidor de autorización o utilizando JWT), y cada aplicación define qué ámbito se requiere para cada recurso. Spring Cloud ya tiene un iniciador OAuth 2.0 , o puedes crearlo fácilmente si usas Spring Boot "normal".
De esa manera, puede implementar aplicaciones individuales donde quiera (en la nube pública o en servidores locales), sin tener que depender de componentes de flujo ascendente para la seguridad o sincronizar las implementaciones de configuración de la puerta de enlace con otros equipos.
La API Gateway es una tentación fácil, pero no pase por alto los riesgos y restricciones:
- No podrás asegurar llamadas internas
- Tendrá que confiar en los componentes de la red ascendente y dar por sentado la entrada de sus aplicaciones
- Las reglas avanzadas de control de acceso pueden convertirse en un dolor de cabeza: cómo obtener los permisos individuales del usuario, etc.
- Tendrás que sincronizar los cambios de configuración con otros equipos.
Estamos utilizando Spring Session para replicar la sesión en todos nuestros servicios que se encuentran detrás de un servidor Zuul Edge. Zuul autenticará al usuario que rellena las credenciales de los usuarios e inserta al usuario autenticado en la sesión. Luego se replica en todos los servicios y cada servicio es responsable de sus propias reglas y configuraciones de seguridad. Así que, en realidad, todo lo que Zuul está haciendo es buscar al usuario en la seguridad de Spring y los servicios en el backend están aplicando las reglas de seguridad según se aplican a sus necesidades. De esta manera, puede cambiar cada servicio de forma independiente, lo que convierte a Gateway en un simple proxy.
Un buen ejemplo de esto es el tutorial de Dave Syers sobre Spring Security y una aplicación Angular JS . También publiqué otra pregunta relacionada con esto que contenía una muestra de cómo lo estamos haciendo, lo que podría ayudar.