AWS News Blog

AWS Identity and Access Management Using SAML

Voiced by Polly

Ben Brauer, Senior Product Manager on the AWS Identity and Access Management (IAM) team, sent along a guest post describing a new, industry standard way to do identity federation with AWS.

— Jeff;

Over the years, weve had a number of blog posts that described how AWS Identity and Access Management (IAM) enables identity federation. (For those who’d like some background, see previous posts on identity federation with IAM, single sign-on (SSO) to the AWS Management Console, and web identity federation). These prior solutions worked for many customers, but some of you wanted SAML (Security Assertion Markup Language) support so that you could leverage your existing investment in SAML-based identity management software.

Today, were excited to announce we’ve expanded our identity federation to include support for SAML 2.0, an open industry standard used by many identity providers. This new feature enables federated SSO, empowering users to sign into the AWS Management Console or make programmatic calls to AWS APIs, by using assertions from a SAML-compliant identity provider (IdP).

Identity federation makes it easier for you to manage your users by enabling you to maintain your identities within your existing directory. SAML-based federation makes it simple for you to configure federation with AWS because you can use any IdP software that supports SAML (e.g., Windows Active Directory Federation Services or Shibboleth). Using federation, if a user leaves your company, you can simply delete the user’s corporate identity in one place, which then also revokes access to AWS. Your users also benefits because they only need to remember one username and password. Have I got your attention yet?

The Federated SSO Experience
Lets walk through a use case that demonstrates how federated SSO works. Imagine you have users that are members of a Windows Active Directory (AD) domain. You want these users to be able to sign into the AWS Management Console, but you dont want to create IAM users for each of them. Instead, you want them to browse to an internal portal, be authenticated by AD, and then be redirected via SSO to the AWS Management Console.  (If youre familiar with SAML terminology, youll recognize this as the IdP-initiated WebSSO use case.) In this use case, your company is the IdP which authenticates users and passes assertions to AWS, the service provider, that accepts those assertions and provides SSO to the console.

To support this use case weve introduced a few new things: SAML providers, the AssumeRolewithSAML API, and an additional sign-in endpoint (https://signin.aws.amazon.com/SAML). A SAML provider is a new IAM entity that defines a principal for one or more organizations that you would like to establish trust with your AWS account. You create a SAML provider by uploading a standard SAML metadata document using the AWS Management Console, AWS CLI, or the IAM API.  The new API, AssumeRoleWithSAML allows you to request temporary security credentials from the Security Token Service (STS) by assuming an IAM role. Unlike the existing AssumeRole API, you dont need to sign the request using AWS credentials (i.e., Access Key ID and Secret Access Key). Instead you simply pass the SAML assertion along with the AssumeRoleWithSAML request. Finally, the new sign-in endpoint enables users to log into the AWS Management Console using a SAML assertion.

Lets explore how users go from signing into their Windows laptops to logging into the AWS Management Console.

  1. A user in your organization browses to an internal portal in your network. The portal also functions as the IdP which handles the SAML trust between your organization and AWS.
  2. The IdP authenticates the users identity against AD.
  3. The client receives a SAML assertion (in the form of an authentication response) from the IdP.
  4. The client posts the SAML assertion to the new AWS sign-in endpoint. Behind the scenes, sign-in uses the AssumeRoleWithSAML API to request temporary security credentials and construct a sign-in URL.
  5. The user’s browser receives the sign-in URL and is redirected to the AWS Management Console.

From the user’s perspective, the process happens transparently. The user starts at your organization’s internal portal and ends up at the AWS Management Console, without ever having to supply any AWS credentials.

So, what do you need to set this up? Here are basic steps:

  1. Generate a metadata document using your IdP software.
  2. Create a SAML provider using that metadata document.
  3. Create one or more IAM roles that establish trust with the SAML provider and define permissions for the federated user.
  4. Configure your IdP software to map attributes (such as AD groups) to the IAM roles.
  5. Finished!

Federated SSO to the AWS Management Console is just one example of how you can use SAML to enable identity federation with AWS.

To get started with identity federation using SAML see the STS documentation.

— Ben Brauer, Senior Product Manager