Spring-cloud-netflix: Zuul filter not modifying sensitive header 'Authorization'

[ghost]

I am trying to modify the request header "Authorization" with zuul filter but it is not sending the modified header instead it is sending the original header value received from client.

I was able to modify non-sensitive custom header value and saw zuul forwarding that to downstream services.

```
authToken = getAuthToken(domainDataServiceResourceId);
String accessToken = "Bearer " + authToken;
ctx.addZuulRequestHeader("Authorization", accessToken);

I have disabled Authorization as sensitive header

zuul:
sensitiveHeaders: Cookie,Set-Cookie
routes:
compute-client:
path: /client/*
serviceId: clinet
compute-service:
path: /service/*
serviceId: service

Zuul didn't send the above modified Authorization header to downstream service. It always sends the original Authorization header received from request.

I found that it modifies any other custom header and send the modified value to downstream services.

Versions:

springBootVersion = '2.0.3.RELEASE'
dependencyManagement {
imports {
mavenBom "org.springframework.cloud:spring-cloud-dependencies:Finchley.RELEASE"

}

}
compile 'org.springframework.cloud:spring-cloud-starter-netflix-zuul'
```

[ryanjbaxter]

Please provide a project that reproduces the issue.

[ghost]

zuul-gateway.zip

Adding minimal project to produce the issue.

My additional findings are:
1) I have OAuth2 enabled on Gateway service and I am sending bearer token in Authorization header to authenticate to Gateway service then want to modify it based on downstream service it is talking. In this case downstream service received the original token that was sent to Authenticate to gateway service

2) If I disable OAuth2 for Gateway service and send bearer token(which doesn't do anything now) and modify it based on downstream service, downstream service receives the modified token.

So the issue is with the first scenario where the token is already being used for authentication and needs to modify for downstream services.
@ryanjbaxter

[ryanjbaxter]

I had to modify your sample a little bit to try and reproduce this. I removed the eureka dependency and added ribbon. Then added the following properties

compute-client:
  ribbon:
    listOfServers: httpbin.org
compute-service:
  ribbon:
    listOfServers: httpbin.org

I dont think this should effect anything though.

Then I made the following request and the filter seemed to work fine

$ http :8282/compute-client/headers Authorization:foo
HTTP/1.1 200
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Type: application/json
Date: Tue, 24 Jul 2018 18:33:12 GMT
Transfer-Encoding: chunked
Via: 1.1 vegur

{
    "headers": {
        "Accept": "*/*",
        "Accept-Encoding": "gzip",
        "Authorization": "Bearer 987ad9siahdsikad9syd98aydsadbksadbksad",
        "Connection": "close",
        "Host": "httpbin.org",
        "Primary": "second",
        "User-Agent": "HTTPie/0.9.9",
        "X-Forwarded-Host": "localhost:8282",
        "X-Forwarded-Prefix": "/compute-client"
    }
}

[ghost]

Yes it worked because it is falling to second category as I mentioned in my previous comment. I have this problem only when I am using initial auth token to authenticate to gateway service itself then trying to update it.
@ryanjbaxter

[ryanjbaxter]

So how do i reproduce the problem then?

[ghost]

Sorry @ryanjbaxter, I have removed OAuth as I was using my company's custom library for OAuth2. I tried to reproduce the problem with Spring basic security but I couldn't as it is modifying the header. I can't think of other solution unless I write resource server and auth server configuration of my own.

[ryanjbaxter]

Without a way to reproduce the problem, I am not sure how we can help. I looked at the code in Spring Cloud Netflix Zuul and the only place I see the Authorization header being manipulated is in the sensitive headers property, so I dont have any idea why you are seeing this problem based on that.

[ryanjbaxter]

I am going to close the issue for now until you can provide a sample that reproduces the problem, then we can reopen it.

[ghost]

By default when I overloaded zuul filter methods, filter type defaulted to "pre". Changing it to "route" fixed the issue

[destan]

I've just manipulated the Authorization header with pre filter and send it w/o a problem. Maybe it was something else.

[amritanshvns]

I was facing the same problem and had to set sensitiveHeaders=Cookie,Set-Cookie to solve the issue. Even if the pre filter adds the Auth. header , it is discarded before the route takes place because of the default configuration. Sensitive Header