appendix A End-to-end example with Amazon Verified Permissions
This appendix walks through an end-to-end ACME “Customer Collaboration” authorization setup on Amazon Verified Permissions, using only the AWS CLI and a Cedar-based model. It begins by explaining that AVP is a managed service for evaluating Cedar policies, then shows how to create a policy store in strict validation mode, upload the Cedar schema, and prepare policies and entities for testing. The overall goal is to demonstrate how a real application can move from local policy definitions to cloud-hosted authorization decisions without building and operating a custom policy engine.
The core of the example is the policy and data model. The schema defines employees, customers, teams, documents, actions, and contextual attributes such as device management and time. On top of that schema, the appendix adds layered policies: customers may view documents if they belong to the right reader team; employees may view documents through team membership or managerial relationship; document owners can view, edit, and share their own documents; sharing is further limited to delegatable documents and authorized employee readers; and a global forbid blocks employee access from unmanaged devices. These policies are uploaded individually to AVP, illustrating how Cedar rules are validated and stored in a policy store.
The final part shows how entities and authorization requests are evaluated together. Employees, customers, teams, and a sample document are loaded as entity data representing the relationship graph AVP uses during decisions. The appendix then calls is-authorized for several cases: the owner is allowed to view, a customer is allowed to view shared content, an employee is allowed to share when conditions are met, and an employee on an unmanaged device is denied despite otherwise qualifying. Together, these examples demonstrate how AVP combines identity, relationships, resource attributes, and environmental context to produce clear allow-or-deny outcomes, with global constraints overriding narrower permissions when needed.
A.7 Wrapping up the end-to-end example
With these tests, we’ve seen authorization scenarios for ACME’s Customer Collaboration platform in action. As the owner, Alice can edit the Q3 plan without restrictions. Kate, representing CustCo, can view the document through her customer readers team. Bob, as an ACME employee, can share the document when it is delegatable and he is on a managed device, but the global forbid policy blocks access when he connects from an unmanaged laptop.
Taken together, these scenarios show how Cedar policies combine various authorization patterns: ownership baselines, customer sharing, discretionary delegation, and global ABAC-style constraints. Each policy is quite simple on its own, but when combined, they create rich, context-aware authorization behavior. In a real-life deployment, ACME wouldn’t upload static entities from a file for each request; instead, the Customer Collaboration platform would read them dynamically from its relationship graph.
FAQ
What is the purpose of the end-to-end Amazon Verified Permissions example in this appendix?
The appendix shows how to run the ACME “Customer Collaboration” example on Amazon Verified Permissions by creating a policy store, uploading a Cedar schema, adding policies, and callingis-authorized to get allow or deny decisions.What prerequisites are needed to follow the AVP example?
You need an AWS account, an IAM user namedproofer with SignInLocalDevelopmentAccess and AmazonVerifiedPermissionsFullAccess, AWS CLI v2 installed and configured, a supported AWS region such as us-east-1, and helpful JSON tools like jq.Why does the example create a separate policy store in AVP?
The policy store acts as the container for the schema, policies, and entities. Creating a new store gives ACME a place to manage authorization data for the example application.Why is strict validation mode used when creating the policy store?
Strict mode makes AVP enforce type checks against the schema and prevents malformed policies from being uploaded.What entities and actions are defined in the Cedar schema?
The schema defines entity typesEmployee, Customer, Team, and Document; document attributes like owner, delegatable, and reader teams; actions doc:view, doc:edit, and doc:share; and context fields for device and time.Why must the Cedar schema be converted to JSON before uploading?
The AVPput-schema API expects the Cedar schema to be embedded as an escaped string inside a JSON object in the cedarJson field, so jq is used to wrap and escape it.What are the main policies uploaded for document access?
The example uploads a customer view policy, an employee view policy, an owner-baseline policy for view/edit/share, a share policy for delegatable documents, and a global forbid policy for unmanaged devices.How does the owner-baseline policy work?
It permits anEmployee to doc:view, doc:edit, or doc:share a document when that employee is the document owner. This gives the owner full control over their document.How does AVP use entities in the example?
Entities represent the relationship graph used by authorization decisions. The example uploads employees, customers, teams, and a document as JSON so AVP can evaluate who belongs to which team and who owns the document.What happens when an employee uses an unmanaged device in the authorization test?
The globalforbid policy overrides the allow policies and returns DENY for employee access when context.device.managed == false, even if the employee otherwise qualifies for access.
Authorization in Action ebook for free
