AWS’ API Gateway v2 (aka HTTP APIs) launched in December 2019, and came with a built-in ability to add JWT authorizers to endpoints. We use AzureAD as our Auth vendor, so I’ve been waiting for a chance to try this out. Finally got an opportunity.
AWS’ Application load balancer supports OIDC authentication, but I couldn’t find a single document that shows how to configure this to work with AzureAD auth.
As I prepare for my baby sabbatical, there’s been a lot of planning of things to be worked on and accomplished while I’m away. On that note, I did a little thinking on a “wish list” of technical things I’d like to see from some of our infrastructure vendors in 2019:
Like many, I’ve been looking for a way to deploy containers in our environment securely and efficiently with a minimal amount of fuss. After taking a hard look at Kubernetes, I came to the realization it might be a little too complex to roll out in our environment, so I started looking at Consul + Nomad. I’m currently using Terraform and Vault heavily in our environment, and I’m pretty comfortable with the HashiCorp way of doing things, so this seemed like a good option.
We have a few NodeJS APIs we’re looking to protect with AzureAD, our chosen identity solution. We ended up picking the ADAL JS library from Microsoft for the client-side of our app, and PassportJS + passport-azure-ad for the back end authentication.
At our org, we’re pushing hard into converting some of our existing applications to utilize serverless technologies, and specifically Lambda + API Gateway. While we normally use Terraform to deploy our infrastructure into AWS, the amount of code required to get Lambda + API Gateway integrations deployed was really a showstopper for us - just absolutely brutal. So we embarked on looking at a number of tools to see if we could find a better way.
AWS recently released support for deploying to S3 with CodePipeline https://aws.amazon.com/about-aws/whats-new/2019/01/aws-codepipeline-now-supports-deploying-to-amazon-s3/.
We use Cloudfront Signed Cookies (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html) to provide secure access to JSON documents stored in S3. The cookies are provisioned by a small webservice that was initially rolled out for a single web application (a great topic for another blog post), but was found to be so useful we used it for a bunch of apps. Unfortunately, we quickly ran into the “cross domain cookie” issue, where the browser will silently drop cookies set via AJAX from a subdomain unless requested with withCredentials, which subsequently requires that the origin not be set to “*”. Here’s how we solved that with our NodeJS microservice.
Like many people, we have an AD implementation that has undergone a number of refactorings over the years, resulting in permissions delegated and applied at various levels. Troubleshooting things like what permissions a user or group has access to always seems like a pain - the AD GUI it not great at showing a quick summary of the discrete permissions for a particular account.
Our team has decided to embark on a conversion process, where we’re planning to migrate a NodeJS + MongoDB API running in EC2 and surfaced via API Gateway to a new Serverless NodeJS using Lambda, DynamoDB, and API Gateway.
NOTE: This assumes that you already have a functional and tested CodeDeploy process built out, and a branch that you want to push with CodeDeploy (i.e. AddCodeDeploy in this example).
I had a hell of a time trying to get Github Pages going with the Jekyll support. The basics are pretty easy to get going, but I couldn’t get some of the more “advanced” features going without digging around. This is my attempt at documenting some of those learnings.