Configuring Access Level of Downstream Endpoints on Zuul Proxy

[KevinVHoutte]

To increase performance, you can choose to implement a configuration security mechanism for making less network hops,

a mechanism implemented on Zuul, where you can configure which route needs private, public or partial authentication.
Every route in Zuul to a downstream service will have security configured based on how secure the endpoints has to be.

[dsyer]

Can you explain how this relates to the existing AuthenticationHeaderFilter? Does it replace it, or enhance it?

Also, please don't use lombok for new code (we are trying to get rid of it in Spring Cloud projects).

[KevinVHoutte]

Alright i’ll remove lombok out of the picture,
This PR is to enhance security. This way you can block requests without an authorization header where it is mandatory.

I got some recommendations regarding this feature so I am going to refactor this PR.
This configuration should exist under the proxy configuration.
See following example:

proxy:
  auth:
    routes:
      customers: oauth2
      stores: passthru
      recommendations: none
  access:
    - customers
      level: private
    - stores
      level: partial-exposed
      paths:
      - /customers/api-docs/*

The customers route should be private so that whenever there is a request without an authorization header, this request will not be forwarded.
When your route has an access level of partial-exposed the proxy should also block all requests without the authorization header, except for the paths that are specified

[dsyer]

I'm not really comfortable with this yet. Isn't it duplicating features in Spring Security?

[TYsewyn]

Are you referring to the filters from Spring Security?
This PR could be refactored into the instantiation of one (or multiple) Spring Security filter(s) which will deny or allow your request based on the configuration that has been set.
This way you don't need to extend ZuulFilter.

EDIT: Another option is to create an implementation of a ChannelProcessor so the ChannelDecisionManager could decide whether or not the channel meets the required prerequisites.

[KevinVHoutte]

It is an enhancement for the proxy configuration so there is a standard for securing your downstream services in Zuul. There is no such configuration in Spring Security that I have found.

[dsyer]

There is no such configuration in Spring Security that I have found.

It looks a lot like HttpSecurity.authorizeRequests() to me (standard stuff you add to a WebSecurityConfigurer), possibly with a custom filter that authenticates on the presence of a header without actually checking it's value.

[KevinVHoutte]

HttpSecurity.authorizeRequests() does go too deep in detail and is pretty verbose for what I'm doing here.
This will mostly be used in the downstream service itself, where authorization control is.
This PR is more high level and and lightweight and an extra security enhancement on top of the secured downstream service.
The added value is that the request gets blocked at Zuul level and not at service level, this will cause less network hops and increase performance.

[dsyer]

I think you misunderstood my comment. I'm not saying the feature is uninteresting, just that the implementation is not ideal - for security we would prefer to use Spring Security, that's all.

[KevinVHoutte]

Ok, thank you for your time and response :)

[pivotal-issuemaster]

@KevinVHoutte Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@KevinVHoutte Thank you for signing the Contributor License Agreement!