Multi-group user management with AWS Cognito
Amazon Cognito is the user management service offered by AWS. It includes everything from creating and maintaining user accounts, to creating identity pools to give role-based access to external users. This comes in handy when we are creating applications where authentication and user management are required. We do not have to spend days and months building our own user management mechanism and then test it for security and conformity. AWS handles all of it!
However, Cognito can be tricky to understand if you are new to AWS or user management is general. I have read and responded to numerous questions on stack overflow related to role-based authentications and user groups. Today, I would like to explain the approach with a small demo of a common use case.
This will be a completely generic guide with default settings so that when you use Cognito for a real product, you will be able to change the settings to match your requirements.
Setting up Cognito on AWS.
Log into your AWS console and open the Cognito service.
Select User Pool and choose to create a new User Pool.
Name your pool and click on Review Defaults to skip through all the other options.
Click on Create Pool. Copy the pool ID somewhere (we will need this in further steps)
Now in the left sidebar, click on App Clients and add a new app client (copy this ID as well).
Name your app client and uncheck Generate client secret, then click on Create.
Now, on the top left corner of the screen, click on Federated Identities.
To create a new identity pool screen, name your pool.
Expand the Authentication providers section. Paste the User pool ID and App client ID that you copied before.
Once you click on create, it will create default roles for you. These roles are not important as we will only be using group roles in this example.
Once the Identity pool is created, click on Edit Pool. This is the part where we handle the dynamic allocation of roles. Expand the Authentication providers drop down and make the following changes. Select Choose a role from token. Select Deny in Role resolution.
These steps need to be followed in all use cases as they are generic. After this is set up, you need to decide what groups your pool will have. Every group will have an IAM role associated with it. For example, the dual role pool, consider the following scenario, you are making a file storage application for a company and the employees from various departments will have access to only their own files and nobody else’s. On the other hand, the managers will have access to all the files in that department.
A clever way to handle this use case would be to create a separate bucket for each department. Create multiple manager groups which have full access to their respective buckets like below:
{
“Effect”: “Allow”,
“Action”: [
“s3:*”,
],
“Resource”: [
“arn:aws:s3:::bucketname/*”
]
}
This is the simple part. For a fine-grained strategy for non-supervisor employees, you can utilize the sub variable upheld by IAM.
So, our s3 pail will have the following structure.
/UserID/file
Here the UserID is the sub-ID from Federated Identity Pool. Do not to mistake this for the sub from User Pool. To get this sub you need to make the GetID decision utilizing whatever SDK you are utilizing to interface with AWS. Now in the role associated with the user write the policy in the following way
{
“Effect”: “Allow”,
“Action”: [
“s3:*”,
],
“Resource”: [
“arn:aws:s3:::bucketname/${cognito-identity.amazonaws.com:sub}/*”
]
}
Here IAM will confine the client’s admittance to all items that do not have the sub of the client in their key. Now, just write your application in your preferred language and get the group and sub id using the SDKs to create a key for pushing and reading files.
And that is it!
Conclusion:
This works for other AWS services as well, like API Gateway or DynamoDB. Experiment with different services and IAM policies.
Using this strategy, you will be able to grant the Least Privilege rights to your users as recommended by AWS.
