-
Notifications
You must be signed in to change notification settings - Fork 244
Documentation or examples for security with proxy #15
Comments
I'm not sure it will ever be possible (or advisable) for the proxy to be so tightly coupled with the backends. At present the default is for the proxy to forward the Authentication header from the front end call directly to the backend, and that won't suit all purposes, but it gets you a long way (and won't affect anonymous routes, since they don't, or shouldn't care if they are authenticated or not). If the front end also has Maybe you could explain your use case and the custom configuration you had to implement in a bit more detail? |
What I am having to do is tell the proxy which routes I want authenticated and which routes I want anonymous and then do the same exact configuration in the resource as well. Code is worth a 1000 words so here it is. Maybe if we put this configuration in the configuration service and used the service name to configure the routes. Than each service and the proxy can read this configuration from the configuration service and everything is in a central location. App.java for the proxy
App.java from the Sessions resource
App.java from the Questions resource
|
Can't you just make your whole "/api/**" on the proxy a passthru (ignore security completely or make it anonymous)? Why does the proxy have to protect routes that are already protected by the backend? |
Its late and it is a long day but I can't think of a good reason why right now. Not sure why I didn't think about that, kind of embarrassing. Maybe because I started with securing things at the proxy and then realized that the resource needed to be secured as well, and never went back and thought about this. I will take a look tomorrow, but I think this simplifies things. |
@dsyer I made it a passthrough as you suggested (added /api/** to security.ignored) but it appears that when doing that it looks like the proxy is not setting the authenticated header when proxying the request to the resource server is rejecting it. I think that makes sense though since we told the proxy to ignore security on those requests. |
So don't ignore it if you want an authentication header. It should be 'permitAll()' I guess? |
So I was certainly able to simplify the configuration on the proxy end
I think a complete example that demonstrates how everything should be configured properly with authentication done at the proxy and auth tokens verified at the resource server would be great. I am still not sure if I could simplify the configuration in the resource apps, I tried a few things to eliminate the WebSecurityConfigurerAdapter like I did in the proxy but I couldn't get it to work. |
See original discussion in #14.
I think if the Zuul proxy somehow knew about the security routes from the resource it is proxying from that would be ideal. That way the configuration stays with the resource and if the resource is accessed without using the proxy the security routes are still in place.
The text was updated successfully, but these errors were encountered: