ory / keto

Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.
https://www.ory.sh/?utm_source=github&utm_medium=banner&utm_campaign=keto
Apache License 2.0
4.71k stars 342 forks source link

OPL traverse.(...) not working #1330

Open DanielPFSeddi opened 1 year ago

DanielPFSeddi commented 1 year ago

Preflight checklist

Describe the bug

I'm trying to check the permits using the traverse.(...) functionality with a very simple OPL model, but it always returns "allowed": false.

This is my OPL model:

import { Namespace, Context } from '@ory/keto-namespace-types';

class User implements Namespace {}

class Document implements Namespace {
  related: {
    viewers: User[];
    parents: Folder[];
  };

  permits = {
    view: (ctx: Context): boolean => this.related.parents.traverse((p) => p.permits.view(ctx)),
  };
}

class Folder implements Namespace {
  related: {
    viewers: User[];
  };

  permits = {
    view: (ctx: Context): boolean => this.related.viewers.includes(ctx.subject),
  };
}

And these are the relation-tuples that I have:

{
    "relation_tuples": [
        {
            "namespace": "Folder",
            "object": "folder_1",
            "relation": "viewers",
            "subject_id": "user_1"
        },
        {
            "namespace": "Document",
            "object": "document_1",
            "relation": "parents",
            "subject_id": "folder_1"
        }
    ],
    "next_page_token": ""
}

So, Folder:folder_1 is parent of Document:document_1, and User:user_1 is viewer of Folder:folder_1. I would expect that User:user_1 can view Document:document_1, but it returns false.

Reproducing the bug

When making the following request on Postman:

http://localhost:10006/relation-tuples/check?namespace=Document&object=document_1&subject_id=user_1&relation=view

I'm getting:

{
    "allowed": false
}

and I expect it to be true. I've also tried adding an extra query parameter like max-depth=10, but I'm getting the same result

Just for checking, when I make the following request:

http://localhost:10006/relation-tuples/check?namespace=Folder&object=folder_1&subject_id=user_1&relation=view

I'm getting:

{
    "allowed": true
}

Which is the espected return value, since User:user_1 is viewer of Folder:folder_1

Relevant log output

No response

Relevant configuration

I'm using a docker image: oryd/keto:latest (service_name=Ory Keto service_version=v0.11.1-alpha.0).

I'm mapping the ports:

- 10006:4466 //read
- 10007:4467 //write

Version

service_version=v0.11.1-alpha.0

On which operating system are you observing this issue?

Windows

In which environment are you deploying?

Docker Compose

Additional Context

No response

bendoerr commented 1 year ago

Wait.... I've been struggling with something similar. My feeling is that the current version of keto is totally broken for anything other than one step removed.

aeneasr commented 1 year ago

Hey, sorry to hear that there's an issue. The primary engineers are currently in completely different contexts but we'll try to get this sorted soon. We're currently swamped with some other work, but obviously it's not acceptable to have such faults.

ChristianSch commented 1 year ago

@aeneasr any updates here? It's been over a month now.

aeneasr commented 1 year ago

Unfortunately our engineers are still busy with other work from customers and we do not have capacity to work on this at the moment.

TimDiekmann commented 11 months ago

I just stumbled over this issue and I had a similar problem, however, I don't know if this was supposed to work or the documentation is outdated but if you specify the namespace in the tuples it should work just fine:

[
  {
    "namespace": "Folder",
    "object": "folder_1",
    "relation": "viewers",
    "subject_set": {
      "namespace": "User",
      "object": "user_1"
    }
  },
  {
    "namespace": "Document",
    "object": "document_1",
    "relation": "parents",
    "subject_set": {
      "namespace": "Folder",
      "object": "folder_1"
    }
  }
]

When then calling

keto check 'User:user_1' view Document document_1

instead of

keto check user_1 view Document document_1

it will return Allowed

kaiba42 commented 10 months ago

Any updates? This seems like core functionality of OPL...

aeneasr commented 10 months ago

Unfortunately our engineers are still busy with other work from customers and we do not have capacity to work on this at the moment.

nmapx commented 10 months ago

This bug actually makes OPL completely useless. Please prioritize this bug as soon as possible.

76creates commented 10 months ago

I just stumbled over this issue and I had a similar problem, however, I don't know if this was supposed to work or the documentation is outdated but if you specify the namespace in the tuples it should work just fine:

[
  {
    "namespace": "Folder",
    "object": "folder_1",
    "relation": "viewers",
    "subject_set": {
      "namespace": "User",
      "object": "user_1"
    }
  },
  {
    "namespace": "Document",
    "object": "document_1",
    "relation": "parents",
    "subject_set": {
      "namespace": "Folder",
      "object": "folder_1"
    }
  }
]

When then calling

keto check 'User:user_1' view Document document_1

instead of

keto check user_1 view Document document_1

it will return Allowed

This is the answer ^

Think of it as a sort of strict type. Problem with the approach you have tried is illustrated simply by adding another namespace to the viewers relation:

class User implements Namespace {}

class Guests implements Namespace {}

class Document implements Namespace {
    related: {
        viewers: (User | Guests)[];
        parents: Folder[];
    };
 ...

This behaviour must be a part of the design, if namespace is not defined system should create it in same namespace the object is located at.