AWS SAML 2.0 Identity Federation

[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 are expressed in the form of portable SAML assertions that applications working across security domain boundaries can trust.

SAML is primarily used in 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. External identities are not allowed to access them. Identity Federation in AWS is the process of allowing such 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 an underlying 12-hour validity.

There are multiple ways that you canimplement 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-premises application could access AWS resources via CLI/API invocations.

Accessing AWS from another identity Provider (via API)


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. AWS should register related IDP, and SAML IDP should be configured in AWS IAM.

Step 2: Once “trust” is established between IAM and the IDP, the on-premises application will 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, the 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 a Temporary Security Credential for the invocation.

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

Identity Federation via AWS Console


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

Accessing AWS from another identity Provider (via Console)


There are multiple steps involved in this approach,although it is much simpler compared to the previous one(see Figure 02).

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

Step 2: An enterprise user accesses the Identity Provider (IdP) to obtainthe 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: The IdP will return a SAMLAssertion to the application with a specified set of roles attached to it.

Step 5: Send the SAMLAssertion to the 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 these 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

Vice President - Technology