Spring-cloud-netflix: Finchley.SR1 Authorization Header is not being forward

[shahbour]

After updating from Finchley.RELEASE to Finchley.SR1 all requests done through Zuul are missing the Authorization header

Below is my configuration

@SpringBootApplication
@EnableZuulProxy
@EnableDiscoveryClient
public class GatewayApplication {

    public static void main(String[] args) {
        SpringApplication.run(GatewayApplication.class, args);
    }
}

@Configuration
@EnableOAuth2Sso
public class WebSecurityConfigurer extends WebSecurityConfigurerAdapter {

    //This is needed on the gateway so OAuth2TokenRelayFilter do check the validation of token and refresh it.
    @Bean
    public OAuth2RestOperations oAuth2RestOperations(OAuth2ClientContext oauth2ClientContext, OAuth2ProtectedResourceDetails details) {
        OAuth2RestTemplate oAuth2RestTemplate = new OAuth2RestTemplate(details, oauth2ClientContext);
        return oAuth2RestTemplate;
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .csrf()
                .disable()
                .headers().cacheControl().disable()
                .and()
                .httpBasic().disable()
                .authorizeRequests()
                .requestMatchers(EndpointRequest.toAnyEndpoint()).permitAll()
                .requestMatchers(PathRequest.toStaticResources().atCommonLocations()).permitAll()
                .mvcMatchers("/uaa/**", "/login","/favicon.ico","/error**").permitAll()
                .mvcMatchers("/xxxx/**").hasRole("ADMIN")
                .anyRequest().authenticated()
                .and()
                .logout()
                .permitAll();
    }

}

Checking the network I see request going to /uaa/user and response correctly returned with token but request to the service is sent without the header

I could not find any change that lead to this

[shahbour]

I found that the problem is from this commit and this pull

After adding

            if (isIncludedHeader(header)){
                headers.set(header, zuulRequestHeaders.get(header));
            }

authorization header is already in the ignoredHeaders and it is not being added.

Is this a bug or I am missing something?

[ryanjbaxter]

@dev-priporov

Can you try setting zuul.ignoreSecurityHeaders to false?

[shahbour]

It is already set I tried with both true and false, also I tried setting the ignored-headers but seems they don't have an effect here

zuul:
      ignore-security-headers: false
      ignored-headers: cookie,set-cookie

[ryanjbaxter]

When I run a basic zuul app and send a request through it with an authorization header that header will make it through to the backend service, so I am not seeing that you are describing.

[shahbour]

The problem is when @EnableZuulProxy is with @EnableOAuth2Sso the authorization header is generated from inside the application not bypass

[ryanjbaxter]

OK. Could you provide a sample that reproduces the problem so we can take a look?

[shahbour]

here is a sample

You just need to run the gateway with RELEASE and SR1 to get the difference

[ryanjbaxter]

Try this

zuul:
  sensitiveHeaders: Cookie,Set-Cookie

By default sensitiveHeaders will contain authorization to protect you from accidentally sending authorization information to downstream services that are not part of the same system. In your case I dont think this is a concern since the service is part of the same system.

[shahbour]

Yes that will work, just tested it

[ryanjbaxter]

Great. I think we may have changed the behavior between Finchley.RELEASE and SR1 but for the better IMO. We shouldnt have been sending that header downstream by default.

[michalborek]

Guys, it is obvious that we should filter headers that came from original request, but filtering headers added by another Zuul filter is IMHO not the same. We should handle it in different way if we want to be so strict about "authorization" header.

What is more, making such breaking change in service release should not happen.

[ryanjbaxter]

@michalborek I disagree. Whether the authorization header is being generated internally or not it should not be forwarded to downstream services by default. The code has no way of knowing whether any downstream service is part of the same system or not so explicit configuration seems like the safest approach.

[spencergibb]

We considered it a bug