Authorization decision based upon the folder a resource resides in.

[robhafner]

We are in the process of evaluating a switch from an in-house developed authorization service to Open Policy Agent. Our in-house authorization service supports the concept of authorizing a request to a particular uri based on the folder that the requesting uri is member of. In our case a folder, is a logical construct, supported by another service. Reviewing OPA's documentation I did not find a direct way to convert this behavior to Rego and so I'm hoping some guidance from the community might point me in the right direction.

Some questions:

1. Is this use case something the OPA community has come across before?
2. Is there an example that I could refer to that might help understand how OPA could support this use case?

[anderseknert]

Sure! That pattern is called dynamic policy composition.

[robhafner]

Thanks for the quick response. I hadn't considered using dynamic policy composition for this use case. I'm fairly new to OPA so I'll need to think about how that pattern might fit here. I'll reach back out as I have more questions.

[robhafner]

I've had a bit more time to think about how I might use dynamic policy composition to enforce authorization of a resource based on the folder hierarchy it resides in.

In general, we have a report resource that resides at the following endpoint:
[report-service]/reports/[id]

In addition, we have a folder service that has the following endpoint:
[folder-service]/folders/[id]

The media type of a folder has a field named 'parent' which can be a non nil value pointing to the id of the parent folder.

The folder service also has another endpoint for members which effectively are resources that are logically contained in the specified folder.
[folder-service]/folders/[id]/members

The media type for a member has a field 'uri' which provides a reference to the location of the resource. In this case the report mentioned earlier but it could be other resources as well.

Our current authorization service has the ability to grant permission for a resource to a subject based upon the folder the resource resides in. For example, given the following hierarchy and a resource residing in the 'son' folder, a rule can be defined on the grandfather, father, or son folder granting the subject permission to access the report.

[folder-service]/folders/[grandfather-id]
--> [folder-service]/folders/[father-id]
----> [folder-service]/folders/[son-id]

To implement authorization for this use case via dynamic composition, I think I will need to provide the list of folder ancestors in which the resource resides to OPA and then in the 'main' policy route the decision to the policy that contains the rego rules for the folder resources to make the authorization decision. Is this how you would expect this type of use case to work with dynamic policy composition? Just looking to confirm I'm not overlooking something or heading down a wrong path.

[anderseknert]

Yeah, something like that yes. Just to be clear, OPA doesn't really care about "folders" (as in, directories), as once all policy and data have been parsed, it'll all be merged into the data document. What you'd rather use for the purpose of dynamic policy composition is package paths, like:

package folder_service.folders.folder1

You can of course put these policies in a directory structure to mirror that, but it would be all the same to OPA.

[robhafner]

Is there a limit on the length of a package name? Our folder hierarchy can be quite deep resulting in the package name being quite long.

[anderseknert]

No, there is no limit to that I'm aware of.

[robhafner]

Won't using a package name in this manner require multiple calls to OPA to make a decision based on the ancestor folder hierarchy? Based on the OPA API the package path is passed into the Decision function. Wondering if that might result in slower performance than a single call.

[anderseknert]

No you could have a main rule that calls out any number of other rules, whether hierarchical or not, in a single request.

[robhafner]

Is there an example test case in the OPA project for dynamic composition that I can refer to? I think I'm struggling a bit to understand the following line.

router[policy] = data.policies[name][policy].deny

I assume data.policies refers to the policies directory and the value of the name variable then refers to the directory under it. However, it's not clear to me what the additional "[policy]" literal means. Looking at a working example might help a bit.

[anderseknert]

router[policy] = data.policies[name][policy].deny

In the above example, router generates an object, where each policy is a key in the map, and each value is the result of dynamic evaluation of data.policies[name][policy].deny.

If you want a real world example, the pattern is used extensively in Regal, to lint policy using any rule not ignored by configuration: https://github.com/StyraInc/regal/blob/main/bundle/regal/main.rego#L66

Feel free to join the #regal channel in the Styra community Slack if you have questions on that.

[robhafner]

Thanks for the reply! I'll take a look the example you shared. Thus far I've been trying to stub out an example which simply delegates the auth decision to a policy defined in a sub folder, but haven't got it to work yet. I've been trying to run the example using "opa test ." in the directory containing the "dynamic composition" folder structure. It's unclear to me if that should work or if I need to use the --bundle option. Given that I'm not passing a "data" value in to the test it's a bit unclear as to how data.policies gets defined.

[anderseknert]

Right. Direcory structure has no impact on policies, only on data when the bundle flag is used.

[robhafner]

I have a working example of our use case in OPA now. Effectively I used Dynamic Policy Composition to delegate to an appropriate policy defined for a folder along with import statements in the policy to traverse the policies of the ancestors of the folder.

Thanks for your help!

[anderseknert]

Awesome!