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.
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.
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.
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?
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.
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.
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.
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?
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).
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.
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.
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
43 comments
[ 3.3 ms ] story [ 102 ms ] threadI 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.
This seems fairly easy by comparison.
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.
[1] https://cloud.google.com/iap/
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.
For things like that, that are very easily solvable other way I don't expect Amazon to work on them anytime soon, if ever.
Also if you use API GW/CloudFront they would do that for you too.
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.
The default connection to your web server should be HTTPS, not HTTP. HSTS is an option to set this up properly.
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.
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/
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.
> 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.
[0] https://caniuse.com/#feat=stricttransportsecurity
checkmate
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...
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 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...
> Click here to see what info was shared with this website after you authenticated.
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.
Quite a number of institutions in my vertical have focused on CAS as opposed to other protocols, hence the ask.