https://authzed.com logo
Join Discord
Powered by
what i'm getting at is that spicedb
# spicedb
y
what i'm getting at is that spicedb answers questions about "does user X have permission Y **on object Z**"
f
The main idea here is to have an admin page where we can assign permissions to users. So, when I open the admin page for user A, I need a way to see what permissions they already have so we can display that. Ideally, we’d pull that info directly from Authzed so we don’t have to keep our own copy and worry about it getting out of sync with them.
y
what do you mean by "assign permissions to users?"
like what i'm trying to get at is that if I were to say that the permission is "unlock," what would it mean to say "Felix can unlock?"
unlock what? the computer? the car? the gate?
can you give me a concrete example of what your customer would refer to as a "permission?"
f
definition telecom26_boss/portaluser {} definition telecom26_boss/account { relation parent: telecom26_boss/brand relation owner: telecom26_boss/portaluser relation viewer: telecom26_boss/portaluser relation end_user: telecom26_boss/portaluser relation location_viewer: telecom26_boss/portaluser relation subscription_manager: telecom26_boss/portaluser relation alert_manager: telecom26_boss/portaluser relation billing_manager: telecom26_boss/portaluser relation subscription_state_manager: telecom26_boss/portaluser relation engineer: telecom26_boss/portaluser relation supporter: telecom26_boss/portaluser relation internal_user: telecom26_boss/portaluser permission view_subscriptions = owner + viewer + end_user + supporter + parent->view_subscriptions permission view_usage = owner + viewer + end_user + supporter + parent->view_usage permission view_charges = owner + viewer + supporter + parent->view_charges permission view_alerts = owner + viewer + end_user + alert_manager + supporter + parent->view_alerts permission view_geolocation = location_viewer + supporter + parent->view_geolocation permission view_internal_fields = supporter + internal_user + parent->view_internal_fields permission view_engineering = engineer + supporter + parent->view_engineering permission manage_subscriptions = owner + supporter + subscription_manager + parent->manage_subscriptions permission manage_subscription_state = owner + supporter + subscription_state_manager + parent->manage_subscription_state permission manage_billing = owner + supporter + billing_manager + parent->manage_billing permission manage_alerts = owner + alert_manager + parent->manage_alerts permission manage_steering = supporter + parent->manage_steering permission manage_applet = supporter + parent->manage_applet permission manage_users = supporter + parent->manage_users }
...
y
so in this UI, would we already be in the context of a particular account?
like would the url be 
/manage/accounts/1234
and then the UI is saying "this is the stuff that a user can do on account 1234?"
f
No
A user belongs to a brand, brand has accounts accounts have billing groups and billing groups have ... other stuff
so for a brand and given userX I want to know all the permissions it has on all accounts
y
as in any permission that the user has on any account, or as in any permission that the user has on all accounts at the same time?
t
So let's say these are the permissions for a user: Brand: 
null
Brand ->Account 1: 
manage_steering
Brand->Account 2: 
manage_applet
You want to return 
[manage_steering, manage_applet]
?
Noting that there isn't any resource where the user actually has both of those permissions
f
It would be "any permission that the user has on any account" Like that if user has 
Brand ->Account 1: manage_steering
I will not add that permission again but another one
y
that's something that you could add additional schema to express
you'd need to add a relation from the brand to the account as well as the account to the brand
and then you'd define 
any_manage_*
permissions on the brand, which walk to the associated permission on an account
and then rather than bulk checking on every account * every permission on the account, you'd bulk check on every 
any_manage_*
permission on the brand, which is a smaller set and can take advantage of SpiceDB being able to return early when it finds a positive result
it's still going to be a pretty heavy query
but it'll be easier to phrase and more performant
i can provide an example if necessary
f
ahhh ... yes please because I am not quite seeing what you mean
y
Copy code
definition user {}

definition brand {
  relation owner: user
  relation user: user
  relation account: account
  permission any_view_usage = account->view_usage
  permission any_manage_steering = account->manage_steering
}

definition account {
  relation brand: brand
  permission view_usage = brand->user
  permission manage_steering = brand->owner
}
this is a simpler schema than the one you provided but it should still capture the same structure. you'd ask 
account:someAccount#view_usage@user:someUser
to see whether a user can view usage on an account. you'd ask 
brand:someBrand#any_view_usage@user:someUser
to see whether a user has 
view_usage
on any account associated with the brand. you'd use 
BulkCheckPermission
to ask the above for all 
any_*
permissions on the brand.
the one bit of nuance is that when you write the relation between the account and the brand, you'd also need to write a relation between the brand and the account (because relations are directional)
f
OK, thanks!
3 Views
PreviousNext
Powered by