Amazon Verified Permissions example policies

The following Verified Permissions policy examples are based on the schema defined for the hypothetical application called PhotoFlash described in the Example schema section of the Cedar policy language Reference Guide. For more information about Cedar policy syntax, see Basic policy construction in Cedar in the Cedar policy language Reference Guide.

Allows access to individual entities

This following example shows how you might create a policy that allows the user alice to view the photo VacationPhoto94.jpg.

permit(
  principal == User::"alice", 
  action == Action::"view", 
  resource == Photo::"VacationPhoto94.jpg"
);

Allows access to groups of entities

This following example shows how you might create a policy that allows anyone in the group alice_friends to view the photo VacationPhoto94.jpg.

permit(
  principal in Group::"alice_friends", 
  action == Action::"view", 
  resource == Photo::"VacationPhoto94.jpg"
);

This following example shows how you might create a policy that allows the user alice to view any photo in the album alice_vacation.

permit(
  principal == User::"alice", 
  action == Action::"view", 
  resource in Album::"alice_vacation"
);

This following example shows how you might create a policy that allows the user alice to view, edit, or delete any photo in the album alice_vacation.

permit(
  principal == User::"alice", 
  action in [Action::"view", Action::"edit", Action::"delete"], 
  resource in Album::"alice_vacation"
);

This following example shows how you might create a policy that allows permissions for the user alice in the album alice_vacation, where admin is a group defined in the schema hierarchy that contains the permissions to view, edit, and delete a photo.

permit(
  principal == User::"alice", 
  action in PhotoflashRole::"admin", 
  resource in Album::"alice_vacation"
);

This following example shows how you might create a policy that allows permissions for the user alice in the album alice_vacation, where viewer is a group defined in the schema hierarchy that contains the permission to view and comment on a photo. The user alice is also granted the edit permission by the second action listed in the policy.

permit(
  principal == User::"alice", 
  action in [PhotoflashRole::"viewer", Action::"edit"],
  resource in Album::"alice_vacation"
)

Allows access for any entity

This following example shows how you might create a policy that allows any authenticated principal to view the album alice_vacation.

permit(
  principal,
  action == Action::"view", 
  resource in Album::"alice_vacation"
);

This following example shows how you might create a policy that allows the user alice list all the albums in the jane account, list the photos in each album, and view photos in the account.

permit(
  principal == User::"alice", 
  action in [Action::"listAlbums", Action::"listPhotos", Action::"view"],
  resource in Account::"jane"
);

This following example shows how you might create a policy that allows the user alice to perform any action on resources in the album jane_vaction.

permit(
  principal == User::"alice", 
  action,
  resource in Album::"jane_vacation"
);

Allows access for attributes of an entity (ABAC)

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. Verified Permissions allows attributes to be attached to principals, actions, and resources. These attributes can then be referenced within the when and unless clauses of policies that evaluate the attributes of the principals, actions, and resources that make up the context of the request.

The following examples use the attributes defined in the hypothetical application called PhotoFlash described in the Example schema section of the Cedar policy language Reference Guide.

This following example shows how you might create a policy that allows any principal in the HardwareEngineering department with a job level of greater than or equal to 5 to view and list photos in the album device_prototypes.

permit(
  principal,
  action in [Action::"listPhotos", Action::"view"],
  resource in Album::"device_prototypes"
)
when {
  principal.department == "HardwareEngineering" &&
  principal.jobLevel >= 5
};

This following example shows how you might create a policy that allows the user alice to view any resource of file type JPEG.

permit(
  principal == User::"alice",
  action == Action::"view",
  resource
)
when {
  resource.fileType == "JPEG"
};

Actions have context attributes. You must pass these attributes in the context of an authorization request. This following example shows how you might create a policy that allows the user alice to perform any readOnly action. You can also set an appliesTo property for actions in your schema. This specifies valid actions for a resource when you want to ensure that, for example, users can only attempt to authorize ViewPhoto for a resource of type PhotoFlash::Photo.

permit(
  principal == PhotoFlash::User::"alice",
  action,
  resource
) when { 
    context has readOnly && 
    context.readOnly == true 
};

A better way to set the properties of actions in your schema, however, is to arrange them into functional action groups. For example, you can create an action named ReadOnlyPhotoAccess and set PhotoFlash::Action::"ViewPhoto" to be a member of ReadOnlyPhotoAccess as an action group. This following example shows how you might create a policy that grants Alice access to the read-only actions in that group.

permit(
  principal == PhotoFlash::User::"alice",
  action,
  resource
) when {
    action in PhotoFlash::Action::"ReadOnlyPhotoAccess"
};

This following example shows how you might create a policy that allows all principals to perform any action on resources for which they have owner attribute.

permit(
  principal,
  action,
  resource
)
when {
  principal == resource.owner
};

This following example shows how you might create a policy that allows any principal to view any resource if the department attribute for the principal matches the department attribute of the resource.

Note

If an entity doesn't have an attribute mentioned in a policy condition, then the policy will be ignored when making an authorization decision and evaluation of that policy fails for that entity. For example, any principal that does not have a department attribute cannot be granted access to any resource by this policy.

permit(
  principal,
  action == Action::"view",
  resource
)
when {
  principal.department == resource.owner.department
};

This following example shows how you might create a policy that allows any principal to perform any action on a resource if the principal is the owner of the resource OR if the principal is part of the admins group for the resource.

permit(
  principal,
  action,
  resource,
)
when {
  principal == resource.owner ||
  resource.admins.contains(principal)
};

Denies access

If a policy contains forbid for the effect of the policy, it constrains permissions instead of granting permissions.

Important

During authorization, if both a permit and forbid policy are enforced, the forbid takes precedence.

The following examples use the attributes defined in the hypothetical application called PhotoFlash described in the Example schema section of the Cedar policy language Reference Guide.

This following example shows how you might create a policy that denies the user alice from performing all actions except readOnly on any resource.

forbid (
  principal == User::"alice",
  action,
  resource
)
unless {
  action.readOnly
};

This following example shows how you might create a policy that denies access to all resources that have a private attribute unless the principal has the owner attribute for the resource.

forbid (
  principal,
  action,
  resource
)
when {
  resource.private
}
unless {
  principal == resource.owner
};

Uses bracket notation to reference token attributes

This following example shows how you might create a policy that uses bracket notation to reference token attributes.

For more information about using token attributes in policies in Verified Permissions, see Mapping identity provider tokens to schema

permit (
    principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup",
    action,
    resource
) when {
    principal["cognito:username"] == "alice" &&
    principal["custom:employmentStoreCode"] == "petstore-dallas" &&
    principal has email && principal.email == "[e-mail]" &&
    context["ip-address"] like "192.0.2.*"
};

Uses dot notation to reference attributes

This following example shows how you might create a policy that uses dot notation to reference attributes.

For more information about using token attributes in policies in Verified Permissions, see Mapping identity provider tokens to schema

permit(principal, action, resource)
when {
    principal.cognito.username == "alice" &&
    principal.custom.employmentStoreCode == "petstore-dallas" &&
    principal.tenant == "x11app-tenant-1" &&
    principal has email && principal.email == "[e-mail]"
};

Reflects Amazon Cognito ID token attributes

This following example shows how you might create a policy references ID token attributes from Amazon Cognito.

For more information about using token attributes in policies in Verified Permissions, see Mapping identity provider tokens to schema

permit (
    principal in MyCorp::UserGroup::"us-west-2_EXAMPLE|MyUserGroup",
    action,
    resource
) when {
    principal["cognito:username"] == "alice" &&
    principal["custom:employmentStoreCode"] == "petstore-dallas" &&
    principal.tenant == "x11app-tenant-1" &&
    principal has email && principal.email == "[e-mail]"
};

Reflects OIDC ID token attributes

This following example shows how you might create a policy references ID token attributes from an OIDC provider.

For more information about using token attributes in policies in Verified Permissions, see Mapping identity provider tokens to schema

permit (
    principal in MyCorp::UserGroup::"MyOIDCProvider|MyUserGroup",
    action,
    resource
) when {
    principal.email_verified == true && principal.email == "[e-mail]" &&
    principal.phone_number_verified == true && principal.phone_number like "+1206*"
};

Reflects Amazon Cognito access token attributes

This following example shows how you might create a policy references access token attributes from Amazon Cognito.

For more information about using token attributes in policies in Verified Permissions, see Mapping identity provider tokens to schema

permit(principal, action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"], resource)
when { 
    context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" &&
    context.token.scope.contains("MyAPI/mydata.write")
};

Reflects OIDC access token attributes

This following example shows how you might create a policy references access token attributes from an OIDC provider.

For more information about using token attributes in policies in Verified Permissions, see Mapping identity provider tokens to schema

permit(
    principal, 
    action in [MyApplication::Action::"Read", MyApplication::Action::"GetStoreInventory"],
    resource
)
when { 
    context.token.client_id == "52n97d5afhfiu1c4di1k5m8f60" &&
    context.token.scope.contains("MyAPI-read")
};