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 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 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 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 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 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 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 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)
};