Add is operator

[khieta]

This RFC was migrated from cedar-policy/cedar#94

Rendered

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[john-h-kastner-aws]

This alternative also does not allow for any short circuiting in the typechecker. Although, that short circuiting is what allow users to go against our best practices for actions, so it could be viewed as a feature of the alternative.

[mwhicks1]

I move that we accept this RFC but with usage of is limited to conditions, and as its own expression not combined with in. This is a two-way door. We have consensus on this aspect, it presents no risk to scope-based policy indexing, and as we get more experience we can choose to allow is in policy scopes and/or combination with in as usage becomes more compelling.

[khieta]

Thanks for the feedback everyone! I am working on revising the initial draft -- hopefully I'll have it posted tomorrow. Here's a sneak peak of what I plan on changing:

• do not allow is in the policy scope
• do not allow combined syntax like .. is .. in ..
• remove "example 1", which can be solved more naturally by Validate requests #11
• spend some more time thinking about how is interacts with the best practice of "typed actions"

[jeffsec-aws]

One example I was working on is ability to define a policy to a specific entity like:

permit (
    principal is User, // here we want to mean any entity of type User while some Admin and Partner entity types might also exist
    action == Action::"read",
    resource == Document::"ToS"
);

I agree that this can be implemented in the condition clause instead to prevent change of other operations like listing policies. It would have the representation:

permit (
    principal,
    action == Action::"read",
    resource == Document::"ToS"
) when {
   principal  is User, // here we want to mean any entity of type User while some Admin and Partner entity types might also exist
};

While some mitigations would also solve the question at stake, is operator existence is more scalable and would prevent to

• have to make the schema larger by creating specific purpose actions ():

      "globalRead": {
          "attributes": {},
          "appliesTo": {
              "principalTypes": [ "User"],
              "resourceTypes": [ "Document" ],
          }
      }
  

• have to go the Group relationship way:

  permit (
      principal in Group::"All users" // This has to be maintained and passed as an entity component.... which can be large, therefore the caveat vs being able to use == User or == User::"*"
      action == Action::"read",
      resource == Document::"ToS"
  );
  

[khieta]

Revision (finally) posted! Based on in-person discussion, I decided to leave the proposal to include is and is ... in in the scope unchanged, but I did make several revisions to the motivating example.

[jeffsec-aws]

The md file for this RFC has a Typo.

The text spells out

In many cases, this can also be done by adding restrictions to the schema. For example, the appliesTo field for each action in the schema allows users to specify which entity types can be used as principals and resources for that action. In the example [above](https://github.com/cedar-policy/rfcs/blob/feature/khieta/is-operator/text/0005-is-operator.md#basic-example), the schema could specify that applyFile should only apply to principals of type User and resources of type File. However, this doesn't help if the user is not using a schema, the action is unconstrained, or the policy refers to an action that may act on multiple principal/resource types.

While the example above is:

permit(
  principal is User,
  action == Action::"viewFile",
  resource is File in Folder::"public"
);

Therefore the action should be viewFile and not applyFile in the sentence the schema could specify that applyFile should only apply to principals of type User

[khieta]

Fixed the typo. Thanks @jeffsec-aws

[khieta]

The final comment period (FCP) for this RFC is starting now, with intent to accept. The FCP will end 2023-07-28 at noon PT / 3pm ET / 7pm UTC. Please add comments, and especially any objections, if you have any. For more on the RFC process, see https://github.com/cedar-policy/rfcs.