Replies: 2 comments
-
When we have a look at this, we might also take into consideration, that admins are able to define their own roles and add the permissions. This is already defined in the following issue: #5257 |
Beta Was this translation helpful? Give feedback.
0 replies
-
What might be worth is defining some use cases / requirements especially for queries to these tables. some that come to my mind:
This brings up the question if we should have a look at zanzibar at least for internal permission checks. Zanzibar is built to answer those questions, maybe more fine grained that we need it: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently ZITADEL defines organization and instance member roles and permissions in
defaults.yaml
. The permission check is done on API call level. For example: "is this user allowed to make this call on this org". This makes sense on the V1 API where the API is permission-level shaped. For example, a search for users always happens in the context of the organization. (Either the organization the calling user belongs to, or through member ship and thex-zitadel-orgid
header.The problem
However, the v2 API is resource based. For example the "users" resource. From a resource perspective organizations will be a different resource and the fact that users belong to organizations is somewhat irrelevant. When an API client is calling the v2 users API to search users, it should be able to search all users from their instance. The fact the users belong to an organization does no longer matter. The caller can still search for user from a particular org, but this is not a hard requirement.
user.read
must be a constant defined by the search query. As the query "knows" what resources it is going to read.So a primary filter has to be done:
However, the current model does not allow:
user_id
androles
.roles
is an array of text in theprojections.org_members
table.roles
bypermission
, because permissions are defined as array values to a role key indefaults.yaml
.permissions
are not in the database at all.This gives a new challenge to managing permissions. The calling user can have
user.read
permission on 0 or more organizations. Using the current permission-model will need to search the database for all memberships a user has and which roles that user has on each organization. Then, search the permissions from runtime configuration (defaults.yaml
) and boil it down to a list of organizations the user is to read and apply it as aresource_owner
filter on the user query. This is a huge hassle and probably bad performance due to the extra round trips to the DB.Proposal
Move permissions into the database. This is an example schema loosely based on current projections, roles and permissions but trimmed down for demonstration purposes. It creates the possibility to search organizations by
user_id
of the Calling User and the required permission.Example data
We can now build a search query that looks like:
The query takes
instance_id
and theuser_id
of the user doing the search query.It searches on which orgs the
user_id
has permission 'user.read' and joins that with the result set.In this example we are searching for users created after a certain date, the third argument.
Try it out on db fiddle.
Still to be defined
CC: @livio-a (auth related), @adlerhurst (db related), @stebenz (resource related)
Beta Was this translation helpful? Give feedback.
All reactions