AVP Policy - how and where to map technical actions i.e. rest endpoints to Business-Friendly Actions ?

1. Mapping Technical Actions to Business-Friendly Names: Currently, Amazon Verified Permissions (AVP) does not provide a built-in way to directly map technical actions to business-friendly names within the policy itself. The policies are written in Cedar language and typically use the technical API endpoints as actions.

However, you can implement a solution to achieve this mapping in your application layer. Here's a recommended approach:

• Create a mapping table or configuration file in your application that associates business-friendly names with their corresponding technical API endpoints.
• In your Lambda authorizer, when receiving a request, translate the business-friendly action name to its technical counterpart before sending it to AVP for evaluation.
• Maintain this mapping in a centralized location in your application, such as a database or configuration file, for easy updates and management.

2. Mapping One Business-Friendly Action to Multiple APIs: AVP policies don't directly support mapping one action to multiple APIs. However, you can achieve this functionality through your application logic:

• In your mapping configuration, associate a business-friendly action name with multiple API endpoints.
• When evaluating permissions in your Lambda authorizer, check if the requested action matches any of the mapped endpoints.
• If a match is found, proceed with the AVP authorization check using the specific technical API endpoint.

For example, your mapping might look like: "Update Entity": ["GET /entity/id", "PUT /entity/id"]

In your Lambda authorizer, you would check if the requested action matches either of these endpoints before proceeding with the AVP check.

3. UI Options for Policy Management: AWS does not currently provide a separate UI for managing AVP policies outside of the AWS Console. For tenant management of policies, you would need to develop your own UI solution. Here are some best practices for implementing such a solution:

• Create a user-friendly interface that abstracts the complexity of Cedar policy language.
• Implement role-based access control to ensure only authorized users can modify policies.
• Provide templates or wizards to guide users through policy creation.
• Include validation to ensure policies are syntactically correct before saving.
• Implement versioning and auditing for policy changes.
• Consider using AWS SDK or API calls to interact with AVP programmatically from your custom UI.

Remember to thoroughly test your custom UI solution to ensure it correctly interacts with AVP and maintains the integrity of your authorization system.
Sources
Community | Using Verified Permissions with Cognito to control access to API endpoints
Community | Protect API Gateway with Amazon Verified Permissions

Sorry for the delay in response! I'm a Sr. Engineer in the AWS Verified Permissions team.

1. What I would do is try to maintain a single source of truth for this. For instance you can export your API to a swagger file, making sure that the swagger file contains OperationIds. Then you can generate your schema and your action mappings from the swagger file. You can parse the swaggerfile and return a data structure like this:

interface ActionMapping {
    method: 'get' | 'post' | 'put' | 'patch' | 'delete';
    apiGatewayResourcePath: string;
    avpResource: {type: string, id: string}; 
    avpAction: { namespace: string, id: string } ;
}

The avpResource is optional; it complicates things a little bit. You if you don't need bespoke resources just hardcode your application as resource

But anyway if you have an array of those, that data structure can represent every single one of the (httpVerb, path) tuples in your API spec. With that, you can generate a schema (hardcode your entity types and use the ActionMapping[] for the actions).

With that same data structure, you can generate a hashmap where you map from the data available in api gateway at runtime (http verb which is under event.requestContext.httpMethod.toLowerCase() and the resource path id which is under event.requestContext.resourcePath). You can do that with something like:

actionMappings.reduce((accumulator, actionMapping) => ({
  ...accumulator,
  [`${actionMapping.method} ${actionMapping.apiGatewayResourcePath}`]: actionMapping.avpAction
}, {});

You can vend this data structure to your lambda authorizer by using AWS AppConfig, which has a lambda layer capable of polling appconfig for you. Or you can just include it in the lambda source code.

2. This is done with action groups. They explain that here https://docs.cedarpolicy.com/bestpractices/bp-implementing-roles.html

3. Most of our customers develop their own UI solutions. You'll want to check out cedar-wasm which is how cedarpolicy.com and the AVP console run cedar in the browser. Cedar-wasm allows you to manipulate policies as an abstract syntax tree. You can use the AST as the state of your SPA component and map user clicks to state changes in the AST, then convert the AST to a cedar policy statement. Details on the JSON policy format here https://docs.cedarpolicy.com/policies/json-format.html