Microsoft Azure AD authentication for CloudFront using Lambda@Edge.
This project is based on Widen/cloudfront-auth, but has diverged in the following ways:
- Stripped down to focus on Microsoft Azure Authentication and Authorization only.
- Webpack config added to bundle the handler and dependencies in to a single file.
- A zip of the bundled lambda (sans
config.json) is released via a GitHub Action for use in downstream IaC projects like terraform-aws-lambda-edge-azure-auth.- Simple URL (a.k.a pretty URLs) handling for default
index.htmland trailing slash redirects (see below).- Downstream terraform module for deployment (terraform-aws-lambda-edge-azure-auth).
Upon successful authentication, a cookie (named TOKEN) with the value of a signed JWT is set
and the user redirected back to the originally requested path. Upon each request, Lambda@Edge
checks the JWT for validity (signature, expiration date, audience and matching hosted domain) and
will redirect the user to configured provider's login when their session has timed out.
If your CloudFront distribution is pointed at a S3 bucket, configure origin access identity so S3 objects can be stored with private permissions. (Origin access identity requires the S3 ACL owner be the account owner. Use our s3-object-owner-monitor Lambda function if writing objects across multiple accounts.)
Enable SSL/HTTPS on your CloudFront distribution; AWS Certificate Manager can be used to provision a no-cost certificate.
Session duration is defined as the number of hours that the JWT is valid for. After session
expiration, cloudfront-auth will redirect the user to the configured provider to re-authenticate.
RSA keys are used to sign and validate the JWT. If the files id_rsa and id_rsa.pub do not
exist they will be automatically generated by the build. To disable all issued JWTs upload a new
ZIP using the Lambda Console after deleting the id_rsa and id_rsa.pub files (a new key will
be automatically generated).
- Clone or download this repo
- In your Azure portal, go to Azure Active Directory and select App registrations
- Create a new application registration with an application type of Web app / api
- Once created, go to your application
Settings -> Certificates & Secretsand make a new client secret with your desired duration. Click save and copy the value. This will be yourclient_secret - Click on Overview, go to
Redirect URIsand enter your Cloudfront hostname with your preferred path value for the authorization callback.Example:
https://my-cloudfront-site.example.com/_callback
- Execute
./build.shin the downloaded directory. NPM will run to download dependencies and a RSA key will be generated. - Choose
Microsoftas the authorization method and enter the values for Tenant, Client ID (Application ID), Client Secret (previously created key), Redirect URI and Session Duration - Select the preferred authentication method
- Azure AD Membership (default)
- JSON Username Lookup
- Enter your JSON Username Lookup URL (example below) that consists of a single JSON array of usernames to search through
- Upload the resulting
zipfile found in your distribution folder using the AWS Lambda console and jump to the configuration step
Manual Deployment or AWS SAM Deployment
This lambda function has some options that enable CloudFront to behave similar to to most static
site web servers. When CloudFront is backed by a private S3 bucket using an OAI (Origin
Access Identity), default index.html files are not resolved unless given explicitly in the url
For example, a request for https://example.com/about/ tries to retrieve an object about/ in
the bucket, not about/index.html)
With the simple_urls_enabled option enabled (defaults to true):
https://example.com/about/will return thehttps://example.com/about/index.htmlobject
With trailing_slash_redirects_enabled:
https://example.com/aboutwill trigger a301redirect tohttps://example.com/about/
Detailed instructions on testing your function can be found in the Wiki.
See CONTRIBUTING.md.