https://authzed.com logo
Join Discord
Powered by
depends on how you see the permissions
# spicedb
j
depends on how you see the permissions evolving over time; you can start with a direct mapping and change it if you ever need to do so in the future
i
Right I think that's what the plan is currently. I guess my question is specifically around how the definitions would look like for that mapping. So instead of something like this:
Copy code
definition user {
}

definition service {
    relation admin: role#member

    permission administer = admin - admin->deactivated_self
}

definition role {
    relation service: service
    relation member: user
}
j
(other note: its better to have a relationship for activated than an exclusion for deactivated)
more data stored, but faster API calls in common cases
or handle activation at the authn layer
i
You would instead just break out the roles into individual definitions that you would create relationships with:
Copy code
definition user {}

definition developer {}

definition service {
  relation developer: developer
  relation user: user
}
And then have different permissions based on each? Sorry for the horrible example lol
The first example feels like a traditional RBAC approach while the second feels more like ReBAC, only downside with the second is that you end up with far more relationships and slightly more complex logic on each resource that a user, developer, etc. would need to access
j
traditional RBAC-in-ReBAC is perfectly fine
so long as you don't see a need in the future for those distinct roles
if you don't think you'll need that flexibility in the future, stick with the simpler approach
if you do, go with the more flexible one
you can always migrate later too
although its harder, of course, once you have a bunch of relationships already written
but schema does allow you to migrate in place
i
Gotcha thank you!
5 Views
PreviousNext
Powered by