AWS STS:AssumeRole vs Federation

Table of contents

Reading Time: 2 minutes

Introduction

AssumeRole and Federation are two widely used approaches provided by AWS to facilitate authorization of cloud resources via Identity Management System (IDMS).

In this post, we will describe the Federation and AssumeRole approaches and their integration. We will also see how they are different, and finally, conclude which one serves better.

FEDERATED USERS

Federated Users(external identities) are users you manage outside of AWS for example: in your corporate directory. These users are granted access to AWS account using temporary security credentials. Federated users differ from normal IAM users in a sense that IAM users are created and maintained by AWS and are permanent entities whereas Federated users are generally created to provide temporary access to AWS resources.

For Example:- When you enter a Food Court, you first obtain a card. You can then access the individual restaurant by swiping that card. Similarly, federated users can access AWS resources but for that, we need to create IAM users who have permissions(Obtaining card first) to access those resources.

Following is an example to create a federation user via Java SDK

STS:FEDERATION

Returns a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) for a federated user.

How it is implemented :-

val client: AWSSecurityTokenService = AWSSecurityTokenServiceClientBuilder.standard().withRegion(Regions.US_WEST_2).build()
    val federationTokenRequest = new GetFederationTokenRequest()
              .withName("Bob")
              .withPolicy(policy)
              .withDurationSeconds(86400)
    val federationTokenResponse = client.getFederationToken(federationTokenRequest)
    val tempCredentials: Credentials = federationTokenResponse.getCredentials

STS:ASSUMEROLE

Returns set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) for a federated user with one extra step of creating an AWS role and attaching permissions policy to it.

How it is implemented :-

val request: AssumeRoleRequest = new AssumeRoleRequest()
      .withRoleSessionName(userName)
      .withRoleArn(role.getArn)
      .withPolicy(policy)
      .withDurationSeconds(43200)
      .withRoleArn(role.getArn)
    val response: AssumeRoleResult = client.assumeRole(request)
    val tempCredentials: Credentials = response.getCredentials

DIFFERENCE BETWEEN BOTH APPROACHES

For AssumeRole,the duration, in seconds, of the role session by default can range from 900 seconds (15 minutes) up to the maximum session duration setting for the role. This setting can have a value from 1 hour to 12 hours.In Contrast, getFederationToken approach are valid for the specified duration, between 900 seconds (15 minutes) and 129600 seconds (36 hours).
AssumeRole,cannot call GetFederationTokenor GetSessionToken.
GetFederation Token cannot call IAM API operations directly and cannot call AWS STS API operations except GetCallerIdentity.
Role sessions defined by assumeRole has the permissions defined by overlap of IAM User,IAM Role and Session Policy.On the other hand,permissions defined by getFederationToken has permissions defined by IAM User and Session Policy attached to the request itself.

WHICH IS BETTER?

It all depends on permission criteria, in case you prefer to maintain permissions solely within your organization, GetFederationToken is better choice. Since the base permissions are derived from the IAM user making the request and you need to cover entire delegated user base. This IAM User will have combination of all permissions of federated users.

If you prefer to maintain permissions within AWS, choose AssumeRole, since the base permissions for the temporary credentials will be derived from the policy on a role. Like a GetFederationToken request, you can optionally scope down permissions by attaching a policy to the request. Using this method, the IAM user credentials used by your proxy server only requires the ability to call sts:AssumeRole.

There is one extra step of creating a new role and attaching trust policy using assumeRole which is not the case with getFederationToken based approach.