i want that the user should acces only
# spicedb
d
i want that the user should acces only one platform not the other one,but how to make the difference at authorization level that , using this schema and relation , here a user is being able to access the both platform that should not be the case.
y
like you're essentially wanting to enforce that a user can't have access to multiple platforms?
there isn't a way to enforce that at the schema level
it's something that people ask about but there isn't an obvious way to do it with the current architecture of SpiceDB
the typical way that we recommend doing it is to either use a
Precondition
on the
WriteRelationships
call when you go to write a new relationship, or else use a
Check
call if the
Precondition
isn't sufficient (because a precondition just asks whether a single hop/relation exists, rather than being able to ask about a full permission check)
d
Yes exactly, i want in my system that if user is assigned to particular platform it cant access the other platform keeping the names of other definitions similar. Here in this case , user is not able to distinguish the user its being assigned to basically it can bypass the Authorization level and can easily any platform but i want that user is authorized to one platform . I still didn't get ur solution much, Do u have any doc on this precondition so that i can clarify and able to clear this for Authorization
y
> if user is assigned to particular platform it cant access the other platform this is a different idea than what i'm talking about, though. if there's not a relation or a path between a platform and a user, a user won't be able to access resources that are only associated with that platform or path.
when you say "access" are you talking about at check time or when you go to modify a user's access to give them additional access?
d
right now i am working on spicedb playground only so i am checking it as assertion , so when i say access its at check time
definition platform { relation client: tenant relation members: user permission can_access = members + client->can_access } definition tenant { relation advertising: ad_account relation members: user // Renamed permission to follow best practices permission can_access = members + advertising->can_access + advertising } definition ad_account { relation branding: brand relation members: user relation tenant: tenant // Renamed permission for consistency permission can_access = members + branding->can_access } definition brand { relation modules: module permission can_access= modules } definition module { relation planner: user relation viewer: user relation approver: user relation admin: user permission view = viewer + planner + approver + admin permission edit = planner + admin permission approve = approver + admin permission delete = admin permission create = planner + admin } definition user {}
and relation // Assigning tenants to the platform platform:sphere#client@tenant:tesco-uk platform:sphere#client@tenant:foodstuffs-nz platform:square#client@tenant:tesco-uk // Assigning Ad Accounts to a Tenant tenant:tesco-uk#advertising@ad_account:TUK-dove tenant:tesco-uk#advertising@ad_account:TUK-dove // Assigning Brands to Ad Accounts ad_account:TUK-dove#branding@brand:dove // Assigning Modules to Brands // brand:dove#modules@module:insights_ brand:dove#modules@module:insights brand:dove#modules@module:measurement brand:dove#modules@module:booking // Assigning Users to Ad Account (Users must belong to an Ad Account) ad_account:TUK-dove#members@user:josh ad_account:TUK-dove#members@user:ram ad_account:TUK-dove#members@user:shyam ad_account:TUK-dove#members@user:ravi // Assigning Users to Roles in Modules (Role-Based Access) module:insights#planner@user:josh module:measurement#viewer@user:ram module:booking#approver@user:shyam module:insights#admin@user:ravi
-------------------------------------------
that user issue with the platform is also there
issue 2- (which is similar to above issue)--------------------------------------------- look in this relations , if i assign same user to another ad_account: tuk-parle,
then user:josh can access the module:insights as viewer and here also i cant distinguish the role for two other ad_account
// Assigning Ad Accounts to a Tenant tenant:tesco-uk#advertising@ad_account:TUK-dove tenant:tesco-uk#advertising@ad_account:TUK-dove tenant:tesco-uk#advertising@ad_account:TUK-parle // Assigning Brands to Ad Accounts ad_account:TUK-dove#branding@brand:dove ad_account:TUK-parle#branding@brand:parle // Assigning Modules to Brands // brand:dove#modules@module:insights_ brand:dove#modules@module:insights brand:dove#modules@module:measurement brand:dove#modules@module:booking brand:parle#modules@module:insights // Assigning Users to Ad Account (Users must belong to an Ad Account) ad_account:TUK-dove#members@user:josh ad_account:TUK-parle#members@user:josh ad_account:TUK-dove#members@user:ram ad_account:TUK-dove#members@user:shya ad_account:TUK-dove#members@user:ravi // Assigning Users to Roles in Modules (Role-Based Access) module:insights#planner@user:josh module:insights#approver@user:josh module:measurement#viewer@user:ram module:booking#approver@user:shyam module:insights#admin@user:ravi
------------------------------------------look here after changing relation , i cant differentiate , i want that tuk-dove should have viewer access in module:insight and same user:josh should have the approver access in ad_account:tuk-parle in module:insights. but it can be done here .
#CHECK WATCHES FOR REFERNCES
----------------------------------------------
What changes should i do in schema according to you to achieve this
To fix this problem
According to you
y
you'd need a different permission on the
ad_account
it would also need to have a
view
permission and an
approve
permission
d
can you write down the schema for this , i am not able to write down on my own ?
y
Copy code
definition user {}

definition organization {
  relation viewer: user
  relation editor: user
  permission view = viewer
  permission edit = editor
}

definition resource {
  relation viewer: user
  relation editor: user
  permission view = viewer + organization->view
  permission edit = editor + organization->edit
}
you might name things a bit differently, and the structure will be slightly different for your use case
but the point is that you need a separate permission on the "parent" object for each of the permissions on the "child" object
d
I understood this , if you you look at my schema , i am initiating user at module level , and you telling me to add these permission at one level above this in adaccount which i am already assigned in module level, i am missing, how can i do this.
Just give a look at schema
y
yes, my point is that you need them at both
d
ok will send new update schema
2 Views