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.

In this post I’ll describe how to integrate Okta and your AWS account. In order everything to work, you’ll have to enable AWS Organization on the master account and then you can add multiple sub accounts in AWS.
Best practice says that the AWS master account should be used for SSO only and you shouldn’t run any workloads. First thing first, let’s start with Okta.

Okta

Log to your Okta account or sign up for a 30 day trial. Once logged in, if you haven’t already done so, change the sign-in domain from trail*-okta.com to your domain. Or you can skip this step.
Click on Admin from the upper right corner and then under Customizations, click on Domain. I’ve used the Okta-managed customization because it’s easier to manage.

After you click Next, you’ll be prompted to add two DNS entries for your domain.

Change the DNS. This will allow us to access Okta dashboard using our domain in my case it’s okta.andreev.it. From the same menu on the left, click on Applications, then Applications again and click on Browse App Catalog.

Search for AWS IAM and choose AWS IAM Identity Center.

Click on Add Integration and then Done.
Click on the Sign On tab and scroll all the way down to SAML Signing Certificates. Click on Actions drop-down and then View IdP metadata.

This will open a new tab with an XML file. Save the file as metadata.xml.

AWS

Go to console.aws.amazon.com and log with your root account. Go to IAM Identity Center and click on Enable and then select Enable with AWS Organizations.


Click on Settings on the left, then Actions drop-down and click on Customize AWS access portal URL. Change the URL so it’s something that you can easily remember, e.g. yourorg or aws-master.

Click on Settings on the left, then Actions drop-down and click on Change identity source.

Choose External identity provider and click Next.

You’ll land on a page with two parts, Service provider metadata (that’s AWS) and Identity provider metadata (that’s Okta).
Click on Download metadata file from upper right. You’ll need this in Okta. The file will be named with some date prefix and some characters plus metadata.xml
Copy the values for the 2nd and 3rd entry. You’ll also need these for Okta.

Click on Choose file under Identity provider metadata and upload the metadata.xml file that you’ve downloaded earlier from Okta.

Click Next, type ACCEPT and finally click Change identity source.

Okta

Go back to Okta, Sign On tab and right bellow click Edit. Enter the two URL entries that you copied from AWS. Click Save after.

AWS

Go back to AWS, then IAM Identity Center, click on Settings and click to Enable the Automatic Provisioning.

Click on Show Token and copy both values for the SCIM endpoint and the Access Token.

Okta

Go back to Okta and for the AWS app, click on Provisioning and then click on Configure API Integration.

Click Enable API Integration and enter the SCIM endpoint and the token value in the corresponding fields. Click Save. Remove the trailing slash from the end of the Base URL (SCIM endpoint) if you get an error (Base URL: Does not match required pattern)
Under Provisioning tab, click on To App, click Edit and select all three checkmarks. Click Save.

Then, go to Assignments tab and assign a group or a user to this AWS app.

AWS

Go back to AWS and under IAM Identity Center and then Users, you can see the user that we just assigned.

But this user has no rights in AWS, so we have to create a Permission set and then assign this user to that permission set and the account that this user has access to. Click on Permission sets on the left and then Create permission set.

I chose AdministratorAccess from the Predefined permission sets.

Go back to AWS accounts, click on the account and choose Assign users or groups.

Select the User tab, click on the user, click Next.

Select the permission set that we just created and click Next then Submit.

We just told AWS that the user xyz will have access to the account abc with AdministratorAccess permissions.

Test SSO

Open a new tab and go to the URL that you configured earlier (Customize AWS access portal). It should be https://whatever.awsapps.com/start.
AWS will redirect you to Okta where you’ll enter your Okta username.

Once authenticated, you’ll see the AWS accounts in your org and the permissions that you have.

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!

AWS Console has its own authentication/authorization directory using IAM users, roles and policies. On top of that, they also offer multi-factor authentication, so your logins are much more secure. But, I wanted to see how I can use Okta for SSO between my AD domain at home and AWS. The setup is very simple as you can see from this diagram.
On the left side, AWS is missing – but you get the point. In my case, I’ll have two AD groups, AWS Full Admin and AWS Read Only. I also have two AD users, admin.user and ro.user. If you haven’t integrated your AD with Okta it’s time to do so.

Okta

Go to the Okta dashboard and from the menu go to Directory | Directory Integrations.

Click on Add Active Directory and proceed so you can download an agent that you have to install on a member server with at least 8GB RAM. You can also install it on a domain controller, which I did in my lab, but I guess it’s not recommended. You’ll see this page telling you that Okta is waiting for your AD to connect.

Go ahead and install the agent. You’ll be prompted to specify the domain name (andreev.local in my case), create a service account OktaService or choose an existing one, choose a proxy to connect to Okta servers over HTTPS (if needed) and finally you have to specify your Okta domain, e.g. the prefix for your Okta landing page, https://company.Okta.com. You have to type -company-.

Once the service starts and authenticates with your Okta admin account to the Okta servers, your dashboard page will change asking you to specify what OUs in your AD you want to sync. Choose the OUs and choose your Okta username format.

In my case I’ll use UPN which is username@andreev.local, but you can choose e-mail if your have a valid e-mail specified for the users, e.g. username@google.com or the SAM account which is your login that you use for AD, e.g. username. See below.

Click Next and unless you have some non-standard AD attributes that you want to map, it’s safe to proceed with the defaults. Under the settings for the AD in Okta, you can choose the scheduled interval for the AD sync. By default, this sync is disabled. To test the integration, go to the settings page of your AD in Okta, choose Test Delegated Authentication (bottom right) and enter the username and password for an AD account that you know it’s synced with Okta.

You can also test the integration if you go to https://-company-.okta.com and log in with a synced AD user.

Okta app for AWS

Before we move to AWS part, click on Applications from the menu and click on Add Application menu. Type Amazon Web Services and select the app. Do not use AWS Console app, that’s a different one.

Click Add and you can leave the settings under General Settings or change it to AWS Console. Click Next and on the next screen, use SAML 2.0
Click on the Identity Provider Metadata link and download the file. You’ll need this for later.

Click Done and once this part is completed, we can go to AWS Console and configure AWS IAM and then come back to Okta.

AWS Console

Log to the AWS Console with an account with sufficient rights to create IAM polices, roles and users. Go to IAM and then Identity Providers on the left side. Click Create Provider and choose SAML for Provider Type, type a description (e.g. OKTA) and choose the metadata file that you’ve just downloaded.

Click on Next Step and then Create. Click on the entry that you just created and make a note of the ARN. You’ll need this later.

IAM

We’ll create two new roles based on existing AWS policies for full admin access and read only access. Go to IAM | Roles and click on Create Role. Click on SAML 2.0 federation, choose the SAML provider that we just created, select Allow programmatic and AWS Management Console access and click on Next: Permissions.

You can create your own policy if you want by clicking on Create policy or choose an existing one like I did by filtering the Read Only policies. Click on Next: Tags after.

You can tag your role and click Next: Review after…and finally you can create the role.

Do the same again IAM | Roles | SAML, but this time create a full admin role named rolFullAdminAccess (filter the policies by Administrator).
Let’s connect AWS and Okta now, but creating a user that will be able to list the roles. Go to IAM | User and click on Add user. Name your user and allow Programmatic access only.

Click on Create policy. This will open a new window. Do not close the previous one.

Click on the JSON tab and paste this policy. Then click Review policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
          "Effect": "Allow",
          "Action": [
              "iam:ListRoles",
              "iam:ListAccountAliases"
          ],
          "Resource": "*"
        }
    ]
}

Name your policy and click on Create policy.

Go back to the previous tab and click on the refresh button, right off the Create policy button. Then filter the policy and assign it. Click Next: Tags.

Proceed to create the user, but make sure you download the CSV file with the credentials for this user.

Okta – app config

Go back to Okta and click on the Sign On tab and then Edit.

Scroll down a little bit and paste your ARN value (the one that you got from AWS earlier) under Identity Provider ARN (Required only for SAML SSO. It’s under IAM | Providers | -your-provider in AWS. Click Save after.
Click on the Provisioning tab next to Sign On and click on Configure API Integration. Click the checkmark, then copy and paste the access key and the secret from the CSV file from AWS. Click Test API Credentials and if everything is OK, click on Save.

Under Provisioning make sure that Create Users and Update User Attributes are enabled.
Finally, go to the Assignments tab and select Groups. Then, click the green button Assign and choose Assign to Groups.

You will see your groups here, select the first one and click the Assign button.

You will see your roles there. Select the admin role and Save.

Do the same for the other group and role and pretty much you are all set. Open a new browser and this time log as one of the users, in my case I am logging as admin.user to https://mycompany.okta.com.

You’ll get a note that you have a new app assigned.

If you click on the app icon, you’ll get logged in to the AWS console without any passwords.

Multi-factor authentication

While the above setup looks good, you still need MFA to make things even more secure. Go to the app settings in Okta and click on the Sign On tab then click Edit.

Scroll all the way down and click on Add Rule.

Name the rule however you want and scroll all the way down.

Click on Prompt for fact and choose whatever you want from the settings.

Once configured, when you log in to your Okta dashboard, you’ll get in without prompted for MFA, but when you click on the AWS Console app, you’ll get redirected to AWS to configure your MFA. You can use the Okta mobile app for MFA or Authy which I prefer. This is because we configured the MFA to occur on the AWS level, not on Okta level.