Support named constants, or imports?

[bencmaps]

Category

Cedar language or syntax features/changes

Describe the feature you'd like to request

I have some Cedar policy files with multiple permit statements referring to the same principal condition, eg. principal in AWS::IDC::Group::"<some uuid>" // the xyz team. They're separated into multiple statements in order to provide more fine-grained @advice comments as well as sometimes to add extra conditions.

I'm wondering what the recommendation is for minimizing duplication of this group ID. It seems like it would be nice to be able to define a named binding somewhere, either in the same file or a standalone file, that could then be referred to by name in all these reference points, so the actual ID only need be spelled out once.

Describe alternatives you've considered

• Status quo: just duplicate the raw IDs everywhere they're needed.
• Introduce some preprocessing step to find-and-replace words like @@@XYZ_GROUP@@@ with their value, but this introduces extra moving pieces/state that is undesirable.

Additional context

No response

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

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

[john-h-kastner-aws]

Thanks for submitting this request! I've tagged this requires-RFC because it would be a substantial change to the language which we wouldn't make without careful planning.

I think you're actually asking for a restricted version of the macro mechanism proposed in cedar-policy/rfcs#61. We're not actively considering that proposal at the moment, but we haven't rejected it completely either. Definitely restart discussion there if that proposal sounds useful. You could also write a fresh RFC proposing a more limited version of macros that work for you, potential avoiding some of the thornier issues identified in general macros.

Depending on your exact use case, we might be able to suggest a nicer alternative. In your example, the uuid appears in the principal constraint. If it only occurs there (or in the resource constraint), then you may be able to use policy templates as a safe alternative to find-and-replace. E.g., given a template permit(principal in ?principal, ...); the Cedar sdk provides a method to construct a template-linked-policy by replacing ?principal with a particular entity uid. If templates don't quite meet your needs, you could restart discussion on some extension to templates we previously considered but decided not to accept: templates groups, and template slots in policy conditions.