Is there any way to remove a header going upstream after the external authentication with the envoy proxy? We planned to migrate to envoy proxy for our internal API gateway, but this is a blocker now.
For example: the external authentication service gets the request and processes the authentication header, in case the validation fails, it throws the 401. But if it succeeds, I want to prevent the auth headers from going upstream.
As per the documentation Ext Auth:
A successful check allows the authorization service adding or overriding headers from the original request before dispatching it to the upstream. This is done by configuring which headers in the authorization response should be sent to the upstream. See allowed_authorization_headers below.
There is no mention whether I can completely remove the header going upstream.
I have the option to override the headers, but that is causing header conflict at the upstream servers. So it is not a possible solution.
How can I achieve this?
Note that I am not an expert in envoy proxy, but from what I was able to find you can actually write a Lua script that would be able to remove the headers. In the documentation you can find an example of such script, and with a little bit of tinkering you should be able to customize it if needed:
-- Remove a response header named 'foo'
response_handle:headers():remove("foo")
You can find more information in the official documentation. Here for config.filter.http.lua.v2.Lua and here are the script examples.
What about using the route level option request_headers_to_remove to remove an Authorization header?
See https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto
Related
I am working on creating a new request in AWS API Gateway. I am having issues with a 404 not found on the URL request.
The request (had to create fake one for the question):
GET https://hello.stackoverflow.com/services/misc/myroute/v1/swagger.json
I created a route in API Gateway ANY /services/misc/myroute/{proxy+}
I attached the route to a Load Balancer Listener integration
I set up the listener rule in the Load Balancer:
IF Path is /services/misc* Then Forward to Target
IF Requests otherwise not routed Then Forward to Default
Created logs for this system in the AWS API Gateway: Monitor -> Logging -> Set Log Destination
Set variables for the log format using the $context variables, Context Variables
Ex Log:
{ "requestId":"QWRHQKWFHWAFZ=",
"routeKey":"ANY /services/misc/myroute/{proxy+}",
"path":"/services/misc/myroute/v1/swagger.json",
"domain":"hello.stackoverflow.com",
"domain_prefix":"hello",
"httpMethod":"GET", "status":"404","protocol":"HTTP/1.1", "endpoint":-" }
One final check I have done to make sure its completing its "route" was see the requests in the monitoring and seeing the 4xx come from this ALB listener.
I can send the request via localhost and get a response with the json body
GET https://localhost:8080/v1/swagger.json --> Status 200 OK with body filled
In my quest to solve the issue, it has lead me to many older (2019) stack overflow questions that seem to be outdated with the AWS Console, same with the AWS documentation. See links below...
AWS API Gateway Method request path parameter not working
AWS API Gateway 404 page not found error when invoking endpoint url
AWS API Gateway Method request path parameter not working
With this being my first project in the AWS cloud space, I am not sure where else to turn. My guess would be the authentication headers from the API Gateway are being lost, but not sure where I can see this loss happening.
From my understanding of how the AWS Request Flow goes, I created this diagram:
We have installed and configured RedHat APIMan for our working API and the plan is migration form current home-grown tiny gateway to APIMan. The problem is that we have some unprotected endpoints which do not need login (Not everyone role! No login required at all). We are using Keycloak OAuth plugin for roles, and Authorization Policy for API security. When Authorization policy is not added, I can allow unauthenticated requests via a boolean value in Keycloak OAuth policy, but after adding Authorization policy, there is no way to let unauthenticated requests pass!
Kamyar. Apiman developer here.
Please file a feature request for this over at https://github.com/apiman/apiman/issues.
I think what you are trying to do may not currently be possible easily because the authentication policy is expecting a successful auth of some sort before it is hit (to get the roles, etc).
We probably need a slightly more detailed explanation of your use-case, and then we can figure out whether we can support it. It seems like it should be doable without major changes if I understand correctly.
If and when we add support for the specifics of your requirement, I will endeavour to update this ticket.
I’m currently experimenting on Metaflow. I followed the documentation and was able to deploy an aws setup with the given cloud formation template.
My question is why is that I’m always getting a:
message: "Missing Authentication Token"
when I access METAFLOW_SERVICE_URL in the browser, even if I made sure that the APIBasicAuth was set to false during the creation of cloudformation?
Shouldn’t this setting make the metadata/metaflow service accessible without the authentication/api key?
How can I resolve this? Or is this expected? That is, I cannot really view the metadata/metaflow service url via browser?
Thanks in advance
This was resolved under this github issue.
You still need to set the x-api-key header if you are trying to access the service url via the browser. To get the api-key you can go to the aws console
Api Gateway -> Api Keys -> show api key
Alternatively you can use the metaflow client in the sagemaker notebook which should be automatically setup for you via the template.
Also worth mentioning that there are two sets of endpoints: The one provided by the api gateway (which you seem to be hitting) and the one provided by the service itself. The api gateway forwards the requests the the service endpoints but needs the x-api-key to be set in the header. You can probably try hitting the service endpoints directly since you disabled auth.
I have the following issue.
After upgrading an application to ASP.NET 2.0 I get a 400 (bad request) status response whenever trying to authenticate in production.
This error does not reproduce locally and doesn't reproduce when using the production container locally.
The only difference that exists between production and local is that there is a reverse proxy in production that implements SSL for all requests.
I've tried moving the authentication code from middleware (as it was initially implemented) into a controller and I've changed the path to the route that was used for authentication. I still get the error.
All other requests work fine (provided you have a jwt token attached to them).
I should also mention that the CORS headers aren't set on the 400 response.
Any ideas?
This issue was caused by an upstream reverse proxy that was stripping some headers from the requests. Requests with verbs Post & Put were affected.
Set the log level of your application to Information to see what Kestrel is actually complaining about.
In our case we had to switch hosting providers because of the issue.
Does Camel-Http4 supports Basic Authentication?
Followed this and other posts
Camel http4 download file using Basic authentication over Https
I am using camel 2.17.3 version. using camel-http4 component. The route sends a https4 multipart request to a REST endpoint . The REST service is behind the siteminder. Have truststore/ketstore/cert all setup and it works fine, just sending basic auth is causing trouble.
Using postman i was able to call REST services with basic auth. However, all the calls from camel route fails and get HTTP error 403.
I tried below options to get it working:
Added basic auth to the HttpConfiguration - got HTTP error 401
Added "Authorization" header to the route, as mentioned in the above link - got HTTP error 403
and Added method,user,pass to HTTP_Query - 403 also clear text password is visible in the siteminder logs, this is not good, so dropped trying this option.
please help resolve this issue with some working example and explain the cause.
Is camel dropping http headers?
also i now thinking should I consider using other available components netty/jetty/cxf?? But I prefer getting HTTPs4 working :)
thanks
To help others with an working example, here is how I got it...
1) Check the site-minder policy and also ensure the user have correct permissions for the services.
2) Passing user/password as query parameter isn't safe (at least it wasn't in my case) Clear text password was exposed in site-minder.
3) setting header (Authorization)
apache-camel-basic-http-auth