My goal is to enable access on one (static) web page/folder only to authenticated users.
auth_basic is NOT option.
There are 2 servers: nginx (contains http,css and javascript) and REST server (doing authentication and provides secure content).
REST server provides access token.
On www.somesite.com/secret (hosted by nginx) should access only authenticated users.
I have tried something similar to this https://www.nginx.com/resources/admin-guide/restricting-access-auth-request/
this is my config example:
location /secret/ {
auth_request /restauth;
auth_request_set $auth_status $upstream_status;
}
location /restauth/ {
internal;
proxy_pass http://localhost:8080/api/auth/login;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
With this, only GET request is sent, REST service support only POST.
How can I send POST with access token, and with code 200 to allow access to content of /auth folder?
Another interesting thing I found is nginscript, but this simple example from this site doesn't work to me.
Related
We are using Auth0 for authentication and NGINX for reverse proxy.
com.auth0.AuthenticationController is used at backend for the login and we updated all the setting at auth0 application and added these urls (http://localhost:8888, http://localhost:9999 ) to allowed callback urls list.
Nginx reverse proxy configuration
server {
listen 8888;
server_name localhost;
location = /login {
proxy_pass http://localhost:9999/login;
}
}
As per the above code when nginx gets login request it redirects it to http://localhost:9999/login
The service running at localhost:9999 is trying to get com.auth0.Token using the auth code
authenticationController.handle(request, response);
but following exception is thrown.
The redirect URI is wrong. You sent http://localhost:9999, and we expected http://localhost:8888
Note: It is telling us that while creating the secret code at Auth0 we have provided http://localhost:8888 as redirect_uri, but trying to access the token using http://localhost:9999
How to tell the Auth0 server that it is proxied url?
server {
listen 8888;
server_name localhost;
location = /login {
proxy_set_header Host $http_host;
proxy_pass http://localhost:9999/login;
}
}
The code started working when we added the following line to nginx configuration.
proxy_set_header Host $http_host;
We have a nginx and an apache2 server.
Apache2 is configured to manage Kerberos (Active Directory) authentication.
We have a website managed by nginx with a reserved area.
I would know if this is possible:
the user goes to main site managed by nginx
from main site, there is a link to "/login" mapped to apache2:
location /login/ {
proxy_pass http://apache2server/testlogin;
}
when the login is successful, apache2 is configured to go to another nginx webpage, using proxypass too:
ProxyPass /testlogin http://nginxserver/logindone.php
ProxyPassReverse /testlogin http://nginxserver/logindone.php
I wonder if this is the right solution to the problem.
The best way you can implement an external authentication to your NGiNX website is using auth_request directive.
Basically, you can protect any request doing a subrequest to any external web server. The subrequest must return HTTP code 2XX to allow proceeding to the content, and any other HTTP code returned will deny access.
To accomplish that, be sure you've NGiNX with auth_request enabled (compiled with --with-http_auth_request_module). To check that, use the following command at shell:
nginx -V 2>&1 | grep "http_auth_request_module"
Add the auth_request directive to the location you want to protect, specifying an internal location where the authorization subrequest will be forwarded to, using:
location /system/ {
auth_request /auth;
#...
}
So, when a request is made to /system/ location, the system will create a subrequest to /auth location. Now we need to create the internal /auth location. We can use the following example below:
location = /auth {
internal;
proxy_pass http://my.app.webserver/auth_endpoint;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
#...
}
Here, we created the /auth internal location. We used the internal directive to disable external NGiNX access (any external request to /auth will not be processed by this location). Also, we removed the request body content and set the request length to zero, removing any original request variable. We do a subrequest to http://my.app.webserver/auth_endpoint passing all requested cookies, so your backend application could determine if user has access or not.
If you need to know the original requested URI, you can add it on an extra HTTP header at subrequest adding:
proxy_set_header X-Original-URI $request_uri;
You can learn more about NGiNX auth_request directive here.
I have an expressjs server to authenticate login requests from a front app built in svelte.
The front app is running on frontenddomain.com and the expressjs server is running on backenddomain.com
Here is my login post route that authenticate and set cookie:
app.post('/login', (req, res)=>{
// check db,find the user, write a jwt token and put it in a cookie to send it to the
// browser
res.cookie("accesstoken", accessToken)
res.cookie("refreshtoken", refreshtoken)
res.send(...)
}
This server code deployed to an ubuntu server with Nginx running as a proxy_reverse, here is my nginx block configuration:
server {
...
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_cookie_domain localhost .frontenddomain.com;
proxy_cookie_domain ~^(.+)(Domain=frontenddomain.com)(.+)$ "$1
Domain=.frontenddomain.com $3";
}
}
server {
listen 80;
listen [::]:80;
server_name backenddomain.com www.backenddomain.com;
root /var/www/backenddomain.com;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
}
When I run the server and svelte app (front app) using my local machine, everything works (customer provide credential, cookie is sent to client browser and upon inspecting google dev tools, I confirm that the cookies has been set correctly in the client's browser)
When I deploy my expressjs server to ubuntu (20.04) and use pm2 to run my server, it does start and I can view all my console.log. My front app runs and I go to my login page, enter credential and click submit, the app logs me in (because credentials are correct and user set to true on the front app localstorage) but NO COOKIES are set in the browser.
I read the nginx docs, I read material and posts from different sites on how to set Nginx proxy_reverse cookie domain but unable to fix the problem (the problem is cookies are not set in the browser, the server issues them) but my proxy server is not passing them to the browser.
These questions about proxy_reverse and cookies come up, the poster comeback and post vague answer to their own question and no other answers. It seems like there are not enough technical people out there with knowledge of this issue.
my location code has the proxy_cookie_domain localhost .frontenddomain.com;
How do you set nginx proxy_reverse to pass-set cookies to the browser passed on from upstream server?
So it wasn't related to the nginx block configuration but it was the cookie settings. For cross site cookies to work, it has to be set with sameSite : none (or strict) and secure flags. Make sure that your backend and front has to be using domains (ip is not allowed in the latest draft as of this writing)
You also need both front and back domains to be secured (https) with an ssl.
Your ufw on nginx needs to allow https.
Cookie settings:
res.cookie("name", "value", { sameSite: "none", secure : true })
restart your nginx after updating the server and your nginx conf sites-available
and it should work.
I am running the Kubernetes dashboard which, as one of its authentication methods, will allow you to pass the Authorization header with a bearer token in it. The token has to be a bearer token, i.e. Authorization: Bearer <token goes here>.
I am also running pam_hook as my authentication service. It uses HTTP basic auth to query PAM to get a user's groups, and it constructs a bearer token with that. I've modified it slightly to return the bearer token in the Authorization header after seeing this answer that tells me that you need to have it in the header for what I am trying to do: https://stackoverflow.com/a/31485557/691859
I have a fronting proxy (nginx) that uses the HTTP auth PAM module to secure the dashboard. Of course, I can have nginx forward the Authorization: Basic <basic auth goes here> header from this to pam_hook, and pam_hook can reply with the bearer token in an Authorization: Bearer <token goes here> header.
However, I'm having two problems:
I am struggling to get the bearer token from pam_hook forwarded to the kubernetes dashboard; nginx is only forwarding the basic auth.
Even if I was able to get it passed, I'm not sure how I can safely cache the responses. I need to cache each user's bearer token separately, otherwise, people will be able to act as each other. This answer alludes to that, but it doesn't tell you how to avoid the problem: https://stackoverflow.com/a/44232557/691859
So right now my config looks like this (I'm simplifying greatly here):
nginx.conf:
http {
proxy_cache_path /tmp/cache levels=1:2 keys_zone=authentication:10m inactive=15m;
proxy_cache_valid 200 15m;
include /etc/nginx/conf.d/pam.conf;
include /etc/nginx/conf.d/upstream.conf;
}
pam.conf:
auth_pam "Log in please";
auth_pam_service_name "nginx";
upstream.conf:
upstream backend {
server localhost:9090
}
server {
listen 443 default_server;
location #upstream {
proxy_pass https://backend;
proxy_redirect off;
}
include /etc/nginx/conf.d/basic_auth_proxy.conf;
location / {
root /dev/null;
try_files $uri #upstream;
auth_request /basicauthproxy;
auth_request_set $authorization_header $upstream_http_authorization;
proxy_set_header Authorization $authorization_header;
}
}
basic_auth_proxy.conf:
location /basicauthproxy {
internal;
proxy_pass https://pamhook/token;
proxy_cache authentication;
proxy_cache_key $cookie_authentication;
proxy_pass_request_body off;
proxy_hide_header Set-Cookie;
proxy_ignore_headers Set-Cookie;
proxy_set_header Cookie "";
proxy_set_header Host $host;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
The behavior I get right now is that I get prompted for basic auth, pass my credentials, that succeeds, and then the dashboard gets the forwarded request... but the Authorization header contains the basic auth info from the proxy, not the bearer token. What am I missing to get this to work?
Edit: I upped the verbosity of pam_hook's logs. It's not getting any request from nginx. So that's probably the first problem to address, not that I understand why it's happening. I do know that I can curl pam_hook from the nginx container, so it's not a matter of a bad NetworkPolicy.
Below is my nginx configuration file for Jenkins. Most of it is exactly as per I've read in the documentation.
Config file:
upstream app_server {
server 127.0.0.1:8080 fail_timeout=0;
}
server {
listen 80;
listen [::]:80 default ipv6only=on;
server_name sub.mydomain.net;
location ^~ /jenkins/ {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://app_server;
break;
}
auth_basic "[....] Please confirm identity...";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}
When navigating to http://sub.mydomain.net/jenkins I get prompted for my basic auth with Server says: [....] Please confirm identify....
This is correct, but as soon a I enter the proper credentials I then get PROMPTED AGAIN for basic auth once again, but this time: Server says: Jenkins.
Where is this second hidden basic_auth coming from?! It's not making any sense to me.
Hitting CANCEL on the first prompt I then correctly receive a 401 authorization required error.
Hitting CANCEL on the second basic auth ("Server says: Jenkins") I get:
HTTP ERROR 401
Problem accessing /jenkins/. Reason:
Invalid password/token for user: _____
Powered by Jetty://
Does anyone know what's possibly going on?
Found the solution to my issue by searching for Nginx used as a reverse proxy for any other application with basic_auth.
Solution was the answer found here:
https://serverfault.com/questions/511846/basic-auth-for-a-tomcat-app-jira-with-nginx-as-reverse-proxy
The line I was missing from my nginx configuration was:
# Don't forward auth to Tomcat
proxy_set_header Authorization "";
By default, it appears that after basic auth Nginx will additionally forward the auth headers to Jenkins and this is what was leading to my issue. Jenkins receives the forwarded auth headers and then thinks it needs to authorize itself too?!
If we set our reverse proxy to not forward any authorization headers as shown above then everything works as it should. Nginx will prompt basic_auth and after successful auth we explicitly clear (reset?) the auth headers when forwarding to our reverse proxy.
I had this issue as well, in my case it was caused by having security enabled in jenkins itself, disabling security resolved the issue.
According to their docs:
If you do access control in Apache, do not enable security in Jenkins, as those two things will interfere with each other.
https://wiki.jenkins-ci.org/display/JENKINS/Apache+frontend+for+security
What seems to be happening is that nginx forwards the auth_basic response to jenkins, which attempts to perform auth_basic in response. I have not yet found a satisfying solution to the issue.