define rego rule which can check authorization on another REST endpoint

[robhafner]

Our existing authorization service supports defining a rule for a particular REST endpoint which can check if the requesting identity has access to another REST endpoint with a condition like the following:

isAuthorized('update', '/analyticsGateway/projects/0fd53308-1add-4e4a-805a-49b7766fb7d0')

I've attempted to port this functionality into rego in the following manner:

grant if { data.request.permission in ["update", "remove", "add", "read"] regex.match(^/folders/folders/0f0a367a-2c26-4e38-8630-8708e8ff0b29/, data.request.uri) authenticated_user = true g := grant with data.request as { "request" : { "permission" : "update", "uri" : "/analyticsGateway/projects/0fd53308-1add-4e4a-805a-49b7766fb7d0" } } d := deny with data.request as { "request" : { "permission" : "update", "uri" : "/analyticsGateway/projects/0fd53308-1add-4e4a-805a-49b7766fb7d0" } } not d g }

However, this results in the following recursion error.

1 error occurred: policy.rego:6376: rego_recursion_error: rule data.sas.types.authz.grant is recursive: data.sas.types.authz.grant -> data.sas.types.authz.grant

Is there an alternative way to model this type of behavior in rego?

[ashutosh-narkar]

From the policy looks like you're recursively calling the grant rule, hence the error. I don't completely understand your use-case but seems like you need some external context to make a policy decision. If that's the case, this would be a good reference. If that does not seem right, it would help if you could provide more details on the use-case.

[robhafner]

Thanks Ashutosh! I don't see a need here for an external context. Let me try to explain a bit more to see if it helps you understand our use case better.

We are currently evaluating OPA to replace our existing authorization service. Our existing authorization service supports authorizing requests made to various microservices. Our existing authorization service supports defining a rule such that the authorization decision for that rule depends on an authorization decision for another API endpoint.

For example, the following rule grants read permission to the /files/files/123 endpoint for authenticated users if the requesting identity "isAuthorizied" to read the the parent file for /files/files/123. This behavior is supported through the 'condition' field defined on the rule below.

{ "type": "grant", "permissions": ["read"], "objectUri": "/files/files/123", "principalType": "authenticated-users", "condition": "isAuthorized(#file?.parentUri)", "reason": "An authenticated user can access and manipulate a file if they are authorized to do so on the file's parent.'", "description": "Grants permission to a file based on the file's parent.'" },

In general, our authorization service supports the ability to delegate part of the evaluation of a rule to another endpoint via the built-in function 'isAuthorization(, )".

Is there a way to model this use case using Rego?

[anderseknert]

That certainly sounds doable — you just can't evaluate the grant rule from expressions in its own body, as that'd be recursive. If you could share a more complete example (but limited to the problem at hand) in the Rego Playground, that'd be helpful!

[robhafner]

Here is a simplified draft of the policy I am trying to write.

https://play.openpolicyagent.org/p/U9iJVoYGmD

[ashutosh-narkar]

https://play.openpolicyagent.org/p/U9iJVoYGmD

Thanks for sharing this. The input OPA gets is

{
    "request": {
        "permission": "read",
        "uri": "/files/files/456",
        "user": "user1"
    }
}

Now given this input, OPA would need two more pieces of information 1) What is the parent of file /files/files/456? In this case /files/files/123 and 2) Is user1 allowed to access /files/files/123?

Is there some way to expose this mapping? Assume it's a map for example, I would imagine graph builtins OPA has would be useful.

[robhafner]

Yes, I am looking to define the parent relationship between /files/files/456 and /files/files/123 in the first rule. Which is similar to how our existing authorization service works. However, it's unclear how that can be done in OPA.

For your second question, this rule has been defined in the policy which grants user1 permission to read /files/files/123.

grant if {
input.request.user = "user1"
input.request.permission in ["read"]
input.request.uri = "/files/files/123"
}

[anderseknert]

Hey again Rob :) I think where both me and @ashutosh-narkar seem to get lost is how you want to model the child-parent relationship between resources. You could hard code it of course, but I assume there's going to be a lot of these relationships, so you'll probably want to model that rather than hard coded strings. Would one file always have a single parent resource, or should the policy traverse the parents parent, and so on?

[robhafner]

Hi @anderseknert , Yes, a file will have a single parent resource. However the parent resource may not be the root of the file hieararchy and may also have a parent resource associated with it, and so on.

Our existing authorization service supports providing the parent resource in couple ways.

1. Hardcoding the parent resource in the rule itself via a string literal.
2. Providing the parent resource based on a field in the media type of the REST resource.

For example, we have a condition in one of our rules that looks like this: (case 1)
isAuthorized('update', '/analytics/projects/f37490e5-5ea9-41c4-a03e-0c2387168fc0')

And another condition which looks like this: (case 2)
isAuthorized('update',#resource?.links?.^[rel == 'authorizedAs']?.uri)

So far I've been trying to model the first case as I think it is the easier of the two to start with.

In general, the file hierarchy is just one example of how the "isAuthorized" function is used in our existing authorization service. The function is used in other parts of our system to effectively delegate part of the authorization decision for a particular rule to another resource which the user may or may not have access to.

[anderseknert]

Very simplified example, but here's something showing how you could model this in Rego using graph.reachable. If the relationship is simpler than that — i.e. only a single node connecting, you could probably get by with just an array.

In the example here, the user isn't granted read access directly on the requested resource, but will be allowed based on a permission defined on a parent resource.

https://play.openpolicyagent.org/p/qP2edpwGQ6

[robhafner]

Thanks @anderseknert! Let me think about this approach some more. I was hoping that we wouldn't have to manage additional data in support of this use case. Are there any other options that might support this use case without managing external data?

[anderseknert]

Can you elaborate on what you mean with external data? In the Playground example I used data for modeling permissions, but it's all just data to OPA, whether it comes from a JSON file or embedded in Rego. Same thing here with the data embedded in Rego: https://play.openpolicyagent.org/p/YNisssFGVo

Note that this data isn't necessarily external — when you package bundles for OPA to use, these normally contain both Rego and JSON. Separating the two is often a good practice, but it's not a requirement.

[anderseknert]

On this topic — this section in the OPA docs explains how it works on a higher level: https://www.openpolicyagent.org/docs/latest/philosophy/#the-opa-document-model

It's a really nice model to work with once it "clicks", in my humble opinion, obviously :)

[robhafner]

Sure. In this case the external data that I'm referring to is the hierarchy and the permission data. This information is stored in another service in our system and will require the ability to dynamically update it as the state of resources in the other service change. I'm aware of the ways that this data can be managed in OPA but trying to be conservative out of the gate to avoid adding the additional complexity of using this data if not absolutely necessary.

Regarding the "document model", I agree it is quite nice. I'm not sure everything "clicks" just yet, but from what I understand thus far, I can certainly see the power of the model.

[robhafner]

Circling back around here to add an example of how I propose to implement support for this functionality in Rego for completeness.

https://play.openpolicyagent.org/p/7gQBVK0Ve4

There are comments in the policy that explain the approach.