do you plan on adding user management API so that we can create and assign users to organizations using API ? Or is there anyway to integrate with oauth or JWT tokens? The idea here is to automate user creation from an app.
We like to have an api token per device, so if we have 1000 devices, that’s 1000 tokens right? Do they expire? There isn’t a limit on how many we can have correct?
- Do you plan on adding user management API so that we can create and assign users to organizations using API?
Yes, our frontend already uses an internal API to create users and assign them to an org. While we haven’t added it to our official documentation (as it might have internal changes), we do plan to add it in the next months.
- Or is there anyway to integrate with oauth or JWT tokens?
We have done integrations using JWT tokens. Please contact our support team at support@ubidots.com for more information.
- We like to have an api token per device, so if we have 1000 devices, that’s 1000 tokens right? Do they expire?
There isn’t a limit on how many we can have correct? If you create these tokens from our web interface (“My Profile” tab) then they won’t expire. If you create them using our API key end-point (see here) then they will expire after 6 hours if not used. There’s no limit on how many you can create.
If I have a user who has access to a sub-set of all my devices - say only the devices in a group. Can I give them an API key for that group?
Also, if I give them an API key, does that give them all the capabilities of that key (delete, change and read) or can I limit the key to only allow read access to the devices they see.
Actually, @jotathebest - I think I have the answer but don’t know how to implement it.
When I set up a new user on my app portal, I should be able to generate an API key for that user as well.
This key would have the same device visibility and the same privileges as the user. I tried logging in as a user on my app portal but could not find a way to generate an API key.
So, if there is no self-service model, is there another approach?
Greetings @chipmc, actually the API Key is unique to your global account, the granularity that we have already implemented for end-users is called device token, which is a key that allows you to send or retrieve data only to devices that belongs to a certain organization. The actual limit that you can set actually with this token is related with the limits of the token’s organization.
Said this, we already have in our roadmap the implementation of token policies per device, this will allow you to better implement business logic not only talking about read/write permissions but a per device-based custom business logic. We hope to deploy this functionality in our next Quarter releases.
OK, if I understand you correctly, I could give an end-user an API token that is tied to the organization. Then that API key would be able to “see” the devices that organization has access to and would be able to “do” what that organization is authorized to do with those devices.
This meets my needs for now. I look forward to seeing what you come up with next.
Hi @chipmc, yes, you can create organizational tokens and with them to split your devices into organizations pools. Please keep in mind that an organizational token actually has read/write/delete permissions, unfortunately we do not have implemented yet a token policy but this is something already in our roadmap.
Sorry to be a pain here but, I realized we still have a problem. At a minimum, the documentation for organizations needs to be updated to clearly state the following:
An App can have multiple organizations under it.
However, an organization has the following characteristics:
a device can only be in ONE ORGANIZATION
a dashboard can only be in ONE ORGANIZATION
but, a user can be in MULTIPLE organizations.
This creates a problem for a typical hierarchical organization in business. You cannot set up a top-level organization that can see all the devices and dashboards unless you let every subordinate organization’s users see every device and dashboard. This is a problem.
Here is an example. Imagine a state park system with a state level organization and a larger number of park organizations. The group at the State level needs to see all the parks and dashboards while the individual park personnel only need to see their park’s dashboard and devices. From what I can see, there is no way to do this in Ubidots today.
The devices are either in the park-level organization or at the state-level. In one case, there is no single API key for the state-level folks to use to access all the devices in all the parks. In the other, the park personnel see a bunch of sensors in parks they are not interested in.
The simple fix would be to allow a device - like a user today - to be in more than one organization.
There may be a better way of doing this and, if so, please let me know.
Hi there @chipmc, my apologies for this tardy response, I was out during holidays. Please allow me to share with you a possible solution to your use-case:
The way to do this is to create an organization per park with its related devices, then, you just need to add the users from the state level to every park organization and the personnel just to their related park, in this way the personnel can access just to the park’s devices while the state level will have a larger device access (all the devices in the park).
Thank you for getting back to me on this. This is how I had things set up originally but, correct me if I am wrong, this approach would require the NC state folks to manage a number of different API keys - one for each park. What I am looking for is an approach that would allow them to see all the parks and access the data using a single key.
I think it may make sense to allow the following:
A device can belong to multiple organizations - just as users already can
A key can be generated for an organization - this gives the key its scope
Keys - again like users - can be assigned roles - this gives the key its permissions
I need to be able to define both the scope and the permissions for API keys. Unless I am missing something, this is not possible today.
Hi there @chipmc, you are right, from your previous message I thought that you were inquirying about user management for visualization purposes, not API key control, my bad.
Actually, an approach as the one exposed by you is not possible with our actual token management. This week we will have an internal product management and we will discuss the new token policies feature. I will add your comments in the meeting.
We will come back with you once we get an advance in this development.