Simplify Login with Application Load Balancer Built-In Authentication | Hacker News Reader

Simplify Login with Application Load Balancer Built-In Authentication

aws.amazon.com

93 pointswanghq42 comments

Is this similar to GCP's "Cloud Identity-Aware Proxy"?

I think the main difference between the two is, IAP aims to replace VPN requirements for Enterprises. It only integrates with Google accounts and it seems to go hand in hand with GSuite. So they are more B2B oriented. We hide our staging servers behind IAP for instance.

Amazon's solution seems to integrate with a few other identity providers and gives the developers the tools to do authorization after authentication is done. It seems to position this more like a B2B2C. Although it feels like it already subsumes Google's IAP by doing so.

This is my understanding by reading the article on Amazon, I haven't actually used it.

I am genuinely amazed by the stuff Amazon does sometimes. There are many times this would have made my life so much easier. Feels like cloud providers are becoming more like language frameworks over time. I guess its a kind of lock in, but no more than your locked into .NET Framework or Boost or Underscore I suppose.

I'm a big fan of this stuff myself so don't get me wrong, but I think it is still a little bit worse to be locked into a cloud provider which can change rates/pricing on you any time, then being locked into a framework.

> which can change rates/pricing on you any time, then being locked into a framework.

I absolutely agree with the sentiment, so don't get me wrong, but have any cloud provider ever did so? And most importantly, given that such change would impact user confidence, would it really be worth on the long term?

Of course there are several other reasons to avoid vendor lock-in, but as far as "major bad faith pricing change" goes, I believe it's unlikely.

Ah, I'd like to prove myself wrong in less than one minute: gcp's pricing change on maps services.

I recall Google App Engine jacking up their prices: http://highscalability.com/blog/2011/9/7/what-google-app-eng...

Or fuel provider, ISP, water and other utilities and so on. So many vendor lock ins, so little time.

Does anyone on Heroku want similar functionality — a shared auth layer for many apps?

I have an addon that puts CloudFront in front of you Heroku app with one click:

https://elements.heroku.com/addons/edge

I have been thinking about adding auth via Lambda@Edge...

Now I have a nice implementation to copy...

or via HAProxy and hashicorp-vault I found this: https://github.com/csawyerYumaed/hapvault

This is nice, but how about a simpler feature for the ALB: redirect http to https.

Add CloudFront, then your CloudFront-provided TLS termination AND redirect will be much closer to the client.

Redirecting HTTP requests to HTTPS should not be the default thing to do. It introduces vulnerabilities (such as MITM attacks) that are hardly considered in most configurations (from what I've seen around).

The default connection to your web server should be HTTPS, not HTTP. HSTS is an option to set this up properly.

You should definitely use HSTS, but I think this is about catching those people entering "website.com" in their browser, where the default behaviour (having never visited the site before) is connecting via HTTP. You want those redirected to a HSTS enabled HTTPS connection immediately, and this seems to be a good place to put this functionality?

> catching those people entering "website.com"

When the domain is registered to use HSTS their browser will use a TLS connection the first time they ever connect to your website.

> You want those redirected to a HSTS enabled HTTPS connection immediately

Websites that depend on advertising probably do as they often want to support very old browsers. Otherwise there's no real need for a redirect/connection upgrade IMO.

First time a client connects it'll be HTTP. Then they'll see the HSTS header. Subsequent connections will be HTTPS

That's why there is the HSTS preload list [0], so that browsers can know this before making the HTTP request.

If you don't want to add your domain to the preload list, you will have to (automatically) redirect/upgrade users to HTTPS, or bounce them.

[0] - https://hstspreload.org/

> That's why there is the HSTS preload list

which has the following requirements: 1. Serve a valid certificate. 2. Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.

oops.

In the second part of that sentence:

> if you are listening on port 80

You don’t have to accept trafic on the http port for HSTS preloading. But iff you do you must redirect it.

This rule makes sense; at least you should never serve content over http.

not everyone's browser has that list. if you turn off port 80, at no point will the browser that doesn't have this list be able to connect to your website.

Except for Opera Mini and UC (Android), all modern browsers do. That’s over 85% of global usage. [0]

[0] https://caniuse.com/#feat=stricttransportsecurity

https://www.reddit.com/r/AskNetsec/comments/6mo4lt/how_long_...

checkmate

This is one of those things security people say that just does not jibe with reality. Everything in security is a trade off with usability, and not having your site on http, just for a redirect to https, is just completely not feasible.

Even if you are not listening on port 80, a MITM attack could just pretend to be you and listen on port 80.

This is probably missing because it's dead simple to solve on the application/infrastructure side by sending 302 or even 301 if you don't really miss the HTTP.

For things like that, that are very easily solvable other way I don't expect Amazon to work on them anytime soon, if ever.

It's easy to solve in the application, but then I need to have an http and https endpoint in my application, just for this redirect, already behind the ALB. I mean, if they can build in authentication redirects on the load balancer, how hard is it then to add a simple http -> https redirect, so this http traffic never has to 'touch' my application.

Well you don't need to have two listeners, you just need to check "X-Forwarded-Proto" header and if it's not "https" then do the redirect. I think checking that header is a good idea anyway for something sensitive.

Also if you use API GW/CloudFront they would do that for you too.

I think it's more likely that they want to differentiate LBs and CloudFront, feature wise.

It would make sense to do it in the load balancer, you want to do the redirect as soon as possible. So if you want to do it the correct way you get the option of paying for both ALB and CF.

I have spent all morning trying to get this to work. What seems to suck is your ALB will return an error with no details.

How does one go about getting authentication like this working in a development environment?

I do JWT token auth for apps as documented here:

https://github.com/nzoschke/gofaas/blob/master/docs/security...

In dev I run the same exact code and copy the JWT cookie from my production site.

Both dev and prod have the same secret to validate the cookie.

I wouldn't want to share keys like that. I'd also lose out on being able to modify my test account(s) with different groups/permissions that might not be in production yet.

You probably are well aware, but security wise that's a huge issue. If it's a hobby app, okay, but anything with actual users should separate keys. The main concern would be that dev keys are not considered secure and anyone with access to the dev key could then impersonate any other user of the production application.

Does Cognito still not support CAS for SSO? I'm not seeing any references to it via my google-fu.

Quite a number of institutions in my vertical have focused on CAS as opposed to other protocols, hence the ask.

I don't get why you'd use this over something like Python Social Auth which is debuggable, runs on any platform and lets you tweak it much much further :G

I assume it's for the same reason that people use services like Auth0 -- they don't want to waste development time programming all the fringe cases for authentication, when all they really care about is logging a user in and trusting that they are who they say they are.

Some benefits:

* Quicker to MVP

* Don't have to rewrite AuthX for each platform (web, iOS, Android, etc)

* Less worrying about the various permutations of 2-factor across all the applicable auth types (username, email, oauth, LDAP)

* Not having to figure out how to federate identity

* Not wanting the burden of GDPR/Privacy compliance in-app

etc.

There is a missing link in the demo after logging in. 2nd paragraph says...

> Click here to see what info was shared with this website after you authenticated.

This looks really interesting. On one of my sites I tried integrating Cognito and was not smart enough to get it working.

This seems fairly easy by comparison.

(Disclosure: Lead for AWS Amplify, amongst other products)

Try AWS Amplify (https://aws.github.io/aws-amplify/media/authentication_guide) to set up Cognito for your site. Let us know if it still didn’t work - we’d love to help.

Looks interesting. Although the example has a TTL of 7 days for the session cookie, which contains an identifier used by the service provider to uniquely fingerprint an individual user. Under GDPR, does all trace of a user have to be removed immediately on demand, even if this has been effectively delegated to something like the ALB?

Don't think it states anywhere that all trace of a user have to be removed immediately on demand.

Generally speaking you have 30 days to remove personal data (But there is a bit more to it than that).

A good overview is from the UK ICO: https://ico.org.uk/for-organisations/guide-to-the-general-da...

Also, it has to be technically feasible to remove the user data. So I don't think data stored on the client's own device is data that you necessarily should remove (though IANAL).

Reply on news.ycombinator.com