I'm trying to write a pre signup lambda that will look for a user in our Cognito pool as to ensure that the data provided by the user is unique. I'm unable to find any docs that mention accessing the user pool directly or looking for a user by a non-username attribute?
You should be able to do what you want using the ListUsers API call, it accepts a filter so that you can filter down to just the attributes you want to get!
Not a search in the most general sense, but should help you to accomplish what you want!
http://docs.aws.amazon.com/cognito/latest/developerguide/how-to-manage-user-accounts.html
Related
I am working on a React Project and in there I want to use AWS Cognito for Role Based Authentication. My Project will be having multiple roles like Super User, User, Admin, Super Admin, etc. and to achieve this I have created multiple userpools. As in 1 userpool for each role and Everything is working correctly but turned out that I can achieve same functionality within single userpool by making groups in it.
So, The problem is that for now I am using 'aws-cognito-identity-js' library to authenticate users. but in that Library I couldn't find any code related to Userpool Groups and also I tried to find another library related to Userpool Groups but I couldn't find any. So, How can I integrate that Groups Logic into my React App?!
When you login to the userpool you get an ID-Token. The payload of this ID token also contains the groups the user belongs to.
let
[header, payload, signature] = idtoken.split("."),
jsonPayload = JSON.parse(atob(payload)),
groups = jsonPayload["cognito:groups"]
Of course you can also use your favourite JWT library (maybe even amazon-cognito-identity-js has something included) to verify and parse the ID token and extract the desired claims from it.
EDIT
amazon-cogito-identity-js cannot be used to manage groups during self-signup of a user. IMHO it would be counter-intuitive and a security flaw, that a user can add himself to a group (which probably has certain security implications in your app) without administrative intervention.
If you really want allow the newly created user to select which groups he belongs to, you can do that via a Post Confirmation Trigger on the userpool.
Add the desired groupname for instance as a custom attribute while signing up the user.
Once the user is confirmed the post confimation trigger (a lambda function) is executed. This lambda function has to have the necessary permissions to execute the AdminAddUserToGroup command.
Within the trigger (which receives the user's attributes as parameter) execute the mentioned AdminAddUserToGroup command.
I am creating a flask app to be used internally in my company. I would like to restrict what a user can do it based on its login ID. I read a lot about using LDAP3 but I don't think I can do what want which send the login ID to the server. There I would have a table which will register which part of the system has the permition to edit. If it try to change somenthing not permited the app will retrieve a warning message.
I won't to do that to avoid having to create a separate login functionality just for this app. I read that I should use AD authentication but I am not very familiarized with that and I would also like to avoid having to ask our IT department to create user groups there for each part of my system.
I know that I can do that using ASP .NET (at least I did once).
Any guidance will be apreciated.
I think you are looking for Role-based Authorization.
In order to use this functionality you will need to implement roles on your model file per the Data-models documentation.
This will allow you to assign users a role when they are created, and you can use a decorator on your routes to 'require' the user to have the role you want them to have before they access the endpoint.
In Amazon Cognito's User Guide, in the page “Configuring User Pool Attributes”, there is this paragraph (with added emphasis):
“If your application does not require a username, you do not need to ask users to provide one. Your app can create a unique username for users in the background. This is useful if, for example, you want users to register and sign in with an email address and password.”
I want to do precisely what the paragraph says: while users sign up, create in the background a custom user ID for them myself, because I need these IDs to follow a specific semantic format, that embeds tenant context into the IDs (something like “T01234#U01234567“, meaning “user U01234567 inside of tenant T01234”).
The users won't know of their custom ID, they will feel as they've signed up (and later signed in) with their emails (or through 3rd parties like Facebook and Google, if possible in this set up). But in the background I will create these custom IDs and store them in their username attribute in the User Pool.
The reason I want to store these iDs specifically in the username attribute is because it is un-mutable and unique, but most important because I will need to query Cognito's APIs (ListUsers, AdminListGroupsForUser, etc.) using these custom IDs as filter, to give my customers some user management capabilities. The username attribute is the parameter for these APIs. Therefore, I cannot use User Pool custom attributes here, since they are not accepted as parameters of these APIs.
The reason I post this Question is because, while the documentation recommends this as a possible setting, there is no specific information on how to set the user pools and sign up flow to support this specific use case.
What is the general settings layout of this? To start with, in the option “How do you want your end users to sign-up and sign-in?”, what do I have to put there in the scenario I described? If anyone can give any additional pertinent information, it would be very helpful, as the documentation feels somewhat opaque.
Thank you very much for those who've read this.
You probably will need to deal this in your frontend.
When your user start the sign-up process, you will need to generate the username based on your requirements and send the request to Cognito User Pool using that generated username + e-mail.
For Cognito User Pools this will be transparent because in the request it will receive the username, the password and the user e-mail. Off course you will need to allow login with e-mail and password.
If you don't want to do this in the frontend you can create a backend with public access that accepts a unauthenticated requests and performs this task directly in Cognito User Pool.
I am using aws cognito sdk with .net core 3.1 webapi. The issue is, I have to display users info as well as user groups. ListUserApi https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html doesn't return users group information. According to the docs I have to call other api ListUserInGroups (https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsersInGroup.html) but as I need both information on single table. This call would be really expensive for me. Is there any other api which returns user's profile info as well as user group info. I tried to find one but couldn't
Also one other question do aws cognito api provied sorting functionality? Like sort by name of email? I can only see filtering option but not sorting.
Cognito's AWS documentation says:
Each custom attribute: Cannot be removed or changed once added to the
user pool.
From: https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes
I believe they are referring to the name of the custom attribute, no the value itself.
So, the value could be changed from a Lambda function for instance. Let's say we are storing fidelity points for each user in our e-commerce website.
Is a custom attribute the proper place to store this kind of information?. Or should I create a new DynamoDB table linked to the UserId in the user pool?
You certainly could store this information in a Cognito custom attribute. If you were to do so, there are two things I would consider:
1) Make sure that the Cognito user pool client that is being used to authenticate against the user pool does not have permission to write to this attribute. Otherwise a rogue user could write code to authenticate themselves against the user pool and give themselves as many fidelity points as they wanted. So you might want to consider hiding the custom attribute update behind a service.
2) Depending on how often you need to update this attribute, and your overall Cognito usage pattern, you may encounter RequestLimitExceeded errors when using the Cognito updateAttributes API. Almost every time I have tried to use Cognito as a primary data store for user information I have been throttled. AWS support will up your limits but the error happens without warning, which isn't great in a production environment. I invariably end up just defaulting to a DynamoDB table. Of course this has just been my experience so YMMV
in my opinion If you need that the attribute value appears on identity token you should use the custom attrib, if not is better to store that on another place.
Example: You have 'users' that are admins of 'pages', then you store on Custom Attrib that relationship. Cognito add that information to the Identity Token, then When the user make an api call to 'pages' you only need to trust the information in the token and not make an extra database call to check if user is related to that page.
Custom Attrib are very restrictive as documentation says:
You can add up to 50 custom attributes to your user pool. You can
specify a minimum and/or maximum length for custom attributes.
However, the maximum length for any custom attribute can be no more
than 2048 characters.
Each custom attribute:
Can be defined as a string or a number.
Can't be required.
Can't be removed or changed once added to the user pool.
Can have a name with a character length that is within the limit that
is accepted by Amazon Cognito. For more information, see Quotas in
Amazon Cognito.
If you don't need the attrib on the token I prefer to use dynameDB, a lot less restrictive.