The Need for Sophisticated Authorization
Modern applications, especially in regulated industries like finance, require moving beyond simple role-based checks. Decisions often depend on dynamic context: user roles, transaction amounts, geographic location, organizational hierarchy, and tenant affiliation. Convera, a global cross-border payments platform, faced this challenge as their service offerings grew. Building an in-house solution for policy management, real-time evaluation, logging, and auditing would have diverted critical engineering resources. Their choice of Amazon Verified Permissions highlights a strategic shift towards using managed services for non-differentiating, complex infrastructure—allowing teams to focus on core business logic.
Key Driver: The flexibility of the Cedar policy language to express complex rules and its seamless integration with AWS services like Amazon Cognito and API Gateway made it an ideal foundation for a centralized authorization layer.
Core Architecture Pattern: User Access Control
The heart of Convera's implementation is the combination of Amazon API Gateway, a Lambda Authorizer, and Amazon Verified Permissions. Authentication is handled by Amazon Cognito, while authorization decisions are delegated to Verified Permissions.
The Authorization Flow:
- A user logs in via a client app, authenticating with Amazon Cognito.
- A Cognito "Pre Token Generation" Lambda hook fetches user roles/attributes from a datastore (e.g., Amazon RDS) and injects them into the JWT.
- The client makes an API call, including the enriched JWT in the request.
- API Gateway intercepts the request and invokes the configured Lambda Authorizer.
- The Authorizer validates the token, extracts principal/action/resource/context, and sends an authorization query to Verified Permissions.
- Verified Permissions evaluates the request against stored Cedar policies in the relevant Policy Store and returns an
AlloworDenydecision. - This decision is translated into an IAM policy returned to API Gateway, which then allows or denies the request to the backend.
Performance Optimization: To guarantee sub-millisecond latency for thousands of authorization requests per second, Convera implemented a two-level caching strategy: leveraging API Gateway's built-in cache for authorization decisions and application-level caching for Cognito tokens.
Advanced Applications: Service-to-Service & Multi-Tenancy
Securing Service-to-Service (M2M) Communication
The same authorization architecture was extended to secure communications between microservices. Each service is registered as a client in a Cognito machine-to-machine (M2M) user pool. Policies are defined based on service identity, allowed operations, and rate limits. Services obtain access tokens using client credentials, and the Lambda Authorizer evaluates requests like "Is Service A permitted to perform action X on resource R?" against Verified Permissions.
Multi-Tenant Access Control
For SaaS offerings, enforcing strict data isolation between tenants is paramount. Convera adopted a Per-tenant Policy Store model.
| Approach | Advantages | Why Convera Chose It |
|---|---|---|
| Per-tenant Policy Store | Strong policy isolation, tenant-specific schema/template customization, easier tenant onboarding/offboarding, per-tenant resource quotas. | Met stringent security requirements for complete policy separation and enabled granular resource management per tenant. |
| Single Store with Policy Segmentation | Single management point, simpler initial setup. | Could become complex to manage and optimize at scale with thousands of tenants and complex policies. |
The flow involves injecting a tenant_id attribute into the user's JWT via a Cognito hook. The Lambda Authorizer reads this tenant_id, looks up the corresponding policy store ID, and directs the authorization query to that specific store. Backend services validate the tenant_id header (applying zero-trust principles) and use it as a data filter in database queries.
Limitations & Considerations:
- Cost: The per-tenant policy store model can increase management costs proportional to tenant count. A single store with policy segmentation might be more cost-effective for smaller-scale or early-stage SaaS products.
- Vendor Lock-in: This architecture is deeply integrated into the AWS ecosystem. Migration to another cloud or hybrid setup would require significant re-engineering.
- Learning Curve: Teams need to become proficient with the Cedar policy language and Verified Permissions concepts.
Conclusion & Next Steps
The Convera case study demonstrates a powerful pattern for decoupling authorization from application logic in complex enterprise environments. By using a declarative policy language (Cedar) and a centralized evaluation engine (Verified Permissions), they achieved enhanced security, maintainability, and scalability.
Practical Advice for Implementation:
- Adopt Incrementally: Start by integrating Verified Permissions with a new microservice or a less critical API, rather than attempting a big-bang rewrite of existing systems.
- Treat Policies as Code: Version control your Cedar policies in Git. Utilize Verified Permissions' policy testing capabilities to create unit tests for your authorization logic.
- Leverage Audit Trails: All authorization decisions are logged to AWS CloudTrail. Use these logs for security audits, compliance reporting, and troubleshooting.
Recommended Learning Path:
- Official Documentation: Study the Amazon Verified Permissions User Guide to master the Cedar syntax and advanced patterns.
- Hands-On Workshop: The AWS Verified Permissions Workshop is the best way to gain practical experience.
- Explore Related Services: Deepen your knowledge of Amazon Cognito advanced features (Pre/Post Token Generation hooks) and API Gateway Lambda Authorizer best practices to design a more robust overall architecture.
You can find the detailed source material for this architecture analysis in the original AWS Architecture Blog case study on Convera.