HTTP Basic auth support

[andybee]

This is neither bug nor feature request, but it was suggested in the Slack channel to post this as an issue for further discussion.

The requirement I'm trying to solve is that a client wants to protect their staging environment in such a way that their distributed team can relatively easily open up the staging URL and authenticate to see the web app. What makes matters a bit tricky is that the web app has a classic auth layer built-in (form submission, cookie returned) that needs to remain part of the testing environment with another wrapper over the top.

The easiest idea I had was to wrap the whole thing with HTTP Basic Auth based on NODE_ENV being staging. Worked great in Sandbox, failed when deployed to AWS because the path between Lambda, API Gateway and CloudFront out to the web means the outgoing WWW-Authenticate header is rewritten.

I came up with a few alternative approaches:

• Remove the challenge aspect and just use credentials in URLs - passing user/pass in the address bar or via a link doesn't seem to work in Safari/Chrome/Firefox, presumably because it doesn't see the challenge so refuses to forward the credentials.
• Custom Authorizer - still can't send the challenge 'WWW-Authenticate: Basic'?
• Lambda@Edge - I can't see a way to set up a function for the hidden distribution that API Gateway sets up?

Only alternative I can think of is just coding up a second level of the classic auth within the codebase, just not a huge fan of writing more code than I need to and in such a way that it will be bundled (but not executed) in all environments.

To try and reach a form of conclusion: have I missed something with my attempts or are there any pointers on how some of the bits I hit a blocker with can be overcome? Is this a solved problem in a different way?

[ryanblock]

have I missed something with my attempts or are there any pointers on how some of the bits I hit a blocker with can be overcome? Is this a solved problem in a different way?

What I'm not clear on is: why not just use a header that isn't overwritten by AWS, such as authorization? The various auth systems we've built with Architect over the years are nothing special and very little code.

Otherwise this issue is fairly fuzzy for me – is this a bug? A feature request? (If it's a bug, what is the problem? If it's a feature request, what is the requested feature?) If the issue is to ask best practices for building serverless auth, over at Begin we wrote a guide for auth with Oauth (https://learn.begin.com/basic/state/oauth), although it sounds like given your credential form posting, this may not be what you're looking for.

[andybee]

Apologies for the Friday evening rambling, let me try and tackle your follow ups with more clarity.

why not just use a header that isn't overwritten by AWS

I'd really like to use basic auth so that less technical users can simply visit the URL and get the user/password prompt from their browser. This requires WWW-Authenticate to be set. The reason I'm using this on top of a standard auth mechanism is that the website I'm trying to stage uses that for normal usage and will use that in production, but I need to layer on a total access block for staging as the product isn't public yet and the client wants to get in to staging, then use it like a normal user (e.g. some pages are public / some behind a login, basic auth gets to the home page, with a login form, login via a POST, cookies, tokens, the usual shebang).

is this a bug? A feature request?

Both and neither 🙃. Having been bitten by the behaviour difference in Sandbox vs API Gateway, I've added a feature request (#879) to capture that.

But when noodling the issue in Slack on Friday, I reached the point of considering Lambda@Edge to write the remapped header back, but struggled to see how you can setup Lambda@Edge against the "hidden" CloudFront distro that API Gateway manages for you. @brianleroux mentioned raising this as an issue as @ryanblock had some experience with Lambda@Edge and Architect.

To update you where I've got to since this, I've got the basics working by introducing an Authorizer and creating a macro to deploy that within the Arc realm. However, I'm aware that with a future move to the HTTP variant of API Gateway we lose the ability to use custom authorisers, so an alternative plan would be useful.

If we can work out a good way of tackling this, I'm interested in spinning it out in to an open macro anyone can use to secure a staging environment external of anything the app itself does for auth, I feel that must be useful to someone other than just my use case...?

[exalted]

@andybee yes, if you could please share the macro you created, I'd love to reuse that for the time being.

Also, I wasn't aware of custom authorizers not being available in HTTP variant of API Gateway are there any docs on that please?

Also also, in your original comment you said:

Custom Authorizer - still can't send the challenge 'WWW-Authenticate: Basic'?

But then you managed to create a custom authorizer via a macro I assume, so above statement is obsolete?

Thanks.

[andybee]

I've not actually built the macro yet, but it shouldn't be too tricky to get in to shape - I'm just worried about releasing something I know will break once Architect ports over to HTTP API Gateway. Struggling to find an easy thing to link to show that issue, but here's a screenshot when you try and add an authoriser to an HTTP API Gateway:

The last bit about not setting the header is obsolete, you can do it but only from an Authorizer.

Having a way to do Lambda@Edge still feels like the best possible solution post move to HTTP.

[ryanhyslop]

@andybee i don’t suppose you got anywhere with this?

I’m coming to architect via remix.run (having previously done aws deployment via terraform and ECS fargate) so it’s all a little bit new. We were looking to put some Basic Auth on our remix app as a ‘quick’ way to secure it temporarily but alas it’s not seeming that straight forward. If anyone has any pointers it would be greatly appreciated.

[andybee]

I ended up creating a middleware layer that is used in each handler and observes ARC_ENV to see if it's staging or not. The middleware has 2x roles:

1. Checks for a lack of valid token cookie and presents an HTML login page
2. Handles the POST that comes back from that form to auth and issue a cookie

It's not elegant and was more work than I hoped, but the alternative options to do Basic Auth were a pain on the AWS side.

[brianleroux]

this is elegant imo! will work forever, no third party libs, classic pattern. chasing cognito would be 100X LOC at least.

what would be more elegant ?

[andybee]

I meant compared to a middleware that throws out an WWW-Authenticate response and parses an Authorization header in a request, avoiding the need to write any HTML.

If there's interest, I could try and spin it out in to a plugin.