Allow comparisons on entity types

[WanderingStar]

Category

Cedar language features

Describe the feature you'd like to request

We'd like to be able to grant permissions on all resources of a given type ("Cyrus can view all Photos").

Describe the solution you'd like

A specific test for this would be ideal:
resource is Photo

Describe alternatives you've considered

It's possible to implement this today using attributes, but that leads to the possibility that an entity might be created with an attribute that doesn't actually match its type.

Syntaxes that treat the entity type like a pseudo-attribute would work too:
resource.type == "Photo"
resource.EntityType == "Photo"
resource.entity_type == "Photo"
However this might be confusing or collide with attribute names.

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

[anwarmamat]

It is on roadmap to add an is operator to the cedar language. is operator can restrict the entity type in the policy. For example:

principal is User in Group::"admins"

or

resource is Cake

[mwhicks1]

Guidance we have given other customers is that actions should be "typed," in the sense that they include in their name the type of the resource they apply to. So instead of writing

permit(
  principal == User::"admin",
  action == Action::"view",
  resource is Photo
);

you could write

permit(
  principal == User::"admin",
  action == Action::"viewPhoto",
  resource
);

In your schema, you indicate that the viewPhoto action should always be accompanied by a Photo for the resource, so the policy doesn't need to say that explicitly (and doesn't need to perform a runtime check).

Would this pattern work for your use-case?

For the example @anwarmamat gave, you can just write principal in Group::"admins" when you know that all entities in Group::"admins" have type User. If they don't, it might be possible to split the group so that it has a uniform type.

Indeed, using groups is another way to implement is -- whenever you might like to write is T you could write in Group::"T" instead, and make sure all of the T elements are members of this group.

[WanderingStar]

Typing actions would cause maintenance problems for us. We have some "roles" (policy template equivalents) in our existing authorization scheme that include things like "allowed to Describe all resources in this subtree", where there are many different resource types in the subtree. We could add a new DescribeXyz action each time we added a new resource, but it would make our policy templates a lot bigger. That might be an okay price to pay.

It seems like using group membership has the same drawback that using attributes does: the potential for data to be out of sync. If we have an AllPhotos group that every Photo is a member of, we need to declare that parent in every Photo entity, right?

[mwhicks1]

Thanks for these clarifying details.

include things like "allowed to Describe all resources in this subtree"

I'm not following how this scenario works. This feature request is to be able to use is to limit the resource to a particular type. But here you are saying the resource will not be a particular type, it could be one of many types. If so, won't you need to make templates for each type anyway, which is tantamount to making a template with a typed action?

If we have an AllPhotos group that every Photo is a member of, we need to declare that parent in every Photo entity, right?

Yes. I agree that it's redundant (the type Photo is signaling the information you want). I'm not sure how you are planning to write your code, but if you put the code that makes entities out of your app data in one place, I imagine it wouldn't be too hard to have that code add the parent link to the "type group." I.e., for every entity of type T, your code will add a parent of type Type::"T". Would that work? Note there is no need to actually create the Type::"T" entity itself, because use of in doesn't require that. Using a group this way also avoids the potential clash with attributes like .type or .EntityType that you pointed out.

[WanderingStar]

@mwhicks1, sorry, I had tried to make the example simple for this feature request. Here's some more context:

We're trying to implement things like this EnvironmentAdmin role:
https://docs.confluent.io/cloud/current/access-management/access-control/cloud-rbac.html#environmentadmin

Our goal is to be able to do this with a single policy template, rather than multiple templates that are granted at the same time because we don't want it to be possible that only part of the role is in effect. We expect millions of these linked policies, so simplicity of maintenance is a priority.

The role has three kinds of abilities:

1. take any action on any resource within the appropriate part of the resource hierarchy
2. take the Describe action on the parents of the appropriate part of the resource hierarchy so that the holder can navigate to their part of the hierarchy
3. take the Describe action on any User in the organization, because this role allows permission granting and the holder needs to be able to see who they're granting permissions to

We can implement these like so:

@id("Admin")
permit(
  principal == ?principal,
  action, 
  resource)
when {
    // take any action in the scope that you're admin on
    resource in ?resource

    // describe up the tree for navigation
    || (action == Action::"Describe" && ?resource in resource)

    // describe principal types for AlterAccess
    || (action == Action::"Describe"
        // && (resource is User || resource is ServiceAccount) // not implemented yet
        && resource has "isPrincipal" // placeholder for ^
        && resource.org == ?resource.org)
};

The last clause relies on the isPrincipal attribute being set correctly for all User and ServiceAccount entities. I would prefer to use their types directly (as sketched in the not implemented yet line).

If we typed our actions, we'd have to change this:

    // describe up the tree for navigation
    || (action == Action::"Describe" && ?resource in resource)

To something like:

    // describe up the tree for navigation
    || (action in [Action::"DescribeCluster", Action::"DescribeEnvironment", Action::"DescribeOrganization"]
      && ?resource in resource)

Though it would make the final clause simpler:

    || (action in [Action::"DescribeUser", Action::"DescribeServiceAccount"]
        && resource.org == ?resource.org)

[mwhicks1]

The change to the action clause doesn't seem too terrible, but I see that use of is would be simpler. I find the typed-action approach more illuminating since it's more clear what the policy is actually allowing, directly.

The alternative I suggested, which is to make a group of all things that are technically principals, might look like this:

        && resource has "isPrincipal"

becomes

        && resource in Role::"principal"

Whenever you create a User or ServiceAccount entity for passing to the Cedar authz engine, you have to add Role::"principal" as a parent. That's code you have to get right (hopefully in just one place) in your application, whereas defining the actions happens in the policy.

Note that per this comment I could imagine splitting this one policy template into several templates that we could ensure are linked all at once (with a new feature we'd have to add).

[WanderingStar]

Agreed that the change to that action clause doesn't seem terrible, but our real resource graph has many more resource types than this example (> 50 with more on the way).

Is memberOfTypes intended to be for type grouping or for instance grouping? It seems awkward to use it for both.

[mwhicks1]

our real resource graph has many more resource types than this example (> 50 with more on the way).

Good to know. I understand that this will increase the number of specific actions. Instead of N generic actions, you'd have M times N, where M is the number of resource types relevant to those actions.

But if you end up needing a separate policy for each resource type, you don't end up saving that much. In particular, for every resource type T instead of a policy like

permit(principal ..., action == Action::"viewT", resource) ...

you'd have a policy like

permit(principal ..., action == Action::"view", resource is T) ...

So the count of policies is the same.

If you don't always need a policy for each resource type, but sometimes want a policy for all resource types for the same action, like "view", you can use action groups. E.g., define a group Action::"view" which contains all the specific typed actions, like Action::"viewPhoto", Action::"viewUser", etc. Then your generic policy would be:

permit(principal ..., action in Action::"view", resource) ...

Notice the in in the policy. All actions in the group are in play.

Is memberOfTypes intended to be for type grouping or for instance grouping? It seems awkward to use it for both.

memberOfTypes is type-level, and memberOf is for instances. The former is used in the entityTypes part of the schema, e.g., that Users can be members of Teams, while the latter is used in the actions part -- memberOf is how you'd implement action groups discussed above.