What are the headers that will be forwarded and what will be modified and dropped
With some exceptions, by default, API Gateway forwards all headers on incoming requests to the downstream services.
The most notable exceptions, ignoring whitelisting and other specific features:
- Authorization header if the request is authenticated with Security Token Service - Accept header and Content-Type header may be manipulated based on the route configuration and version: https://confluence.inside-box.net/display/ETO/On-boarding+new+APIs#On-boardingnewAPIs-HeaderManipulation
Related
What I want to do
Calling an URL which is proxied by the oauth2 proxy. The oauth2 proxy should perform an authorization code flow in case no authentication is available. In case there is already an authentication available, the access token should be set to the Authorization Header in the request which is forwarded to the upstream.
What I tried
According to the documentation I'd expect that, when setting --pass-authorization-header the token which is requested should be added to the authorization header.
I also experimented with --pass-access-token which should set an X-Forwarded-Access-Token header.
I couldn't see this header at my service either.
Could someone explain to me what I'm doing wrong?
I found the solution.
This post on a github issue lead me to my mistake.
I did misunderstand what the request is and what the response is and how to handle them using nginx ingresses.
If you are using OAuth2-Proxy with a Kubernetes ingress using nginx subrequests (https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/) the data that comes back to nginx is actually an HTTP response, so you will need to use HTTP Response headers (the --pass-* options configure request headers to the upstream).
Try --set-authorization-header and then you need to use this annotation to have the Kubernetes take the subrequest response header and add it to the proxied request header: nginx.ingress.kubernetes.io/auth-response-headers
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#external-authentication
I am trying to set session cookie from a Lambda API Gateway integration to the client but it will never send the Set-Cookie header.
I don't see the Set-Cookie in the API Gateway logs neither.
Here is an example of the Set-Cookie header hard-coded in the Integration Response when HTTP Status is 200
The Set-Cookie is not sent but the Access-Control-Allow-Credentials header is sent to the client
UPDATE 23-06
It appears that using the Mapping template in the Integration Response is working but setting it in the Header Mapping doesn't.
When i send Authorization Header from rest client(postman), also from browser, to back end springboot(2.0.3v) AuthorizationService (without API Gateway), the 'Authorization' Header will be exists and every flow works fine.
But when i send the same Header through API Gateway, The 'Authorization' Header will be missed. This header will be present in all filters of API Gate way. But it will be missed in backend(AuthorizationService)'s filter.
Kindly help what might be cause? any filter is intercepting to avoid Authorization Header? I have also registered CORS Filter with Access-Control-Allow-Origin to "" and Access-Control-Allow-Headers to "".
API gateway has a lambda proxy integrated when you are integrating lambda function with it, if ur wrapping a http url to it, you need to pass the header in Method integration section and also enable CORS by clicking on resource and manually adding the headers with custom name and enabling cors might help.
When Authorization header present in the inbound request, it's always a Cache Miss. My requirement is, I need ATS to treat the Authorization header like any other header (It should not cause cache miss and it should get forwarded to upstream service). How can I achieve this.
This may sound non-secure, but, I have a specific usecase for this. This cache is for internal use and it's access is controlled by other means.
I tried this
As per the official documentation
By default, Traffic Server does not cache objects with the following
request headers:
Authorization
Cache-Control: no-store
Cache-Control: no-cache
To configure Traffic Server to ignore this request header,
Edit proxy.config.http.cache.ignore_client_no_cache in records.config.
CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1 Run the
command traffic_ctl config reload to apply the configuration changes.
but, no luck
If your origin returns a cache-control header with the 'public' directive (for instance, "Cache-Control: max-age=60,public") or including the s-maxage directive (for instance, "Cache-Control: s-maxage=60"), ATS should start caching the object. The relevant http RFC:
https://www.rfc-editor.org/rfc/rfc2616#section-14.8
When a shared cache (see section 13.7) receives a request
containing an Authorization field, it MUST NOT return the
corresponding response as a reply to any other request, unless one
of the following specific exceptions holds:
1. If the response includes the "s-maxage" cache-control
directive, the cache MAY use that response
...
3. If the response includes the "public" cache-control directive,
it MAY be returned in reply to any subsequent request.
Similarly, you could also use the header_rewrite plugin to remove the Authorization header from the request, or to add public/s-maxage.
Actually this https://docs.trafficserver.apache.org/en/latest/admin-guide/configuration/cache-basics.en.html#configuring-traffic-server-to-ignore-www-authenticate-headers did the trick for me.
The following instructions was applicable for Authorization header as well, besides WWW-Authenticate Header. They need to update the documentation.
Configuring Traffic Server to Ignore WWW-Authenticate Headers
By default, Traffic Server does not cache objects that contain WWW-Authenticate response headers. The WWW-Authenticate header contains authentication parameters the client uses when preparing the authentication challenge response to an origin server.
When you configure Traffic Server to ignore origin server WWW-Authenticate headers, all objects with WWW-Authenticate headers are stored in the cache for future requests. However, the default behavior of not caching objects with WWW-Authenticate headers is appropriate in most cases. Only configure Traffic Server to ignore server WWW-Authenticate headers if you are knowledgeable about HTTP 1.1.
To configure Traffic Server to ignore server WWW-Authenticate headers:
Edit proxy.config.http.cache.ignore_authentication in records.config.
CONFIG proxy.config.http.cache.ignore_authentication INT 1
Run the command traffic_ctl config reload to apply the configuration changes.
I am trying to access NIFI rest api of another server from my machine using ajax like below,
url:"https://serverip:port/nifi-api/",
{Authorization : 'Bearer ' + 'access token here'}
Getting Response to preflight request doesn't pass access control
check: No 'Access-Control-Allow-Origin' header is present on the
requested resource error.
Apache NiFi's API is designed to be invoked by a variety of clients, but in this case I think you are encountering a security precaution put in place by CORS (Cross-Origin Resource Sharing).
If a piece of code on server A (your non-NiFi machine) makes an AJAX request to a different origin (your NiFi instance), and the HTTP method is not GET (and some other minor restrictions), server A will first send a "preflight" request, which is HTTP OPTIONS, to the remote instance to determine what requests are valid. A server can reply to this with the header Access-Control-Allow-Origin: *, which is a wildcard value denoting it accepts requests from any origin. However, if you want to send credentials along with the request, the originating hostname must be explicitly listed in the response (Access-Control-Allow-Origin: https://serverA.com).
Because NiFi uses an embedded Jetty server to host the API, you may have to explicitly add a CrossOriginFilter as described here.