feat(tpe): add type-aware partial evaluation entity model and validation - #370
Open
muditchaudhary wants to merge 1 commit into
Open
muditchaudhary wants to merge 1 commit into
muditchaudhary wants to merge 1 commit into
Conversation
Introduces the entity-side foundation for Cedar's type-aware partial evaluation (TPE), where an entity's attributes, parents, and tags may each be independently unknown. Signed-off-by: Mudit Chaudhary <chmudit@amazon.com>
muditchaudhary
force-pushed
the
tpe-step1-foundation
branch
from
September 16, 2026 21:56
0469e31 to
b3c5f6f
Compare
muditchaudhary
marked this pull request as ready for review
September 16, 2026 22:55
| * @return a debug rendering of this partial entity | ||
| */ | ||
| @Override | ||
| public String toString() { |
Member
There was a problem hiding this comment.
Should we have some tests for this?
| .next(); | ||
| assertTrue(nullFields.getAttrs().isEmpty()); | ||
| assertTrue(nullFields.getParents().isEmpty()); | ||
| assertTrue(nullFields.getTags().isEmpty()); |
Member
There was a problem hiding this comment.
What about a test checking that a present-but-empty attrs/parents/tags in the JSON comes back as present-and-empty rather than unknown? The blocks above only cover the omitted and null cases, which map to unknown.
|
|
||
| /** | ||
| * Constructs a collection from concrete entities, each of which is fully known. Mirrors | ||
| * {@code PartialEntities::from_concrete}. |
Member
There was a problem hiding this comment.
I am not sure this is true, it calls lift, which calls from_json_value?
| } | ||
|
|
||
| @Test | ||
| public void testRejectsDuplicateUid() throws InternalException { |
Member
There was a problem hiding this comment.
This covers the set entities constructed with Set but maybe we should also test from_json (i.e. build the json array of entities).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the entity model for Cedar's type-aware partial evaluation (TPE) to CedarJava: entities whose attributes, parents, and tags may each be independently unknown. Everything is
@Experimentaland purely additive — no existing API changes.This is the entity half of the foundation. The TPE request/response types and the authorization call itself follow in a separate PR.
What
CedarJava
PartialEntity— EUID always known; attrs, parents, and tags each either absent (unknown) or present and complete.PartialEntities— the collection, carrying the two checks that only make sense over the whole set: no duplicate UIDs, and no in-collection parent whose own parents are unknown.PartialEntityUID— partial counterpart toEntityUID, reusingEntityTypeNameandEntityIdentifier. The type is always known, since TPE needs it to type check a request.Schemaand validate eagerly, so a value in hand has already been checked.CedarJavaFFI
tpeCargo feature andsrc/tpe.rswith two validators, accepting a schema in either Cedar or JSON format.Why
TPE evaluates policies against incomplete data, which needs a way to say "this entity exists but I don't know its attributes" — distinct from "I don't know whether this entity exists at all," which is expressed by leaving it out of the collection.
Validation happens at construction rather than at authorize time so that a bad entity fails where the mistake was made, with a message naming the offending attribute, instead of surfacing later as an opaque error from a call that looks unrelated.
Issue: #364