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
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
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.
I'm building an MVC web app that uses the openID Connect hybrid flow to authenticate with Identity Server 3. The MVC web app contains jQuery scripts to get async JSON data from een ApiController. That ApiController is part of the same MVC web app.
I don't want that everyone is able to access the data from the API, so I want to secure the API as well. I added an [authorize] attribute to the ApiController. When requesting the API with a JQuery ajax request I get the following error message:
XMLHttpRequest cannot load
https://localhost:44371/identity/connect/authorize?....etc.
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:13079' is therefore not allowed
access. The response had HTTP status code 405.
But, when I do a request to the API method directly in browser, I will be correct redirected to the Login page of Identity Server..
So, what's exactly the problem here? I read something about that requesting the /authorize endpoint is not allowed via 'back-channel', but I don't understand what's the difference between 'front-channel' and 'back-channel'. Is it possible that I mixed up the wrong OAuth flows? Is the Hybrid flow not the correct one maybe?
I also find out that the API is often a seperate app, but is it always neccessary / best-practice to build a seperate API app that for example requires a bearer token?
Please point me in the right direction about this.
The authorize method on your identity server does not allow ajax calls. Even specifying CORS headers is not going to help you in this particular case. Perhaps you could return a forbidden response instead of a redirect and manually redirect the client to the desired location via window.location
You need to allow your IdentityServer to be accessed from other domains, this is done by allowing "Cross Origin Resource Sharing" or CORS for short. In IdentityServer the simplest way to allow this is in your Client configuration for your Javascript Client, see this from the IdentityServer docs on CORS:
One approach to configuing CORS is to use the AllowedCorsOrigins collection on the client configuration. Simply add the origin of the client to the collection and the default configuration in IdentityServer will consult these values to allow cross-origin calls from the origins.
The error you're seeing is the browser telling you that when it asked IdentityServer if it allows requests from your Javscript client, it returned a response basically saying no, because the origin (http://localhost:13079) was not specified in the "Access-Control-Allow-Origin" response header. In fact that header wasn't in the response at all meaning CORS is not enabled.
If you follow the quickstart for adding a JavaScript client from the docs here all the necessary code is detailed there that you need for the Client config and to setup IdentityServer to allow CORS.
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.
I have one micro service "user-service". It is secured with spring-cloud-oauth2. It has one REST endpoint "/data/v1" which returns some JSON response.
When I send GET request to this endpoint it gets redirected to /oauth/login for authentication and after successful authentication it returns the token and then I am able to get the JSON response.
Later I added zuul proxy service ("micro-proxy-service") to route all external requests to internal back end services like "user-service".
It has single route "/resource" which then forwards the request to "/data/v1"
But now if I send GET requests to "/resource/data/v1" even after successful oauth2 authentication I get HTTP 302 response code with redirection to /login page.
If I try to access the "/data/v1" without zuul proxy then I am able to get response after oauth2. But when I request through zuul then I get 302.
If I remove the oauth2 from "user-service" then I can access "/data/v1" in both ways: directly or through zuul.
Please let me know If I am missing anything in zuul configuration.
Thanks.
Zuul strips the authentication headers by default, to enable them use the following configuration
zuul:
sensitiveHeaders: Cookie,Set-Cookie