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.
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 have been struggling with setting up AWS API Gateway to pass Query string parameters to my Lambda function.
If I set to API to use Lambda proxy integration, I get a CORS error at the Web client
[index.html:1 Access to XMLHttpRequest at 'https://g2kza1o79f.execute-api.eu-west-2.amazonaws.com/prod/gettest8' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.]
( - even when I have set the API with CORS enabled.
If I set the API to not use Lambda proxy integration, and CORS enabled, the API call works (no CORS error), but the event object received in my Lambda function is empty( hence no query string parameters).
In both cases I am using the GET method.
I can see in the Method Response Header the Access-Control-Allow-Origin option is present, but cannot access the Integration Response
Question: How can I set-up my API to pass query string parameters through to my Lambda function without getting the CORS error? I will also be wanting to set up APIs for POST requests to other Lambda functions.
I believe it is related to First Enable CORS Then Deploy API.
A good thread could be found here.
API Gateway CORS: no 'Access-Control-Allow-Origin' header
I work in project that uses microservice architecture with JWT, every thing is good but when I send the Authorization in the request from client (Angular app) it is checked by the api-gateway (ZuulFilter) and after that the request is sent to auth-server, the problem is that I don't find the Authorization in the header and every data is lost. Any one has an idea ?
The solution was to add he property sensitive-headers in zuul properties and remove "Authorization" from default value as explained here and here
Im using Jmeter to write some load tests on an API secured by oAuth.
I want to be able to reuse the header manager once the bearer token has been produced from the access token call.
However when I try to move the header manager out side of the http request the call is no longer authorised. I think its because it can no longer get the bearer token.
For Post Request, when i put the header manager outside it no longer works, it only works when I put it under the request as I have done for User get request, Delete request and Put request.
How do I make the header manager reusable and therefore only manage one header manager?
Thank you.
{"fault":{"faultstring":"Invalid access token","detail":{"errorcode":"oauth.v2.InvalidAccessToken"}}}
My expectation is that this is due to clash with the HTTP Authorization Manager
Both are Configuration Elements and both obey JMeter Scoping rules
When you move HTTP Header Manager outside the HTTP Request sampler it might be the case that Authorization Header comes from the HTTP Authorization Manager
You can check which exact header value is being sent using Request -> Request Headers tab of the View Results Tree listener
Given you manually create Authorization header for your request I believe if you disable or delete the HTTP Authorization Manager your test should start working as expected as you basically don't need it.
I tried to send a Javascript XHR request that includes a
'Authorization: Basic base64encodedCredentials'
header through a Zuul proxy. Behind the proxy is my Spring Security Server that exposes an endpoint which is secured by Basic HTTP authentication. My server reacts with a 401 ("unauthorized"). If I send the same request via curl, all is well.
Using a network monitoring tool, I observed that the header Zuul is sending looks like this:
'authorization: Basic base64encodedCredentials' (notice the lowercase 'a' in 'authorization')
After I had a look at the source code of BasicAuthenticationFilter in Spring Security, I suspect that the lowercase 'a' is the reason why my XHR request is not authenticated by my server.
Is this a bug in Zuul ? What do you think ?
Edit: http header names are actually case insensitive.
So Zuul is not to blame. What else has then caused the authentication to fail ?
I was looking at the wrong place.
For everyone stumbling over this, I'll depict what happened:
My Zuul route was set to
http://<host>/<securityContext>/auth/token
while it should have been set to
http://<host>/<securityContext>/oauth/token (notice the extra 'o')
The wicked reaction of the Spring Security Server was not to respond with a '404' ("not found") to the wrong route, but with a '401' ("unauthorized"). This lead me to the assumption that there is something wrong with the authentication header (or some other header for that matter).
As of now, I don't know why the Security Server responded that way. It seems to me that there is actually an endpoint exposed under /auth/token.