问题
I want to introduce Zuul through Spring Cloud as an API Gateway in front of a few services.
I have some design doubts around Authentication. The Authentication would be handled by Spring Security, which comes before Zuul in the servlet filter chain.
My concern:
the Gateway would sit in front of many services
some services may expose endpoints which do not require authentication
some services may expose endpoints which need a Session Id and some with a token", an arbitrary opaque value (for example downloading a file if you know a "hard to guess" url) In the API Gateway/Spring Security you can configure all the endpoints with their specific authentication requirements.
In terms of managing the API Gateway:
- how do you enforce the actual Service Teams to provide the required settings per downstream service?
- how do you allow frequent Authentication settings changes in the Gateway (as per service needs) without having to stop the entire Gateway?
Thanks, Adrian
回答1:
We are using Spring Session to replicate the session across all of our services that sit behind a Zuul Edge Server. Zuul will authenticate the user which populates the users credentials and inserts the authenticated user into the session. This is then replicated across all the services and each service is responsible for their own security rules and settings. So really, all Zuul is doing is looking the user up in spring security and the services on the backend are enforcing the security rules as they apply to their needs. This way, you can change each service independently making the Gateway just a dumb proxy.
A good example of this is in Dave Syers tutorial about Spring Security and an Angular JS app. I also posted another question related to this which contained a sample of how we are doing this as well which might help.
回答2:
- the Gateway would sit in front of many services
What is the concern here ?
- some services may expose endpoints which do not require authentication
Spring Security has a permitAll()access rule
- some services may expose endpoints which need a Session Id and some with a token", an arbitrary opaque value (for example downloading a file if you know a "hard to guess" url) In the API Gateway/Spring Security you can configure all the endpoints with their specific authentication requirements.
Your Zuul proxy can have sessions. If you are using Spring Security OAuth 2.0 you can use ResourceServerSecurityConfigurer#stateless(false) and activate sessions with HttpSecurity#sessionManagement().sessionCreationPolicy(...) to create sessions everytime you receive a valid access token. A JSESSIONID Cookie will be placed in the HTTP Response.
- how do you enforce the actual Service Teams to provide the required settings per downstream service?
I'm not sure I understand the question here, don't you want to enforce security constraints at the API Gateway (zuul proxy) level ? or are you trying to have "security double checks" both on the proxy AND target application ?
- how do you allow frequent Authentication settings changes in the Gateway (as per service needs) without having to stop the entire Gateway?
Zuul allows you to add ZuulRoutes dynamically at runtime, if you use it as a standalone library that is. Wrapped in Spring Security, whose context is initialized once at startup time... I doubt you can easily alter the security config at runtime.
EDIT following precisions by the OP in the comments : If your teams should be responsible for their security rules, having a centralized gateway is a contradiction by design.
My interpretation of the microservice philosophy is that each application is standalone, and in charge of its full functional scope, and security / access control is part of it. You can easily verify tokens at the application level (by either making a call to the authorization server or using JWTs), with each application defining which scope is required for each resource. Spring Cloud already has an OAuth 2.0 starter, or you could easily create one if you use "plain" Spring Boot.
That way you can deploy individual apps wherever you want (public cloud or on premise servers), without having to rely on upstream components for security or synchronize your gateway configuration deployments with other teams.
The API Gateway thing is an easy temptation, but don't overlook the risks and constraints :
- You won't be able to secure internal calls
- You will have to rely on upstream network components, and take your applications' input for granted
- Advanced access control rules may become a headache : how do you get the user's individual permissions, etc
- You will have to synchronize configuration changes with other teams
来源：https://stackoverflow.com/questions/33921375/zuul-api-gateway-authentication