Providing Access to Externally Authenticated Users in AWS

The objective of this blog is to outline the possible ways in which we can authenticate users from an external identity provider and access the AWS resources, or in AWS terms Identity Federation.

We will also be discussing the custom authorizers and ways we can lockdown the downstream AWS resources from the API.

There are a couple of ways to delegate the authentication from AWS IAM to another trusted OIDC compatible identity provider.

1. Amazon Cognito Identity Pools (Federated Identities)
2. Identifying Users with Web Identity Federation Using STS.AssumeRoleWithWebIdentity
3. API Custom Authorizers

Amazon Cognito Identity Pools (Federated Identities)

This is the simplest way to assign AWS roles to the user signing in through a trusted OIDC IdP. We can create Amazon Cognito identity pools (federated identities) which enables us to create unique identities for our users and federate them by establishing a trust relationship between the provider and the identity pool.

Steps:

• Create an OIDC trust relationship on the IAM identity provider console.

Create a Cognito identity Pool and select the OIDC provider under authentication providers and assign the authenticated and unauthenticated roles.

Use federated.SignIn option to login:

This returns back a set of temporary AWS creds.

Amplify supports this feature OTB. We just need to configure the identityPoolId in the Auth context of amplify.

Identifying Users with Web Identity Federation Using STS.AssumeRoleWithWebIdentity

It is advisable to specify roles/access policies in IAM based on configuration of app or userId in our case enterpriseID. So the folders are locked in by these identifiers.

and the policies to access these look something like :

Calling AssumeRoleWithWebIdentity does not require the use of AWS security credentials. Therefore, you can distribute an application (for example, on mobile devices) that requests temporary security credentials without including long-term AWS credentials in the application.

Steps: Create a role in the IAM and set up the trust relationship with the OIDC/SAML compatible Id provider.

Call STS.AssumeRoleWithWebIdentity exchanging tokens received from the trusted OIDC compatible identity provider to get back a valid AWS credential with the specified role.

API Custom Authorizers

For resources behind the gateway, we can configure the endpoint to secure the service with a given Execution Role in the integration request.

The call is allowed only when the Lambda/custom authorizer returns back true with an execute-api-invoke policy in it.

Example solution architecture

Use API Gateway Lambda authorizers

This documents an example of a custom authorizer.

The authorizer should get back an invoke-api policy in order to invoke the next step.

We can then lockdown the AWS resources in the Integration Request part where the call gets the policies defined under the Execution role.

The additional token from the custom authorizer can be passed to the downstream services using the mapping Template.

Reference:

https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/STS.html#assumeRoleWithWebIdentity-property

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#stsapi_comparison

https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html

https://aws-amplify.github.io/docs/ios/authentication#federated-sign-in

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc_user-id.html