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.

There is a newer version of this post but feel free to refer to this one in case you have any issues.
In this post, I’ll explain how to configure both Azure and AWS so when you log to AWS you’ll use your Azure AD credentials. In my lab, I have an Azure subscription and Azure AD (free tier). I also have a multi account AWS in AWS Organization structure. I want to be able to log to both Azure and AWS using the same Azure AD credentials. This way, I can use only Azure AD to control access to my cloud resources.
First, we’ll configure AWS for SSO. Log to your management/root account in AWS. Type sso in the search bar and choose Azure Single Sign-On.

Click on the button to Enable AWS SSO.

From the Dashboard, Choose your identity source.

You’ll be taken to the Settings pane. Click on Change under Identity source.

Select External identity provider and click on Download metadata file.

In Azure, go to Azure Active Directory and from the left, click on Enterprise applications.

Click on New application.

Search for AWS Single and choose AWS Single Sign-on. Make sure you choose this one if you have multi accounts in AWS. The setup is slightly different for the other single account access.

Click on the Create button on the right and wait for about 30 seconds. When this screen shows up, click on Single sign-on.

Choose SAML from the choices.

When this screen shows up, choose Upload metadata file.

Select the file that you just downloaded from the last step you did previously in AWS. You don’t have to do anything, just click Save and then close the blade on the right.

You’ll get something like this, just click there as instructed to fix it.

If you are asked if you want to test the SSO, just ignore the message and click on, No, I’ll test later.

Scroll down a bit to step 4 and click on Install the extension. This is the easiest way to do this. You can go the manual way, but it’s not worth it. Don’t worry, you can always remove the extension after. It’s for a one time setup. I use Firefox and it works fine, which means it will definitely work on Chrome and Edge.

Once you install the extension, click on it in the upper right corner.

Click on Sign in to get started button.

You should be automatically signed if you have the Azure session open in another tab. You’ll see something like this if everything is OK.

Click on the button Set up AWS Single Sign-on under step 5. Azure will prompt you to save the federation XML file and just click OK for the Azure prompt.

Azure will open a new AWS tab and ask you to confirm if it’s OK to make changes in AWS. Click OK.

You’ll see some action on the screen like someone clicks in your browser. Don’t do anything. Just click Yes or OK when asked.

The extension will ask you to upload the federation XML file from Azure that you saved earlier and then it will reconfigure AWS and you should see this at the end.

You’ll end up at the initial screen for step 1 in Azure. Just click Save and you are OK.
Now, if you don’t have any users or groups in Azure AD, go create some. In my case, I use free Azure AD so I am not gonna be able to use groups. It requires Azure AD P1 which is not free. But, I’ll show you how to assign a user in Azure AD. If you use Azure AD Connect to sync your on-prem AD with your Azure AD, you can choose that user as well. With your AWS Single Sign-on app selected, click on Users and groups.

Click on Add user/group.

As I mentioned earlier, I can’y choose groups because of my Azure AD free tier, so click on None Selected.

Select the user and just click Assign at the bottom.

I’ve assigned this guy from Azure AD (awsadmin). Just click on Provisioning on the left. We have to sync these users to AWS now.

Click on Get started and choose Automatic.

You’ll have to provide a Tenant URL and a Secret Token.
Go back to AWS, then SSO, click on Settings and click on Enable automatic provisioning under Provisioning.

Click on Show token. Copy both values on the clipboard, those are the Tenant URL and the token needed for Azure. Copy and paste them in Azure.

Click Test Connection and make sure you get OK as a result. Click Save.

You’ll be back here. Click on Edit attribute mappings.

Change the Provisioning status to On and click Save.

If you close that blade, you’ll see that one user synced successfully.

Go to AWS and under Users you’ll see the same user. Yay!

OK, if you look at the User portal, you’ll see the URL for your Single Sign-on. You definitely want to customize the URL to suit your needs.

Go to that URL, but use a separate browser or some private mode, so you don’t affect any open sessions. You’ll be redirected and prompted to log with your Azure AD. You might get a prompt to configure MFA, skip it for now, you can always configure it later.
This is what you’ll see.

But we assigned AWS app in Azure to this user. What’s going on?

Just go to AWS | SSO | AWS Accounts, select the accounts that you assign to a user and click Assign users.

Select the user (in my case awsadmin) and click Permission sets.

Click on Create new permission set. This will open a new tab.

This is where you assign permission to that user or group (if you have license). Use the second option for custom policies, e.g. access to only a set of S3 buckets or assign tagging policies only. I’ll use the first option for the pre-made policies. Click on Details.

I’ll use the Administrator access. Click Tags to proceed.

Finish the rest and go back to the first AWS tab. On the right click the Refresh button.

The permission set should show up. Select and click Finish.

If the permission set doesn’t show up, don’t worry. Repeat the same same procedure from the AWS accounts menu to select accounts and users and you’ll see that this time the permission set will show up.
Finally, go to the same URL where nothing showed up when we logged with that awsadmin user. Click Refresh in the browser and you’ll see the accounts now.

Click to log to the Management Console and you are all set!

In this post I’ll describe how to connect/integrate your on-prem domain with Azure AD and enable SSO. So, when you want to log to your Office 365 subscription or access your Azure resources, you can just type your username and you’ll be logged on without being asked for a password. In order to do that there are some prerequisites. First, you will need admin access to both your on-prem local Active Directory and your Azure AD subscription. I am using Office 365 so I have Azure AD already and my on-prem domain controller is Windows 2012R2. If you are using Azure cloud, you should also have Azure AD. The trial version is also supported. Second, the SSO works only for devices joined to the domain. IE and Chrome are supported, Edge is not. The process below explains how to do this with a single AD forest. If you have multiple domains and forests, read the links all the way at the bottom.

The on-prem AD server needs to be able to talk to Azure AD.

Add custom domain in Azure AD

Go to Azure AD and on the left side click on Azure Active Directory and then click on Custom domain names.
Click on Add custom domain on the top.

Enter the name of your public domain and you’ll get some instruction on what to do next. Pretty much, you have to create a TXT record in the DNS for the public domain that you want to use.

It might take some time. My DNS is with godaddy and it took about 10 mins. Just wait for 5-10 mins, click Verify and the domain should show up as Verified.

On-prem change

As I said earlier, the SSO won’t work with your local domain user name. You will have to change it to be with a public domain suffix. For example, if my on-prem username is kliment and the UPN is kliment@domain.local, I have to change that to be kliment@public-domain.com. You can do that by adding the public domain in AD. On the domain controller, open up Active Directory Domains and Trusts, right-click the top item and click Properties.

Add your public domain that you just verified in Azure AD.

Now, open up Active Directory Users and Computers and change the UPN for a test user so the public domain is visible, not the local one.

If you need to change the UPN using a script, look at this link all the way at the bottom.

Azure AD Connect

On a PC or a domain controller that’s joined to the local domain, download and install Azure AD Connect from their official site. Enter the admin credentials for your Azure AD subscription.

Enter the admin credentials for your on-prem AD.

Make sure your domain shows up here and says Verified. Click on Continue without any verified domains.

At the end you’ll see this. Click Exit.

Give it some time for the initial sync to complete. This might take some times depending on the size of your AD. I have only a couple of users on-prem, so the sync took about 5 mins or less. Once it’s complete, launch the Azure AD Connect again and click on Change user sign-in.

Click on Enable single sign-on and click Next. You’ll be prompted to enter your on-prem admin password again.

At this point you should be able to log in. Just go to portal.office.com if you have an Office 365 subscription or portal.azure.com for Azure and once you enter your e-mail address as a login, you’ll be able to log in.

Tips

If your username for the Azure AD is the same as an on-prem user, you’ll have problem syncing. The easiest way is to not change the UPN for that user. Or you can create a separate OU and not sync that OU with the AD Connector. If you have a conflict, you’ll get an email that looks like this.

In AD connector, go to Customize synchronization options.

Then uncheck the OU that you don’t want to be synchronized.

In case you want to remove the domain, you’ll have to remove the users first. But in order to remove the users, you’ll have to stop the sync. Uninstalling the AD Connector won’t help. So, download PowerShell for Azure Active Directory and execute these lines.

Connect-MsolService
Set-MsolDirSyncEnabled –EnableDirSync $false

You have to wait quite a while, in my case about 30 mins. You can check if the sync is disabled by doing:

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

Once you get false as an output, you can delete the users and the custom domain.

Useful links

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-quick-start
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect
https://support.office.com/en-us/article/how-to-prepare-a-non-routable-domain-such-as-local-domain-for-directory-synchronization-e7968303-c234-46c4-b8b0-b5c93c6d57a7
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso