Fine-Grained Authorization with Amazon Verified Permissions - Access Control Using Cedar Policies
Learn how to externalize authorization logic from application code using the Cedar policy language and implement token-based authorization decisions with Cognito integration.
Overview of Verified Permissions
Verified Permissions is a managed service that provides fine-grained authorization for applications. Traditionally, with authorization logic implemented as if-statements within application code, changing policies involved code deployments. Verified Permissions externalizes authorization rules using the Cedar policy language, allowing policy changes to take effect without code deployments. Cedar is an open-source authorization policy language developed by Amazon, designed to support formal verification. Policy evaluation is deterministic - the same input produces the same authorization decision, which can be used for debugging and auditing.
Cedar Policies and Cognito Integration
Cedar policies consist of permit (allow) and forbid (deny) statements. You can declaratively write rules such as "User A is permitted to perform the read action on Document X" or "The admin role is permitted to perform all actions on all resources." Forbid policies take precedence over permit policies, so access denial under specific conditions can be enforced. Condition clauses (when/unless) enable dynamic conditions like "allow access only during business hours" or "allow only when the IP address is within the corporate network range." With Cognito integration, ID token claims (groups, custom attributes) are used as principal attributes in Cedar policies for authorization decisions based on tokens. You can place a Lambda function as an API Gateway authorizer that calls the Verified Permissions IsAuthorized API.
Policy Stores and Batch Authorization
A policy store is a collection of Cedar policies, created per application. You define entity types (User, Document, Folder) and actions (Read, Write, Delete) in a schema and validate policy syntax against it. Defining a schema prevents the creation of policies that reference non-existent entity types or actions. The IsAuthorized API authorizes a single request, while the BatchIsAuthorized API authorizes multiple requests together. Using the batch API to determine access rights to multiple resources at once on list screens can reduce the number of calls compared to repeated individual API calls. Policy templates define common patterns, and template-linked policies dynamically bind users and resources, and policies for common patterns are managed together. API calls recorded with CloudTrail can be used for auditing access.
Design Best Practices and Pitfalls
For policy design, one approach is to combine RBAC (role-based) and ABAC (attribute-based). Manage basic permissions through roles, and express fine-grained conditions like "only the document owner can delete" through attributes. A common pitfall is debugging difficulty as policy count grows. When policies accumulate in a single policy store, tracking which policy evaluated a specific authorization decision becomes challenging. The countermeasure is to use policy templates to abstract common patterns and keep the number of concrete policies manageable. Additionally, Cedar formal verification tools integrated into CI pipelines detect policy conflicts (where both permit and forbid apply to the same request) before deployment. When implementing authorization result caching, cache TTL involves a tradeoff with immediate policy change reflection requirements. Applications requiring real-time responsiveness use short TTLs, while applications with high read frequency and rare policy changes use longer TTLs.
Comparison with Other Authorization Approaches
Multiple approaches exist for application authorization, selected based on requirements. IAM policies are for access control to AWS resources and do not handle business logic-based authorization within applications (e.g., "only the document creator can edit"). Verified Permissions handles this application-layer authorization. Open Policy Agent (OPA) enables general-purpose policy descriptions in the Rego language but requires self-managed policy engine hosting and availability management. Verified Permissions is a managed service, so there is no policy engine to host yourself. Cognito group-based authorization suits simple RBAC but does not support resource-level fine-grained control or declarative policy management. For multi-tenant SaaS, you can isolate policy stores per tenant so that policies do not interfere across tenants.
Verified Permissions Pricing
Verified Permissions pricing is based on the number of requests for single authorization, batch authorization, and policy management. By integrating with Cognito, you can separate user authentication (Cognito) from authorization (Verified Permissions) and externalize authorization logic from application code. For applications with high request volumes, caching authorization results to reduce request counts can lower costs. Each call to the BatchIsAuthorized API is metered as one request, regardless of the number of authorizations included in it.
Summary
Verified Permissions is a service that externalizes application authorization using the Cedar policy language. It separates user authentication from authorization through Cognito integration and validates policy syntax with policy store schemas. The BatchIsAuthorized API authorizes multiple requests in bulk, and policy templates manage common patterns. Combining RBAC and ABAC lets you handle both role management and fine-grained conditional access control.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon Verified Permissions official page
- Amazon Cognito official page
- Amazon API Gateway official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.