AWS SAML 2.0 Identity Federation

Crishantha Nanayakkara
3 min readApr 20, 2021

[Part 01 — AWS Identity Management Advanced Concepts Series]

SAML 2.0 — An Overview

The Security Assertion Markup Language (SAML) standard defines an XML based framework for describing and exchanging security information between business entities [1]. These security information is expressed in the form of portable SAML assertions that applications working across security domain boundaries which can trust.

SAML primarily being used in multiple use cases in terms of exchanging security information in a typical enterprise setting.

  1. Single Sign On (SSO)
  2. Identity Federation
  3. To define web services standards such as WS-Security

In this blog post, I will be focusing on the Identity Federation aspect in an AWS environment.

Identity Federation in AWS

In AWS, by default, only AWS users are allowed to access AWS resources and external identities are not allowed to access them. Identity Federation in AWS is the process of allowing external identities to be used to indirectly access AWS services.

If the users in your organization already have a way to be authenticated, such as by signing into your corporate network, you do not have to create separate IAM users for them. Instead you can federate those user identities into AWS.

SAML 2.0 with AWS

SAML (Security Assertion Markup Language) is an Open Standard Identity Federation Protocol, which is used by many Identity Providers. As an Identity Federation protocol, SAML will allow you to indirectly use on-premises IDs to access AWS resources.

AWS expects Identity Federation to be done with Identity Providers, which are SAML 2.0 compatible.

AWS Identity Federation uses IAM Roles and AWS temporary credentials with 12 hour validity underneath.

There are multiple ways that you could implement SAML 2.0 based identity federation within AWS.

  1. Via CLI/ API based identity federation
  2. Via AWS Console based identity federation

Identity Federation via CLI/ API

This scenario basically talks about how an on-premise application could access AWS resources via CLI/API invocations.

Figure 01 — AWS Identity Federation — via CLI/ API Invocations

There are multiple steps involved here (See Figure 01).

Step 1: AWS IAM should trust the SAML 2.0 compatible Identity Provider (IDP). This trust is “bi-directonal” and mutual. In here, AWS should register related IDP and SAML IDP should be configured in AWS IAM.

Step 2: Once the “trust” was established between IAM and the IDP, On-Premise application access the Identity Provider for authentication

Step 3: Then the IDP authenticates the request and identifies which roles are available for the application. Here, there can be multiple roles attached to a single identity.

Step 4: Once the above is completed, IDP will return a SAMLAssertion back to the application.

Step 5: Invoke AWS using STS:AssumeRolewithSAML having SAMLAssertion as an input parameter

Step 6: AWS will return Temporary Security Credential for the invocation.

Step 7: Use this Temporary Security Credential to invoke AWS services afterwards.

Identity Federation via AWS Console

This scenario basically talks about how an external identity (user) could access AWS resources via AWS console.

Figure 2.0 — AWS Identity Federation — via AWS Console

There are multiple steps involved here as well though it is much simpler to the previous approach (See Figure 02).

Step 1: Create a “Trust” between external Identity Provider (IdP) and AWS IAM by creating a SAML/SSO Endpoint

Step 2: An enterprise user accesses the Identity Provider (IdP) for the required authentication

Step 3: Then the IDP authenticates the request and identifies which roles are available for the user and returns them. Here, there can be multiple roles attached to a single user identity.

Step 4: IDP will return a SAMLAssertion back to the application with specified set of roles attached to it.

Step 5: Send SAMLAssertion to SAML/SSO Endpoint URL, which is defined in the AWS end

Step 6: IAM interacts with STS to return Temporary Security Credentials

Step 7: Use those Temporary Security Credentials to invoke AWS services.

References

  1. Security Assertion Markup Language (SAML) V2.0 Technical Overview — http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

--

--

Crishantha Nanayakkara

Enterprise Architect, Consultant @ FAO (UN), Former CTO, ICTA Sri Lanka