Multi-Tenant Authentication with AWS Cognito
Asked Answered
S

1

22

My current project is in AWS, using Cognito and microservices with Lambda. We have designed the microservices using DDD and are in the process of implementing basic functionality.

However, there is a business need for users of the API to be able to be categorised into the client company that they work for, and only be able to access data for that client company as well as any role-based authentication we will have.

This isn't a full multi-tenant solution as every user will be working with the same website, but their account will have been associated with a particular client.

Everything I have read about doing something like this in AWS suggests using one user role or pool per client and associating users with it when they are created, however we do not want to do this, as the clients typically consist of 2-3 users and there are many clients. This would quickly become unmaintainable in terms of number of user pools.

I tried to think of ways around this issue using "conventional" means, such as adding a domain service into the architecture which was solely designed to add client data to each request by a particular user by calling into the user microservice, but this seems overly complex. I also considered changing the architecture to include basic user and role information in each microservice, but that seems messy.

My question is are there any officially supported ways to add data into an AWS Cognito profile programmatically, and in such a way that this could be changed through a front-end website by a client admin after the account has been created? Even if it's just a clientId field in the token.

If not, then what would anybody who has experienced a similar issue recommend as an alternative to the user pools suggestion.

Thank you.

EDIT:

I have also been investigating several ways to do this using attributes on Cognito profiles, as mentioned here. It seems like this is the way to do more or less what I'm trying to achieve, but I'd still like to hear about alternatives or advice.

Stenson answered 11/7, 2018 at 9:46 Comment(0)
S
34

The solution we will use for this issue will be to use custom attributes as part of the Cognito user set-up. We will have text fields for additional attributes or groups that the user belongs to.

The way this should be implemented can be found at the following links:

With this data being automatically passed into each service as part of the Cognito credentials, we will be able to check that the user has the valid credentials for accessing data specific to each client.

Examples of how to work with Cognito in a NodeJS application (sometimes with Serverless) include:

https://serverless-stack.com/chapters/login-with-aws-cognito.html

https://serverless-stack.com/chapters/add-a-create-note-api.html#configure-the-api-endpoint

This seems to be most easily achieved by using the aws-amplify package, which is primarily designed for front-end authentication, but which can be used in NodeJS for back-end authentication as specified here.

Stenson answered 17/7, 2018 at 13:48 Comment(2)
Here is one more potentially useful resource; an AWS re:INVENT talk given by one of the authors of the quickstart mentioned above. This talk goes through in some detail the application architecture of not just the quickstart, but multitennant authentication in general. media.licdn.com/embeds/…Fullbodied
The source code for the quickstart is here: github.com/aws-quickstart/saas-identity-cognitoFullbodied

© 2022 - 2024 — McMap. All rights reserved.