Hacker News Reader

Comment by nuccy | Hacker News Reader

I find HTTP basic auth very useful to "protect" gitlab, wiki, forum, et al. internal resources exposed to the internet. With a simple apache/nginx config it is possible effectively to hide those from the intenet and in addition to their built-in authentications (ldap-based) have a fense reliable enough to prevent zero-day vulnerabilities of these populular web applications. Having them as sub-folders of a single web-domain (with proper rewrites added to apache/nginx) prevents numerous HTTP basic auth requests so authentication is required just once after the browser has been restarted.

View on HN

I do the same, e.g. to expose static resources like API docs in an S3 bucket to the world (you can configure CloudFront to check Basic Auth). However, at some point you run into issues (doesn't work well with password managers, how do new team members learn the password, no easy way to rotate passwords when offboarding, etc.).

Now I want to upgrade to a proper OAuth wall. Some server needs to act as a reverse proxy that has permission to access the private resource but checks your identity as a, say, Google Apps user.

Assuming a private bucket on S3, what's the easiest way to accomplish this today?

> doesn't work well with password managers, how to new team members learn the password, no easy way to rotate passwords when offboarding

This is where LDAP and similar are really strong. Unfortunately a lot of companies know that and charge big bucks for this simple feature, often hiding it behind "enterprise" subscriptions where you need to contact them for pricing.

It's also the reason why companies love Exchange and the rest of Microsoft's ecosystem.

That's the thing though - I don't want the complexity of Exchange, LDAP, etc. Complexity kills. This is a simple problem calling for a straightforward solution.

Technically as far as I understand the client side certificates and signing/revoking them through internal CA solve the same problems.

However I have yet to encounter such setup used in a professional environment for humans. Is the complexity of such approach just too high compared to LDAP and the passwords?

Normal users (including some people with graduate degrees in computer science) can't manage client-side keys or certificates, as anyone who has ever had to support users using ssh key authentication knows. So then you have to provide functionality to do this for them in a foolproof and secure way, which is a big bite to chew.

Yeah, I figured the end-user support would fall under the abstract "complexity" I mentioned in my original comment. I can build a hotrod in my garage but nobody sane will use it for public transportation.

Google Cloud offers Identity Aware Proxy and AWS offers Cognito integration with their Application Load Balancers which can do this.

That's helpful thanks. Googling "CloudFront cognito" gives me a bunch of interesting links:

https://awslabs.github.io/aws-cloudfront-extensions/deploy/d...

https://aws.amazon.com/blogs/security/protect-public-clients...

Maybe combining Lambda integration with CloudFront (CF)?

You could intercept every HTTP request before it reaches CF, check auth data and decide to let it through or respond with 401 already. The CF auth password could be kept as an internal secret. You rotate temporary passwords on Lambda environment variables (bit insecure) or using AWS Secrets Manager (very safe).

Requests successfully authenticated on Lambda level gets rewritten with the master CF password to make them succeed there.

It's a lot more trouble than simply setting up basic auth, but you setup only once and theoretically it works.

I used vouch-proxy with nginx for something like this.

The nginx auth_request module authenticates each request against vouch-proxy before it executes the proxy_pass. Vouch-proxy can be configured to authenticate users against google apps or other oauth/iodc providers. And there are some options to pass along username, groups or other data as headers to the proxied service.

Vouch Proxy author here. Thanks for the mention @zorr

VP can be found at https://github.com/vouch/vouch-proxy

Here's to a safe, secure and authenticated 2022!

Amazon cognito?

You can use API Gateway to delegate to any auth server that can generate JWTs. https://docs.aws.amazon.com/apigateway/latest/developerguide... has more details.

I have a few webpages that have to be protected this way, due to an external client that only supports HTTP Auth. I’ve actually been pretty happy with this setup. I have nginx configured to use subauth authentication so I can still have external username/passwords stored in LDAP, etc. It’s been a surprisingly good combination.

I do the same thing; really nice for those things you just can’t put behind a VPN for one reason or another.

A nice alternative to VPN (especially when you don't have a root to set it up) is using ssh tunnels: ssh user@server -D 1234 and Firefox with socks proxy set to 127.0.0.1:1234 (e.g. using Foxyproxy addon, though possible without it via the Firefox network settings). Then all Firefox trafic is exiting on the server side (including DNS requests).

> including DNS requests

Don't be sure about that!

There's an additional setting to check to be sure dns goes through the proxy.

Can't recall the details now, but it's there!

Or maybe it was due to dns over tls not being proxied?

Reply on news.ycombinator.com