permitio / cedar-agent Goto Github PK

The api requires uploading the entire entities,
if I modify part of data , I should regenerate json to upload.

Any suggestions?

Hey, this is a wonderful library.

I actually just packaged it up into @teaxyz's ecosystem.

One thing I'm wondering is if there's a recommended workflow for formatting/stringifying real .cedar files into something resembling policies.json?

(I can probably hack together some convoluted bash script, but I'm wondering if there's a known CLI or a better way).

(I'm also iterating on a real-life example here:
https://github.com/kevinmichaelchen/cedar-learning/tree/main/examples/policies)

To avoid the same policy compilation, cedar has policy template to use.
cedar policy template

Does cedar-agent support cedar policy template ?

I got error when I POST policy.

permit(
    principal == ?principal, 
    action in [Action::"readFile", Action::"writeFile"] 
    resource  == ?resource
  );

Our system has a substantial number of entities, making it impractical to store them all in the memory of the Cedar Agent. To overcome this limitation, we propose enhancing the functionality of the POST /is_authorized endpoint by allowing to pass in additional entities. These entities would be considered when evaluating policies for the current request.

How I would expect it to work:

Let's say that the data stored in the memory of Cedar Agent is the following:

[
  {
    "attrs": {},
    "parents": [],
    "uid": {
      "id": "fraud",
      "type": "ResourceGroup"
    }
  },
  {
    "attrs": {},
    "parents": [
      {
        "id": "Admin",
        "type": "Role"
      }
    ],
    "uid": {
      "id": "[email protected]",
      "type": "User"
    }
  },
  {
    "attrs": {},
    "parents": [],
    "uid": {
      "id": "get",
      "type": "Action"
    }
  },
  {
    "attrs": {},
    "parents": [],
    "uid": {
      "id": "Admin",
      "type": "Role"
    }
  }
]

Additionally, let's consider the following policies:

[
  {
    "id": "fraud-docs-policy",
    "content": "permit(principal in Role::\"Admin\",action in [Action::\"get\"],resource in ResourceGroup::\"fraud\");"
  }
]

Consider the authorization request:

{
  "principal": "User::\"[email protected]\"",
  "action": "Action::\"get\"",
  "resource": "Document::\"fraud-doc\"",
  "additional_entities": [
    {
      "attrs": {},
      "parents": [
        {
          "id": "fraud",
          "type": "ResourceGroup"
        }
      ],
      "uid": {
        "id": "fraud-doc",
        "type": "Document"
      }
    }
  ]
}

The expected decision for this authorization request is "Allow" because the principal User:"[email protected]"
is permitted to perform action get on resources belonging to ResourceGroup:"fraud",and the resource Document:"fraud-doc" belongs to that resource group.

Of course, if you have any other ideas how to solve this, then feel free to let us know.

Cant load the swagger or rapidoc after running using docker as per the README instructions.
docker run permitio/cedar-agent
OS: Mac M1 Pro Ventura

Is Cedar Agent able to support Partial Evaluation?

In this permit.io video with Mike Hicks and the Cedar team, they present a Partial Evaluation feature that lets you answer the question:

What resources could this principal perform this action on successfully?

The result is a series of residual expressions that can enumerate all of the allowed resources, from which we can derive a where clause (e.g., WHERE id IN [1, 2, 3]) to constrain which resources get retrieved by the database, thereby saving unnecessary data transfer.

Impact

The impact of this feature would be huge for service calls dealing with large batches of resources, which may only be partially accessible to the principal.

Example Scenario

Consider a university application where teachers may only view data (subjects, classroom blocks, other teachers, etc.) that they specifically teach.

We could try to model this fine-grained authorization logic using where clauses, but eventually, the database may exhaust its ability to do so. (Maybe, for example, authz decisions will be decided by data that simply is not in the database, e.g., Salesforce or some other external system).

query {
  schoolByPk(id: 42) {
    name
    teachers {
      id
      fullName
    }
    subjects {
      name # e.g., Linear Algebra
      blocks {
        recurrenceRules
        teacher {
          id
          fullName
        }
      }
    }
  }
}

Current Approach

My current approach to make sure the client sees only what is accessible is to:

1. Constrain the query by some kind of notion of multi-tenancy (e.g., school 42)
2. Retrieve everything under that from the database
3. Aggregate all the resources and submit them, one by one, in parallel, to Cedar Agent.
4. Filter out any resources that are not accessible.

I can't help but think an approach using Partial Evaluation would be cleaner.

just playing with this, I ran into a surprising HTML response -- not surprising in its error, but rather that it wasn't JSON

% curl -X PUT -H "Content-Type: application/json" -d @./examples/policies.json http://localhost:8180/v1/policies/viewers-policy
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>422 Unprocessable Entity</title>
</head>
<body align="center">
    <div role="main" align="center">
        <h1>422: Unprocessable Entity</h1>
        <p>The request was well-formed but was unable to be followed due to semantic errors.</p>
        <hr />
    </div>
    <div role="contentinfo" align="center">
        <small>Rocket</small>
    </div>
</body>
</html>
%