feat: implement policy templates

[caiorcferreira]

Description of changes:

One of Cedar's main features is Policy Templates, which allows for managing large sets of policies while keeping the authorization rules centralized.

This PR is an attempt to implement Templates in cedar-go.

Features

This implementation follows the Template behavior described in the Language Guide.

We can break the Template behavior described in the Language Guide in 3 main requirements:

1. Template Variables

You can use placeholders in a Cedar policy template for only the following two elements of a policy statement:

• Principal – ?principal
• Resource – ?resource

You can use either one or both in a policy template.

To fulfill this requirement, we introduce types.SlotID with two possible values: PrincipalSlotID (?principal) and ResourceSlotID (?resource).
The unmarshaling logic expects only these values and errors otherwise.

2. Operator support

Placeholders can appear in only the policy scope on the right-hand side of the == or in operators. This includes in operators when appearing together with an is operator, but excludes solitary is operators.

This requirement guided the changes in marshaling and the ScopeTypeX supported by the linkScope function.

3. Cascade change propagation

However, the new policy isn’t actually constructed as a static policy with that policy statement. Instead, the new policy is a template-linked policy that dynamically links the policy template with those two specific placeholder values. Later, you might choose to modify the policy template, such as by adding an additional condition to the unless clause. From that moment on the change immediately affects all authorization decision results for all template-linked policies created from the modified policy template.

Based on this requirement, we created the LinkedPolicy type. It holds a template reference, a template ID, a link ID, and the slot env with values that will replace the variables.

The LinkedPolicy can be serialized to JSON, following the cedar-cli structure, so that it can be persisted and later rendered into a policy again. Because we store the template ID (instead of the actual template), if the template content changes in the meantime, the client code should be able to retrieve the template's latest version and create a new instance of the LinkedPolicy to render the policy.

Conclusion

Policy templates will soon become a critical feature for my Cedar use case. Hence, I want to try to move this feature forward, and I appreciate any help!

[patjakdev]

I think we are close to being able to merge this.

However, after consulting internally at StrongDM, we'd like to move the template-supporting PolicySet into x/exp/templates for now. Some work we just to expose an Authorize() function that takes a policy set iterator interface will probably help make that work well.

Can we sync up on the Cedar Slack to discuss further?

[patjakdev]

This bookkeeping seems unnecessary. Let's just hunt for slot usages in the expected places and replace them with the provided values from the environment or return an error if no value is provided.

[caiorcferreira]

Which bookkeeping do you refer to?

• Checking if slotEnv size is the same as the number of slots in the template? If so, I did the same as in the Rust impl, such that if a policy fails in the Rust impl it also fails in the Go impl.
• Iterating over the return from Slots()? It just makes it easier to check whether the slot is used or not.

[patjakdev]

I was imagining that we didn't need Slots() at all. It seems to me that ast.Policy ought to not know anything about templates (beyond the VariableSlot nodes in the AST) and that we could just iterate the AST here looking for VariableSlots to replace with values from slotEnv. The error conditions would then be:

1. A value does not exist in the slotEnv when we go to replace it
2. A value in the slotEnv isn't used. We'd obviously have to do some bookkeeping locally in Render() to keep track of that, but I think I prefer that to polluting types.Policy with knowledge about templates.

[patjakdev]

Similarly, when parsing a Cedar document and trying to decide whether it's a Policy or a Template, I'd just look at the scope AST to see if there are any VariableSlots.

If templates ever become more general (which, perhaps, one day they may), this will be more expensive and we can address it then. For now, it's easy enough to look through the scope AST to decide what's going on.

[philhassey]

I see there are some conflicts here yet.