302 redirection for proxy calls to microservice with oauth2 behind zuul proxy - spring-boot

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

Related

Spring Security + Keycloak - setting no bearer token to REST request leads to an response with HTML content

I'm using a SpringBoot 2 (2.7.0) application (including Spring security 5.7.1) to secure REST endpoints with Keycloak for authentication and authorization. Everything works fine but the only thing which bothers me is when I don't set the bearer token I get a HTTP 400 response. The response itself is correct but the body of the response contains HTML (Keycloak login page).
Is there a way to avoid that the body of the response contains the login page? I would like to set a custom response body.
That is an expected default behavior. If you want to instead get relevant 4xx error instead, you can try setting the the "bearer-only" in your "keycloak.json" file so that it would not redirect API calls (i.e. AJAX calls from browser) to the login page:
{
...
"bearer-only": true
}

quay.io OAuth2 Proxy: Setting Bearer token to Authorization Header

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

Spring Security Oauth2 Swagger

I am attempting to configure Swagger Authentication on my resource server, so that I can authenticate against my authorization server.
I have the resource and authorization servers separated. They are both starting up on my localhost with different ports.
Resource Server on port 8083
Authorization Server on port 8081
Whenever I attempt to "Authorize", there is a CORS issues.
I forked a project from another website to use as my testing grounds. Below is the forked project.
https://github.com/cbriarnold/oauth2-spring-boot-2.0.2
To test, once both the authorization server and resource server are started, do the following:
Go to http://localhost:8083/swagger-ui.html
Click on "Authorize" button
Click on "Authorize" button in dialog
If you have the developer tools open, you will see that there is the CORS error
Access to fetch at 'http://localhost:8081/oauth/token/' from origin 'http://localhost:8083' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
The http status code associated with the above CORS error was 302.
So, I modify the source to try to permitAll (I know this is undesired from a security perspective, but I am just trying to figure out what is going on). I will receive the same CORS error, but with the https status code of 403. Code is found on the following branch.
https://github.com/cbriarnold/oauth2-spring-boot-2.0.2/tree/permitAll
Any suggestions?
I think you need to add #CrossOrigin(/*your hitting server*/) on your controllers
it's a chrome security check to see if your are permitted to talk with that server or not it sends an option request at first and if you're permitted it send your original request which is accessing swagger
if you want to make sure if that is a cross origin problem or not try to send that request via postman because postman send your request direct without option request at first

Login once with client once to the REST remote app

I am developing a REST client (A) that talks to the another rest based application (B).
Now B is a secure application and has login url. When I hit the url using RestTemplate I get nothing in response but headers. But after that if I ask for any other resource using RestTemplate to app B it says unauthorized.
Below image shows the headers. How can I login once and then use this headers to talk with application B using RestTemplate.
thank you
I also don't have any login code for my rest client app A. As it will completely depend on app B. So I will not have any local user database for app A.
Request: POST /login username=user&password=password
Response: 302 Set-Cookie: JSESSIONID=xxxxxxx
Request: GET /protected-endpoint Cookie: JSESSIONID=xxxxxxx
Response: 200 Stuff...
A successful POST request to the /login endpoint should return a JSESSIONID Cookie. This is what you'll need to pass along in subsequent requests as this is your session token.
Depending on your Security Configuration you may need to make some modifications but that is the gist of it.

Http request not authenticated after passing through Zuul

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.

Resources