AWS STS (Security Token Service)

Overview

There are two widely used authentication methods in the IT industry. They are sessions and tokens. Token-based authentication is a protocol that generates one encrypted security token. Users can use this token to authenticate themselves. The AWS Security Token Service or AWS STS is used to dynamically generate a short-lived token. One can use this AWS STS token to access AWS resources. Thus, we can delegate user permission for our AWS account.

What is AWS STS?

AWS STS is a web service that is used to request temporary, limited-privilege credentials. AWS STS is integrated with AWS IAM (Identity and Access Management) service. It is available as a global service as well as a regional service.

By default, AWS STS is available as a global service and all the STS requests are sent to the global endpoint at https://sts.amazonaws.com. Global requests map to the US East (N. Virginia) Region.

In addition to that, AWS provides us with the option to send the STS request to the AWS region of our choice. In fact, AWS recommends using Regional AWS STS endpoints over the global endpoint.

The Benefits of Using AWS STS

Using STS, we no longer need to embed the long-term AWS credentials in applications or servers.
AWS STS doesn’t need to rotate or revoke the keys or credentials as the token will expire after 12 hours by default. We can request AWS to change the expiration limit to a minimum of 15 minutes and a maximum of 36 hours.
AWS STS incurs no additional charge
If we choose to send the STS request to an AWS regional endpoint, it will help us to reduce latency and build in redundancy when compared to using the AWS STS global endpoint.

How Do AWS STS Keys Work?

If you enter STS in the AWS Management console search bar, nothing comes up. Because it is not available in the console, AWS STS is accessed programmatically only by the AWS SDK or AWS CLI.

The AWS IAM entity will make API calls to the STS global endpoint or regional endpoint (if enabled). Then the STS key will be generated dynamically.

Once STS receives the request, it will return a response with the following

Access KeyID and Secret keyID : The Access key and secret key will be used to access the AWS Services programmatically

Session Token : Key generated by STS Service to obtain a session with AWS Services

Expiration: Time duration for the session expiration

The above diagram illustrates the sample Architecture flow diagram for an AWS STS API Call with Web Identity Federation.

The Web Identity federation is the option we usually see on the login screen, such as Login with Amazon, Facebook, Google, or any other OpenID Connect (OIDC)-compatible IdP.

1. Client Authentication:

We can see that the Web identity provider authenticates the user identity and returns with a JSON Web Token (JWT).

2. AWS STS API Request:

Using the token, the user will assume that identity to request the STS API.

3. AWS STS API Response:

AWS STS returns a dynamically generated token as a response to the API call request. The user will use that token to obtain a session.

4. Accessing AWS Services:

Using the session token, the user will be able to access the AWS Services.

Every time the user logs in and accesses the AWS service, a unique session token will be generated dynamically by AWS STS.

Note: Here, the AWS services that the user can access will depend on the policy attached to the role, which is integrated with Web Identity.

AWS STS Actions

AWS STS actions are categorized into three categories. They are

Read
Tag
Write

Read Action

No	Action	Description
1	GetAccessKeyInfo	Allow us to get details about the access key ID passed as a parameter to the request
2	GetCallerIdentity	Allow us to get details about the IAM identity whose credentials are used to call the API

3	GetFederationToken	Allow us to obtain a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) for a federated user (ADFS or SAML 2.0)

4	GetServiceBearerToken	Allow us to obtain an STS bearer token for an AWS root user, IAM role, or an IAM user

5	GetSessionToken	Allow us to get a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) for an AWS account or IAM user

Tag Action

No	Action	Description
1	Tagging	Grants permission to add tags to an STS session

Write Action

No	Action	Description
1	AssumeRole	Allow us to access the AWS service that we might not normally have access to use
2	AssumeRoleWithSAML	Allow us to obtain a set of temporary security credentials for SAML users
3	AssumeRoleWithWebIdentity	Allow us to obtain a set of temporary security credentials for users with a web identity provider such as Login with Google or Facebook
4	DecodeAuthorizationMessage	Provides permission to decode additional information about the authorization status of a request from an encoded message returned in response to an AWS request
5	SetSourceIdentity	Provide permission to set a source identity on an STS session

Note:

Web Identity is a 3rd party web Identity Provider (IdP) like Google or Facebook.
On-premise SAML or ADFS can integrate with IAM, then users in that directory can access AWS Services using SSO (Single Sign-on). Every time on-premise users sign in to the console, the AWS STS token will be generated and mapped to the user session for the assumed IAM role. Thus, SAML or ADFS supports a hybrid cloud.

Use Cases for AWS STS

Common scenarios for temporary credentials in AWS are listed below:

Identity federation using SAML 2.0 and Web identity such as Google, Facebook, etc

Instead of creating IAM users, we create an IAM role. We integrate our SAML 2.0 or ADFS or Web identity into the AWS Identity provider. Then users available in ADFS or SAML 2.0 will assume the role to access the AWS service. Whenever they access the AWS Service, a unique session token will be created and mapped to that user.

Roles for cross-account access

Assume we have an AWS Production Account and a Developer Account.
By assuming the role with STS permission, users in the developer account will be able to access the production AWS account without creating an IAM user with the help of temporary access tokens. The same goes for AWS resources as well.

Roles for Amazon EC2

We create an IAM role with AWS resource access and attach it to the EC2 server. The EC2 server can now access the AWS resource (policy-based) without creating the IAM users or credentials on the EC2 server.
EC2 uses the STS service under the hood to achieve this.

Access AWS services with IAM role

We can further delegate our IAM access by allowing the IAM users to follow role-based access. The IAM role will use STS to access the AWS services, instead of the IAM credentials.

For example,

If an IAM user wants to access an S3 bucket, instead of attaching the S3 policy directly to the IAM user, we can create one IAM role with S3 Bucket permission.
The policy will then be attached, stating that IAM users can assume the role to access S3.

AWS STS Example

In this example, we will provide the EC2 server with the access to an S3 bucket using IAM roles.

STEP 1: View the available S3 bucket. If there is no S3 bucket, create one.

STEP-2: Launch one EC2 server on a public subnet and the ensure that the server is in running state.

STEP 3: Follow the steps below to create an IAM role.

Select AWS Service and use case as EC2

Policy: AmazonS3FullAccess (AWS Managed Policy)

Name: ec2-role-for-s3

Create the role.

Note down the role name.

STEP-4: Attach this IAM role to the EC2 server.

Select the created role under the dropdown and click Update IAM role.

STEP-5: Login to the EC2 server. In the server CLI, enter the below command.

Login view:

This command will list the buckets available in the region of the launched EC2 instance.

What have we achieved here?

You may have noticed that we didn't pass or store any IAM credentials to the EC2 servers. By attaching the IAM role to the EC2 instance, the EC2 server will be able to access the S3 services using STS.

In this example, we will provide an IAM user with the access to AWS Account services using STS Assume role

Step 1: Create an IAM user with no permissions.

In the above image, we can see that the IAM user will be able to log in to the server but is not able to view any services or resources. It is because we didn't attach any policy to the IAM user.

Step 2: Create an IAM Role with Administrator permissions and copy its ARN.

Note: Admin access includes all access to the AWS account, including reading and writing for all AWS services.

Step 3: Create a policy as mentioned below and attach it to the IAM user.

Choose STS Select Action: Read and Write Select Role and enter the Role Name that we have created in Step 2.

Optionally, we can use the below JSON. AWS Visual editor will generate the policy .

JSON Policy

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "sts", "sts", "sts", "sts", "sts" ], "Resource": "*" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": "sts:*", "Resource": "arn:aws:iam::569262334921/iam-admin-role" } ] }

Here, the IAM user will assume the iam-admin-role using the above policy by using the STS service.

Step 4: Log into the console, then click Switch Accounts

Enter the following information:

Enter the AWS account number. Enter the role we created in step 2. Display name is optional

Now an IAM user with no permission is assuming the IAM role with admin access and will be able to access the AWS services and resources. Here, we can see that we didn't use or pass any credentials to the role. AWS STS Services will create a session for the role and let the IAM user access the service and resources.

The same use case can be extended to a cross-account role wherein the IAM user is available in one AWS account and the IAM role is available in another account.

Using policies, we will establish a session with the help of AWS STS without creating or managing any long-term or embedded credentials.

Conclusion

AWS STS provides short-lived credentials to access AWS services securely.
Organizations can delegate IAM audit and security responsibilities using AWS STS.
AWS STS is free of charge. A customer can optionally enable a regional STS endpoint to reduce latency.
AWS STS also allows us to access the resource in a different AWS account using a cross-account role.