--- Sjoerd Hooft's InFormation Technology ---

User Tools

Site Tools


Recently Changed Pages:

View All Pages

View All Tags


WIKI Disclaimer: As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.
Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.

Pages with comments

View All Comments


Federated Login for AWS with Azure AD

After Getting Started With AWS and Getting Started With Office 365 I now also want to login to the AWS console using Azure Active Directory. This article describes the steps to do so. Used technologies:

  • Azure AD
  • Azure AD Enterprise App

Note that the goal here is to keep user provisioning in Azure Active Directory, something that is already common for many organizations and that I don't want to create users in AWS IAM. I just want to login to AWS using the original account.

Azure Active Directory

We start with configuring the Azure AD part.

Create Groups in Azure

First we want to create groups in Azure AD so users with privileged access can become a member and have access based on their group membership.

Note that you need Azure AD Premium to assign Azure AD groups to an Enterprise App which we'll create later on. I don't have that (yet - because of the costs), so even though I am creating them here I won't use them later on. If you have an Azure AD subscription which allows you to use group membership in Enterprise Apps I highly recommend doing so.

Follow these steps to create Azure AD groups:

  • Log into the azure portal with the office365 global administrator account we created earlier
  • Go to Azure Active Directory → Groups
  • Create the group as described in the table below, note that I'm right now creating only two groups, both with the same account as a member. When you start adding multiple accounts you should name your Azure AD groups accordingly to separate them from each other.
Group name Group / Role description Group type Membership type Members AWS Role AWS Permissions
awsadmins AWS Administrators Security Assigned Sjoerd Hooft ( AccountName-AWSAdmin AdministratorAccess
awsreaders AWS ReadOnly Security Assigned Sjoerd Hooft ( AccountName-AWSReadOnly ReadOnlyAccess
Note that the AWS columns can be ignored for now, and that the AWS Role Name is the only easy way to separate different roles for a user, so include the accountname.

Create Enterprise Application in Azure

Now we need to create an Enterprise App in Azure. This way the AWS Console App shows up in the myapps page for users with access.

  • Log into the azure portal with the office365 global administrator account we created earlier
  • Go to Azure Active Directory → Enterprise Applications → New Application
  • In the “Add from the gallery” section search for “Amazon Web Services (AWS)” and select the Application
  • In the new blade keep all the default settings and click “Add”. Wait for the application to be added. When done, the overview page of the AWS Application will open.
  • In the “Amazon Web Services (AWS) - Overview” page go to “Single sign-on”, and Select SAML as your single sign-on method by clicking on the tile
    • Keep Section 1, Basic SAML Configuration, default, AWS is pre-integrated so you do not need to change this
      • Note that both the identifier and reply url should be filled in as
    • Edit Section 2, User Attributes & Claims, by clicking on the edit icon, and add the two attributes from the table below by clicking on “Add New Claim”
      • Go back by closing the User Attributes & Claims blade
    • Edit Section 3, SAML Signing Certificate, by clicking on the edit icon, and create a new certificate by clicking the “New Certificate” link
      • Fill in a valid notification email address, and click save.
      • Click the three dots on the right to activate the certificate.
      • Go back by closing the SAML Signing Certificate blade
    • In Section 3, SAML Signing Certificate, you can now download the “Federation Metadata XML” file by clicking the link.
Claim Name Value Source Attribute Source Namespace User.userprinciplename Attribute empty User.assignedroles Attribute empty 43200 Attribute empty
SessionDuration: provide a value between 900 seconds (15 minutes) to 43200 seconds (12 hours)
Depending on the version and interface you're using the names of the different fields such as Name/Claim Name may differ. Please use the screenshots below of both the new interface as the old one to verify your settings:

New interface:
Old interface:


During my configuration I ran into a problem. Microsoft switches the experience for the Enterprise Application SAML Single Sign-on to a new one, changing the look and feel compared to when I done this previously in the past. Still, all information was still valid and everything still worked the way I expected. However, when trying to log start the Amazon Web Services (AWS) from the myapps page I was asked to fill in the AWS account number and my credentials. Something was not right, so after checking all settings I decided to check the old experience, and I noticed that in the advanced URL setting the Identifier (Entity ID): field got automatically updated with “”. I saved this and tested the SAML connection by using the “Test SAML Settings” button and I got a success back. Now the myapps application worked as well.

Note that it kept working after switching back to the new experience.

Amazon Web Services

We now continue with AWS.

Create AWS Identity Provider

We must now set Azure AD as an Identity Provider with AWS IAM:

  • Log in to the account you want to federate with your root account and go to the IAM service
  • Go To “Identity Providers” and click “Create Provider”
    • Provider Type: SAML
    • Provider Name: AzureAD
    • Metadata Document: Select the “Federation Metadata XML” you downloaded in the previous step
    • Click Next Step and Create to finish creating the provider
  • When the provider is created click on the name to see the details and note the ARN, as you will need it later: arn:aws:iam::accountnr:saml-provider/AzureAD

Create Roles

  • Still in the IAM service, go to Roles and click “Create Role”
    • Type: SAML 2.0 Federation
    • SAML Provider: AzureAD
    • Allow programmatic and AWS Management Console access
    • Click “Next:Permissions”
    • Attach Permissions as in the table above
    • Click “Next: Tags” and “Next: Review”
    • Role Name and description as in the table above
  • When the role is created click on the name to see the details and note the ARN, as you will need it later: arn:aws:iam::accountnr:role/AWSAdminsInAzureAD & arn:aws:iam::accountnr:role/AWSReadOnlyInAzureAD

Set Duration for CLI/API Duration

In case you want to allow accounts accessing AWS using CLI and or the API to have a longer session duration than 1 hour, change the “Maximum CLI/API session duration” to your needs as it is only 1 hour by default. You can find this setting at the default summary page of your role.

Repeat for Accounts

Note that you have to repeat creating an Identity Provider and Roles for every account you want to enable for federated login.

Azure Active Directory

Add AWS Roles to Azure AD Enterprise Application

This is where the two worlds come together. Now we integrate the AWS roles into the Azure AD Enterprise Application:

  • Log into the azure portal with the office365 global administrator account we created earlier
  • Go to Azure Active Directory → App Registrations → Select the “Amazon Web Services (AWS)” Application (make sure the app selector is set to “all apps”)
  • Click Manifest and click Edit to edit. Start by making a copy of the default:

Default Manifest:

"appId": "16a70ec9-1e72-49f4-8c9e-d07e913df89a",
"appRoles": [
"allowedMemberTypes": [
"displayName": "msiam_access",
"id": "7dfd756e-8c27-4472-b2b7-38c17fc5de5e",
"isEnabled": true,
"description": "msiam_access",
"value": null
"availableToOtherTenants": false,
"displayName": "Amazon Web Services (AWS)",
"errorUrl": null,
"groupMembershipClaims": null,
"optionalClaims": null,
"acceptMappedClaims": null,
"homepage": "|ISV9.1|primary|z",
"informationalUrls": {
"privacy": null,
"termsOfService": null
"identifierUris": [
"keyCredentials": [],
"knownClientApplications": [],
"logoutUrl": null,
"oauth2AllowImplicitFlow": false,
"oauth2AllowUrlPathMatching": false,
"oauth2Permissions": [
"adminConsentDescription": "Allow the application to access Amazon Web Services (AWS) on behalf of the signed-in user.",
"adminConsentDisplayName": "Access Amazon Web Services (AWS)",
"id": "1a6a3f4d-d629-4326-8b9b-d4d267500be3",
"isEnabled": true,
"type": "User",
"userConsentDescription": "Allow the application to access Amazon Web Services (AWS) on your behalf.",
"userConsentDisplayName": "Access Amazon Web Services (AWS)",
"value": "user_impersonation"
"oauth2RequirePostResponse": false,
"objectId": "c86f145a-1c55-4d7a-b57c-1dbc72ac3910",
"parentalControlSettings": {
"countriesBlockedForMinors": [],
"legalAgeGroupRule": "Allow"
"passwordCredentials": [],
"publicClient": false,
"replyUrls": [
"requiredResourceAccess": [],
"samlMetadataUrl": null

The part to add the roles is the allowedmembertypes. Replace it with the correct values, like this:

  • displayName: AccountName_AdminAccess
  • Id: Must be unique within the enterprise application. Format is like “00000000-0000-0000-0000-000000000001” (note that only 0 is not a valid number)
  • Description: AccountName_AdminAccess_AccountNR
  • Value: ARN Role, ARN identity provider
"allowedMemberTypes": [
"displayName": "Warmetal_AdminAccess",
"id": "00000000-0000-0000-0000-000000000001",
"isEnabled": true,
"description": "Warmetal_AdminAccess_**accountnr**",
"value": "arn:aws:iam::**accountnr**:role/AWSAdminsInAzureAD,arn:aws:iam::**accountnr**:saml-provider/AzureAD"
"allowedMemberTypes": [
"displayName": "Warmetal_ReadOnlyAccess",
"id": "00000000-0000-0000-0000-000000000002",
"isEnabled": true,
"description": "Warmetal_ReadOnlyAccess_**accountnr**",
"value": "arn:aws:iam::**accountnr**:role/AWSReadOnlyInAzureAD,arn:aws:iam::**accountnr**:saml-provider/AzureAD"
"allowedMemberTypes": [
"displayName": "msiam_access",
"id": "7dfd756e-8c27-4472-b2b7-38c17fc5de5e",
"isEnabled": true,
"description": "msiam_access",
"value": null
Note that the different allowedmembertypes sections are separated by commas (except for the last one)
Also note that you need to add all accounts with their roles to the manifest

Don't forget to click save to save your changes to the manifest.

Add Groups to Azure AD Enterprise Application

  • Log into the azure portal with the office365 global administrator account we created earlier
  • Go to Azure Active Directory → Enterprise Applications → Amazon Web Services (AWS)
  • Go to Users and Groups → Add User

We now see an error: “Groups are not available for assignment due to your Active Directory plan level.” To be able to assign groups to Enterprise Applications you need either E5 or Azure AD Premium P2.

  • You can still select the individual users and assign the role you want to assign.
  • Repeat these steps to assign all the roles to all the users you need.


You can now test by logging into as the user you assigned the role to in the Enterprise Application. You should see the Amazon Web Services (AWS) listed. Clicking on it should let you choose between the different roles you were assigned so you can log in.

Billing Information

Billing information is by default not available for IAM users. To enable this for a specific role log into your master organization account using your original root credentials:

  • Go to My Account
  • Scroll down to “IAM User and Role Access to Billing Information” and click edit next to it
  • Click Activate IAM Access and click Update
Now the full Access as configured and described above also gives access to the billing dashboard = Resources =

* *

You could leave a comment if you were logged in.
federatedloginforaws.txt · Last modified: 2021/09/23 22:24 (external edit)