Skip to content

Allow is_authorized() to source action entities from a schema #286

@cdisselkoen

Description

@cdisselkoen

Category

User level API changes

Describe the feature you'd like to request

Today, in order to provide is_authorized() with information about action entities (e.g., attributes or parents), you have to pass them as part of the entities argument to is_authorized(). If callers want to reuse the action definition from their schema, they have to manually call .action_entities() on their schema and then add those entities to their other Entities. Cedar could/should provide a convenience API that automates this. As one possible design (but not the only design), Authorizer::new() could take an optional schema argument; if present, action entities from that schema would automatically be added to each authorization request made with that Authorizer.

Describe alternatives you've considered

  • Instead of changing Authorizer::new(), we could make an additional Authorizer constructor that takes a schema argument. This might be better for backwards compatibility.
  • Instead of embedding the schema in the Authorizer, we could just have an optional schema argument to is_authorized(), or a new version of is_authorized() that takes a schema argument.
  • We could prevent actions from being passed in entities, and instead take a actions argument to is_authorized(), which could be provided by a schema or directly from a second Entities object. This would probably involve a new trait IntoActions or something, which would be implemented by both Schema and Entities.

Additional context

  • We still don't want to make schemas required for authorization. This means that you need to be able to call is_authorized() without a schema, and also that you'll need to still be able to provide action entities somehow even if you're not providing a schema. In the main proposal above, this would be trivially satisfied by continuing to allow action entities to be passed as part of entities.
  • This issue may or may not involve a breaking change to Cedar's public API, depending on design choices above.
  • This issue affects/is impacted by New API for validating requests #191

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

Metadata

Metadata

Assignees

Labels

feature-requestThis issue requets a substantial new feature

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions