No problem and feel free to check back in with any other questions

often collections are also owned by another resource like an organization, which could have

permission list_widgets = ...

for something like

/v1/myorganization/widgets/

Hello all! I'm doing a POC with spicedb to try and replace our handmade permission service, but I'm having lots of trouble wrapping my head around the schema language. I'm trying to implement a permission which seems pretty basic to me:

definition user {}

/* feature flags can be enabled per organisation */
definition flag {}

/* we have multiple organisations in our system */
definition organization {
    /* each organisation has multiple users */
    relation member: user
    /* each organisation has multiple admins */
    relation admin: user
    /* this represents whether this org has the new_admin_dashboard
     * feature flag enabled */
    relation flag_new_admin_dashboard: flag

    /* to access the new admin dashboard, the user needs to be an admin and
     * the org needs to have the new_admin_dashboard feature flag enabled */
    permission view_new_admin_dashboard = admin & flag_new_admin_dashboard // doesn't work :(
}

I just can't seem to figure out how to implement this

view_new_admin_dashboard

permission! I've been reading the docs for hours but I'm probably still missing the correct mental model, could you help me out?

@User sure! the trick is to consider for whom you're checking `view_new_admin_dashboard`; in this case, its a user, so that means your

flag_new_admin_dashboard

needs to end in a set of users for the

&

to work

one option would be to have

flag

link back to its organization

so you could do:

definition flag {
  relation organization: organization
  permission org_admin = organization->admin
}

then, in your `view_new_admin_dashboard`:

view_new_admin_dashboard = admin & flag_new_admin_dashboard->org_admin

that will include all org admins and any org admins "accessible" via the flag (which will only "contains" users if the flag exists at all)

Mmmmh I see, thank you @User! But if I'm understanding correctly that would mean that, when writing my relationships, I need to write both: -

flag:new_admin_dashboard#flag_new_admin_dashboard@organization:my_org

-

organization:my_org#organization@flag:new_admin_dashboard

That's redundant, which makes me sad 😢 For reference, our current system which works very very similarly to SpiceDB (SPARQL-based, also Zanzibar-inspired) is based on checking that a set of relationships exist. So our policy would look something like (this is a made-up policy format):

permission view_new_admin_dashboard: flag:new_admin_dashboard#flag_enabled@organization:{subject} AND user:{object}#admin@organization:{subject}

This does not have the problem of storing duplicated relations, nor do I need the awkward

flag_new_admin_dashboard

relation: I can hardcode a specific flag directly in my policy and have a generic

flag_enabled

relation. I'm super keen to use SpiceDB as it does everything we had to implement ourselves, and very likely it does better! But being able to easily handle feature-flags (and similar things like user settings) is super important for us: is there any other approach I could explore?

yes, you could have the flag just be a relation:

definition organization {
  relation admin: user
  relation feature_flag_new_admin_dashboard: organization#admin
  permission view_new_admin_dashboard = feature_flag_new_admin_dashboard
}

then you just write

organization:foo#feature_flag_new_admin_dashboard@organization:foo#admin

its more terse and direct, but less easy to understand, which is why I showed the other example first

long term, we have this proposal for defining caveats on relationships: https://github.com/authzed/spicedb/issues/386

It's super interesting, thanks! I'll play with it 🙂 I'm a bit confused as to what

organization#admin

means here, but I'll figure it out

it means: follow to the users in the admin relation of organization

It looks like it would work for this example 👍 I am finding that it's not very descriptive of our actual domain though, I'd like to be able to write

user:123 is admin of org:foo

and

flag:new_admin_dashboard is enabled in org:foo

and walk through these relations to decide permissions. Here I'd have to write

the admins of org:foo have feature_flag_new_admin_dashboard in org:foo

which doesn't make a lot of sense (

feature_flag_new_admin_dashboard

shouldn't really be a relationship) and encodes part of the permission logic within the relationship (the user needs to be an admin of the organisation), which makes it harder to evolve in the future.

I'm having a more complex use-case for which this approach wouldn't work I think, I'll be a few minutes 😄 I'm not trying to complain about SpiceDB at all, just trying to get my head around it to understand what's possible or not, and give what's hopefully constructive feedback 😃 if we do manage to make it work for us, I'd be super happy to document all of that for future users with similar problems!

yes, its less "accurate"

well, you'd rename the relation to make it more correct: its not that the admins have feature flag

but rather access to the new admin dashboard

so the relation could be

relation new_admin_dashboard_viewer

Feature flags toe the line on being authorization or not, so it might not always map as cleanly as you'd like. A good way to think about what should be in SpiceDB or not is whether or not another (micro)service would ever want to also check for that relationship/permission.

that's why the previous example walks through the feature flag: in that case, the relation is correct in having the flag on the org

but it does require the extra relation back for the walk

another option would be to link the flag back to the org itself:

definition organization {
  relation admin: user
  relation feature_new_admin_dashboard_enabled_on: organization
  permission view_new_admin_dashboard = feature_new_admin_dashboard_enabled_on->admin & admin
}

(naming needs work)

> the relation could be relation new_admin_dashboard_viewer "Viewer" is already a matter of permission though: admins can "view and manage" the dashboard while non-admins can only "view", and we can imagine inactive users who can't do anything. Feature flags in our system are applied on orgs, not users. Modelling it to be per-user is always going to be confusing for us: our developers writing permissions will want to express "this permission is given if the user is an admin and its org has the feature flag XXX enabled". That's not necessarily a dealbreaker but is less than ideal! > A good way to think about what should be in SpiceDB or not is whether or not another (micro)service would ever want to also check for that relationship/permission. Yes, our microservices do need to check permissions that are dependent on feature flags > but it does require the extra relation back for the walk Out of curiosity, is there a technical reason why the permission must express a set of paths ending on a user, rather than any set of paths at all?

> another option would be to link the flag back to the org itself: Lemme play around with that!

it doesn't have to end on a user, but rather the subject you're checking