Currently, if a Tulip API token has the tables:read / tables:write scope, the client using it can read / write all Tulip tables without distinction.
I find that this is not granular enough since there can be cases where a client should only access specific tables and not all of them. This is especially important regarding the writing scope. I think this can also interest Tulip customers who significantly rely on numerous Tulip tables and people in charge of data security.
I suggest to refine the tables:read and tables:write scopes per-table. The idea would be to allow an API token to read or write specific tables while preventing read / write access to others.
Hello Fabien, this is definitely something we want to add in the future.
The way we have been thinking about it is to add the concept of a table “owner”, and allow that owner to give access to individual users, user groups and API keys to modify the table or table records in certain ways.
What do you think of that approach? Its sort of the inverse of what you proposed, but also solves for the problem of “which users can edit this table?” at the same time.
That sounds interesting to me! It would be nice if we had a possibility to manage access for all tables from a single location (otherwise that would mean manually going to every table to configure access).
The owner terminology is very consistent with the Account Owner and Workspace Owner role names, i.e. an owner has all rights and decides what others can do with the resource they own.
I notice that you don’t mention the ability to define a user group as an owner. I don’t know if that would be desirable?
I find it nice to distinguish the ability to modify the table’s structure and the table’s records. This gives a lot of flexibility.
Regarding the table “consumers”, users, user groups and API keys all make sense. I wonder if apps should also be considered though, since I see a slight difference in terms of access management when comparing with the shop floor (hoping I’m not mistaken):
In the shop floor, the app is assigned to the station. If the user has physical access to the station, he has access to the app. Which means that we enforce access by relying on physical/organizational security (assuming no custom in-app access control). Which also means the user itself doesn’t really matter when configuring app access.
With your approach, table access is mainly conditioned on users (or API tokens). There is no way to tell that a given app is not authorized to access to a table.
All of this makes me wonder:
Should app access also be conditionable on users?
Should table access also be conditionable on apps?
And, if an access is conditionable on both users and apps, which configuration has priority (assuming we can apply both at the same time)?
Thanks for this! Yes, agreed that it opens up a lot of product questions, and it could create a convoluted mess of permissions if we don’t implement it correctly.
To quickly touch on app access- as of LTS13.4, you have the ability to restrict user access to an app in a maintainable way. You will just need to add a trigger on “App Start” that checks a user’s user group membership within an “if” statement, and then kick them out of the app if they are not a member of the right user group. So, it is not formally recognized on either the app or stations page, but certainly possible.
A user group would certainly be desirable to be owners of an asset. That would be part of the first launch of this feature.
There should certainly be a distinction between table and table record permissions- I imagine we would do table permissions first, because table records open up other questions, as you highlighted.
We are still thinking about how to implement the “app access to tables question”. You could argue that it could be solved through the approval process of a new version of an app, if we made our approval feature more flexible. But yes, these are the right questions!