In this post I’ll explain how to configure a static web app in Azure and put the app behind Entra ID (Azure AD) SSO authentication. You’ll have the same protection as logging with your Entra ID credentials to Azure and Office 365. There is no need for any code change in the app. As long as you are an user or a member of an Entra ID group assigned to the Enterprise Application, then you can access the Static Web App URL. I’ll use Azure DevOps to host the files for the web site, but you can use any other repo.

Azure DevOps

Log to your ADO organization and create a new project. I called mine Static Web App. Click on Initialize and then copy the path so you can clone it locally.

Once cloned, go to the repo locally and you’ll see a README.md file. Clone this web site template or just create an index.html file.

git clone https://github.com/designmodo/html-website-templates.git

Then move the index file back to the root of our repo.

mv html-website-templates/Animated\ Landing\ Page\ Website\ Template/* .
rm -rf html-website-templates/

You should have the index.html file in the root of our repo. Push to ADO.

git add .
git commit -m "Updated website"
git push

Azure Static Web App

Log to your Azure subscription and create or use an existing resource group. I’ll call mine rgStaticWebApp. Go to the Static Web Apps menu and create a new Static Web App. Specify a subscription, a resource group and name it. In my case it’s called mystaticwebapp.

Make sure you choose the Standard hosting plan. SSO won’t work with the free plan. Choose the repo location, the branch and HTML for Build Preset.
Use the defaults for the rest and click on Create. The static web site will be deployed in 5-10 seconds and if you go to the resource, click Overview, you’ll see the URL of your website. Go to that URL and you’ll see our website is public.

Custom domain (optional)

In case you want a custom domain, then these changes are required. This is not a requirement for the SSO, but it’s better if you have your own domain URL.
Click on Custom Domains and then choose where is your domain hosted. In my case I have it with CloudFlare.

Enter how you want to access your website, in my case it is mysite.andreev.it.
You’ll have to create a CNAME in CloudFlare.

Do not proxy it thru CloudFlare for now.

Click on Add at the bottom and it might take some time for Azure to verify the new CNAME record. In my case it took less than a minute.

…and if you go to whateveryou.namedyour.site, you should see the same static web page.

Entra ID (Azure AD) SSO

In order to add SSO, we have to add a file in the root of our static web site and then make some changes in Azure. Refer to this link for more information.
Create the following file in the root of the static web site and name it staticwebapp.config.json. It has to be this name.
This is what the file looks like.

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  },
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/TENANT_ID/v2.0",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "AZURE_CLIENT_SECRET"
        }
      }
    }
  }
}

We need 3 values. The first value, TENANT_ID needs to go to this file hardcoded and the other two values for the CLIENT_ID and CLIENT_SECRET will be added in Azure. Here is how to fine these values. Go to Entra ID and click Overview. This is your TENANT_ID value. Copy and paste that value in line 18 and save the file. After, git add/commit/push the file back to Azure DevOps repo.

Go to App Registrations and click on New registration.
Enter these values and click Register. Replace the URL with yours even if it’s not a custom domain. Add .auth/login/aad/callback as a suffix.

The app registers right away and if you click the Overview you’ll see the app client ID. Copy this value in notepad or somewhere.

From the menu on the left, click Certificates & secrets and then click on New client secret.

Name the secret and choose for how long it’s valid.

You’ll see that a secret has been created and you’ll have a value and a secret ID. Copy the value not the ID in notepad or somewhere.
Now, go to the Static Web App and click on Environment variables. Add both AZURE_CLIENT_ID and AZURE_CLIENT_SECRET and click Apply at the bottom.

Finally, go to App Registration, find your app there, click Authentication on the left and make sure that ID tokens option is checked.

Now, if you go to the URL of the app, you’ll be prompted to log in and after successfully logging in, you’ll see our static web page. But every user from your tenant can log in, the only restriction is that you are member of the Entra ID tenant. If you want to restrict the website only to specific people, do the following. Go to Enterprise Applications, find your application and click on Properties. Make sure Assignment required is set to Yes. Click Save on top.

Then, click on Users and Groups and assign a group or users to the app. Mind that if you use the free version of Entra ID, you won’t be able to assign groups, only users.

I wrote about this topic a couple of years ago, but some things changed so I am writing this post again. In this post I’ll explain how to log to AWS Console and AWS cli with Entra ID (former Azure AD) credentials. For this you’ll need admin access to both the AWS account and Entra ID.

IAM Identity Center

The former AWS Single Sign-on is now IAM Identity Center. You need to enable this in order to configure SSO. Go to IAM Identity Center and click on the Enable button.

Enable it with AWS Organizations.

What you want to do first is to change the AWS access portal URL. Click on the Edit button and change the URL. It has to be unique, so don’t expect you can type aws and be done with it.

Another setting that you have to change is the Identity source. On the left side of the IAM Identity Center, you are on the Dashboard screen. Click on Settings and then click on Change identity source.

Choose External identity provider and click Next.

You will see this screen which consists of two parts, service provider metatada (that’s AWS) and Identity provider metadata (that’s Entra ID). Click on Download metadata file. You’ll get an XML file.

Keep the page open and in a new browser window go to portal.azure.com.

Entra ID

Once logged to Azure, go to Enterprise Applications and search for AWS IAM Identity Center (successor to AWS Single Sign-On). Click to install. When you are presented with the Overview of the application, click on Assign users and groups. Depending on your Entra ID level (P1 or P2) you might not be able to assign groups, so you have to assign users.

The next step is to setup the SSO. Click on 2. Set up single sign on and then SAML. You’ll be presented with this page and eventually you’ll see a prompt if you want to save some SSO settings. If you don’t see the prompt, no worries. If you see the prompt, click Yes.

Click on Upload metadata file and point to the XML file that you saved from AWS. Click Save and don’t worry about any of the fields there. If you see a popup to test the config, just click No, I’ll test later. Under step 3, SAML Certificates, click to Download Federation Metadata XML.

You’ll get another XML file called AWS IAM Identity Center (successor to AWS Single Sign-On).xml.

Back to AWS

Go back to the same page where you’ve downloaded the XML metadata file, but this time look at the bottom part where it says Identity provider metadata and IdP SAML metadata. Click on Choose file and upload the file from Azure. Click Next, type ACCEPT and click Change identity source.
Once completed click to Enable Automatic provisioning. Copy the SCIM endpoint and the access token.

Back to Azure

Under the AWS SSO application. on the left side click on Provisioning. Change the Provisioning Mode to Automatic. Expand Admin credentials and for Tenant ID enter the SCIM endpoint and for Secret Token, enter the token. Click Test Connection and upon successful test, click Save. If you see clientsecret instead of Tenant ID, it means you are not using the right AWS application and you use the AWS Single Account application instead. Start from scratch.
Anytime you assign a new user or a group to AWS application, Azure will sync the user to AWS. But, instead of waiting (40 mins by default) for the initial sync, click on the Overview and click Start provisioning.

Back to AWS

If your provisioning works fine, you’ll see your assigned Azure user under Users in IAM Identity Center. On the left side of the IAM Identity Center, click on Permission sets. Click Create Permission set and choose Predefined permission set, then AdministratorAccess. Change the name, description, session duration if needed and then click Next and then Create.
Finally, click on AWS accounts, select an account from the organization, click Assign users or groups, click Users or Groups, select a user and click Next. Assign a permission set, click Next and Submit.

Now, test the SSO by going to whatever.awsapps.com/start# and you’ll be redirected to the Microsoft sign in prompt. Follow the authentication process for Entra ID (username, password, MFA etc) and once you pass the authentication process you’ll see the AWS account that you have access to.

AWS CLI and SSO

Follow the instructions to install AWS CLI for your OS, then configure SSO. Name your session, enter the URL you configured earlier, enter the region where you configured SSO and hit enter for the registration scopes.

aws configure sso
SSO session name (Recommended): sso
SSO start URL [None]: https://your_url.awsapps.com/start
SSO region [None]: us-east-1
SSO registration scopes [sso:account:access]:
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://device.sso.us-east-1.amazonaws.com/

Then enter the code:

PWKG-CAFZ

After successful authentication, you’ll be presented with the accounts available to you. Pick one.

You’ll be prompted to choose the roles available to you and then specify your default region, default output and the profile. \
NOTE: If you’ll be working with multiple accounts, maybe you should specify a different profile than the default. It’s up to you. E.g. specify prod and dev profiles.

There are 2 AWS accounts available to you.
Using the account ID 123456789012
The only role available to you is: AdministratorAccess
Using the role name "AdministratorAccess"
CLI default client Region [None]: us-east-2
CLI default output format [None]: json
CLI profile name [AdministratorAccess-123456789012]: default

To use this profile, specify the profile name using --profile, as shown:

aws s3 ls --profile default

After your SSO session expires, you have to log back in.

aws sso login

If you are like me and always uses the default profile so I don’t have to type –profile parameter, then anytime you want to use a different account, just aws configure sso again, but specify the other account now.