https://authzed.com logo
Join Discord
Powered by
be helpful to craft an example here, if
# spicedb
j
be helpful to craft an example here, if you don't mind
r
Yes sure, let's say we have: Sales and Support as jobs. If you are Sales you should have internal_admin relationships with accounts, if you are Support you should have internal_tech relationships with accounts The accounts you should have relationships with will be syncd from accounts in your Book of Business in the CRM user:alice has a job Sales; also account:123 in her Book of Business in the CRM this should ultimately allow me to ask does "user:alice have internal_admin on account:123" and answer should be true I change user:alice job to Support and the previous query should be false, and this query, does "user:alice have internal_tech on account:123" should be true I decide actually Support should allow internal_admin, then does "user:alice have internal_admin on account:123" should be true again, while "user:alice have internal_tech on account:123" would be false
j
> I decide actually Support should allow internal_admin
and is this per-account
or a global decision?
r
This would be global So user:bob who is also Support with account:456 in book of business should now also get true for the query "user:bob have internal_admin on account:456"
j
okay, this sounds like you want access to be granted via a role
so something like...
Copy code
definition user {
  relation role: role
  permission is_internal_admin = role->is_internal_admin
}

definition role {
  relation can_admin: organization
  permission is_internal_admin = can_admin->member
}

definition organization {
  relation member: user
}

definition account {
  relation user: user
  permission can_admin = user->is_internal_admin
}
(note the above is not necessarily the best design, just one I threw together)
so each user would have one (or more) role(s), each which (in turn) links a 
can_*
to the organization's members
now when you add a 
user
to account, you're asking if the user also has a role with 
can_
for the specific permission
if there are no organizations, this can also be done using wildcards in place of 
organization->member
r
Thank you
I'm wondering what do you see is the difference between a "permission" and a "relationship"? We were thinking we would have multiple types of roles/relationship a user would have with an account, and those relationships would end up with a different set of permissions, something like this definition account { relation internal_admin: user relation internal_tech: user relation external_admin: user relation external_tech: user relation external_read_only: user relation external_billing: user permission write = internal_admin + external_admin + internal_tech permission view = internal_admin + internal_tech + external_admin + external_tech + external_read_only permission view_dianostics = internal_admin + internal_tech + external_tech permission write_billing = external_admin + external_billing }
j
a relationship (defined over a 
relation
) is a piece of data
connecting two objects
a permission is computed
r
Ok so this is more of a performance thing, and not necessarily and conceptual thing?
j
what is?
a
relationship usually are defined as noums "the user is MANAGER of email x" the permission is computed based on relationships and are usually defined as verbs (edit, remove) you can`t add data in permission only in relationships.
r
I guess I meant in terms of checking access to a resource there's no difference between the two. But a relationship is a stored record and a permission is computed relationship
j
correct, but you should avoid checking relations directly
because you might want to rename the semantics down the road
so its always recommended to check a permission
even if that permission is simply
permission view = viewer
PreviousNext
Powered by