I want to list the IOT things on a UI logged in with AWS Cognito. A user can create an IOT thing and should be able to see the IOT thing created by that user only and not by other users.
There are couple of ways to do that, one way would be creating an IoT group for each user and whenever the user add new IoT device, it should be added to that group. In this way you can then get the list of all things which are in the same group using AWS IoT SDKs. For example, by using AWS SDK for Python (Boto) you can get the list of things in an specific group using list_things_in_thing_group command, you can find more information here.
The other way would be using name/value pair for each IoT thing, say name: [user]. You can then filter things with this pair and list the things that created by specific user.
The third way would be saving the name of IoT devices created by each user in databases (like DynamoDB, RDS,...) and list them on UI.
Although, for all of these ways, you should consider the correct policy for users.
Related
In AWS IoT it is possible to attach multiple things to a single certificate. Also the Device SDKs support attaching multiple devices/things to the same IoT client.
How can a policy be defined for such a client to allow only for topics belonging to the shadows for the attached things?
A policy variable ${iot:Connection.Thing.ThingName} exists, but that will only work for the thing matching the client id, but it doesn't work for other attached things. The policy variable ${iot:Connection.Thing.IsAttached} on the other hand doesn't seem useable within the Resource section for specific topics.
In our case not all of our things are connected to AWS IoT directly, so we would like to interact with multiple thing shadows from within the same IoT client/certificate, which acts as an IoT Gateway. We do have a hook where the (un-)linking happens, but updating the policy there to add things "hard-coded" doesn't feel right.
What would be a good approach to keep this setup secure? Allowing access to all topics for linked things and denying access to others?
We are open to suggestions for a different approach on implementing this single client, multiple things/shadows interactions securely.
I am trying to make a connection between AWS IoT and my React JS APP.
I followed this tutorial (https://medium.com/serverlessguru/serverless-real-time-reactjs-app-aws-iot-mqtt-17d023954045), and it is not clear to me how to attach the Cognito Identity ID to the AWS IoT Policy.
During all my investigation, I found that this process must be done through command line.
In the article above, theses process is done by the following command line:
• Note that the “identity_pool_id” has to be considered in this command.
In the aws documentation (https://aws-amplify.github.io/docs/js/pubsub), it says to write the “identity_id” in the command line:
When I use the “identity_pool_id” in the command line, and I try to publish a message from AWS IoT, I got the following error:
When I use the “identity_id” in the command line, I can perform the communication between AWS IoT and the Frontend successfully:
The problem is that the “identity_id” is a different code for each user. Considering that I am going to have a lot of user in my application I don’t know how to perform this task.
• Am I doing the right process to consider the “identity_id” instead of “identity_pool_id”?
• If yes, how could I automatically attach the Cognito ID to the AWS IoT Policy every time I have a new user signedIn in my application?
• Are there any problem to have thousands of Cognito certificates attached in a AWS IoT Policy?
Following answer is in chronological order corresponding to 3 questions.
You can attach only identity_id (user) to IoT policy. Also, I can see you have used "attach-principal-policy" API which is deprecated now, so instead of that please use AttachPolicy API
I'm unsure here, still I'd recommend to evaluate and verify it on Cognito's post confirmation trigger
Absolutely right, you can attach a IoT policy to myriad of certificates; technically it is known as Simplified Permission Management
For #3, Relevant Snippet from AWS (Ref - https://aws.amazon.com/iot-core/faqs/ where find Q. What is Simplified Permission Management?)
"You can share a single generic policy for multiple devices. A generic policy can be shared among the same category of devices instead of creating a unique policy per device. For example, a policy that references the “serial-number” as a variable, can be attached to all the devices of the same model. When devices of the same serial number connect, policy variables will be automatically substituted by their serial-number."
Attached graphic is a list of different access levels offered for a particular service. Is there any way I can use the AWS CLI to pull a list of all the different access levels for all different Amazon services?
This is an example picture from 'Alexa for Business' service.
The image you attached is AWS Console's visualization of some actions, these actions roughly maps to the API calls that you can make from the AWS CLI which you can list
AWS do maintain a document that list all Actions, Resources, and Condition Keys for all their services which I believe is what you want
Otherwise, can you clarify your question to show exactly what you want to get from the CLI?
What are the "Access Levels" you are referring to here?
I am new to AWS platform. I am trying to build a backend for a mobile app using AWS lambda, API gateway and DynamoDB using Facebook Authentication of AWS Cognito for my app.
A user are able to logged in to app and data should saved in a table with UserID (which I get from Cognito), data1, data2, data3. This only belongs to this. Let's say those are user's activities.
Again when he login to app next time, he should be able to see all his entered data.
I was looking for the example of it, I found this link which is about fine grained access control where the table is Partitioned with a particular user and permission.
https://aws.amazon.com/blogs/mobile/dynamodb-on-mobile-part-5-fine-grained-access-control/
That doesn't sound right. In a regular RDBMS centered app, the application connects to the database using a specific user in a connection string. User specific data is returned to the user using a query that is constructed on the fly with "username = user_id".
Is this above link talking about something different?
I am confused.
Thanks for your time!!
I believe the article you linked is discussing allowing an app to access DynamoDB directly, by calling the AWS API directly instead of going through a backend application layer. It is using variables in the IAM policy to only allow a user to execute queries against the table that contain their ID as the primary key.
In your case the AWS Lambda function is your backend application layer. You could simply assign an IAM role to the Lambda function that allows it to query all records in the DynamoDB table, and build queries in the Lambda function using the UserID as the query key.
Ok, so using the AWS IoT Thing Registry, you can list all your devices. But "you" means the AWS customer, and would list all devices registered under that AWS customer's custom endpoint.
But what if an AWS customer has multiple end users, that authenticate via e.g. Amazon Cognito Identity and they each have a number of devices. You would not want to have an end user list all e.g. thermostats of a specific brand/standard, but only the one actually registered to him. This is a use case I imagine would be very common, yet I can find no example in the AWS IoT sample code or documentation.
My only idea is to use a "UserId" attribute for each thing, and then filtering on this, when doing a ListThings on the thing registry. But how would you make sure that a user could only list his things, and not other users' things - an IAM policy per user?