Problems modelling mixed RBAC with explicit resource access plus super-role

[dgg]

Hi everyone,
My team is evaluating the future usage of SpiceDb/AuthZed for authorization of the applications hosted in our upcoming platform.
In order to evaluate it, we want to model and run some tests with a schema that we have used in an application. But we are having quite some problems with the modelling side of it that is making us wonder whether this is the right product for us.

The model is (we believe) simple:

graph LR
    U((User)) -- belongs_to_single --> T((Tenant))
    U -- invited_to_many --> T
    U -- member_of_single --> R((Role))
    U -- access_many --> D((Device))
    U -- access_all --> D
    R -- performs_many --> A((Action))

A user belongs to one and only one tenant. But can be invited to many other tenants.
Each user is member of a single role in each of the tenants (the single one the belongs to or any of that the user was invited).
Each role can perform multiple activities.
On top of the activities, the user can access some or all (present and future) of certain devices. However, if the user is member of the "admin" role in one of the tenants, it has access to all (present and future) devices as well as the ability to perform all activities.

We started to model the role/perform activity and user/access device to begin with (leaving aside the multi-tenant complication for later).

We came with this model (https://play.authzed.com/s/ZmlkPjNebzgl/schema):

definition user {}

definition role {
	relation member: user

	permission is_member = member
}

definition activity {
	relation performer: role

	permission can_perform = performer->is_member
}

definition device {
	relation accessor: user

	permission can_access = accessor
}

That, alongside these relationships (https://play.authzed.com/s/ZmlkPjNebzgl/relationships)

user:adm belongs to role:admin
user:usrA belongs to role:common
user:usrB belongs to role:common

device:1 can be accessed by user:usrA
device:2 can be accessed by user:usrA
device:3 can be accessed by user:usrB

activity:manager can only be performed by role:admin
activity:dashboard can be performed by role:admin and role:common

Allows us to test (https://play.authzed.com/s/ZmlkPjNebzgl/assertions) the access to perform act
activities by role:

assertTrue: [
     "activity:dashboard#can_perform@user:adm"
     ,"activity:dashboard#can_perform@user:usrA"
     ,"activity:manager#can_perform@user:adm"
]

And explicit access:

assertTrue: [
     "device:1#can_access@user:usrA"
     ,"device:2#can_access@user:usrA"
     ,"device:3#can_access@user:usrB"
]

We are not able to model successfully the fact that all user assigned to admin role can access all devices.
We would also like to omit the assignation of the admin role to each and any of the activities if that would be possible (it is a minor annoyance).

We have read blog posts, checked community examples and watched the videos, but we cannot "connect the dots" on how to implement the super-user pattern on the transitive user/role relationship.

Thanks in advance for all the help.

[vroldanbet]

@dgg what you present is a recurring use-case for SpiceDB, and is something similar to our GCP Cloud IAM example, which should cover your requirements. This example shows how to model a schema that supports creating roles with specific permissions in runtime.

If you don't need runtime-defined activities/roles, I'd suggest skipping that and modeling the activities in the schema. I assume this is not your case but for the sake of illustrating

definition user {}

definition tenant {
	relation member: user
	relation adminers: user

	permission admin = adminers
}

definition device {
	relation tenant: tenant
	relation accessor: user

	permission can_activity_1 = accessor + tenant->admin
	permission can_activity_2 = tenant->admin
}

To implement "admin has access to all devices" you need to have an entity that connects to all devices. Everything is a graph and the key is to create the relations that connects those.

• if admins have access to only devices in a tenant, then a device must have a relation to the tenant, and the user must be an admin in the tenant. It's the inverse of how you modeled, roughly
• if you are referring to "platform-wide admins", you can define yet another object (we typically refer to these as the platform object) that links to all the tenants.

[dgg]

Thanks for getting back to me.
I will check the resources you provided and give it another spin.

[dgg]

Well, I gave a fair shot at the IAM example.
Although I think that I understand the purpose of such example, it seems that my modelling brain is not ready to make the connections and identify similarities and differences between what is in the example and my use case (I believe mine is simpler, but I cannot tell).
My frustration also comes from the fact that I am unsure about how to get better at it so that I can help others within my organization.

I really like the idea of SpiceDb, the tooling around it and the APIs... for the very simple examples that I was able to successfully model.
However, I think that there is a non-trivial obstacle when it comes to the initial step of modelling that could deter people from using the product (it is definitely very close to cross it from the list of candidates for my organization).

There are examples, and they are somehow described (not explained) but I would find more comfortable with recommending SpiceDb if there was more documentation on the modelling topic. The whys, the procedures, the patterns, the pitfalls, ... Without those, I found very difficult to move beyond a simple example.

A very good example on the kind of documentation that I am missing would be the training material that MongoDB University offers around data modelling (https://learn.mongodb.com/courses/introduction-to-mongodb-data-modeling).

[corkrean]

Hey @dgg, Thanks for this feedback. We are in the process of improving our docs, so this feedback is really useful, and we will pass it on to the documentation team.

We want you to be successful with SpiceDB. It seems that you are in a situation where a live schema modeling session would be helpful. If you're interested in setting up a chat to work through your schema with me, send me an email at evan.corkrean@authzed.com