CROSS APPLICATION TEMPORARY ACCESS DELEGATION USING AWS PaaS SERVICES

Target Audience:

AWS cloud practitioners with understanding of cognito, IAM and STS services and who is familiar with Angular app development.

Problem Statement:

There are two cloud applications hosted on separate AWS accounts. Additionally there is customer support platform application hosted on 3rd AWS account for managing the two applications.

Let us assume a scenario where one of application user faces some challenges with application usage and needs the assistance of Customer support team. Screen sharing/remote access is not acceptable solution given long duration operation involving configuring over multiple pages.

Now the support engineer, who is a user of customer support platform application, has to access the user account after getting the user consent via email. This access should be temporary in nature with a time period of say 8 hours and post which the access should be revoked.

Assumptions:

Here we are assuming all UIs are angular applications, and each application uses cognito userpool for user management. User Access is managed by AWS IAM role, associated with user group(s).

Approach:

Let us say we have two cloud applications A & B, and customer support applications say P.

First step would be to enable application P user to raise user consent with the application say A user. For simplicity let us consider application A only as application B will also be in line with application B.

In this scenario we need to employ cognito for Authentication, identity pool for access token exchange for fetching IAM Access Key and Secret Access Key, and finally authorization to accessKey through IAM roles. We will need AWS STS service as well.

The workflow can be achieved by providing one application A screen to navigate from where P user will be able to raise consent request by providing application A user email-id. While navigating from P to A, all the required info can be passed as context parameter.

Let us see what all required parameters to be passed. First of all we need application A user’s email-id to send email for his approval. Additionally we need ticket number and problem description to identify the purpose of consent request. And finally we need application P user email Id to which consent is being given.

With this info, it is possible to call backend API of application A to create temp user for P user with required access to application A.

However the mentioned application A screen and API call it makes must be available to only authorized application P user. Also each request must have expiry.

Application A, API calls can be limited to authorized user through IAM roles. Let’s create IAM role with policy to allow API call. Let’s name IAM role as A_TEMP_USER_CREATE_ROLE.

While creating A_TEMP_USER_CREATE_ROLE, we must specify trust entity i.e. application P account id must be added as trusted account with application A account to use this role.

Define or attach predefined policy to give required access to call the backend API. Below screen is used only as example to give permission to call all APIs and create cloud watch log.

In order to get A_TEMP_USER_CREATE_ROLE of application A, application P user needs additional steps which are a) P aws account to be added as trusted entity to A aws account for IAM role A_TEMP_USER_CREATE_ROLE b) An IAM role to be created for application P aws account, which allows to assume application A aws account IAM role A_TEMP_USER_CREATE_ROLE. Let’s name it as P_CROSS_ACC_ACCESS_ROLE c) Application P user through cognito usr group gets P_CROSS_ACC_ACCESS_ROLE on successful authentication and programmatically assumes role A_TEMP_USER_CREATE_ROLE by calling STS assumeRole method IAM role P_CROSS_ACC_ACCESS_ROLE, will be similar to below

Now P user can invoke application A APIs. While getting cross account API access is good enough for backend, at UI we might need to first authenticate with cognito user pool of application A UI. So far support engineer is only authenticated to application P user pool and having authorization to call application A APIs. Hence now from application P UI, support engineer need to be redirected to application A to initiate process to get temp credentials from application A userpool followed by sign in, and to navigate to application A screen. The overall workflow can be as explained below. AWS Amplify through its Auth interface, simplifies through transparent token exchange with identity pool.

On application A, request API invocation will first validate through session token if it is not expired and user P is authenticated. Post successful validation it will make DB entry and send email with consent link to application A, end user for his consent. Once end user clicks to link url in email, he gets redirected to approve/deny page post authentication (if not already authenticated). On approval, below steps are executed through single API call

a) Application A user details are fetched from cognito identity provider for it’s group, and custom attributes

b) Using P user email-id and some random string, user signup is called

c) On user creation, user group is assigned and custom attributes are updated in line with A user who approved the consent user

d) User delete lambda is scheduled to get triggered post 8 hours, and deletes cognito user if not already deleted.

e) Consent request DB record is updated with generated password if not expired

f) Success response is sent

On API success response, approval page confirms application A user of approval, and consent request page will proceed with user signin using P user email-id, and updated random password. On successful authentication, support engineer gets same access as application user, and can perform actions on behalf of A user.

Below code sample illustrates how Application P code can be extended