core: creating policy programmatically

[axel7083]

Category

Internal refactors/changes

Describe the feature you'd like to request

I am looking for a way to create a Policy object without using json or text. The only public functions are the from_json and from_str

https://github.com/cedar-policy/cedar/blob/42a500a7ab1808cd45698a28230acb7fd7a3ee7c/cedar-policy/src/api.rs#L2473

Describe alternatives you've considered

Using serde_json::json!({...}) to build the Policy but I would rather not use it in the code.

Additional context

No response

Is this something that you'd be interested in working on?

• [X] 👋 I may be able to implement this feature request
• [ ] ⚠️ This feature might incur a breaking change

[khieta]

Thanks for the suggestion! We agree that it would be convenient to have some constructors for building policies. However, the json approach is sufficient for our purposes for now, so we don't have any immediate plans to work on this. I'll mark the issue as "backlog" to confirm that we think it's a good idea and "help wanted" to indicate that we're happy to take external contributions.

[mwhicks1]

I have a question for you, @axel7083 : What would you think about generalizing templates, and using those as a basis for "policy builders." That is: You make a template that is the equivalent of a SQL prepared statement but for Cedar rather than SQL, and then fill in the holes with the programmatic pieces of your policy. See RFC 3 and let us know what you think!

[axel7083]

Thanks for the suggestion! We agree that it would be convenient to have some constructors for building policies. However, the json approach is sufficient for our purposes for now, so we don't have any immediate plans to work on this. I'll mark the issue as "backlog" to confirm that we think it's a good idea and "help wanted" to indicate that we're happy to take external contributions.

@khieta thanks for the answer :) ! I will definitely open a PR if the idea sound good for you! I started using cedar for an internal POC, and in our use case the policies would be created on the fly based on other services events, and being able to directly create Policy object without having to create a serde_json::value , or parse a string would probably give a small performance boost for our case.

I have a question for you, @axel7083 : What would you think about generalizing templates, and using those as a basis for "policy builders." That is: You make a template that is the equivalent of a SQL prepared statement but for Cedar rather than SQL, and then fill in the holes with the programmatic pieces of your policy. See RFC 3 and let us know what you think!

@mwhicks1 I really like the idea of generalizing templates, in many cases it can lead to better readability and maintenance for developers, making logic reusable. I do not have yet, enough knowledge in the matter or the use case to have a direct requirements on it or fully understand all the possible pros and cons.

As I said above, we have policies created at runtime, and in the proposal I can read the following

If policies could be created on the fly, then an auditor or tool would have to also analyze the application code.^1

And in our use case, we prevent the services or applications to create freely policies for entities/actions not in their namespace, so we do have to analyse them, to prevent them from accessing or defining policies on entities that they should not access to. I can see some possible usage of the template to enforce some of the rules we implemented manually.

For instance we could probably reduce the freedom we give services for creating policies, and give instead a set of pre-defined template, that they can use. But this would also result in limitation in the end on their freedom.

[mwhicks1]

we have policies created at runtime

Are the policies pretty general, or do they mostly conform the particular shapes? If they are very general, mostly written directly by users, say, then templates will not work. But if they are just variations based on a few shapes, then templates can be ideal. I'd love use-cases to help us design a revised RFC #3.

Thanks for the quick and insightful response!

[axel7083]

we have policies created at runtime

Are the policies pretty general, or do they mostly conform the particular shapes? If they are very general, mostly written directly by users, say, then templates will not work. But if they are just variations based on a few shapes, then templates can be ideal. I'd love use-cases to help us design a revised RFC #3.

The shape is pretty basic and simple at the moment, for the POC we are working on we try to keep things simple.

Thanks for the quick and insightful response!

My pleasure !

[cdisselkoen]

This is a very reasonable suggestion. We should also do the same thing for Schema objects.