Reauth workflows

[noah-paige]

Feature or Bugfix

• Feature

Detail

• Add Configurable feature to have sensitive API Operations require re-auth before proceeding

• For specific sensitive actions, such as destructive actions like "deletes" of AWS Resources, there should be additional steps for a user before they can proceed with performing said action

• Enforce a user to re-authenticate themselves before they are able to successfully call the API request performing the sensitive action

Technical Implementation:

Backend Process

• There is a SSM Parameter with a list of API Names defining which API actions require re-auth workflow
  • API Names are configurable (in cdk.json)
• There is a configured time to live (TTL) for any user's latest authentication time until they would have to re-authentication again for any sensitive action
  • TTL is configurable (in cdk.json)
• API Handler Lambda is updated to
  • Determine whether API Request is for a sensitive action
  • If so
    • Pull latest authentication time from auth_time header from API Request
    • Ensure current time is within the TTL window from the latest authentication time (auth_time) and if not return a 401 Unauthorized Error with extension code REAUTH

Frontend Error Handling (if receiving custom 401 error indicating re-auth required)

• User's API Request details get stored along with a timestamp and UI path name
• User gets prompted with a ReAuth Modal to either
  • Continue their current session without performing the sensitive action
    • This option will remove any API details from storage
  • OR Re-Authentication by
    • Logging Out and logging back in to the data.all UI
    • On log in the API details get restored and the API request is automatically retried
      • Notification to user displayed with the success or error message returned from the API Request
      • On Queries the user is also redirected back to the page they were previously on to continue from where they left off on the UI
        NOTE: The re-login flow will give user new tokens and update latest auth_time in future API Requests

User Experience

• User A logs in to data.all and immediately requests a sensitive action (e.g. DELETE_DATASET) on the data.all UI for DatasetA
  
  

  • Cognito Auth allows API Request and API Handler Lambda determines that this request requires re-auth but the user's latest auth_time is within the configured TTL time window (configured at 5 minutes) so the delete action is allowed

• User A waits 10 minutes and requests another sensitive action (e.g. DELETE_DATASET) on the data.all UI for DatasetB

  • Cognito Auth allows API Request but API Handler Lambda determines that this request requires re-auth and the user's latest auth_time is NOT within the configured TTL time window anymore so a 401 is returned and the ReAuth modal pops up
    
    

• UserA decides to re-authenticated is a logged out of data.all

• UserA provides proper credentials to its Identity Provider and receives a new token with a new auth_time
  

  • Now UserA's deleteDataset request is automatically retried successfully for DatasetB
    

Relates

• Issue #571

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[noah-paige]

Additional Considerations/Requirements

1. (Requirement) Ensure that the log out workflow forces full log out for both Cognito IdP and for federated data.all users using integrated 3rd party IdPs

• Have documentation on how to implement - to add to data.all documentation pages

2. User Experience of force logout and log back in and manually navigating back to the data.all page to perform the sensitive operation is sub-optimal

• Currently when a user opts to re-authentication, after another proper signin, they are navigated back to data.all’s homepage and not back to the previous page they were just at to perform the sensitive operation
• We could look into
  • retrying to API operation immediately after login
  • redirect user back to the page they previously were on rather than manually navigating back in the data.all UI

[noah-paige]

In the latest commits I have added the ability to retry the API Request that required ReAuth upon a User re-logging in to the data.all UI. For retry logic, the reauth operation will be retried if:

• There exists a re-auth sensitive action to retry
• The user has re-logged in within the TTL (configured in the cdk.json)
• The user logs in as the same user as the before when trying to perform the sensitive action

For queries, the user will also be redirected to the page they were formerly on. For mutations this redirection is not built in as it may not make sense for most mutations (i.e. take the example of a user deleting a dataset… upon re-auth and the retry of the DeleteDataset it does not make sense to navigate the user back to the particular dataset’s view as that view no longer exists)

Testing in AWS Deployment

• ReAuth on Sensitive Query --> Retry API Request + Navigate back to old page + Success Message
• ReAuth on Sensitive Query + wait > TTL before re-login --> No Retry API Request + Error Message
• ReAuth on Sensitive Mutation --> Retry API Request + Success Message
• ReAuth on Sensitive Mutation w/ Bad Inputs --> Retry API Request + Error Message
• Login as New User between ReAuth log in --> No Retry API Request
• Normal Logout and Login functional

[dlpzx]

In the cdk.json it will be an int right? Then we will define it in the env variables as string and then back to int and datetime delta in api_handler

[noah-paige]

Yes - environment variables are handled as a string so casting it as such before passing in to lambda and then casting back during runtime of the function.

I thought it would be confusing for a user to enter a string format of a numeric TTL value so thought we could just handle casting to string and then back as int - let me know your thoughts

[dlpzx]

I agree! In the cdk.template can you add the info that it is INT and in minutes?

[itsmo-amzn]

LGTM!

[dlpzx]

@dbalintx and I tested in existing deployment with internet_facing=true and custom_domain.
Reauth workflow and logout/login successful.

The only remark is that it is relatively easy to make mistakes when defining the reauth_apis. To use this feature we need to make it very clear in the docs that the query is the one defined in the gql schema and how to obtain it.

But overall, incredible work @noah-paige