Circular relationships

[imclem]

Hello there 👋

I'm looking for guidance and understanding with circular relations.

I've got the following schema (which is already used in production):

definition user {
	relation manager: user
	permission manage = manager + manager->manage
}

definition note {
	relation owner: user
	relation viewer: user
	relation editor: user
	permission edit = owner + editor + owner->manage
	permission view = edit + viewer
}

Let's say we have the following "Hierarchy":

Corresponding to the following relationships:

user:A#manager@user:foo
user:B#manager@user:foo
user:C#manager@user:foo
user:D#manager@user:foo

user:A#manager@user:bar
user:B#manager@user:bar
user:C#manager@user:bar
user:D#manager@user:bar

Our customers have told us that they want a way to say, I want Foo to be able to see everything that Bar is doing and the opposite.

On the technical side, we've tried to come up with a solution which requires the less work.

We've added the two following relations:

user:A#manager@user:foo
user:B#manager@user:foo
user:C#manager@user:foo
user:D#manager@user:foo

user:A#manager@user:bar
user:B#manager@user:bar
user:C#manager@user:bar
user:D#manager@user:bar

-- New relations
user:foo#manager@user:bar
user:bar#manager@user:foo

But now when we use our method to "Get subordinates", we get the following error io.grpc.StatusRuntimeException: UNKNOWN: max depth exceeded: this usually indicates a recursive or too deep data dependency

We do the following LookupResourcesRequest (Java Client used in Scala):

    val subjectReferenceBuilder = SubjectReference
      .newBuilder()
      .setObject(
        ObjectReference
          .newBuilder()
          .setObjectType("user")
          .setObjectId("foo")
          .build()
      )

    val subjectReference = request.subjectReference.relation.map { relation =>
      subjectReferenceBuilder.setOptionalRelation(relation)
    }.getOrElse(subjectReferenceBuilder)
      .build()

    val lr = PermissionService.LookupResourcesRequest
      .newBuilder()
      .setConsistency(
        Consistency
          .newBuilder()
          .setFullyConsistent(true)
          .build()
      )
      .setResourceObjectType("user")
      .setPermission("manage")
      .setSubject(
        subjectReference
      )
      .build()

    IO.fromTry(Try {
        permissionService
          .lookupResources(lr)
          .asScala
          .map(_.getResourceObjectId)
          .toSet
      })
      .mapError(AuthorizationThrowableWrapper)

How would you model this differently, or is there a way to fix the error ?

Some precisions:
we use:

<dependency>
    <groupId>com.authzed.api</groupId>
    <artifactId>authzed</artifactId>
    <version>0.4.0</version>
</dependency>

And spicedb ghcr.io/authzed/spicedb:v1.18.0 deployed through the kubernetes operator.

Thanks

[vroldanbet]

If there is a cycle in the graph, that error is expected. Foo is marked as manager of bar, and bar is marked as manager of Foo.

What's not clear from the description is why can Foo see notes from Bar, and Bar see notes from Foo, from a business perspective. Is it because they share the same manager? Or is it just because you want to be able to share notes between users?

Can you clarify what "see what Foo is doing" in terms of permissions in the schema?

[imclem]

Hi @vroldanbet thanks for your answer.

They might share the same manager, but they can also be at the top of the org and there might be multiple people at the same level at the top.

We tried adding the peer relation but to make it bidirectional we added two relations and ended up with the same issue

[vroldanbet]

It's still not clear to me what the business requirements are. Under what conditions can a user see the same another user sees? Do they have to perform an action in the UI to share ("please share all I see with user X"), or is that defined by the hierarchy (each one of a manager's reports should be able to see each other's work)? This is fundamental because it will inform what the graph would look like.

For example, if the business requirement is "I should see everything my team-mates see", it could be solved by traversing via a relation reports in a manager (which is the inverse of manager). It would not cause a cycle because it's not recursive (you can see everything your peers see, but you can't see everything your managers' peers see).

If instead, you wanted to have something like "share everything I see with user X", then we need to explicitly model in the schema "Everything I See" as a concept. Here is a playground schema with assertions.

The trick here is to "normalize" the schema just like you'd do with a relational model, refactoring the grant from the note into a definition that connects users and notes.

definition user {
	relation manager: user
	permission manage = manager + manager->manage
}

definition grant {
    relation owner: user
    relation shared: user
  
    permission grantees = owner + shared  + owner->manage
}

definition note {
	relation owner: grant#grantees
	relation viewer: grant#grantees
	relation editor: grant#grantees
	permission edit = owner + editor + owner->manage
	permission view = edit + viewer
}

[imclem]

You are right, the requirement is "automatic sharing between two people", no matter who does the setup (the user himself or a superadmin).

I will try to add an intermediate relation like you proposed

Thanks a lot for your help!