This section introduces the options to enable your human users federated access to your AWS environment by using an identity source that is external to AWS Single Sign-On (AWS SSO). Once you’ve selected an option, further sections lead you through the process of setting up the desired option.
Moving from using AWS SSO local identity store to an external identity source: Earlier in this guide, you may have taken the default path to begin defining users and groups in the local identity source within AWS SSO. This is a common initial step to help you quickly set up your AWS environment and provide you with the time to consider your options to reuse an existing identity source. If you choose one of the AWS SSO options listed below, you will need to plan for the implications of the change. See Considerations for Changing Your Identity Source for details.
You may have one or more of the following requirements as you consider reusing your existing identity source to help control human access to your AWS environment:
End User Requirements
The following options are typically considered when you intend to reuse an existing identity source in support of your requirements for federated access to your AWS environment:
In later sections, this guides goes into more detail on the first two options given that they suit the majority of customers' needs.
The following decision tree provides a summary of your options based on your requirements. Generally, if you already have a SAML identity provider (IdP) or intend to establish one, we recommend using your SAML IdP to enable reuse of your existing identity source. If you don’t plan on having a SAML IdP to use for this purpose, then you can integrate your existing AD with AWS SSO.
If you have specific SAML IdP needs that can’t be met via integration with AWS SSO, then it’s likely that you can use your SAML IdP directly with AWS IAM. For example, if you need to integrate multiple SAML IdPs, then you would integrate those IdPs directly with AWS IAM.
If you either already have a SAML 2.0 IdP that you use in support of other enterprise applications or you plan to establish an IdP for this purpose, the most straightforward route is to use AWS SSO in conjunction with a SAML 2.0 IdP.
Review the Connect to Your External Identity Provider for an overview of this option and a list of the supported identity providers.
Here are several examples of this option:
If you don’t already have a SAML 2.0 IdP that you use in support other enterprise applications and you don’t plan to establish one, then you might consider integrating your Microsoft Active Directory (AD) directory with AWS SSO. This option may be especially convenient if you already plan to have AD directory services in your AWS environment in support of workloads that depend on AD.
Review Connect to Your Microsoft AD Directory for an overview of this option.
If you have a requirement to use a SAML 2.0 IdP, but AWS SSO does not meet your needs, you can establish federated access directly via AWS IAM. This option predates AWS SSO.
Review Integrating third-party SAML solution providers with AWS for an overview of this option.
In this option, you take on the responsibility of provisioning IAM SAML provider resources in each AWS account and managing the distribution of SAML IAM roles to each account. Setting up and making use of end user to the AWS CLI, SDK, and APIs requires more work on your part.
AWS SSO provides some benefits over this traditional option:
There are a few considerations that might still lead you to use this traditional option:
Here are several examples of using external SAML IdPs directly with AWS IAM:
If you choose either of the first two options, you can proceed to one of the following sections to review the detailed architecture and setup steps: