Changing semantics of unspecified appliesTo.principalTypes/appliesTo.resourceTypes

[max2me]

Category

Cedar validation features

Describe the feature you'd like to request

Current behavior
In Cedar 2.x, if action's appliesTo.principalTypes or appliesTo.resourceTypes is not given (or if entire appliesTo element is given), then it's interpreted as action that applies to all principal types and resource types.

Challenges
Discussion of RFC 24 highlighted challenges this introduces, primarily the risk of unintentionally specifying that action applies to all principal types / resource types and related complications it causes for analysis and experience of actual policy validation as error messages become more confusing.

Feature request
We can mitigate challenges listed above by making following changes:

• Specified appliesTo but ommited appliesTo.principalTypes / appliesTo.resourceTypes means that request component is unspecified, i.e., corresponding to the None option in the principal and/or resource component of a Request.
• Omitted appliesTo means that action cannot be used in a request is used exclusively as an action group
• Disallow empty arrays for appliesTo.principalTypes / appliesTo.resourceTypes
• Disallow empty appliesTo attribute thus requiring at least one of principalTypes, resourceTypes or context to be specified if appliesTo is specified.

Describe alternatives you've considered

• Keeping it as is
• Improving documentation / tooling
• Introducing explicit way of specifying that action applies to all principal types / all resource types

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

[mwhicks1]

I'm not understanding how one specifies that a particular Action cannot be used in a request, i.e., it can only be used as a group. That was what an empty principalTypes and/or resourceTypes indicates in the status quo, and I believe it is also when a missing appliesTo indicates.

For the four bullets in your request:

• The first matches the status quo
• The second bullet also matches the status quo
• Implementing the third bullet would prevent indicating that an action cannot be used in a request at all

I would think that what we want is to go with your bullet list, but to change the second bullet thusly:

• Omitted appliesTo means that it cannot be used in a request, rather than that it can be used with the unspecified principal/resource and empty context

[max2me]

Mike, maybe I'm misreading the docs but I don't first and second bullet correspond to status quo?

If the principalTypes component is omitted from the appliesTo element, then an authorization request with this action can have a principal entity of any type, or the unspecified entity. The same is true for resourceTypes, for a request’s resource component. If the appliesTo component is omitted entirely, it’s the same as if it were present with both principalTypes and resourceTypes components omitted (i.e., a request can have both principal and resource entities of any type, or leave them unspecified).

[max2me]

After reading @mwhicks1 a few times I understood the issue. I've updated comment to be more explicit about desired behavior.

4th point does introduce the constraint that for actions applied to unspecified principal and resource, context must be defined. I'd love to get feedback on whether this is too restrictive. If so, we can drop it (and yes, next time I'll number my bullet points and will order them better too :).

[mwhicks1]

I think what you have is fine. It seems very unlikely to me that you will have an action with unspecified principal, resource, and context. Otherwise that action is essentially unconditionally accepted. For AVA you will have unspecified principal and resource but you will specify the context. If you don't have a context, you are very likely to care about details of principal, resource, or both.

[cdisselkoen]

The above discussion refers to "first", "second", and "third" bullets but it seems things have been edited at some point, making this discussion very hard to track. For someone new to the discussion, can someone describe the status quo and how the proposal in this issue differs?

[max2me]

Let me take a stab at it.

Scenario	Status Quo	Proposal
Specified appliesTo but ommited principalTypes/resourceTypes	Authz request can have a principal/resource entity of any type, or the unspecified entity	Authz request with this action can only have unspecified entity as principal/resource
Omitted appliesTo	Authz request can have a principal/resource entity of any type, or the unspecified entity	Action cannot be used in authz request
appliesTo.principalTypes: [] / appliesTo.resourceTypes: []	Action cannot be used in authz request	❌ Not allowed
appliesTo is defined but sub-elements are ommited	Authorization request can have a principal/resource entity of any type, or the unspecified entity; context is an empty record	❌ Not allowed

[cdisselkoen]

Thanks!

Does the proposal have no way to specify that the action applies to a principal/resource entity of any type?

What is the difference between the first row and fourth row in your table?

[max2me]

Does the proposal have no way to specify that the action applies to a principal/resource entity of any type?

That is correct. Proposal advocates for removing this option as customers can manually list entity types action applies to.

What is the difference between the first row and fourth row in your table?

In a way 4th row argues that if appliesTo element is defined and principalTypes/resourceTypes are ommitted, then context must be defined.

[cdisselkoen]

Makes sense to me; I'm in favor of this proposal.

I assume that if you omit just the context, it defaults to empty record (in both the status quo and the proposal)?

[mwhicks1]

I assume that if you omit just the context, it defaults to empty record (in both the status quo and the proposal)?

Yes. And also, if for some reason you wanted to allow the unspecified principal and resource, and the empty context record, you can write appliesTo { context: {} }. It seems very unlikely you'd want to do this, but you can.

[khieta]

Thanks for filing this issue @max2me! I'm also in favor of this proposal. But since this proposal is a breaking change for our schema format, I think it would be better to open an RFC for it so it's recorded with all our other design discussions. I took the liberty of converting the issue to an RFC here: cedar-policy/rfcs#35 I've marked it as a draft for now, pending your sign off.