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

Question

**Current State of Our Application:**

We provide API-level authorization for REST APIs exposed by our application.
We are using Cognito for user authentication and AVP for authorization.
Requests from authenticated users go through an API Gateway that triggers a Lambda authorizer.
The Lambda authorizer interacts with the AVP service to evaluate requests against defined policy schemas and policies.
AVP either allows or denies access based on permissions defined using the Cedar language.

**Queries:**
1. Mapping Technical Actions to Business-Friendly Names:
Currently, our policies define actions in a technical way, referring directly to APIs.

Example:

```
  permit (
      principal in {namespace} :: UserGroup :: {user-group},  
      action in [ {namespace} :: Action :: "get /samples1/entities" ],  
      resource  
  );  
```

In this case, the action is `GET/samples1/entities`,  which is technical.

* Is there a way to define these actions in more human-readable or business-friendly terms, such as "Fetch Entities", but still map them to the underlying API  **GET /samples1/entities** ?  
*  If yes, how can this be achieved?
* If no, what is AWS’s recommendation? Should the application handle this mapping, and if so, where should this mapping ideally be maintained? Do you have any examples or reference material on this?

2. Ability to map one business-friendly named action to multiple APIs:

Is there a way, where we can map one action in a policy to multiple APIs behind the scenes ?
Ex:
  If I define the policy as follows

```
    permit (
      principal in {namespace} :: UserGroup :: {user-group},  
      action in [ {namespace} :: Action :: Update Entity ],  
      resource  
  );  
```
  
  Here, the `Update Entity` action should allow permissions to say two APIs

```
   Ex: GET /entity/id
           PUT /entity/id

```

3. UI Options for Policy Management:
* Is there any UI provided by AWS (other than the AWS Console) that can be used to define or update these policies? We want to avoid sharing the AWS Console directly with our tenants.

* If yes, could you please share any relevant references?
*  If no, does AWS recommend that applications develop their own UI for this? Are there any best practices or guidelines for implementing such a solution?

re:Post Agent · Answer

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](https://community.aws/content/2fGON2AupHO29uPWZg9ln68mE1b/using-verified-permissions-with-cognito-to-control-access-to-api-endpoints)  
[Community | Protect API Gateway with Amazon Verified Permissions](https://community.aws/content/2euY03dfEImW1VDerX1ILegHqRb/protect-api-gateway-with-amazon-verified-permissions)

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

Relevant content