Partial schema validation #8
Conversation
|
I just want to point out that ability to declare |
|
|
||
| # Summary | ||
|
|
||
| This RFC proposes extending the Cedar validator to work with partial or even complete empty schemas, |
| When a policy mentions an undefined entity type, or attempts to access an undefined attribute of some entity type, | ||
| the validator will not signal an error, unless it recognizes that there is an inevitable type error. | ||
| For example, even if the type of `access_level` is not declared, we know `principal.access_level > "5"` will inevitably error due to the `>` comparison against a string. | ||
| Partial schema validation does not attempt to detect all type errors, and is therefore unsound. |
There was a problem hiding this comment.
Per offline discussion, it would be interesting to emit warnings in cases where the current proposal silently accepts the policy (e.g., in cases where the policy mentions an undefined entity type, or attempts to access an undefined attribute).
I like this idea because it allows us to prove some kind of soundness property (namely that in the absence of validation warnings or errors, the policy will not produce an error at authorization time). The other benefit of this design (as pointed out in offline discussion) is that it allows for tooling to help users improve their schemas (e.g., offering to add a definition for a new entity type).
| # Motivation | ||
|
|
||
| We want to provide some of the benefits of policy validation to Cedar users who have not written or may not be able to write a schema. | ||
| Detecting any amount potential errors during development is preferable to discovering the errors later, |
| Undeclared entity types and actions are treated as incomplete according to the second two kinds of incompleteness. | ||
| At the extreme, it is possible to have a schema that does not declare any entity types or actions. | ||
|
|
||
| This policy will validate with an empty schema that does not declares either of the entity types or the action. |
There was a problem hiding this comment.
either of the entity types or the action -> any entity types or actions
| The bottom type functions like the [TypeScript `any` type](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any). | ||
| It is used to ensure that the type is allowed to appear in any expression without causing additional type errors. | ||
| The `>` operator expects a value of type `Long` as its operand. | ||
| It will in fact accept any subtype of `Long`, and the bottom type is a subtype of every type, so it accepted. |
| so an expression `principal.role == "Admin"` would still be accepted by the validator. | ||
|
|
||
| Alternatively, we might have complete information about the attributes present for `User` entities. | ||
| When we know that `access_level` does not exist, the `shape` for the principal entity type can include `"additionalAttributes": false` to specify that there are no undeclared attributes for this entity type. |
There was a problem hiding this comment.
Note that "additionalAttributes": false is the default, so it is unnecessary to say this explicitly.
There was a problem hiding this comment.
I see now that it's noted in a later section, but still good to include here to head off confusion.
| We extend the schema format to support the above example schema. | ||
| Specifically, we add the following properties to the JSON: | ||
|
|
||
| * Any record type, including the record types for entity attributes and action context attributes, may include `"additionalAttributes": true` to specify that values having that record type may have attribute other than those declared. |
There was a problem hiding this comment.
may have attribute -> may have attributes
| This change does not necessarily require any change to the behavior of the standard validator, | ||
| but the additions to the schema format could be soundly supported. |
There was a problem hiding this comment.
Will the implementation make these changes, or is this noting that the changes are possible?
| A sound, type inference based, approach to partial schema validation would report _more_ type error than this proposal, | ||
| so it could not be used as a drop-in replacement. |
There was a problem hiding this comment.
type error -> type errors
Also: why would an inference-based approach result in more errors?
|
|
||
| * Policy validation is not required to use Cedar, | ||
| so we could continue to support validation only for users who are able to provide a complete schema. | ||
| * We could design and implement a type inference algorithm for Cedar. |
There was a problem hiding this comment.
It would be useful to have more details about the schema inference option to determine whether it is a viable alternative.
Experimental implementation of partial schema validation as described in cedar-policy/rfcs#8.
rendered
RFC for cedar-policy/cedar#99