I am working on a Project and in there I have used AWS Cognito for basic Authentication for My Web Application; In this web Application I am providing multiple role-based Authentication (Like Super User, User, Admin, Super Admin) and for that right now I have created different Userpools for each. Is there another way to achieve the same functionality? like I can use single Userpool and still can achieve Role-based Authentication. Also, which one is the Appropriate?
You can setup different groups in the same Cognito User Pool.
In your case Super User, Admin and Super Admin. Then assign your users to the group that they belong to. In your backend code you will then need to check what group the user is in by looking up the group that the user belong to.
See this link for more details: cognito-user-pools-user-groups
Related
After importing an existing user pool into a new amplify application, i no longer have the option to delegate api access using user pool groups from the CLI.
Building an application using React and amplify. Used command line to create cognito user pool auth and then created groups within this user pool. This allowed me to delegate api access based on the unique user groups. Whooopeee! Then... I started building a second application with the same user pool imported. Tried to follow the same process from the command line and restrict api access using user pool groups but it seems that aws CLI doesn't even register the user pool groups and only gives me the options to restrict by guest and authentication. Does anyone have a solution to this problem? Thank you.
I am creating an app using vue3 and amplify. My app needs to have 2 different user types. I am able to add 1 user type using amplify auth API and that user type is able to register and log in. However, when I do amplify add auth to add a second Cognito pool, I get the result: "Auth has already been added to this project. To update run amplify update auth."
Is there a way to support this either through amplify studio or amplify cli?
No, it is not possible to add two user pools. Instead, you can use single user pool and create different groups for different user types inside that user pool.
Could you elaborate more on your user case? If you really need two user pools, there might be also advanced ways to solve your case. For example, using Cognito Federated Identities (identity pools) and adding two user pools as authentication providers.
For the last few years, I've built a PHP and MySQL based website where users can submit reprographics and IT requests. I'm hoping to make this cloud-based rather than running it from a local webserver. My initial idea was to have an EC2 instance running as a web server for each company which uses my system, but as the system is PHP session based I'm assuming the security would not be great so I think I need to move towards more of an AWS system using Cognito for user management and the API Gateway with Lambda to do the job of getting the data from the databases. My question is, my current system has an admin console where the admin user can access the lists of users, and assign them permissions (session variables) which allows them access to specific pages. How would I make a webpage where users can manage the users in a Cognito user pool without giving them access to the AWS console.
Implement a Cognito AdminAddUserToGroup operation in your Lambda function for admin users to manage what Cognito Groups your users belong to. Your admins will be the only ones that are able to invoke the API call to the Lambda function because they'll be included in the Cognito Admin Group with appropriate permissions to invoke the Lambda function that you specified as the developer.
Specify permissions of what each Congito Group has access to by assigning roles for each Cognito Group.
You can also decode the jwt on the backend to determine what Cognito Group the user belongs to that made the request and use Amplify on the FrontEnd to manage the FrontEnd's display of content based on the Group (links, etc). More info about that can be found in this thread: How do I access the group for a Cognito User account?
I do not have enough points to comment on the CLI update-user-pool suggestion, but wanted you to know that wouldn't work because 1.) It would impact the entire user pool and affect ALL users in the user pool and 2.) It would make no difference in regards to what your users were able to have permission to access in your application.
My production environment uses AWS cognito federated identities (AKA: identity pool) for allowing users to sign in with their Google/FB accounts. This is working fine.
However, for my staging environment I want to offer a similar sign in functionality (that is: users sign in in via Google) but I want to restrict the ability to sign in only to a specific whitelist (of, say, #gmail.com accounts). This is because the staging environment should only be accessed by team members and a bunch of trusted users.
My question is this: is it possible to define a Cognito identity pool that allows only the whitelisted users to sign in? if the answer is "yes", then how?
I know that I can do the whitelist checking at my backend (that is: at the backend of my staging env. I will reject every request not coming from these whitelisted users) but this is a bit unclean. In particular, I want the rejection to happen as early and possible and, ideally, to be carried out by cognito itself, and not by my backend.
Clarifications:
I mentioned a list of #gmail.com accounts as the whitelist. I am open to any other mechanism for defining the whitelist.
In a way I am asking whether I can have user directory functionality (in particular: determining if a user is in a certain group of users) with an cognito identity pool.
The purpose of the Identity pool is to provide access to authenticated identities. Therefore, this resource cannot manage users (ie: white listing a user group).
There are two ways to do this:
Link 3rd Party Identity into a User Pool and white list by User Group. Your user group will have a Roles and permission it will assume that will allow your test users to have the functionality they need without allowing other users who log to have that functionality.
Manage users from the 3rd Party Identity - I am not an expert at Google authentication.. but some OpenID providers allow you to create user groups with different access roles. This is an example for Google.
You can invoke a trigger and execute a lambda function when the user submits their information to accept or deny the sign in request.
I'm trying to build a web app that can be accessed by any user that signs up with facebook.
I want to use AWS Cognito to speed up the development for users management.
It has to have 3 type of users:
Normal users - any user that logs in with facebook
Editors - users that have a different access level (IAM role?), they can call a specific AWS Lambda function, that normal users can't call.
Administrators - users that can modify the status of normal users to make them editors or admins
Can someone please point me in the right direction? I've set up AWS Cognito Identity Pool but I'm not sure if I have to set up a User Pool or how do I assign a different role or policy to a user to make him an admin or editor (different access levels for other AWS resources), if I can get in my web app the users list from Cognito (only for an authenticated admin) and how do I allow him to modify other users roles.
Some tutorial, documentation or at least a short description of how can I do this would help me a lot.
Optional: let users to not only sign up with facebook but also with email/pass, and have the same functionality.
You should be able to use 'Role Based Access Control' feature of Cognito federated identities. This is the relevant part of the doc:
http://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html
If you are only using Facebook, you can use Facebook sub to assign appropriate role.
If you are using username and password based sign-in with user pool, you can use group support and create editors group and assign appropriate permissions.
Instead of managing Administrators with federated identities or user pool, probably directly using IAM user will be a better idea. This IAM user will have full permission to modify/add identity pool rules or user pool groups.