Allow operator IN list for resource element

[Maev4l]

Category

Cedar language or syntax features/changes

Describe the feature you'd like to request

Is there any reason why the following syntax is not permitted for resource element:
resource in [PhotoApp::Photo::"vacationPhoto.jpg", PhotoApp::Photo::"birthdayPhoto.jpg"] ?
Whereas the same functionnality functionnality is ok for the action element:
//matches any of the listed actions
action in [Action::"listAlbums", Action::"listPhotos", Action::"view"]

Describe alternatives you've considered

If I want to have the same functionnality for the resource element, I have considered the following approaches:
1/ First approach
permit (
principal == PhotoApp::User::"alice",
action == PhotoApp::Action::"viewPhoto",
resource
) when {
resource in [PhotoApp::Photo::"vacationPhoto.jpg",PhotoApp::Photo::"birthdayPhoto.jpg"]
};

It looks weird to have no defined constraints on resource in scope, whereas there is a constraint in the condition clause related to the resource ID itself

2/ Second approach
Have 2 permissions:
permit (
principal == PhotoApp::User::"alice",
action == PhotoApp::Action::"viewPhoto",
resource == PhotoApp::Photo::"vacationPhoto.jpg"
);

permit (
principal == PhotoApp::User::"alice",
action == PhotoApp::Action::"viewPhoto",
resource == PhotoApp::Photo::"birthdayPhoto.jpg"
);

But that would lead to a huge number of permissions

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]

As part of the design of the Cedar language we decided that that role-based policies should ideally be associated with a single principal or resource (or principal group or resource group), so we softly enforce this by limiting what you can write in the policy scope while leaving the condition unconstrained to accommodate any other uses cases.

Both of your approaches are perfectly valid, though the second duplicates part of the policy in a way I would rather avoid. Two approaches you may not have considered:

1. policy templates.

You can write one policy template

permit (
  principal == PhotoApp::User::"alice",
  action == PhotoApp::Action::"viewPhoto",
  resource == ?resource
);

Which you link twice, once for each resource you want the policy to apply to. This is essentially your second approach, but without duplicating the rest of the policy.

2. resource groups.

permit (
  principal == PhotoApp::User::"alice",
  action == PhotoApp::Action::"viewPhoto",
  resource in PhotoApp::Album::"shared-with-alice"
);

where the two resources you want to grant access to are a member of that group.

I would probably go with policy templates just based on the small examples policy you shared, but this of course depends on the rest of your authorization code.