Support wildcards in template policy resources

[WanderingStar]

Category

Cedar language features

Describe the feature you'd like to request

We would like to be able to use template linking to grant permissions on patterns of resources, for example "Shohreh has the Editor policy on all Documents matching *.pdf".

This depends on #81

Describe the solution you'd like

Allow the like operator to accept expressions, not just literal strings on the RHS. Support like on entities, with the logic that the LHS entity must be the same EntityType as the RHS entity and the LHS entity's name must be like the RHS entity.

@id("Editor")
permit(
    principal == ?principal,
    action in [Action::"Read", Action::"Write", Action::"Comment"],
    resource like ?resource
);

Describe alternatives you've considered

To achieve this goal today, we can create more policies with the wildcards in literal strings, but we would prefer to use policy templates so that the templates can evolve.

If #94 is implemented, one option would be to separate the type check from the name check:

resource.name like ?resource.name
&& resource is Document

If there were more placeholders than just ?principal and ?resource, maybe a string placeholder would be better:

resource.name like ?pattern
&& resource is Document

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

[khieta]

Thanks for the suggestion! There are a couple different pieces here, and I'd like to make sure I understand them all (and make separate issues, as appropriate).

1. Allow like to match on entity id. Currently, like requires a string-typed expression on the left and a literal string (e.g., "*.pdf") on the right. We do not support an expression like resource like "*.pdf, which could return true when the resource was something like Some::Document::"foo.pdf".
2. Allow like expressions in the policy scope. Currently only expressions like principal == ?principal or action in [Action::"Read", Action::"Write", Action::"Comment"] are allowed in the policy scope. Assuming that change (1) was made, your example proposes that we allow like expressions in the scope as well.
3. Add support for a placeholder on the right side of a like operator. The only template placeholders we currently allow are ?principal and ?resource, which are both entities, whereas like expects a string on the right side (per (1) above). Independently of changes (1) and (2), it may be useful to support placeholders of other types (e.g., string) so that users could write expressions like resource.some_string like ?pattern, and instantiate with different strings like *.pdf and *.txt.

Is that a correct summary of your suggestion?

For your current example, here are some ideas for workarounds for each of the points above:

1. Add a "filename" field to each resource, and use like to match on that.
2. Put the like expression in the policy condition instead of the scope.
3. Make a distinct policy for each type of filename you want to match on, or use ||.

So, for example, a valid policy for your example in the current version of Cedar might look something like the following:

@id("Editor")
permit(
    principal == ?principal,
    action in [Action::"Read", Action::"Write", Action::"Comment"],
    resource
) when {
    resource.filename like "*.pdf"
};

[WanderingStar]

Thanks for your comments @khieta!

Let me give a little more context that may make this make more sense. Sorry for not providing it earlier, it's just so ingrained in how I think about permissions that I don't always think to mention it.

We have a system that is similar to GCP IAM Roles. The idea is that a "Role" is a predefined set of permissions. At the time you grant the role, you specify the principal you're granting the role to and the resource(s) you're granting the role on. Template linking seems purpose-built for this. A "Role" becomes a policy template, and granting the role is creating a template link.

The wrinkle here is that we allow our users to grant roles on patterns of resources, not just one resource at a time. For example, maybe the user wants to grant access to all Kafka Topics that start with us-finance- to their new accountant. The like operator seems purpose-built for this kind of thing.

We want to combine these two Cedar features.

Addressing the pieces questions:

1. That's right. Being able to write things like resource like Document::"*.pdf" or resource like Kafka::Topic::"us-finance-*" would allow granting the "Role" on a user-specified set of resources.
2. Thanks for pointing out that like isn't supported in the scope. I wasn't aware of that. At the end of the day, I'd be just as happy to do that test in the condition, but see: Support template placeholders in conditions #81
3. Yes, that's right. We'd like to specify the pattern at grant time.

And thanks for the suggestions. Comments on those...

1. like matching on an attribute would work, but in the current version of Cedar, that would mean giving up on using policy templates and doing substitutions ourselves. I guess we could create a policy template template like:

permit(
    principal == ?principal,
    action in [Action::"Read", Action::"Write", Action::"Comment"],
    resource
) when {
    resource.filename like "{{ escaped_pattern }}"
};

And substitute the {{ escaped_pattern }} and then create a template link to fill in ?principal, but if we're going to do that, it seems more straightforward to just do all of the substitutions and avoid template linking altogether:

permit(
    principal == {{ principal }},
    action in [Action::"Read", Action::"Write", Action::"Comment"],
    resource
) when {
    resource.filename like "{{ escaped_pattern }}"
};

Then every grant is a new policy.
2. We'd be happy to do the check in the condition instead of the scope, but we still want it to be against a placeholder.
3. We were hoping to avoid creating lots of new policies.

Maybe the outcome here will be "Template linking isn't for that. Just create more policies." But the system seems very close to being able to do this.

Thanks again for your consideration!

[khieta]

A "Role" becomes a policy template, and granting the role is creating a template link.

Yes, I think this is a natural way to think about things. Another way to do this is to use the entity hierarchy to help express roles. For example, you could say that every user in UserGroup::"roleA" is allowed to read/write all files with a name like *.doc using the following policy:

permit(
    principal in UserGroup::"roleA",
    action in [Action::"Read", Action::"Write"],
    resource
) when {
    resource.filename like "*.doc"
};

Then when you want to give a user User::"alice" this "role", you can add UserGroup::"alice" to be a member of UserGroup::"roleA" in your entity hierarchy.

You could also do something similar to group files together. For example, you could create an entity FileGroup::"doc" that will be the parent of all files with an entity ids like *.doc, and then use a template like

permit(
    principal in ?principal,
    action in [Action::"Read", Action::"Write"],
    resource in ?resource
);

where you instantiate ?principal to be UserGroup::"foo" (for example) and ?resource to be FileGroup::"doc".

But getting back to your original question: If you're ok with the "filename" solution, then I think you'll want to file a new issue that requests allowing templates to be instantiated with non-entity type values (Strings in this case). If the "filename" solution won't work for you, then you could consider the group-based approach above, or narrow the scope of the current issue to ask for allowing like operations on entity ids.

[khieta]

One more comment: in your example, I think there is still value in using template-linking in the first case:

permit(
    principal == ?principal,
    action in [Action::"Read", Action::"Write", Action::"Comment"],
    resource
) when {
    resource.filename like "{{ escaped_pattern }}"
};

Although it is inconvenient to have to manually create different templates for different filename patterns, you still get the benefit of have a single template definition for multiple ?principals, which allows you to update multiple policies from a single location.