New API for validating requests

[khieta]

Category

User level API changes

Describe the feature you'd like to request

The content of this issue was migrated from RFC#11.

Overview

Given a schema, validation checks that policies conform to the schema, and schema-based parsing checks that entities and context conform to the schema. This issue proposes to add support for checking that a request conforms to a schema.

Example

Say the schema specifies that an action readFile should only be used with principals of type User and resources of type File. This RFC proposes to add a new constructor for the Request type, which takes a schema argument that is used to validate fields when constructing a Request.

Examples (using informal syntax for EUIDs):

Request::new(Some(principal), Some(action), Some(resource), context); // original API; unchanged by this RFC

Request::new_with_validation(Some(User::"alice"), Some(Action::"readFile"), Some(File::"secret_file.txt"), context, schema); // returns a Request

Request::new_with_validation(Some(User::"alice"), Some(Action::"readFile"), Some(Folder::"some_folder"), context, schema); // returns an error (invalid resource)

See RFC#11 for additional motivation and examples.

Describe the solution you'd like

Add a new constructor for the Request type, which takes a schema argument that is used to validate fields when constructing a Request. More concretely, the new API will have the following signature:

pub fn new_with_validation(
        principal: Option<EntityUid>,
        action: Option<EntityUid>,
        resource: Option<EntityUid>,
        context: Context,
        schema: &Schema
    ) -> Result<Request> {
        ...
    }

(This is the same as the signature for Request::new, aside from the schema argument and return type.)

If the action is None (indicating that it is "unspecified"), then the function performs no additional checks. If the action is Some, then the function checks that the specified action is present in the schema, and that the principal and resource are consistent with the action's appliesTo lists in the schema.

Describe alternatives you've considered

See discussion on RFC#11.

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

[ChunghaSung]

Need this feature! It takes an advantage of schema for more intuitive authorization.
The current authorization for action/resource hierarchy is not intuitive.

It will solve the issue below.

Here is the structure of the resource.

         media
          /    \
       photo   video

And I have three actions in the below structure

                 view
          /                         \
   viewPhoto               viewVideo

And, I want viewPhoto is applicable to photo only and viewVideo to video.

I use below schema.json

"actions": {
      "viewPhoto" : {
        "appliesTo" : {
          "resourceTypes" : [ "Photo" ],
          "principalTypes" : [ "User" ]
        },
        "memberOf" : [ {
          "id" : "view",
          "type" : "Action"
        } ]
      },
      "viewVideo" : {
        "appliesTo" : {
          "resourceTypes" : [ "Video" ],
          "principalTypes" : [ "User" ]
        },
        "memberOf" : [ {
          "id" : "view",
          "type" : "Action"
        } ]
      },
      "view" : {
        "appliesTo" : {
          "resourceTypes" : [ "Media" ],
          "principalTypes" : [ "User" ]
        },
        "memberOf" : [ ]
      }
    }
...

I expect viewPhoto is allowed to perform only photo and viewVideo for only video.
But, I am getting ALLOW on viewPhoto on video and viewVideo on photo.

../cedar-2.3.2/target/debug/cedar authorize -p "User::\"mike\"" -a "Action::\"viewPhoto\"" -r "Video::\"video\"" --policies policy.txt --entities entities.json --schema schema.json

This behavior seems not intuitive to me.