Differences between Amazon Verified Permissions and the Cedar policy language
Amazon Verified Permissions uses the Cedar policy language engine to perform its authorization tasks. However, there are some differences between the native Cedar implementation and the implementation of Cedar found in Verified Permissions. This topic identifies those differences.
Namespace definition
Verified Permissions implementation of Cedar has the following differences from the native Cedar implementation:
-
Verified Permissions supports only one namespace in a schema
defined in a policy store. -
Verified Permissions doesn't allow you to create a namespace
with the following values: aws
,amazon
, orcedar
.
Policy template support
Both Verified Permissions and Cedar allow placeholders in the scope for only the
principal
and resource
. However, Verified Permissions also requires that
neither the principal
and resource
are unconstrained.
The following policy is valid in Cedar but is rejected by Verified Permissions because the
principal
is unconstrained.
permit(principal, action == Action::"view", resource == ?resource);
Both of the following examples are valid in both Cedar and Verified Permissions because both the
principal
and resource
have constraints.
permit(principal == User::"alice", action == Action::"view", resource == ?resource);
permit(principal == ?principal, action == Action::"a", resource in ?resource);
Schema support
Verified Permissions requires all schema JSON key names to be non-empty strings. Cedar allows empty strings in a few cases, such as for properties.
Extension type support
Verified Permissions supports Cedar extension typesentities
parameter of the
IsAuthorized
and IsAuthorizedWithToken
operations.
Extension types include the fixed point (decimal
) and IP address (ipaddr
) data types.
Cedar JSON format for entities
At this time, Verified Permissions requires you to pass the list of entities to be considered in an
authorization requestion using the structure defined for the EntitiesDefinition, which is an array of EntityItem
elements. Verified Permissions doesn't currently support passing the list of entities to be considered
in an authorization request in Cedar JSON
format
Action groups definition
The Cedar authorization methods require a list of the entities to be considered when evaluating an authorization request against the policies.
You can define the actions and action groups used by your application in the schema. However, Cedar doesn't include the schema as part of an evaluation request. Instead, Cedar uses the schema only to validate the policies and policy templates that you submit. Because Cedar doesn't reference the schema during evaluation requests, even if you defined action groups in the schema, you must also include the list of any action groups as part of the entities list you must pass to the authorization API operations.
Verified Permissions does this for you. Any action groups that you define in your schema are
automatically appended to the entities list that you pass to as a parameter to the
IsAuthorized
or IsAuthorizedWithToken
operations.
Length and size limits
Verified Permissions supports storage in the form of policy stores to hold your schema, policies, and policy templates. That storage causes Verified Permissions to impose some length and size limits that aren't relevant to Cedar.
Object | Verified Permissions limit (in bytes) | Cedar limit |
---|---|---|
Policy size¹ | 10,000 | None |
Inline policy description | 150 | Not applicable to Cedar |
Policy template size | 10,000 | None |
Schema size | 10,000 | None |
Entity type | 200 | None |
Policy ID | 64 | None |
Policy template ID | 64 | None |
Entity ID | 200 | None |
Policy store ID | 64 | Not applicable to Cedar |
¹ There is a limit for policies per policy store in Verified Permissions based on the combined size of principals, actions, and resources of policies created in the policy store. The total size of all policies pertaining to a single resource can't exceed 200,000 bytes. For template-linked policies, the size of the policy template is counted only once, plus the size of each set of parameters used to instantiate each template-linked policy.