[Q] Equal Modeling Cases | Permify | Page 1

nocturne kindle Apr 2, 2023, 8:06 PM

#

It seems like they’re not equal since we can also assign system member to viewer in first block.

But if you’re comparing “company.viewer” with “company#viewer” in terms of action functionality, there is not much diference
and both can be usable.

In particular, if we look at both schemas’ queries:

entity user {}

entity organization {
relation member @user
}

entity company {
relation viewer @user
}

entity x {
relation viewer @organization#member @company#viewer

action view = viewer

}

can user:1 view x:1 ?

query: find viewers of x:1
query: if the result includes organization members or company viewers, engine will find the users within those (this can potentially result in more sub-queries as the userset response returns)

Entity user {}

entity organization {
relation member @user
}
entity company {
relation viewer @user
}

entity x {
relation company @company
relation viewer @organization#member

action view = viewer or company.viewer
}

can user:1 view x:1

query: find the viewers of x:1
query: find the members of any organization that is related to x:1, if any (this can potentially result in more sub-queries as the userset response returns)
query: find the companies that are related to x:1
query: find the viewers of the companies found in the previous step (this can potentially result in more sub-queries as the userset response returns)

lone oak Apr 2, 2023, 8:11 PM

#

Is there a bug in the playground then?

Model

    entity user {}

    entity system {
        relation member   @user
        relation support  @user
        relation infosec  @user
        relation manager  @user
    }

    entity company {

      relation member @user
      relation guest @user @company#member
      relation viewer @user @company#member @system#member
      relation contributor @company#member @system#support
      relation maintainer @company#member @system#infosec
      relation manager @company#member @system#manager

      action manage = manager
      action maintain = maintainer or manage
      action contribute = contributor or maintain
      action view = member or guest or viewer or contribute
    }

    entity organization {
      relation member @user
      relation company @company
      relation guest @user @organization#member
      relation viewer @organization#member @system#member @company#viewer
      relation contributor @organization#member @system#support @company#maintainer
      relation maintainer @organization#member @system#infosec @company#manager
      relation manager @organization#member @system#manager

      action manage = manager
      action maintain = maintainer or manage
      action contribute = contributor or maintain
      action view = member or guest or viewer or contribute

    }

Data:

[TUPLE]
user:U1 is member of company:C1
company:C1#member@user:U1

[TUPLE]
company:C1 is company of organization:O1
organization:O1#company@company:C1#...

[TUPLE]
user:U1 is viewer of company:C1
company:C1#viewer@user:U1

Check (Data Filtering)

which organization user:U1 can view

^ results in [] instead of O1

#

If I switch from @company#viewer to @company with the action of view having company.viewer then [O1] is the response from data filtering

#

#

This is after I change to company.viewer

lyric shard Apr 2, 2023, 8:38 PM

#

Hey @lone oak, SUBJECT_TYPE_NOT_FOUND error displayed on the screen is a frontend issue within the playground, and we will be fixing this bug as soon as possible.

As for the model, when we take a look at it:

entity organization {
...
  action manage = manager
  action maintain = maintainer or manage
  action contribute = contributor or maintain
  action view = member or guest or viewer or contribute or company.viewer
}

You should add or company.viewer at the end; otherwise, user U1's association with the company won't be meaningful, and O1 will not be returned as a response.

lone oak Apr 2, 2023, 8:39 PM

#

Then what is the point of the relation viewer @organization#member @system#member @company#viewer capability?

#

To me, from reading the docs, these two things should be equivalent because I am saying the viewer contains company#viewers in the list of people to take the action view. If I have to list company.viewer on the action - then I would never see a point in using anything but relation viewer @user

lyric shard Apr 2, 2023, 8:48 PM

#

Actual purpose of these definitions is to specify the sets of users that can be assigned. For example:

relation viewer @user

When you define it like this, you can only add users directly as tuples:

organization:1#viewer@user:U1
organization:1#viewer@user:U2
However, if you define it as:

relation viewer @user @organization#member

You will then be able to specify not only individual users but also members of an organization:

organization:1#viewer@user:U1
organization:1#viewer@user:U2
organization:1#viewer@organization:O1#member
You can think of these definitions as a precaution taken against creating undesired user set relationships.

#

If you have set up the relationships in this way, O1 will be returned as a response.

  ...
  relation viewer @organization#member @system#member @company#viewer
  relation contributor @organization#member @system#support @company#maintainer
  relation maintainer @organization#member @system#infosec @company#manager
  relation manager @organization#member @system#manager

  action manage = manager
  action maintain = maintainer or manage
  action contribute = contributor or maintain
  action view = member or guest or viewer or contribute
}```

TUPLES

* company:C1#member@user:U1
* company:C1#viewer@user:U1
* organization:O1#viewer@company:C1#viewer

#

In other words, when we compared the two models, only the relationships we created and the way of searching changed a little.

lone oak Apr 2, 2023, 10:46 PM

#

So the relation is a subset of who can be assigned but the action will still need all the use-cases of the rules.

#

and using the relation as a superset of who can do the action is not the appropriate method

lyric shard Apr 3, 2023, 12:27 AM

#

Yes, we opted for this design to enable the creation of more comprehensible models. What are your thoughts on this approach?

lone oak Apr 4, 2023, 11:30 PM

#

I will need to think about it. I see merits in the approach but I also see the need to set many permissions to make hierarchical structures possible in implementation while keeping the schema easy to understand (a hard balance)

lyric shard Apr 5, 2023, 1:13 PM

#

Got it. We are currently working on the model examples provided in both this thread and the “#Hierarchical relations with most explicit permissions” thread to keep the schema easily understandable while providing least privilege. Maybe we can conduct alternative solutions to improve our authorization language around it, we’re open to any potential solution ideas you may have.

#[Q] Equal Modeling Cases