At the beginning of your journey on AWS (or later) you may want to configure the single sign-on functionality to manage your AWS identities. The right service to do it is AWS Identity Center and it does the job quite well. But the path to deploy this service is sometimes strewn with pitfalls. 

In this example I will take the example of deploying AWS Identity Center with Azure AD as Identity Provider.

How to deploy?

The AWS and Microsoft documentations are very complete and detailed. In most cases if you follow them you will not encounter any error:

• AWS documentation
• Microsoft documentation

The basic idea are: 

1-Setup the AWS Identity Center on AWS side (prefer the delegated administration so that you reduce the interactions with your management account) and get the metadata file

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://eu-west-1.signin.aws.amazon.com/platform/saml/d-XXXXXXXXXX">
    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://eu-west-1.signin.aws.amazon.com/platform/saml/acsXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" index="0" isDefault="true"/>
    </md:SPSSODescriptor>
</md:EntityDescriptor>

Which reflects what you can see on the AWS console:

2-Configure an application AWS IAM Identity Center on Azure AD side and upload the metadata file provided by AWS Identity Center. Note: you can do the copy/paste of the different URLs but it increases the probability of an error

Now you have two cases: either your configuration is working and you can connect with your Azure AD identity, or it is not and we’ll try to understand how to fix the errors.

It’s not you, it’s us

But shit happens and I’m no exception. I made mistakes on the different configurations with Azure AD and it can be difficult to fix.

When the SSO configuration is not working, after you log with your identity provider you have this screen:

Thank you AWS for taking all the responsibility for my mistakes and flogging yourself instead of blaming me. But this message doesn’t help me to solve my issue and you’re not providing any logs at the service level for investigating where the problem is. Hopefully we still have  CloudTrail in case there is a deny on a monitored AWS API.

Anyway we will go through the different checks you need to perform before opening a support ticket.

Check the format of the exchanged configurations

The first step to perform is to check the format of the URLs on Azure AD side and AWS side. 

You log from the access portal sign-in URL which needs to follow the format

https://d-[a-z0-9]{10}.awsapps.com/start

On Azure AD we provided 2 URLs that we need to check:

• The Assertion Consumer Service https://eu-west-1.signin.aws.amazon.com/platform/saml/acs/[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}
• The issue URL: https://eu-west-1.signin.aws.amazon.com/platform/saml/d-[a-z0-9]{10} where the string regex matches the one of the access portal

If you used the metadata file those URLs are the ones exported.

On AWS side you setup two URLs:

• The IdP sign-in URL: https://login.microsoftonline.com/[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}/saml2
• The issuer URL: https://sts.windows.net/[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}/ where the string regex matches the one on the IdP

You can also check the SAML certificate. This one has to be of this format: `CN=Microsoft Azure Federated SSO Certificate`. If it doesn’t look like this format you can import the certificate once again.

Be careful on the Azure AD console to download the base64 certificate and not the raw one. The raw certificate will be imported successfully and display information in the console but not under the expected format above. I made this mistake and this one is tricky to find, especially when you don’t have direct access to the Azure AD console but a colleague is doing it for you.

Check the format of your users on Azure AD side

AWS is expecting several attributes from the users it receives from Azure AD. If the attributes are not provided by the IdP they will not even appear in the AWS user synchronization if you’ve enabled automatic provisioning.

The attributes are detailed into the Azure AD console when the service is setup:

You can check the user attributes by directly requesting Azure AD: 

Get-AzureADUser -ObjectId “myUser@myDomain” | Select givenname,surname,mail,userprincipalname

A common error is to have a blank givenname or surname even if they are not explicitly required into the AWS documentation (although it gives us the corresponding values on Azure AD) but specified into the FAQ.

Other considerations about delegated administration access

Once your IdP is working well you can deploy your permissions sets to match your groups with your rights on AWS. 

As described in the documentation some actions cannot be performed from the delegated administration account:

As you can see the management account (account hosting the AWS Organizations) cannot be managed from this delegated account. The reason is to avoid privilege escalation on the management account. You can try you’ll have an error:

Setting up your permissions set from infra as code (e.g. Terraform) means that you cannot deploy permissions sets exclusively from the delegated account! This particular behavior implies two possible strategies to manage your permissions:

• Deploy everything from the management account, but the delegated administration loses interest 
• Deploy standard permissions sets for any account from the delegated administrator account and deploy the dedicated permissions sets to the management account from itself. It means you have separate permissions sets for the management account. Hopefully the permissions on the managed account will almost never evolve.

Conclusion

Debugging the AWS SSO service when deploying the setup can be a tricky experience although in most cases it will not be obscured by clouds.

If you double checked the parameters and it is not working, you can have a look at the FAQ. If it is still not working you need to open a ticket to the support because you have no clue where your issue is. If someone from the service team reads those lines, please consider delivering logs for the Identity Center as this service is more than recommended to manage the AWS identities.