First time I read about ReBAC, I thought it allows to define any graph and specify access control on top of it. But for now it looks like ReBAC allows only one relation type — parent/child. Thus it's only trees. Is it correct? Don't you think, that a better name for ReBAC would be hierarchy-based access control (HBAC)?

I don't think that'd be accurate, you can certainly define cycles. I fact SpiceDB has a maxDepth parameter to detect that kind of loops

oh, good argument. There is can be Folder resource which is part of Folder. But it is still parent-child relationship. May you have a look at my example? I have three resource types. User, Group & Person. Group resource points to two lists. managers & members. They are many-to-many relationships, but in my domain model Group resource manages both lists, that is why arrows points from Group resource. My security policy is > Manager can see all their Groups and Persons in those groups. It feels natural to say, that user has access to person if the person is a member of the group user has access to. And this makes me reverse relation write

person:p-1#member@group:gr-1

instead of

group:gr-1#member@person:p-1

So I had to transform my graph into hierarchy. Is it possible to write relation

group#member@person

and implement the policy I need?

you can walk from user to group back to person if you wish; its really a matter of how you define your relationships

and how can I define

read

permission for person in this case?

definition user {}

definition group {
  relation manager: user
  relation member: group
}

definition person {
  permission read = member; // wrong
}

SpiceDB reports a problem > relation/permission

member

not found under definition

person

you need to define a relation linking the person to its group

ok. this time it's ok. And we are back to hierarchy. 😄

definition user {}

definition group {
  relation manager: user
}

definition person {
  relation member_if: group
  permission read = member;
}

but then my triplet

group:gr-1#member@person:p-1

is wrong. It must be reversed.

person:p-1#member_of@group:gr-1

. It leads me to another question. Can I tell SpiceDB that relation

group:gr-1#member@person:p-1

implies relation

person:p-1#member_of@group:gr-1

?

no; you'd need to write that relationship

I have an endpoint to save Group resource and I need sync my data with SpiceDB.

PUT /Group/gr-1

member:
- id: p-1

I would like to have the same graph model in my app and SpiceDB. But as we can see, in order to implement my security policy, I have reverse relationship between Group and Person. It is not possible to do it in my app, and I want to if I may just push relationships from my app to SpiceDB as is, or I have to implement some logic on the app side to find out how to write triplet into SpiceDB

you'll need to write the two relationships, yes

isn't it the same? 😮

no, because its walking up and then back down again

This is not clear for me. My model still looks hierarchical. And the movement I can see is also just up, up and up. person → group → user. Do you mean implementation details of SpiceDB? Or ability of ReBAC/SpiceDB to cover more complex scenarios than I imagine by sticking to hierarchies? Maybe I don't see some hidden and/or important part. Could you, please, help me to understand it? If you have some materials which may shed the light on this, it would be great.

It’s a mental model

I'm investigating, how next-gen authorization systems can be applied to Aidbox, a platform for building healthcare applications. Applications on top Aidbox may have various security policies. Currently we support request-level policy engine and sql customizer for auth purposes. But those features looks ad-hoc in comparison with next-gen auth systems (Zanzibar-like). I want to understand opportunities next-gen auth systems provides, constraints they have and integration requirements they expect. The happy path I wish to see is telling developers > Just point Aidbox to SpiceDB, define your authorization model in SpiceDB and get your secured FHIR API. Maybe extra configuration on Aidbox side is required, but I would like Aidbox to be able just to read SpiceDB definition schema and know 1. what triplets to send to SpiceDB. 2. what questions to ask on authorization steps. You helped me disprove my hypothesis that I can map FHIR model to SpiceDB as is. As it turned out, I need sometimes to store reversed relations. My second hypothesis is that ReBAC is suitable for hierarchies only. Perhaps, I should have notice that I mean hierarchies more from user standpoint. E.g. as a manager, I can see list of my groups, and drill down to each of them a see the list of related persons. But if we also allow users to see groups they are member of, and let managers to take part in groups, then generally we will not have hierarchy in authorization model. We still may have two different hierarchies in our application (

User(manager) → Group → Person

and

User(member) → Group

), but not in the auth model. I think I agree, that hierarchy badly describes ReBAC. But what did you mean by 'upside-down "V" shape'. I can't find anything on Google.

if your downstream users will be specifying the model, it might be worth allowing for user-defined roles, or a more dynamic schema

You mean implementation user-defined role in spicedb? we have user-defined roles in Aidbox. But security policies still look hard to develop & analyse.