Hacker News Reader

Comment by loevborg | Hacker News Reader

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?

View on HN

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!

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...

> 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.

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.

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.

Amazon cognito?

Reply on news.ycombinator.com