Cognito get list user in group with Warrant - flask

I just try with AWS cognito for authentication my web application.
I am using Warrant library https://github.com/capless/warrant
I have many users which belong to my group (Ex: G1, G2, G3)
However, I cannot find the way to get list of users for specific group.
Can anyone tell me how to get list users in specific group?
Thank in advance.

I've just passed by the same situation as you, because I'm using warrant to. The problem is that warrant is an high level library, so it doesn't have capacity to manipulate all features that cognito can provide.
So, if you can try to solve this problem without using warrant, my solution is to use boto3 identity provider api, an low level feature that works with various usefull features of cognito.
Check these low level functions in AWS API documentation
So, using these functionalities, I made the code bellow to list all users at some group:
import boto3
cognito_cl = boto3.client('cognito-idp')
res = cognito_cl.list_users_in_group(
UserPoolId=<some_pool_id>,
GroupName=<some_group_name>
)
group_users = res.get('Users', 'empty')
Then, if you access group_users variable, you can see the list of all users in this group, just like all of their attributes.
Hope that I have helped you even after so long.

Related

How to retrieve groups for a specific user using the AWS SSO SCIM API?

I am trying to use the AWS SSO SCIM API in order to retrieve the AWS SSO groups for a particular user.
Looking at the documentation https://docs.aws.amazon.com/singlesignon/latest/developerguide/listgroups.html
It mentions the following
To see group info for a certain member, call ListGroup with a member filter
If you're using the member filter, you have to use the id filter (refer to supported filter combinations).
It appears that the id filter, is the group ID, because of this note: Note that the use of id as an individual filter, while valid, should be avoided as there is already a getGroup endpoint available.
Also, at https://docs.aws.amazon.com/singlesignon/latest/developerguide/limitations.html next to the members attribute it mentions that it is supported, but cannot be read in a response.
I have been playing with the API but could not get any group info for a user regardless of the combination of the parameters.
Based on the above, I conclude that the API does not support retrieving group data for a user. Would you agree?
I don't have access to an AWS SSO SCIM endpoint, but from looking at the documentation I suspect one of the two approaches may be possible:
GET /users/id and look at the value for "groups" - this one seems questionable as the limitations page says they support the user resource's "groups" attribute, but there's also a note about not supporting multi-valued user attributes. You may need to explicitly add the ?attributes=groups parameter to your GET to ask for that attribute to be returned, if it is in fact supported.
GET /groups?filter=members[value eq "userId"] or some variation of that depending on what syntax they allow. This isn't listed as supported, but if it works, I expect that you would get a list of groups in response that did not contain the "members" attribute - but that each group returned would match the query.
There's some amount of uncertainty with both of these, but with the information available those seem like the two most likely paths to successfully accomplish what you are aiming for. If neither of those work, it may not be possible - but a support case with AWS would probably be helpful to confirm there.
As #ZollnerdMSFT recommended, I raised an AWS support request. AWS support responded that the AWS SSO SCIM API does not support retrieving the groups associated with a user. They have submitted this as a feature request internally, however, cannot provide an estimate as to when it will be implemented.

Should I store failed login attempts in AWS Cognito or Dynamo DB?

I have a requirement to build a basic "3 failed login attempts and your account gets locked" functionality. The project uses AWS Cognito for Authentication, and the Cognito PreAuth and PostAuth triggers to run a Lambda function look like they will help here.
So the basic flow is to increment a counter in the PreAuth lambda, check it and block login there, or reset the counter in the PostAuth lambda (so successful logins dont end up locking the user out). Essentially it boils down to:
PreAuth Lambda
if failed-login-count > LIMIT:
block login
else:
increment failed-login-count
PostAuth Lambda
reset failed-login-count to zero
Now at the moment I am using a dedicated DynamoDB table to store the failed-login-count for a given user. This seems to work fine for now.
Then I figured it'd be neater to use a custom attribute in Cognito (using CognitoIdentityServiceProvider.adminUpdateUserAttributes) so I could throw away the DynamoDB table.
However reading https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-dg.pdf the section titled "Configuring User Pool Attributes" states:
Attributes are pieces of information that help you identify individual users, such as name, email, and phone number. Not all information about your users should be stored in attributes. For example, user data that changes frequently, such as usage statistics or game scores, should be kept in a separate data store, such as Amazon Cognito Sync or Amazon DynamoDB.
Given that the counter will change on every single login attempt, the docs would seem to indicate I shouldn't do this...
But can anyone tell me why? Or if there would be some negative consequence of doing so?
As far as I can see, Cognito billing is purely based on storage (i.e. number of users), and not operations, whereas Dynamo charges for read/write/storage.
Could it simply be AWS not wanting people to abuse Cognito as a storage mechanism? Or am I being daft?
We are dealing with similar problem and main reason why we have decided to store extra attributes in DB is that Cognito has quotas for all the actions and "AdminUpdateUserAttributes" is limited to 25 per second.
More information here:
https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html
So if you have a pool with 100k or more it can create a bottle neck if wanted to update a Cognito user records with every login etc.
Cognito UserAttributes are meant to store information about the users. This information can then be read from the client using the AWS Cognito SDK, or just by decoding the idToken on the client-side. Every custom attribute you add will be visible on the client-side.
Another downside of custom attributes is that:
You only have 25 values to set
They cannot be removed or changed once added to the user pool.
I have personally used custom attributes and the interface to manipulate them is not excellent. But that is just a personal thought.
If you want to store this information, and not depend on DynamoDB, you can use Amazon Cognito Sync. Besides the service, it offers a client with great features that you can incorporate to your app.
AWS DynamoDb appears to be your best option, it is commonly used for such use cases. Some of the benefits of using it:
You can store separate record for each login attempt with as much info as you want such as ip address, location, user-agent etc. You can also add datetime that can be used by pre-auth Lambda to query by time range for example failed attempt within last 30 minutes
You don't need to manage table because you can set TTL for DynamoDb record so that record will be deleted automatically after specified time.
You can also archive items in S3

Query AWS SNS Endpoints by User Data

Simple question, but I suspect it doesn't have a simple or easy answer. Still, worth asking.
We're creating an implementation for push notifications using AWS with our Web Server running on EC2, sending messages to a queue on SQS, which is dealt with using Lambda, which is sent finally to SNS to be delivered to the iOS/Android apps.
The question I have is this: is there a way to query SNS endpoints based on the custom user data that you can provide on creation? The only way I see to do this so far is to list all the endpoints in a given platform application, and then search through that list for the user data I'm looking for... however, a more direct approach would be far better.
Why I want to do this is simple: if I could attach a User Identifier to these Device Endpoints, and query based on that, I could avoid completely having to save the ARN to our DynamoDB database. It would save a lot of implementation time and complexity.
Let me know what you guys think, even if what you think is that this idea is impractical and stupid, or if searching through all of them is the best way to go about this!
Cheers!
There isn't the ability to have a "where" clause in ListTopics. I see two possibilities:
Create a new SNS topic per user that has some identifiable id in it. So, for example, the ARN would be something like "arn:aws:sns:us-east-1:123456789:know-prefix-user-id". The obvious downside is that you have the potential for a boat load of SNS topics.
Use a service designed for this type of usage like PubNub. Disclaimer - I don't work for PubNub or own stock but have successfully used it in multiple projects. You'll be able to target one or many users this way.
According the the [AWS documentation][1] if you try and create a new Platform Endpoint with the same User Data you should get a response with an exception including the ARN associated with the existing PlatformEndpoint.
It's definitely not ideal, but it would be a round about way of querying the User Data Endpoint attributes via exception.
//Query CustomUserData by exception
CreatePlatformEndpointRequest cpeReq = new CreatePlatformEndpointRequest().withPlatformApplicationArn(applicationArn).withToken("dummyToken").withCustomUserData("username");
CreatePlatformEndpointResult cpeRes = client.createPlatformEndpoint(cpeReq);
You should get an exception with the ARN if an endpoint with the same withCustomUserData exists.
Then you just use that ARN and away you go.

Selecting Categories using API in Amazon MWS

I am developing a integration between a desktop application and Amazon MWS and need to be able to offer users a choice of categories to put the product they are listing into. My problem is that I can't find any way of programmatically getting the current categories from MWS using the API.
Additionally once I have a category reference to use I will need a way to the pull in and add the category specific XML child of ProductData (eg Home, Jewelry, Computers, etc) but they don't seem to be linked in any well defined way. For example, I can't say "if the chosen category is reference nnnnn ask them to populate the Computers specific ProductData", unless I write something myself to map them.
Has anyone else come across these problems and found a workable solution?
Any help appreciated...
I am currently exploring the option of limiting users to only selling products already listed on Amazon but still can't figure out how to pull in the correct category specific XML.
There are various product look-ups but they all seem to work from either my SKU (which will not yet be there) or Amazons ASIN (which I don't yet know)
You can use amazon advertizement api for this.
You have to create account on amazon affiliate programme.From that you have to get security credentials also .
After That go to BrowseNode Tree Page and download root categories list and save it to file or database.From there you get categoryname and their browseNodeId.
Then call BrowseNodeApi to get Child Categories for parent Category.
Please Follow This Link
http://docs.aws.amazon.com/AWSECommerceService/latest/DG/ProgrammingGuide.html
code for calling BrowseNodeApi
SignedRequestHelper helper =
new SignedRequestHelper(appConfig["AWSAccessKey"], appConfig["AWSSecretKey"], appConfig["endpoint"]);
string url = helper.Sign("http://ecs.amazonaws.com/onca/xml?Service=AWSECommerceService&Operation=BrowseNodeLookup&BrowseNodeId=" + value + "&AssociateTag=beginners00-00&Version=2011-08-01");
HttpWebRequest request = WebRequest.Create(url) as HttpWebRequest;
// Get response
using (HttpWebResponse response = request.GetResponse() as HttpWebResponse)
{
}
and also download SignatureGenerator class HMAC

When using AWS SQS, is there any reason to prefer using GetQueueUrl to building a queue url from the region, account id, and name?

I have an application that uses a single SQS queue.
For the sake of flexibility I would like to configure the application using the queue name, SQS region, and AWS account id (as well as the normal AWS credentials and so forth), rather than giving a full queue url.
Does it make any sense to use GetQueueUrl to retrieve a url for the queue when I can just build it with something like the following (in ruby):
region = ENV['SQS_REGION'] # 'us-west-2'
account_id = ENV['SQS_AWS_ACCOUNT_ID'] # '773083218405'
queue_name = ENV['SQS_QUEUE_NAME'] # 'test3'
queue_url = "https://sqs.#{region}.amazonaws.com/#{account_id}/#{queue_name}
# => https://sqs.us-west-2.amazonaws.com/773083218405/test3
Possible reasons that it might not:
Amazon might change their url format.
Others???
I don't think you have any guarantee that the URL will have such a form. The official documentation states the GetQueueUrl call as the official method for obtaining queue urls. So while constructing it using the method above may be a very good guess, it may also fail at any time because Amazon can change the URL scheme (e.g. for new queues).
If Amazon changes the queue URL in a breaking way it will not be immediate and will be deprecated slowly, and will take effect moving up a version (i.e. when you upgrade your SDK).
While the documentation doesn't guarantee it, Amazon knows that it would be a massively breaking change for thousands of customers.
Furthermore, lots of customers use hard coded queue URLs which they get from the console, so those customers would not get the updated queue URL format either.
In the end, you will be safe either way. If you have LOTs of queues, then you will be better off formatting them yourself. If you have a small number of queues, then it shouldn't make much difference either way.
I believe for safety purposes the best way to get the URL is through the sqs.queue.named method. What you can do is memoize the queues by name to avoid multiple calls, something like that:
# https://github.com/phstc/shoryuken/blob/master/lib/shoryuken/client.rb
class Client
##queues = {}
class << self
def queues(queue)
##queues[queue.to_s] ||= sqs.queues.named(queue)
end
end
end