Does SpiceDB support relation hierarchies (e.g. operations on relations)?

[seeruk]

Hey there, just evaluating using SpiceDB for a couple of upcoming projects, it looks like a really fantastic tool, congratulations on this implementation. Thank you for open sourcing it!

One of the things I'm looking to do is implement RBAC within a couple of apps. This all seems 100% possible with SpiceDB already, but I'm wondering if there's a better way to implement role hierarchy. For example, if a user has the writer relation, I'd like to be able to have them automatically inherit the capabilities of the viewer relation, rather than defining writer against all of the permissions that viewer has access to.

For permissions themselves this of course can be implemented using union operations, but would it be possible to do something similar for relations? I think the semantics differ really so I'm not sure what that should look like necessarily.

I don't think this would be how to do it, but you should get the idea from this:

definition user {}

/** resource is an example resource. */
definition resource {
	relation viewer: user
	relation writer: user -> viewer

	permission view = viewer
	permission write = writer
}

In this case, the writer relation would have both the view and write permissions.

Honestly, I can see that this might've been something you've already discussed but decided not to do. In cases like the above it looks a little pointless, and in larger cases you could certainly argue that it's not as clear. Either way, it's not a deal breaker for my use-case by any means - it's just something I'd seen in some other systems (e.g. quite a long time ago when I worked with Symfony, the RBAC system there supported role inheritance).

[jakedt]

This is something that Zanzibar supports out of the box, and that we actually supported in our v0 APIs. It is something that we explicitly chose to move away from when we created the schema.

You can accomplish what you want by just referencing a computed permission from another permission:

definition user {}

/** resource is an example resource. */
definition resource {
	relation viewer: user
	relation writer: user

	permission view = viewer + write
	permission write = writer
}

By having a strict separation between permissions (computed) and relations (direct relationships) we get:

• flexibility to mutate permissions freely while being able to reason about the computation complexity
• a convenient place in the schema to talk about the types of the subjects of relationships
• a way to avoid needing a reference to the self-relationships in a computed relation (_this{} from the paper)

consider the schema:

// THIS IS NOT REAL SCHEMA, DO NOT COPY

definition user {}

/** resource is an example resource. */
definition resource {
	relation viewer: _this{} + writer
	relation writer

	relation fully_synthetic: viewer + writer
}

Now:

• when we call Check on resource#viewer we are subject to whatever computation complexity determining writer happens to require
• unable to know what type viewer will have relationships to
• potentially confused by when _this{} is required or not, and why writes to fully_synthetic succeed but don't have any effect on Check calls to resource#fully_synthetic

[seeruk]

Aha, that's pretty handy there. So the above is saying "if you can write, you are also able to view things"? That's perfect in that case.

That all makes sense. I had a feeling it may have been a conscious decision to omit it. Thanks for taking the time to explain why!