Authentication Architecture
Last updated
Last updated
This is brief authentication diagram, the main goal is to provide a birds-eye view of how the authentication works and the different AWS resources used to accomplish this authentication process.
The crux of the challenge was to have a token that Hasura can parse and decrypt; thankfully, Hasura is compatible with AWS Cognito and it can use its certificates to decrypt its tokens. Hasura is also compatible with many other providers, such as Auth0, FireBase, etc.
Provide a centralized user pool for Moped
Protect the Moped Hasura endpoint and its data, and provide compatibility.
Protect the Moped API endpoint, and provide compatibility.
Allow for Single Sign-on using Outlook/Microsoft
The stack consists of four distinct AWS resources:
AWS Cognito
AWS Lambda (with Python)
AWS DynamoDB
AWS Secrets Manager
We should assume that Netlify and that the Moped editor written in React are working properly using AWS-Amplify, and that it always complies with the way the architecture works (even if it isn’t at the moment).
The user goes to the website hosted on Netlify, provides credentials to the app. The AWS-Amplify library knows the name of the Cognito user pool, and attempts authentication.
Cognito retrieves the credentials, checks its user pool and authenticates. It executes a lambda trigger based on the event type, in this case it executes the pre-token trigger which is in charge of generating the token which includes our claims.
The trigger is a simple Lambda function written in Python which uses the Boto3 library. The only task of the script is to generate a JSON document with the claims we need for our token, and it is provided the user uuid as it is stored in Cognito and DynamoDB.
The trigger will first attempt to fetch the encryption key from Secrets Manager, once it gets it it should be able to decrypt any content.
The trigger will then attempt to find the user record in DynamoDB by its unique cognito user id (uuid). The DynamoDB table has two string columns: user_id and claims. The main goal is to fetch the claims string and to decrypt it. The claims string is just a JSON string that contains the permissions for Hasura.
The trigger returns a decrypted JSON containing claims back to Cognito
Cognito will “tokenize” the claims and encrypt using its own certificate along with a large metadata payload and it sends it back to the aws-amplify react client.
The client now has a token it can use against an API or against Hasura.
Other notes:
This is not a permanent model, this architecture was designed to be changed and customized.
Also, in order to access all the other AWS resources, a role has been created named atd-moped-cognito-hook which includes
Lambda Execution
Limited DynamoDB access
Limited Secrets Manager Access
The deployment of the structure was manual (initially); however, the lambda functions for the triggers have been automated to be deployed to AWS using GitHub actions. These lambda triggers live in the repo under the moped-auth folder.
Currently PRs are not supported for the Lambda triggers, so right now we only deploy:
Main Branch → Staging
Production → Production
The claims should have a custom logic to determine what the default role is and what the allowed roles will be, this should be done at the API level which should in turn be controlled by the MOPED editor.
This is what it looks like encrypted:
Requests Per Second (RPS): DynamoDB does have a pre-set “limit” in the number of requests per second, initially it is 5 requests per second, which is the default. This should probably be changed to something like 20-40 RPS but it needs to be investigated.
Latency: Cognito has a 3 seconds limit to fetch the claims, if it doesn’t get it within 3 seconds, cognito will return an timeout error message back to aws-amplify and to the user.
Hasura Cognito Documentation: https://hasura.io/docs/1.0/graphql/core/guides/integrations/aws-cognito.html
Using Amplify CLI for adding Auth to your Hasura GraphQL engine: https://dev.to/hasurahq/using-amplify-cli-for-adding-auth-to-your-hasura-graphql-engine-23f9
Diagram owner
Team
@ Team member
Informed
@ Stakeholder
@ Stakeholder
Status
Last date updated
e.g.,24 Sep 2020
On this page
Name
Description
Operational Excellence
The ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures.
Security
The ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies.
Reliability
The ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.
Performance Efficiency
The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve
Cost Optimization
The ability to run systems to deliver business value at the lowest price point.
()