Forem: Daniel Aniszkiewicz

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XVI: AVP meets new pricing

Daniel Aniszkiewicz — Fri, 13 Jun 2025 16:44:37 +0000

Hello there! Long time no see! Let's get back to our series about Amazon Verified Permissions!

The last few months haven't brought much news in AVP, other than the addition of tags (which should have been added a long time ago), but a few days before re:Inforce, we got a real game changer: a price change.

As we know, AVP has many advantages, but the biggest drawback has always been the price. For a new service, this made it very difficult for customers to adopt. I've conducted many workshops, talks, and a large implementation around AVP, but this pricing has always been a pain point for many people.

In this blog post, I want to share my perspective on the price change based on the use case I implemented with my team.

Recap on pricing

Until today, pricing looked like this: we paid for the number of authorization requests, and depending on how many requests we made, we had several tiers. The more requests you made, the less you paid per request (but this only made sense with a large number of requests).

We also have a cost for Policy management requests, but it's a small cost for managing policy stores.

Let's look at a 70 million requests scenario monthly (our current volume):

First 40 million requests: 40,000,000 × $0.00015 = $6,000
Next 30 million requests: 30,000,000 × $0.000075 = $2,250
Total: $6,000 + $2,250 = $8,250 monthly => $99,000 yearly

Such a price can cause a big headache. Often in smaller companies, this is the entire annual AWS budget, not just for one authorization service.

Cache?

When talking about AVP with different people, the discussion always went to: "Well, okay, but we can always cache authorization decisions so we don't have to pay so much for AVP." And it's true - this is especially efficient if you have M2M flows with lots of repetitive requests in a short period.

I presented our use case for AVP, handling authorization for 70 million API requests monthly. This consisted of traffic on API Gateway and monolithic apps - API calls only.

In my Re:Invent 2024 presentationI presented our use case for AVP, handling authorization for 50 million API requests monthly (currently it's 70 million so in this blogpost I will focus on this number). This consisted of traffic on API Gateway and monolithic apps - API calls only.

I also presented how we built the cache for AVP (API Gateway with its built-in cache mechanism, and how we built our own cache). You'll see that we cache up to 98% of requests when we have 70 million authorization requests per month (currently)!

To be more precise:

Total authz decisions: 70.7M
Direct AVP: calls1.4M
Cache hits: 69.3M

Unfortunately, AVP doesn't have a built-in cache option.
If you use AVP in a Lambda authorizer attached to API Gateway, you can use the authorizer cache mechanism - just remember to set the correct cache keys! If you use it in a monolithic application, you have to build the cache yourself and understand the whole mechanism well. You can use Redis (whether it's ElastiCache Redis or Valkey on AWS). The cache isn't free, but the cost isn't huge either.

Our current ElastiCache Setup:

Multiple clusters (cache.t4g.micro, primary + replica = 2 nodes/cluster)
Engine Redis OSS 7.x (reserved, 1-year)
Current cost: $7.34/day

Which was about 220$ USD monthly for Elasticache clusters.

New pricing

Today a pricing change came out that changes everything. There are no more tiers for authorization requests, which means we have a flat rate of $5 per million requests (down from $150). That's a 97% price drop!

For our case with 70 million authorization requests, the calculation now looks like:
70 million requests: 70,000,000 × $0.000005 = $350 monthly → $4,200 yearly (compared to $99,000 in the old pricing).

Keep in mind that batch authorization request costs remain unchanged!

Will You Still Cache?

I'm getting lots of questions about whether I plan to get rid of the cache with such a dramatic price change.
"AVP is so cheap now, why bother with cache anymore?"
"Let's simplify and just use direct API calls"

The short answer is no.

This only applies to my specific use case - in other cases, the outcome might be totally different. Here's why we're keeping our cache:

First, we built the cache mechanism ourselves (for those who don't use API Gateway's built-in mechanism). It's already implemented, works well, and handles a huge number of requests. This means both a smaller AVP bill every month AND better performance because we get data faster from cache than by sending requests to AWS APIs. (We use 10-minute TTL and spent quite a lot of time developing it.)
Second, our cache hit ratio is insanely high (98%). This means without cache, we'd go from 1.4 million API calls to 70 million API calls. That's not just "a few more API calls" - it's 50x more calls. Even at the new cheap rate, 50x more of anything adds up fast.
Third, there are quota and performance considerations. Loading from cache is faster than direct API calls.
However, if we wanted to reduce cache costs, we could look at ElastiCache with Valkey (based on pricing, it would reduce costs by 20% just by changing the engine).
We could go even further and consider Serverless Valkey (my calculations showed about 80% cheaper per cluster per month).

Certainly, if we were starting from scratch today (in our use case), we would not be building a cache with the new pricing structure. We were one of the early adopters of AVP.

My opinion

I think this is a great and needed change that will definitely boost AVP adoption among customers
It solves one of AVP's major problems, but we still have others (developer experience, lack of aliasing, versioning, cross-region replication, and several others)
I'm very optimistic that the AVP team is working hard on new features and improvements, so I can't wait for more news!

Go build now!

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XV: AVP with Cognito groups

Daniel Aniszkiewicz — Sat, 27 Apr 2024 16:40:16 +0000

Welcome back to my blog post series dedicated to building authorization using Cedar and Amazon Verified Permissions. In a previous blog post, we learned about the usage of AVP getting started. Today, we will cover the topic of using Cognito Groups with AVP.

Related to AVP getting started, Cognito groups are now supported in the AVP, as you well know from the previous blogpost. However, in this blogpost we won't focus on building a getting started gateway with AVP, but we will focus on building authorization with AVP itself using cognito groups (So you can use it for API gateway, resource server, and enhance it for your use case pretty easily. If you want to see the finished result, you can use the scenario from avp-cli here.

In addition, we will also use the new BatchIsAuthorizedWithToken API operation that was recently released.

Cognito groups support

Currently, AVP only supports Cognito as an external identity provider(IdP). We create the reference from Cognito through the CreateIdentitySource action.

For configuration, we need to specify:

policyStoreID
- userPoolArn (ARN of the Cognito user pool),
clientIds (optional, unique application client IDs that are associated with the specified Amazon Cognito user pool.)
principalEntityType (namespace and data type for the entity that will be a principal for our policy store)

What was introduced into the CognitoUserPoolConfiguration, that groupConfiguration is the entity type that the policy store maps to groups from the Cognito user pool identity source. In short, which entity from the policy store will be mapped from the Cognito group.

Below you can see example values for principalEntityType and groupEntityType in the case of namespace MyApp for the AVP policy store to see how it will look in reality.

That is, in short, when building an identity source for a policy store, we need to pass it on, and there you go!

Practice

Today, we would like to build an authorization system for the banking transaction system. Within, we have a user who can perform operations such as:

View
Approve
Edit for resources of type TransactionRecord.

We would like to introduce here RBAC based on groups:

transaction_viewers
transaction_approvers
transaction_editors in Cognito, that is, depending on the role, the user can perform different operations.

Cognito part

Let's start with our IDP from Cognito, we will create a user pool with groups, app client id, and add users there and add them to groups. Then we will obtain a Cognito token and use it for testing.

In order not to build this from scratch, for the purpose of this blogpost I created a ready-made Cloudformation template that will create a Cognito user pool, groups, and app client, we just need to later create users and add them to groups.

Navigate to the AWS console, and open the AWS console, open Cloudformation, and upload the authentication.yaml from the avp-cli repo.

After the deployment, as outputs you can see both the CognitoUserPoolId as well as CognitoUserPoolId.

Navigate to the Cognito user pool.

You will see 3 groups generated, now what you need to do, is create users and assign them to the groups:

Later we will need to copy the ARN of the Cognito User Pool, App Client Id (it is called avp-client, and initiate the auth with our users.

I am aware I am showing the cognito user pool, however before publishing the blogpost the cognito user pool on my site will be already deleted. Never share credentials, ARNs, JWTs, ClientIds, or secrets over the internet!

Policy Store part

Let's start building a policy store, log in to your AWS console, open the AVP service, and create an empty policy store.

Go to the schema tab, and paste this schema. Save the changes, you should see this action diagram and entity types diagram:

As we can see, we have principal as user (i.e., who), actions like approve, edit, view (i.e., what operation we want to perform), and resource (i.e., on what resource we want to do), i.e., TransactionRecord.

In addition, we can see that we have an entity of type Group, to which our user belongs (Hierarchy).

Identity Source.

Now, we can reference our IDP (so Cognito) with AVP. Navigate to the Identity sources in the AVP console and create a new one. Fill the user pool ID (copy it from the user pool details from the Cognito details page, the same for the client application ID (you will find it in the App integration section of the user pool).

For the principal details we will use the Principal type as BankingTransationSystem::User so this will map our user pool to Cognito as a principal. Moreover the principal ID so the token issued for the connected user pool will be mapped to a principal ID in the format ‘|’

Unfortunately, we cannot add groupEntityType from the AWS console position (we cannot both see the value, modify it, or add it from the console). Although we can do it through AWS-CLI, AWS-SDK, Cloudformation, or through AVP-CLI.

AVP CLI for CreateIdentitySource

So if we want to do it via AVP-CLI, we can do it with:



➜  avp-cli git:(main) node index.js
🚀 Welcome to the AVP CLI Tool!
Designed to streamline your interactions with the Amazon Verified Permissions (AVP) service.
🔧 Create, manage, and delete policy stores, schemas, and policies. Plus, deploy and test with predefined scenarios!
⚠️ Ensure your AWS credentials are correctly set up before proceeding.
? What would you like to do? Manual approach
? What would you like to do? Create Identity Source
? Enter the ID of the policy store TKdiMU5n3DeypqsnEHb9d6
? Enter the entity type of the principal BankingTransactionSystem::User
? Enter the Amazon Cognito User Pool ARN arn:aws:cognito-idp:eu-west-1:ACCOUND_ID_GOES_HERE:userpool/eu-west-1_sXVC4jUDf
? Enter the Amazon Cognito App Client ID 5b33v2gf0cr1c4n6qj04rajjhf
? Enter the entity type for groups, or press enter to skip

Under the hood it will make an SDK call like this:



{
  policyStoreId: 'TKdiMU5n3DeypqsnEHb9d6',
  principalEntityType: 'BankingTransactionSystem::User',
  configuration: {
    cognitoUserPoolConfiguration: {
      userPoolArn: 'arn:aws:cognito-idp:eu-west-1:ACCOUNT_ID_GOES_HERE:userpool/eu-west-1_sXVC4jUDf',
      clientIds: [Array],
      groupConfiguration: [Object]
    }
  }
}

In the console you will see it like:

Hopefully, soon we will see the group over there.

Policies

Now it's time to add three access policies, for each action separately, it will look like this:



permit (
    principal in
        BankingTransactionSystem::Group::"<user-pool-id-goes-here>|<cognito-group-name-here>",
    action in [BankingTransactionSystem::Action::"View"],
    resource
);

What we see is:

we check if the principal is (with in operator which checks hierarchies) in a specific group (in the above example transaction_viewers) from the Cognito user pool.
we check a specific action
resource is any.

We need to add it for all three groups (per action) accordingly, and it will look like this:

Feel free to add those three policies from the AVP-CLI repo, remember to replace <user-pool-id-goes-here> with your Cognito user pool ID (not the ARN!)

Remember about | between cognito user pool id and group name from the Cognito!

Approach with AVP-CLI scenario

As you can see, a little has to be done to get everything ready. What you can do more simply is to use avp-cli to do the deployment of all the things you need.

Remember to first do the deployment of the authentication.yml file in the Cloudformation console if you haven't done it before.

Next, simply use the AVP-CLI:



➜  avp-cli git:(main) ✗ AWS_PROFILE=personal node index.js
🚀 Welcome to the AVP CLI Tool!
Designed to streamline your interactions with the Amazon Verified Permissions (AVP) service.
🔧 Create, manage, and delete policy stores, schemas, and policies. Plus, deploy and test with predefined scenarios!
⚠️ Ensure your AWS credentials are correctly set up before proceeding.
? What would you like to do? Use prepared scenarios
? Choose a scenario Ecommerce with Cognito Groups Scenario
? Enter the ARN of the Cognito User Pool arn:aws:cognito-idp:eu-west-1:ACCOUNT_NUMBER:userpool/eu-west-1_sXVC4jUDf
? Enter the App Client ID 5b33v2gf0cr1c4n6qj04rajjhf
./scenarios/ecommerceCognitoGroupsScenario/ecommerceCognitoGroupsScenario.json
Starting creating scenario: Ecommerce Cognito Group Scenario
description: This is a basic scenario with a group cognito management platform schema and three policies.
Policy store created with ID: Ny9v75vt5cQGxzEovBgL9R
Schema put successfully for policy store ID: Ny9v75vt5cQGxzEovBgL9R
Creating an identity source...
Identity source created with ID: 9M6FTv52wSnLTR2LAJkRYa
Creating a static policy...
Static policy created with ID: W4Z31yfapD5jWJqvXr57XH
Creating a static policy...
Static policy created with ID: 5k1QXfuWxYJqQa9r3Mnygh
Creating a static policy...
Static policy created with ID: WDu7Pac7umBpHrY2o55TYF
┌────────────────────────────────────────┬────────────────────────────────────────┬────────────────────────────────────────┐
│ Policy ID                              │ Policy Store ID                        │ Created Date                           │
├────────────────────────────────────────┼────────────────────────────────────────┼────────────────────────────────────────┤
│ W4Z31yfapD5jWJqvXr57XH                 │ Ny9v75vt5cQGxzEovBgL9R                 │ 2024-04-27 18:00                       │
├────────────────────────────────────────┼────────────────────────────────────────┼────────────────────────────────────────┤
│ 5k1QXfuWxYJqQa9r3Mnygh                 │ Ny9v75vt5cQGxzEovBgL9R                 │ 2024-04-27 18:00                       │
├────────────────────────────────────────┼────────────────────────────────────────┼────────────────────────────────────────┤
│ WDu7Pac7umBpHrY2o55TYF                 │ Ny9v75vt5cQGxzEovBgL9R                 │ 2024-04-27 18:00                       │
└────────────────────────────────────────┴────────────────────────────────────────┴────────────────────────────────────────┘
Generating of the undefined is finished. Open the AWS console to play around with that.

Consider testing it with our prepared test scenarios:
Either use `Test Scenario` in main CLI to select the specific test scenario, or use below path as argument to `IsAuthorized` from the manual approach option of the CLI:
 Remember to update the policy-store-id within files.
- ./scenarios/ecommerceCognitoGroupsScenario/allow_test_1.json (Access for user who has transaction_viewer group can view) allow
- ./scenarios/ecommerceCognitoGroupsScenario/allow_test_2.json (Access for user who has transaction_approve group can approve) allow
- ./scenarios/ecommerceCognitoGroupsScenario/allow_test_3.json (Access for user who has transaction_edit group can edit) allow

Generating of the ecommerceCognitoGroupsScenario is finished. Open the AWS console to play around with that.

And that's it, you can test.

Prepration for tests

First, we need an access token (or ID token) from Cognito for our user.

Remember, when you create a new user, you must generate a new password for them, which can be done in the AWS CLI with:



aws cognito-idp admin-respond-to-auth-challenge

You can generate code via AWS-CLI, SDK, or by doing the HTTP request via POSTMAN or curl like this:



curl --location 'https://cognito-idp.<REGION>.amazonaws.com/<USER_POOL_HERE!!!!!>' \
--header 'Content-Type: application/x-amz-json-1.1' \
--header 'Accept: */*' \
--header 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' \
--data-raw '{
  "AuthFlow": "USER_PASSWORD_AUTH",
  "ClientId": "<ID_HERE>",
  "AuthParameters": {
    "USERNAME": "<USERNAME>",
    "PASSWORD": "<PASSWORD>"
  }
}
'

As a response, you will obtain both an access token and an id token, use the access token.

If you decode the token with jwt.io you will see:



{
  "sub": "sub",
  "cognito:groups": [
    "transaction_viewers"
  ],
  "iss": 'BLABLA",
  ...
  "auth_time": 1713899648,
  "exp": 1713903248,
  "iat": 1713899648,`
  "username": "daniel"
}
```
so you can double check at this point, whether a proper group is within the JWT of a user.

## Testing
So we can't test it using the test bench because it doesn't support isAuthorizedWithToken operations and for Batch, so we can do it through AWS CLI, SDK, or through AVP-CLI.

### With isAuthorizedWithToken

For authorization with a token, we will use the [isAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html) operation.

We can provide both an access token and an ID token, we will use the access token. It is worth reminding that our principal is a user from the Cognito user pool. AVP on its side will decode the token and check if it is ok, so we don't need to do it on our side.

**If you delete an Amazon Cognito user pool or user, tokens from that deleted pool or that deleted user continue to be usable until they expire.
**

The structure of the request is [here](https://github.com/Pigius/avp-cli/blob/main/structureAuthorizationWithTokenRequest.json). For use usecase we can use this [allow test](https://github.com/Pigius/avp-cli/blob/main/scenarios/ecommerceCognitoGroupsScenario/allow_test_1.json). Generate the access token, and pass it together with policy store ID.

So I've generated an access token for a user which is in the `transaction_viewers` group, and based on the allow test I will try to access the `View` action.

now we will use AVP-CLI:

```shell
? What would you like to do? Manual approach
? What would you like to do? Make an authorization decision with Cognito Identity Token
? Enter the path for json test file scenarios/ecommerceCognitoGroupsScenario/allow_test_1.json

┌──────────┬──────────────────────────────┬────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┐
│ Decision │ Determining Policies         │ Errors             │ Policy Store ID              │ Principal                    │ Action                       │ Resource                     │ Context                      │
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┤
│ ALLOW    │ 7UQxoV3bvzpYvGnm939HZH       │                    │ TKdiMU5n3DeypqsnEHb9d6       │ BankingTransactionSystem::Us │ BankingTransactionSystem::Ac │ BankingTransactionSystem::Tr │ {}                           │
│          │                              │                    │                              │ er::eu-west-1_sXVC4jUDf|f245 │ tion::View                   │ ansactionRecord::*           │                              │
│          │                              │                    │                              │ a454-90c1-7084-7709-1dfbfdb1 │                              │                              │                              │
│          │                              │                    │                              │ 0930                         │                              │                              │                              │

```

If I will try the second test scenario I will be rejected, as my user is only allowed to view.

### With BatchIsAuthorizedWithToken

As recently [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html) has been released, we can use it to test our scenario.

With this operation, we can make up to 30 requests during a single request (and we paid per request, and performance is better). Note that the current request limit is 30, and also our batch can contain up to 100 resources and up to 99 user groups. Example structure is [here](https://github.com/Pigius/avp-cli/blob/main/structureBatchAuthorizationWithTokenRequest.json).

We can pass either an access token or an ID token. The request is either principal or resource oriented.

So, in our scenario, what we can do, is to check, whether my user can access multiple actions on a single resource by making one request to AVP.


![Batch](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ibjhssbay8ss7vn7x6q1.png)



I've prepared test file for that [here](https://github.com/Pigius/avp-cli/blob/main/scenarios/ecommerceCognitoGroupsScenario/batch_allow_test.json).

Let's try with AVP-CLI now:


```
➜  avp-cli AWS_PROFILE=personal node index.js
🚀 Welcome to the AVP CLI Tool!
Designed to streamline your interactions with the Amazon Verified Permissions (AVP) service.
🔧 Create, manage, and delete policy stores, schemas, and policies. Plus, deploy and test with predefined scenarios!
⚠️ Ensure your AWS credentials are correctly set up before proceeding.
? What would you like to do? Manual approach
? What would you like to do? Make a batch authorization decision with Cognito Identity Token
? Enter the path for batch authorization with token json test file scenarios/ecommerceCognitoGroupsScenario/batch_allow_test.json
Making batch with token authorization decision...

┌──────────┬──────────────────────────────┬────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┐
│ Decision │ Determining Policies         │ Errors             │ Policy Store ID              │ Principal                    │ Action                       │ Resource                     │ Context                      │
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┤
│ ALLOW    │ 7UQxoV3bvzpYvGnm939HZH       │                    │ TKdiMU5n3DeypqsnEHb9d6       │ BankingTransactionSystem::Us │ BankingTransactionSystem::Ac │ BankingTransactionSystem::Tr │ {}                           │
│          │                              │                    │                              │ er::eu-west-1_sXVC4jUDf|f245 │ tion::View                   │ ansactionRecord::123         │                              │
│          │                              │                    │                              │ a454-90c1-7084-7709-1dfbfdb1 │                              │                              │                              │
│          │                              │                    │                              │ 0930                         │                              │                              │                              │
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┤
│ DENY     │                              │                    │ TKdiMU5n3DeypqsnEHb9d6       │ BankingTransactionSystem::Us │ BankingTransactionSystem::Ac │ BankingTransactionSystem::Tr │ {}                           │
│          │                              │                    │                              │ er::eu-west-1_sXVC4jUDf|f245 │ tion::Edit                   │ ansactionRecord::123         │                              │
│          │                              │                    │                              │ a454-90c1-7084-7709-1dfbfdb1 │                              │                              │                              │
│          │                              │                    │                              │ 0930                         │                              │                              │                              │
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┤
│ DENY     │                              │                    │ TKdiMU5n3DeypqsnEHb9d6       │ BankingTransactionSystem::Us │ BankingTransactionSystem::Ac │ BankingTransactionSystem::Tr │ {}                           │
│          │                              │                    │                              │ er::eu-west-1_sXVC4jUDf|f245 │ tion::Approve                │ ansactionRecord::123         │                              │
│          │                              │                    │                              │ a454-90c1-7084-7709-1dfbfdb1 │                              │                              │                              │
│          │                              │                    │                              │ 0930                         │                              │                              │                              │
└──────────┴──────────────────────────────┴──────────
```
We will obtain the array of authorization request decisions. As you can see, my user is only allowed to `View`.


## Sumup

That's it for today. We now know:
- how to build AVP policy stores with Cognito as IDP
- use Cognito groups within the access policy
- how to test it.

Now go build!

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XIV: AVP Getting Started

Daniel Aniszkiewicz — Tue, 23 Apr 2024 19:52:27 +0000

Welcome back to my blog post series dedicated to building authorization using Cedar and Amazon Verified Permissions. In a previous blog post we learned about usage of AVP with IaC Cloudformation. Today, we will cover the topic of recently added AVP getting started.

Learning curve

As with any adoption of any technology, there's always a learning curve, in the case of AVP, it's a new service, so, naturally, it's not popularized, and there aren't a lot of materials (but there are more and more every day), as well as a learning curve related to the Cedar language.

The Cedar language is very simple and fun for the developer, but it is a learning curve if you want to implement it in an organization. Let's look at what we need to build authorization with AVP.

To use AVP, we need several elements:

Policy store, which is a container for our access policies, where all policies are kept, and every authorization request, is checked against a specific policy store.
Schema, which is the definition of all entities for our authorization system, possible actions, hierarchies, required and optional attributes, and their types. With schema we can check that our access policies are correct against schema, and so is the payload we send to AVP.
Access policies in Cedar language, which AVP then evaluates for us.
payload - once we have all of the above, it would be nice to finally test our policy store, but for that we need a payload that we will send to the AVP for authorization decision (i.e. we need to send information about the principal, the action it wants to perform, on what resource, pass the required attributes, hierarchy information, etc.)

When you look at it from the side, it seems like a lot of things, and it can be overwhelming.

Rest assured, it was not clear to me at first either, but over time everything has been clarified, and now I fully understand it. That's why the avp-cli was created, to quickly help others understand what it's all about.

Getting started

The AVP team was aware of a learning curve, so to simplify the use of AVP it added getting started to the service. As we know, most authorization cases are mainly RBAC, on API gateway, so the AVP team wanted to simplify the process (especially if you use Cognito for auth).

Typical flow as shown in the figure, Gateway with various endpoints, Cognito for authentication, in addition, we can have some Cognito authorizer that will check access to the gateway.

What AVP Getting Started does for us:

Allows for authorization setup through the AVP wizard in the console under API Gateway.
Based on the actions in the API Gateway, it maps these actions to Cedar actions, eliminating the initial learning curve of Cedar.
Creates a lambda authorizer that we can easily attach to the API Gateway and use, so we don't have to worry about how to build the payload for AVP and use it properly (and overall knowledge about lambda authorizer at all).
On our part, deploying the gateway is required once the authorizer is attached.

Let's assume that we would like to streamline basic flow, and add Role Base Access control (RBAC) authorization, based on groups in Cognito. Before, it was not possible to use Cognito groups in AVP, now it is possible.

So that it's not just a theory, we'll try using Getting Started on some simple examples.

What we will build today?

Based on the AWS announcement post, consider the example of a loan application with two key actions:

Creating a Loan Request (POST /loan): Users can submit new loan applications.
Approving a Loan (POST /loan/approve/{loan_id}): Certain users can approve loans that have been submitted.

Suppose we have two Amazon Cognito groups that have user permissions as follows:

loan_creators: Members of this group are allowed to perform the "Creating a Loan Request" action.
loan_officers: Members of this group have permissions for both creating and approve loans.

And based on that we would like to do authorization at the Gateway level.

Starting point Gateway and Cognito

For the purposes of the blog post, I created two Cloudformation so that everyone can play with it themselves, I know how annoying it always is when you do not have an example at hand that you can quickly use in the console, so I prepared:

a simple Cloudformation with Gateway API, which implements the two endpoints mentioned before.
both endpoints are mocks (to make it simpler).
a simple Cloudformation for Cognito (with groups inside).

Feel free to do deployment of the above cloud formation templates in the AWS console (just grab the template, and go via Cloudformation wizard to deploy it).

Gateway

After successful deployment, you can see Gateway with two endpoints.

Cognito

After successful deployment, you can see the Cognito user pool with two groups, and the avp-client user pool client.

At this stage, we don't have any users, so it would be worthwhile to create a user and add them to a group. This is relatively simple; you need to create a new user and add them to the appropriate group.

Now, let's finally have some fun with AVP! We have everything we need—authentication, gateway, groups, users in groups—so we can finally add authorization.

AVP time!

Gateway actions

Currently, there is no support for CloudFormation, so we need to do this manually. Open the AWS console, and then go to Amazon Verified Permissions.

Start by creating a new policy store, and then select the option Set up with Cognito and API Gateway - new.

First, we need to select an API; we choose our Loan API, select the stage (v0), and then press 'Import API'. Our resources from the API will automatically be translated into Cedar policies.

Identity Source

Now, we need to use our Cognito user pool as an identity source. Simply select the newly deployed Cognito user pool, and use all default options untouched.

Assign actions to groups

Now, we need to assign actions to our Cognito groups, do it the same way as in the picture below (based on our requirements).

Deploy policy store

For the last step, you need to hit Create policy store which will trigger the deployment of the Lambda Authorizer.

You will need to wait for the deployment, and then make sure the lambda authorizer is attached to the gateway, and then you need to re-deploy API.

Show me AVP!

We can immediately check in practice how it works, but before we test it, it will be simpler to see exactly what we have generated in AVP.

Let's start from schema:

So we have two actions (our endpoints), principal as User and Resource as Application

As we deal with hierarchy, we also have UserGroup, which our User is a member of. So based on that, we have an access policy for group membership.

Let's check the generated actions:

Policy defining permissions for loan_officers cognito group



permit(
  principal in loan_api::UserGroup::"eu-west-1_sXVC4jUDf|loan_officers",
  action in [ loan_api::Action::"post /loan/approve/{loan_id}", loan_api::Action::"post /loan" ],
  resource
  );

Policy defining permissions for loan_creators cognito group



permit (
    principal in loan_api::UserGroup::"eu-west-1_sXVC4jUDf|loan_creators",
    action in [loan_api::Action::"post /loan"],
    resource
);

By specifying loan_api::UserGroup::"eu-west-1_sXVC4jUDf|loan_officers and loan_api::UserGroup::"eu-west-1_sXVC4jUDf|loan_creators, the policies are targeting actions based on the membership of the principal in these particular groups (with usage of in operator). They also explicitly define what actions these principals can perform. In the case of loan_officers, the policy permits actions like post /loan/approve/{loan_id} and post /loan. For loan_creators, the policy permits the action post /loan.

With deny as a default rule, we don't need to create forbid policies.

Lambda

The generated lambda authorizer is a type of request-based authorizer, which also will have in the event data section, the data from the request, including query params etc.

The runtime is Node.

Lambda is quite simple, but for us, the most important part is:



  let bearerToken =
    event.headers?.Authorization || event.headers?.authorization;
  if (bearerToken?.toLowerCase().startsWith("bearer ")) {
    // per https://www.rfc-editor.org/rfc/rfc6750#section-2.1 "Authorization" header should contain:
    //  "Bearer" 1*SP b64token
    // however, match behavior of COGNITO_USER_POOLS authorizer allowing "Bearer" to be optional
    bearerToken = bearerToken.split(" ")[1];
  }
  try {
    const parsedToken = JSON.parse(
      Buffer.from(bearerToken.split(".")[1], "base64").toString()
    );
    const actionId = `${event.requestContext.httpMethod.toLowerCase()} ${
      event.requestContext.resourcePath
    }`;

    const input = {
      [tokenType]: bearerToken,
      policyStoreId: policyStoreId,
      action: {
        actionType: actionType,
        actionId: actionId,
      },
      resource: {
        entityType: resourceType,
        entityId: resourceId,
      },
      context: getContextMap(event),
    };

    const authResponse = await verifiedpermissions.isAuthorizedWithToken(input);
    console.log("Decision from AVP:", authResponse.decision);

We can observe the building of the payload for AVP, which uses the token from Cognito. AVP will decode the token and validate the JWKS for us, so we don't need to do this in Lambda. Then, we use the isAuthorized action which performs the authorization request. Based on the decision, we either grant or deny access to the endpoint.

The full lambda code can be found here. Please keep in mind that Lambda code could change, I am not the author of this code!

You don't need to explicitly create a log group for lambda, they will go to /aws/lambda/yourFunctionName.

Let's test it in practice

Now that we have everything, we can finally test our solution. First, we need an access token from Cognito for our user. I recommend creating two users who are in two different groups.

Remember, when you create a new user, you must generate a new password for them, which can be done in the AWS CLI with:



aws cognito-idp admin-respond-to-auth-challenge

You can generate code via AWS-CLI, SDK, or by doing the HTTP request via POSTMAN or curl like this:



curl --location 'https://cognito-idp.<REGION>.amazonaws.com/<USER_POOL_HERE!!!!!>' \
--header 'Content-Type: application/x-amz-json-1.1' \
--header 'Accept: */*' \
--header 'X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth' \
--data-raw '{
  "AuthFlow": "USER_PASSWORD_AUTH",
  "ClientId": "<ID_HERE>",
  "AuthParameters": {
    "USERNAME": "<USERNAME>",
    "PASSWORD": "<PASSWORD>"
  }
}
'

As a response, you will obtain both an access token and an id token, use the access token.

If you decode the token with jwt.io you will see:



{
  "sub": "sub",
  "cognito:groups": [
    "loan_creators"
  ],
  "iss": 'BLABLA",
  ...
  "auth_time": 1713899648,
  "exp": 1713903248,
  "iat": 1713899648,`
  "username": "daniel"
}
```
so you can double check at this point, whether a proper group is within the JWT of a user.

## Testing Gateway
Now we can test our endpoints, starting from the `loan approval endpoint`:

You can use this curl:

```shell
curl --location 'https://<gateway-id>.execute-api.eu-west-1.amazonaws.com/v0/loan/approve/1234' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <TOKEN GOES HERE>' \
--data '{"statusCode": 200}'
```

The `'{"statusCode": 200}'` is needed as is the mock integration type.

The same for `loan creation`:

```shell
curl --location 'https://<gateway-id>.execute-api.eu-west-1.amazonaws.com/v0/loan/' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <JWT here>' \
--data '{"statusCode": 200}'
```

If your user will be with a not allowed group you will obtain the below response:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2dfnphfr5kudmwzk9x2l.png)

## Summary, next steps

And that wraps up today's blog post. As you can see, you can quite simply "click through" the authorization setup for the API Gateway, which as a `getting started` seems sufficient for a PoC and taking the first steps.

When I started, such tools weren’t available, so there was a lot to figure out on your own.

It's also important to note that there is no CloudFormation support for this, so you can't just throw this into your CI/CD and expect it to automatically build. However, you do have something to start with, something you can copy, play with, and then start to build authorization flows in your organization.

You might also try expanding this example to better understand how the service works, for example, try validating an additional parameter from the query params, and learn what needs to be changed.

and now... **Go Build!**

In the next blogpost we will cover [AVP with Cognito Groups](https://dev.to/aws-heroes/authorization-and-amazon-verified-permissions-a-new-way-to-manage-permissions-part-xv-avp-with-cognito-groups-4gjm)


## Useful resources
- [Official quick overview and demo video](https://www.youtube.com/watch?v=OBrSrzfuWhQ)
- [Offical Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/e25284b6-851c-4a89-bee1-ed7571787895/en-US)

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XIII: Cloudformation

Daniel Aniszkiewicz — Sat, 20 Jan 2024 17:17:30 +0000

Welcome back to my blog post series dedicated to building authorization using Cedar and Amazon Verified Permissions. In a previous blogpost we've learned about usage AVP with IaC Terraform. Today, we will cover the topic of how to use AVP with Cloudformation.

Introduction

Cloudformation (IaC) does not need to be introduced to anyone, plus if you read the previous blogpost, the terraform provider (CC) we used is based on Cloudformation. Moreover, you will notice a lot of similarities, after all, we are implementing the same scenario, but with a different tool.

All the Cloudformation references you can check here.

Let's assume that we would like to recreate one of the scenarios from avp-cli in Cloudformation, for example, the documents scenario. This is a basic scenario with a document management platform schema and two policies (Allow all users to view all documents and Forbid user X from viewing any documents).

To recreate this, we need:

A policy store, which is a container for our policies. In such a container, we keep all policies, as well as the schema. It's important to remember that later when using AVP for authorization requests, we send requests against a specific policy store.

A schema is the structure of all available entities for a given policy store. In short, it defines what entities are available for our authorization system, including available actions, principals, and resources. The schema not only informs us about the available entities but also validates the correctness of authorization requests.

Finally, we will also need to add our policies.

Let's build!

The code for today's blog post can be found here.

The example we will create is not intended for production use; it has been created for educational purposes. However, in the future, In the next weeks, I will try to recreate all scenarios from avp-cli to Cloudformation. It will be in this repository, as well as a couple of more advanced, production-wise examples.

For our example, we will need two types of resources from the Cloudformation:

Now that we know everything, we can start building the project with Cloudformation.

Let's start with empty avp.yaml for our Cloudformation configuration.

AWSTemplateFormatVersion: "2010-09-09"

Description: >
  IaC for AVP

Resources:

We've started from adding AWSTemplateFormatVersion to tell CloudFormation which template version we're adhering to. The Description part refers to the overall description of the template.

Now we can focus on the Resources section where we declare the AWS resources you want CloudFormation to create or manage.

Create a policy store

Now our focus will be to add a configuration for a policy store. First, we need to define the validation_settings. It specifies the validation setting for this policy store. In our use-case, we would like to be strict as we will add schema and check the validation of our authorization requests.

  PolicyStore:
    Type: AWS::VerifiedPermissions::PolicyStore
    Properties:
      Description: "Policy store for the documents scenario"
      ValidationSettings:
        Mode: STRICT

We're declaring a resource of type AWS::VerifiedPermissions::PolicyStore, which represents a container in AVP where we will store policies. The Description nested within Properties gives our policy store a description. Moreover, we've added validation settings setup as strict.

Now if we deploy it, we will have an empty policy store with a validation mode setup as strict.

Adding Schema

Now we want to add a schema, which you can find here. As you can see, it is a JSON file that we need to have. Let's update the configuration

...
  PolicyStore:
    Type: AWS::VerifiedPermissions::PolicyStore
    Properties:
      Description: "Policy store for the documents scenario"
      ValidationSettings:
        Mode: STRICT
      Schema:
        CedarJson: |
          {
            "DocumentManagementPlatform": {
              "entityTypes": {
                "User": {
                  "shape": {
                    "type": "Record",
                    "attributes": {}
                  }
                },
                "Document": {
                  "shape": {
                    "type": "Record",
                    "attributes": {}
                  }
                }
              },
              "actions": {
                "View": {
                  "appliesTo": {
                    "principalTypes": ["User"],
                    "resourceTypes": ["Document"]
                  }
                },
                "Edit": {
                  "appliesTo": {
                    "principalTypes": ["User"],
                    "resourceTypes": ["Document"]
                  }
                }
              }
            }
          }

This way, we've added a schema to our policy store.

Policy Store ID

Before we jump into the policies, we need to tackle one important thing in our template. We would like to know the ID of our policy store, so we can easily find it, and check our Policy Store, or pass it to the resources that will use it (for instance Lambda function which will make requests to AVP later on).

So to have it, we need to use Cloudformation Outputs which specifies the values that are returned whenever you view your stack's properties.

We can easily add it like:

...
Outputs:
  PolicyStoreId:
    Description: "Identifier of the Amazon Verified Permissions policy store."
    Value: !Ref PolicyStore

The actual !Ref directive within Value is an intrinsic function used to retrieve the ID of a resource defined in the same template. In our case, !Ref PolicyStore gets the ID of the PolicyStore resource created by the stack.

Adding policies

Now, it's time for the final step, adding policies:

Now we can add:

  AllowPolicy:
    Type: AWS::VerifiedPermissions::Policy
    Properties:
      PolicyStoreId: !Ref PolicyStore
      Definition:
        Static:
          Description: "Allow all users to view all documents"
          Statement: |
            permit (
                principal,
                action in [DocumentManagementPlatform::Action::"View"],
                resource
            );

  DenyPolicy:
    Type: AWS::VerifiedPermissions::Policy
    Properties:
      PolicyStoreId: !Ref PolicyStore
      Definition:
        Static:
          Description: "Forbid user X from viewing any documents"
          Statement: |
            forbid(
              principal == DocumentManagementPlatform::User::"xyz",
              action in [DocumentManagementPlatform::Action::"View"],
              resource
            );

The Type: AWS::VerifiedPermissions::Policy is used for creating two policies.
As any policy is part of that policy store, we needed to reference the Policy Store ID.
For the Definition, we've used static, which indicates that the policy is static – it's not dynamically created from a template but is rather a fixed definition.
For the Statement we just need to pass the definition in Cedar language.

The whole file will look like this:

AWSTemplateFormatVersion: "2010-09-09"

Description: >
  IaC for AVP

Resources:
  PolicyStore:
    Type: AWS::VerifiedPermissions::PolicyStore
    Properties:
      Description: "Policy store for the documents scenario"
      ValidationSettings:
        Mode: STRICT
      Schema:
        CedarJson: |
          {
            "DocumentManagementPlatform": {
              "entityTypes": {
                "User": {
                  "shape": {
                    "type": "Record",
                    "attributes": {}
                  }
                },
                "Document": {
                  "shape": {
                    "type": "Record",
                    "attributes": {}
                  }
                }
              },
              "actions": {
                "View": {
                  "appliesTo": {
                    "principalTypes": ["User"],
                    "resourceTypes": ["Document"]
                  }
                },
                "Edit": {
                  "appliesTo": {
                    "principalTypes": ["User"],
                    "resourceTypes": ["Document"]
                  }
                }
              }
            }
          }

  AllowPolicy:
    Type: AWS::VerifiedPermissions::Policy
    Properties:
      PolicyStoreId: !Ref PolicyStore
      Definition:
        Static:
          Description: "Allow all users to view all documents"
          Statement: |
            permit (
                principal,
                action in [DocumentManagementPlatform::Action::"View"],
                resource
            );

  DenyPolicy:
    Type: AWS::VerifiedPermissions::Policy
    Properties:
      PolicyStoreId: !Ref PolicyStore
      Definition:
        Static:
          Description: "Forbid user X from viewing any documents"
          Statement: |
            forbid(
              principal == DocumentManagementPlatform::User::"xyz",
              action in [DocumentManagementPlatform::Action::"View"],
              resource
            );

Outputs:
  PolicyStoreId:
    Description: "Identifier of the Amazon Verified Permissions policy store."
    Value: !Ref PolicyStore

Deployment

Now that we have everything, let's try to deploy our template.

Navigate to the AWS console, and open Cloudformation service. Inside the Cloudformation service in the AWS console, press Create a new stack with the option With existing resources (import resources). Use the Template is ready.

Overall, we have 3 options for deploying our Cloudformation, either by storing it in S3 (if you use SAM or Serverless Framework you will be aware of that), you can upload it (which we will use), or you can deploy it from your repo. Here is a great article on that.

This time, use the Upload a template file option.

Attach the avp.yaml file and then for Stack name create a name, you can leave the rest of the configuration unchanged.

If we check the Designer option it will look like this:

Attach the avp.yaml file and then for Stack name create a name, you can leave the rest of the configuration unchanged.
Review a stack, accept capabilities, and deploy.
After a couple of minutes everything will be deployed. In the resources tab, you can see 3 resources (AVP policy store, and 2 access policies), and in the output section, you will AVP policy store ID, which you can grab and check the resources in the AVP service.

Feel free to grab the Policy Store ID and check it in AVP.

Final words

As you can see, it's quite simple to create a basic project with AVP using Cloudformation.

If you're interested in more Cloudformation templates, I've recreated all of the AVP-CLI scenarios in CF, you can find them here. In the next blogpost we will tackle AVP getting started feature.

That's all for today. I encourage you to experiment on your own.

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XII: Terraform

Daniel Aniszkiewicz — Mon, 15 Jan 2024 22:46:29 +0000

Welcome back to my blog post series dedicated to building authorization using Cedar and Amazon Verified Permissions. In a previous blogpost we've learned about batch authorization. Today, we will take a look at how to build AVP with one of the most popular Infrastructure as Code (IaC) tool - Terraform.

Introduction

Let's assume that we would like to recreate one of the scenarios from avp-cli in Terraform, for example, the documents scenario. This is a basic scenario with a document management platform schema and two policies (Allow all users to view all documents and Forbid user X from viewing any documents).

To recreate this, we need:

Finally, we will also need to add our policies.

Terraform provider for AVP

In the context of AWS, a Terraform provider is a plugin that allows Terraform to interact with AWS services and resources. It provides the necessary tools and interfaces for managing the lifecycle of various AWS resources through Terraform's infrastructure as code approach.

If we check the support for the Terraform AWS Provider here (state for the date of publishing this article), we will see that the service is not yet fully supported. Last week, after more than half a year, support for creating a policy store was added. Additionally, we have the configuration to add template policies. However, the identity source is in the form of a PR draft, and there is no PR yet for the ability to create policies.

Does this mean that we currently cannot use AVP with Terraform? Not necessarily, as the Cloud Control Provider comes to our rescue.

What is cool about that provider, is that it's auto-generated straight from AWS CloudFormation schemas, meaning it's always in sync with the latest AWS features - no more waiting for manual updates!

Weekly deployments (always on Thursday) with the newest AWS enhancements. This provider taps into the AWS Cloud Control API so you can expect new AWS offerings (supported via Cloudformation) in Terraform almost as soon as they're released.

Let's build!

The example we will create is not intended for production use; it has been created for educational purposes. However, in the future, I will add more advanced projects with Terraform to the repository, also more suited for production use.

For our example, we will need two types of resources from the Terraform:

Now that we know everything, we can start building the project in Terraform. At the end, a link to the repository will be provided, which you can easily clone.

Let's assume we have a new repository, and we start with an empty main.tf file. In order to configure the provider, you will need to employ the configuration blocks shown here, while specifying your preferred region:

main.tf



terraform {
  required_providers {
    awscc = {
      source  = "hashicorp/awscc"
      version = "~> 0.68.0"
    }
  }
}

provider "awscc" {
  region = "eu-west-1"
}

Create a policy store



resource "awscc_verifiedpermissions_policy_store" "policy_store" {
  validation_settings = { mode = "STRICT" }
}

This line declares a new resource of type awscc_verifiedpermissions_policy_store, which is provided by the AWS CC provider. The policy_store is a local name given to this resource instance, which can be used to refer to it within the Terraform configuration. We've added validation settings setup as strict.

At this point, we could easily deploy our configuration via:



AWS_PROFILE=your-profile name terraform init
AWS_PROFILE=your-profile name terraform apply

Which will create an empty policy store with validation settings.

Adding Schema

Now we want to add a schema, which you can find here. As you can see, it is a JSON file that we need to have. Let's add a schema.json file to our main project directory, and then update our configuration:



resource "awscc_verifiedpermissions_policy_store" "policy_store" {
  validation_settings = { mode = "STRICT" }
  schema              = { cedar_json = file("${path.module}/schema.json") }
}

This new line defines the schema for the policy store using the cedar_json attribute.
The file("${path.module}/schema.json") function reads the contents of a file named schema.json located in the same directory as the Terraform module (${path.module} refers to the current module's directory).

The content of this file, which should be in JSON format, is used as the schema for the policy store.

Now when we deploy changes we will schema in our policy store.

Adding policies

Now, it's time for the final step, adding policies:

this allow policy in the root directory under the name of allow_policy.cedar
this deny policy in the root directory under the name of deny_policy.cedar

Later, we can add this config to main.tf:



resource "awscc_verifiedpermissions_policy" "allow_policy" {
  policy_store_id = awscc_verifiedpermissions_policy_store.policy_store.id
  definition = {
    static = {
      statement   = file("${path.module}/allow_policy.cedar")
      description = "Allow all users to view all documents"
    }
  }
}

resource "awscc_verifiedpermissions_policy" "forbid_policy" {
  policy_store_id = awscc_verifiedpermissions_policy_store.policy_store.id
  definition = {
    static = {
      statement   = file("${path.module}/deny_policy.cedar")
      description = "Forbid user X from viewing any documents"
    }
  }
}

The resource "awscc_verifiedpermissions_policy" "allow_policy": declares a new resource of type awscc_verifiedpermissions_policy, named allow_policy. This resource represents a policy in the AVP Policy Store (similar to the forbid_policy).
policy_store_id = awscc_verifiedpermissions_policy_store.policy_store.id: This line specifies the ID of the Policy Store where this policy will be created. It references the id of the previously defined awscc_verifiedpermissions_policy_store resource named policy_store.

Inside the definition block of the policy we have:

static: Indicates that this is a static policy definition.
statement = file("${path.module}/allow_policy.cedar"): The policy statement is defined in an external file named allow_policy.cedar.

The file function reads the contents of this file, which contain the policy written in Cedar policy language. This policy is expected to specify conditions under which access is allowed.

The repo for this project can be found here with proper readme. I've made small improvements to the project (adding outputs to see policy store id and region), and when you deploy it you can see:



wscc_verifiedpermissions_policy_store.policy_store: Creating...
awscc_verifiedpermissions_policy_store.policy_store: Creation complete after 1s [id=VUdm7eCYdN3xW8CeJrrVx8]
awscc_verifiedpermissions_policy.allow_policy: Creating...
awscc_verifiedpermissions_policy.forbid_policy: Creating...
awscc_verifiedpermissions_policy.allow_policy: Creation complete after 9s [id=VKo7ca1kCNHSpVhLfHgrYs|VUdm7eCYdN3xW8CeJrrVx8]
awscc_verifiedpermissions_policy.forbid_policy: Creation complete after 9s [id=VN4qXzoMRhLqxa51KY3WPr|VUdm7eCYdN3xW8CeJrrVx8]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

aws_region = "eu-west-1"
policy_store_id = "VUdm7eCYdN3xW8CeJrrVx8"

Final words

As you can see, it's quite simple to create a basic project with AVP using Terraform. That's all for today. I encourage you to experiment on your own.

If you're interested in more TF templates, I've recreated all of the AVP-CLI scenarios in TF, you can find them here.

In the next blogpost, you can read about usage AVP with Cloudformation.

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XI: Batch Authorization

Daniel Aniszkiewicz — Wed, 06 Dec 2023 17:12:10 +0000

Hello again in the series about building authorization with Amazon Verified Permissions (AVP) and Cedar. In the previous post, we focused on the AVP-CLI tool (which we will also use today). This time, we will focus on a new feature called batch authorization, which, in my opinion, is a game changer in terms of using AVP.

Batch Authorization

Batch authorization in AVP allows you to process up to 30 authorization decisions for a single principal or resource in a single API call. The entities of an API request can contain up to 100 principals and up to 100 resources.

One of the many objections to AVP was the theory that it is too expensive as a service. Now, where we can make many requests in one, it allows for a significant reduction in costs and an increase in performance, as everything goes in one request (and we will pay just for one request).

`isAuthorized` vs `batchIsAuthorized`

Traditionally, the isAuthorized action in AVP is used to process a single authorization request (If you use Test Bench in the AVP console, the AVP is using this API operation to make the authorization decision). This involves sending an individual request for each authorization decision, which can be resource-intensive, especially when multiple decisions are needed.

An example of an isAuthorized request structure can be found below:

{
    "policyStoreId": "your-policy-store-id",
    "principal": {
        "entityType": "Principal::Type",
        "entityId": "entity_id"
    },
    "action": {
        "actionType": "Action::Type",
        "actionId": "action_id"
    },
    "resource": {
        "entityType": "Resource::Type",
        "entityId": "resource_id"
    },
    "entities": {
        "entityList": []
    },
    "context": {
        "contextMap": {}
    }
}

This JSON file outlines the format for a typical single authorization request, including details about the principal, action, resource, entities, and context. More examples of authorization requests you can found in the avp-cli scenarios.

The response looks like this:

response {
  decision: 'ALLOW',
  determiningPolicies: [ { policyId: 'ID_OF_THE_POLICY' } ],
  errors: []
}

It contains:

decision - authz decision that indicated if the authorization request should be allowed or denied.
determiningPolicies - The list of determining policies used to make the authorization decision.
errors - Errors that occurred while making an authorization decision.

The batchIsAuthorized action, however, allows for processing multiple authorization requests in a single API call. This is particularly useful when you need to make several authorization decisions simultaneously, either for one principal across multiple resources or for one resource across multiple principals. The structure of a batchIsAuthorized request is as follows:

{
   "policyStoreId": "your-policy-store-id",
   "entities": {
      "entityList": [
         {
            "identifier": {
               "entityType": "Principal::Type",
               "entityId": "entity_id"
            },
            "attributes": {},
            "parents": []
         },
         {
            "identifier": {
               "entityType": "Resource::Type",
               "entityId": "entity_id"
            },
            "attributes": {},
            "parents": []
         },
         // Additional entities can be included here
      ]
   },
   "requests": [
      {
         "principal": {
            "entityType": "Principal::Type",
            "entityId": "entity_id"
         },
         "action": {
            "actionType": "Action::Type",
            "actionId": "action_id"
         },
         "resource": {
            "entityType": "Resource::Type",
            "entityId": "resource_id"
         },
         "context": {
            "contextMap": {}
         }
      },
      // Additional requests can be included here
   ]
}

In this format, the entities section defines a common list of entities (principals and resources) involved in the batch request. The requests array then specifies individual authorization requests, each comprising a principal, action, resource, and context.

The response looks like this:

"results": [
    {
      "decision": "ALLOW",
      "determiningPolicies": [
        {
          "policyId": "policyId"
        }
      ],
      "errors": [],
      "request": {
        "action": {
          "actionType": "EcommerceStore::Action",
          "actionId": "View"
        },
        "context": {
          "contextMap": {}
        },
        "principal": {
          "entityType": "EcommerceStore::User",
          "entityId": "Ken"
        },
        "resource": {
          "entityType": "EcommerceStore::Product",
          "entityId": "Hat"
        }
      }
    },
    {
      "decision": "ALLOW",
      "determiningPolicies": [
        {
          "policyId": "policyId"
        }
      ],
      "errors": [],
      "request": {
        "action": {
          "actionType": "EcommerceStore::Action",
          "actionId": "GetDiscount"
        },
        "context": {
          "contextMap": {}
        },
        "principal": {
          "entityType": "EcommerceStore::User",
          "entityId": "Ken"
        },
        "resource": {
          "entityType": "EcommerceStore::Product",
          "entityId": "Hat"
        }
      }
    },
...

As we can see, we have results which is a series of Allow or Deny decisions for each request and the policies that produced them. We have an array of authorization decision objects, and with that, we have a request key, which is the authorization request that initiated the decision.

E-commerce example

To demonstrate the power of batch authorization, I've added a new scenario in the AVP CLI tool - the Batch Scenario Scenario. This scenario simulates an e-commerce platform with various user roles, actions, and policies.

Schema Overview

Our schema includes entities like Product, Role, User, and Order, each with specific attributes. Actions such as View, Edit, Buy, GetDiscount, and Preorder are defined to mimic typical e-commerce operations.

Policies

We've crafted policies that cater to different user roles and scenarios:

Admin Role - Order Editing Policy

permit(
    principal in EcommerceStore::Role::"admin",
    action in [EcommerceStore::Action::"Edit"],
    resource
)
when { resource.status == "paid" };

This policy allows users with the admin role to edit orders. However, it restricts editing based on the order's status. Admins can only edit orders that are in the "paid" status, ensuring that orders in other stages of processing are not altered.

Customer Role - Basic Access Policy

permit(
  principal in EcommerceStore::Role::"customer",
  action in [EcommerceStore::Action::"Buy", EcommerceStore::Action::"View"],
  resource
);

Customers are granted the ability to perform basic actions like Buy and View on products. This policy is straightforward and applies to all customers, allowing them to browse and purchase products from the e-commerce platform.

Premium Membership - Special Privileges Policy

permit (
    principal,
    action in
        [EcommerceStore::Action::"GetDiscount",
         EcommerceStore::Action::"Preorder"],
    resource
)
when { principal has premiumMembership && principal.premiumMembership == true };

This policy is designed for users with a premium membership. It allows them to access special actions like GetDiscount and Preorder on products. The policy checks if the user has a premiumMembership attribute set to true, indicating their premium status.

Testing Policies

I've designed two types of tests for this scenario: single authorization requests and batch authorization requests, each serving a unique purpose in our testing strategy.

Single Authorization Request Tests

These tests focus on individual authorization requests, assessing one action at a time. They help us verify the specific behavior of our policies in granular scenarios. Examples include:

Admin Editing Paid Orders: Checks if an admin user (Daniel) can edit orders with the status "paid."
Customer Viewing Products: Verifies that a customer (Tom) can view any product.
Premium Member Discounts: Ensures a premium member (Ken) can access discounts on products.

Batch Authorization Tests

Batch tests are more comprehensive, allowing us to evaluate multiple authorization requests in a single API call. We've prepared two types of batch tests:

Resource-Oriented Batch Test: This test checks multiple resources against a single principal to determine what actions they can perform. For instance, it can assess which orders an admin user is authorized to edit. This approach is particularly useful for scenarios where a user's role or status might grant them varying levels of access across different resources.

Principal-Oriented Batch Test: Conversely, this test evaluates multiple actions for a single principal on a specific resource. It helps us understand the range of actions a user (like Ken) can perform on a particular product. This type of test is essential for applications where user permissions vary based on the resource they are interacting with.

To test the BatchIsAuthorized, we cannot do this through the Test Bench, where we can test our isAuthorized requests to AVP. To solve this problem, I added the option to test batchIsAuthorized to avp-cli. You need to select it from the manual approach option, select make a batch authorization decision, and provide a path to the json test file (use structureBatchAuthorizationRequest.json as a reference) It looks like this:

? What would you like to do? Manual approach
? What would you like to do? Make a batch authorization decision
? Enter the path for batch authorization json test file structureBatchAuthorizationRequest.json
Making batch authorization decision...
┌──────────┬──────────────────────────────┬────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────
│ Decision │ Determining Policies         │ Errors             │ Policy Store ID              │ Principal                    │ Action                       │ Resource                     
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────
│ ALLOW    │ Vz4ZUYv36HwY6v65XTix4i       │                    │ JahHZkVn82ryyn5qMfBXG9       │ EcommerceStore::User::Ken    │ EcommerceStore::Action::View │ EcommerceStore::Product::Hat 
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────
│ ALLOW    │ 4ZbngosNQ8ZCbaBcEQ4SE9       │                    │ JahHZkVn82ryyn5qMfBXG9       │ EcommerceStore::User::Ken    │ EcommerceStore::Action::GetD │ EcommerceStore::Product::Hat 
│          │                              │                    │                              │                              │ iscount                      │                              
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────
│ ALLOW    │ Vz4ZUYv36HwY6v65XTix4i       │                    │ JahHZkVn82ryyn5qMfBXG9       │ EcommerceStore::User::Ken    │ EcommerceStore::Action::Buy  │ EcommerceStore::Product::Hat 
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────
│ ALLOW    │ 4ZbngosNQ8ZCbaBcEQ4SE9       │                    │ JahHZkVn82ryyn5qMfBXG9       │ EcommerceStore::User::Ken    │ EcommerceStore::Action::Preo │ EcommerceStore::Product::Hat 
│          │                              │                    │                              │                              │ rder                         │                              
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────
│ DENY     │                              │                    │ JahHZkVn82ryyn5qMfBXG9       │ EcommerceStore::User::Ken    │ EcommerceStore::Action::Edit │ EcommerceStore::Product::Hat 
└──────────┴──────────────────────────────┴────────────────────┴──────────────────────────────┴──────────────────────────────┴──────────────────────────────┴──────────────────────────────

For our Batch Scenario, we have also the option to test prepared batch authorization test requests like this:

? What would you like to do? Test Batch Authorization Scenario
? Choose a scenario ecommerceBatchScenario
? Choose a test (Use arrow keys)
❯ Checking multiple actions for a single principal (For specific product, What action can be taken by Ken 
  Checking multiple resources, to check which orders can admin edit.
...

Remember to update policy_store_id in here and here.

Example test structure:

{
   "policyStoreId": "your-policy-store-id",
   "entities": {
      "entityList": [
         {
            "identifier": {
               "entityType": "EcommerceStore::User",
               "entityId": "Ken"
            },
            "attributes": {
               "premiumMembership": {
                  "boolean": true
               }
            },
            "parents": [
               {
                  "entityType": "EcommerceStore::Role",
                  "entityId": "customer"
               }
            ]
         },
         {
            "identifier": {
               "entityType": "EcommerceStore::Product",
               "entityId": "Hat"
            },
            "attributes": {},
            "parents": []
         }
      ]
   },
   "requests": [
      {
         "principal": {
            "entityType": "EcommerceStore::User",
            "entityId": "Ken"
         },
         "action": {
            "actionType": "EcommerceStore::Action",
            "actionId": "View"
         },
         "resource": {
            "entityType": "EcommerceStore::Product",
            "entityId": "Hat"
         },
         "context": {
            "contextMap": {}
         }
      },
      {
         "principal": {
            "entityType": "EcommerceStore::User",
            "entityId": "Ken"
         },
         "action": {
            "actionType": "EcommerceStore::Action",
            "actionId": "GetDiscount"
         },
         "resource": {
            "entityType": "EcommerceStore::Product",
            "entityId": "Hat"
         },
         "context": {
            "contextMap": {}
         }
      },
      {
         "principal": {
            "entityType": "EcommerceStore::User",
            "entityId": "Ken"
         },
         "action": {
            "actionType": "EcommerceStore::Action",
            "actionId": "Buy"
         },
         "resource": {
            "entityType": "EcommerceStore::Product",
            "entityId": "Hat"
         },
         "context": {
            "contextMap": {}
         }
      },
      {
         "principal": {
            "entityType": "EcommerceStore::User",
            "entityId": "Ken"
         },
         "action": {
            "actionType": "EcommerceStore::Action",
            "actionId": "Preorder"
         },
         "resource": {
            "entityType": "EcommerceStore::Product",
            "entityId": "Hat"
         },
         "context": {
            "contextMap": {}
         }
      },
      {
         "principal": {
            "entityType": "EcommerceStore::User",
            "entityId": "Ken"
         },
         "action": {
            "actionType": "EcommerceStore::Action",
            "actionId": "Edit"
         },
         "resource": {
            "entityType": "EcommerceStore::Product",
            "entityId": "Hat"
         },
         "context": {
            "contextMap": {}
         }
      }
   ]
}

Conclusion

Batch authorization in AVP offers a powerful and efficient way to handle multiple authorization requests simultaneously (up to 30 requests principal or request oriented, with up to 100 entities (principals and resources)).
It will decrease costs for requests to AVP as well as improve performance.
Keep in mind that you cannot use the BatchIsAuthorized with the token option, it's not supported currently.
Keep in mind that you cannot use the BatchIsAuthorized within the Test Bench currently.

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part X: AVP-CLI

Daniel Aniszkiewicz — Tue, 15 Aug 2023 13:09:15 +0000

In previous article, we delved deep into the world of hierarchies and ABAC (Attribute-Based Access Control) within the AWS Verified Permissions (AVP). We've learned how to deal with hierarchy and ABAC with practical example.

Today, we shift our focus to a tool that aims to make your interactions with AVP smoother and more intuitive: the open-source avp-cli.

The Big Picture behind avp-cli

AWS Verified Permissions (AVP) is a relatively new service. While AWS provides comprehensive documentation, workshops, and examples, there was a noticeable gap in community-driven resources. For developers like me, eager to dive deep and experiment with AVP, the initial journey was filled with manual setups via the AWS console. This process was not only repetitive but also prone to errors, especially when dealing with intricate components like schemas and policy definitions.

Imagine the hassle of setting up multiple policy stores, schemas, and policies, only to realize you made a small mistake and had to start over. Or the challenge of managing and deleting resources, especially when you find yourself with 85 policy stores cluttering your AWS account!

This is where the idea of avp-cli was born. I envisioned a tool that would simplify these interactions, making the process of learning and experimenting with AVP more efficient and enjoyable. The initial versions of the CLI focused on basic API operations, such as creating and deleting policy stores, schemas, and policies.

However, as I delved deeper into AVP, I had an "aha" moment. Why not create predefined scenarios? These scenarios would encapsulate a policy store, schema, and set of policies, providing a ready-to-use example for developers to play with, experiment, and modify. This not only reduced the setup time but also provided a tangible context for understanding how different AVP components interacted, as well as differences between Cedar and AVP format.

The most recent addition to avp-cli has been the test scenarios. These are designed to validate that the policies and configurations set up through the scenarios work as expected.

What is avp-cli?

The avp-cli is a command-line interface tool designed to streamline your interactions with the AWS Verified Permissions (AVP) service. Its primary goal is to enhance the learning and prototyping experience for developers diving into AVP. Whether you're a beginner trying to grasp the basics or an advanced user looking to experiment with complex policies, avp-cli offers a set of functionalities tailored to your needs.

🚀 Welcome to the AVP CLI Tool!
Designed to streamline your interactions with the AWS Verified Permissions (AVP) service.
🔧 Create, manage, and delete policy stores, schemas, and policies. Plus, deploy and test with predefined scenarios!
⚠️ Ensure your AWS credentials are correctly set up before proceeding.
? What would you like to do? (Use arrow keys)
❯ Test Scenario 
  Manual approach 
  Use prepared scenarios 
  Exit

However, it's essential to note that while avp-cli is a powerful tool for learning and experimentation, it is not intended for production workloads. Always ensure that tools and configurations used in production environments are thoroughly vetted and adhere to best practices.

Features of avp-cli

API operations: avp-cli supports all API operations provided by the AWS Verified Permissions service. This includes:

Creating, listing, updating, and deleting policy stores.
Adding and retrieving schemas.
Creating, updating, retrieving, and deleting policies (both static and template-linked).
Making authorization decisions (with or without Cognito Identity Token).
Identity source and more...

? What would you like to do? Manual approach
? What would you like to do? (Use arrow keys)
❯ Make an authorization decision 
  Make an authorization decision with Cognito Identity Token 
  Add Policy Template 
  Add Schema to a Policy Store 
  Add Static Policy 
  Add Template Policy 
  Create a Policy Store 
(Move up and down to reveal more choices)

Scenarios: One of the standout features of avp-cli is the predefined scenarios. These scenarios encapsulate a policy store, schema, and a set of policies, providing developers with ready-to-use examples. Each scenario is designed to showcase a specific feature or use-case of AVP, making it easier to understand its practical applications.

Scenario Name	Description
Documents Scenario	This is a basic scenario with a document management platform schema and two policies.
Ecommerce with Context usage Scenario	This scenario demonstrates the use of context in AVP. It allows customers to view products only when they are in the US region.
Ecommerce with Group usage Scenario	This scenario demonstrates the use of Groups in AWS Verified Permissions. It allows customers who belong to the VIP group to preorder products.
Ecommerce with Policy Template usage Scenario	This scenario demonstrates the use of policy templates and template-linked policies in AWS Verified Permissions. It allows sellers to list their own products.
Ecommerce with Cognito Integration usage Scenario	This scenario demonstrates the use of Cognito integration in AWS Verified Permissions. It allows sellers to discount if they have agreed discount privilege. Refer to this blogpost for setup.
Ecommerce with Hierarchy and ABAC Scenario	This scenario demonstrates the use of Hierarchy and ABAC (with Entities) in AWS Verified Permissions. It allows sellers to sell car if department matches the car's department.

Usage:

⚠️ Ensure your AWS credentials are correctly set up before proceeding.
? What would you like to do? Use prepared scenarios
? Choose a scenario Documents Scenario
Starting creating scenario: Documents Scenario
description: This is a basic scenario with a document management platform schema and two policies.
Policy store created with ID: 3rJVM5629fGKxxcuPg87es
Schema put successfully for policy store ID: 3rJVM5629fGKxxcuPg87es
Static policy created with ID: 5FcwTty3sAvgJPQGp7rcji
Static policy created with ID: XqJb31ZJ9E2VBLzFxTY7Y2
┌────────────────────────────────────────┬────────────────────────────────────────┬────────────────────────────────────────┐
│ Policy ID                              │ Policy Store ID                        │ Created Date                           │
├────────────────────────────────────────┼────────────────────────────────────────┼────────────────────────────────────────┤
│ 5FcwTty3sAvgJPQGp7rcji                 │ 3rJVM5629fGKxxcuPg87es                 │ 2023-08-15 14:52                       │
├────────────────────────────────────────┼────────────────────────────────────────┼────────────────────────────────────────┤
│ XqJb31ZJ9E2VBLzFxTY7Y2                 │ 3rJVM5629fGKxxcuPg87es                 │ 2023-08-15 14:52                       │
└────────────────────────────────────────┴────────────────────────────────────────┴────────────────────────────────────────┘
Generating of the documentsScenario is finished. Open the AWS console to play around with that.

Consider testing it with our prepared test scenarios:
Either use `Test Scenario` in main CLI to select the specific test scenario, or use below path as argument to `IsAuthorized` from the manual approach option of the CLI:
 Remember to update the policy-store-id within files.
- ./scenarios/documentsScenario/allow_test_1.json (User Daniel is allowed the ability to view (action) the Payslip (resource)) allow
- ./scenarios/documentsScenario/deny_test_1.json (User xyz is denied the ability to view (action) the Payslip (resource)) forbid
- ./scenarios/documentsScenario/deny_test_2.json (User Daniel is denied the ability

Test Scenarios: To complement the predefined scenarios, avp-cli also offers test scenarios. These are predefined sets of inputs and expected outcomes that allow users to test the policies and configurations set up by the scenarios. It's a seamless way to validate and troubleshoot configurations, ensuring they function as intended.

What would you like to do? Test Scenario
? Choose a scenario documentsScenario
? Choose a test (Use arrow keys)
❯ User Daniel is allowed the ability to view (action) the Payslip (resource) (allow) 
  User xyz is denied the ability to view (action) the Payslip (resource) (forbid) 
  User Daniel is denied the ability to edit (action) the Payslip (resource) (forbid)

Example:

? Choose a test User Daniel is allowed the ability to view (action) the Payslip (resource) (allow)
Making authorization decision...
┌──────────┬──────────────────────────────┬────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──────────────────────────────┐
│ Decision │ Determining Policies         │ Errors             │ Policy Store ID              │ Principal                    │ Action                       │ Resource                     │ Context                      │
├──────────┼──────────────────────────────┼────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┼──────────────────────────────┤
│ ALLOW    │ 5FcwTty3sAvgJPQGp7rcji       │                    │ 3rJVM5629fGKxxcuPg87es       │ DocumentManagementPlatform:: │ DocumentManagementPlatform:: │ DocumentManagementPlatform:: │ {}                           │
│          │                              │                    │                              │ User::Daniel                 │ Action::View                 │ Document::Payslip            │                              │
└──────────┴──────────────────────────────┴────────────────────┴──────────────────────────────┴──────────────────────────────┴──────────────────────────────┴──────────────────────────────┴──────────────────────────────┘
? What would you like to do? (Use arrow keys)

Dive in and experiment

I encourage you to play around with avp-cli. Whether you're setting up a new policy store, experimenting with a scenario, or running a test, the tool is designed to make your AVP journey smoother and more insightful.

Cedar Policy Language Slack

A significant portion of the success and functionality of avp-cli can be attributed to the invaluable support and guidance I received from the teams behind the Cedar Policy Language and AWS Verified Permissions (AVP) on the Cedar Policy Language Slack. I'd like to thank you all individuals at AWS who took the time to address my queries, clarify my doubts, and provide insights that were instrumental in shaping the tool.

Looking Ahead

As the AWS Verified Permissions service and Cedar continue to evolve, so will avp-cli. I'm particularly excited about the upcoming is operator in Cedar and the potential to name policy-stores in AVP (which now is autogenrated string). Once these features are available, you can expect avp-cli to incorporate them, ensuring the tool remains up-to-date and continues to serve the AVP community effectively.

Next steps

Feel free to read next article from the series, about batch authorization.

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part IX: Hierarchies and ABAC

Daniel Aniszkiewicz — Fri, 11 Aug 2023 14:36:03 +0000

Welcome back to our series on Amazon Verified Permissions (AVP)! In the previous article we've discussed how to integrate AVP with Cognito. Today, we're going to delve into a more advanced topic: hierarchies and entities in AVP.

Hierarchies vs Groups

In one of a previous article, we've seen how to use groups in AVP to manage permissions for a set of users. Groups are a powerful tool for simplifying permission management, especially when you have a large number of users with similar roles. For example, in our e-commerce platform, we might have a group for VIP customers who have access to preorder some products.

However, groups are not always sufficient to capture the full complexity of real-world authorization scenarios. For example, consider an e-commerce platform with a hierarchical customer structure, where permissions need to be inherited or overridden based on the customer's level in the hierarchy. In these cases, we need a more sophisticated way to model the relationships between users and resources. This is where hierarchies and entities come into play.

Entities and Attributes in AVP

In AVP, an entity is a representation of a principal, action, or resource in your application. Each entity has:

An identifier: This includes an entity type and an entity ID. For example, for a customer entity, the entity type might be "EcommercePlatform::Customer" and the entity ID might be "Daniel".
A set of attributes: These are properties or characteristics of the entity. For example, a customer entity might have attributes like 'purchase history' and 'loyalty level'.
A list of parent entities: This is used to define the parent entities. In our use case we will add departments.

Cedar vs AVP Format: A Comparative Look

To better understand the differences between the Cedar and AVP formats, let's take a look at how a Seller entity from our e-commerce example would be represented in each format:

Cedar Format:



{
    "uid": {
        "type": "Seller",
        "id": "1"
    },
    "attrs": {
        "rating": 5,
        "department": {
            "__entity": {
                "type": "Department",
                "id": "luxury"
            }
        }
    },
    "parents": []
}

AVP Format:



{
    "identifier": {
        "entityType": "EcommercePlatform::Seller",
        "entityId": "1"
    },
    "attributes": {
        "rating": {
            "long": 5
        },
        "department": {
            "entityIdentifier": {
                "entityType": "EcommercePlatform::Department",
                "entityId": "luxury"
            }
        }
    },
    "parents": []
}

Key Differences:

Entity Representation:

Cedar: Uses uid with type and id to represent the entity.
AVP: Uses identifier with entityType and entityId.

Attribute Types:

Cedar: Directly assigns values to attributes.
AVP: Attributes are typed, such as {"long": 5} for the rating.
Entity Relationships:

Cedar: Uses the __entity key inside attributes to denote relationships.
AVP: Uses the entityIdentifier key for relationships.
Entity Naming:

Cedar: Uses concise names like "Seller".
AVP: Uses namespaced names like "EcommercePlatform::Seller".

Ecommerce example

Let's take our ongoing example of an e-commerce system where we have Sellers, Customers, Products, and now, Departments. We've used these entities in our previous blog posts as well. This time, let's imagine we're dealing with a car dealership. Our sellers are car dealers, and they have actions like selling cars, giving discounts, and ordering new cars.

We can define our entities like this:

A Seller entity might have attributes like 'rating', and 'department'. The 'department' attribute links the Seller to a Department entity, indicating which department the seller belongs to.
A Department entity represents different departments within the dealership, each responsible for selling certain types of cars.
A Product (in this case, a Car) entity might have attributes like 'price', and 'department'. The 'department' attribute links the Car to a Department entity, indicating which department is responsible for selling this car.
A Customer entity might have attributes like and 'loyalty level'. In this setup, we're going to implement two rules:

Hierarchy Rule: A seller can sell a car if the seller's department matches the car's parent department. This rule represents a hierarchical relationship between sellers, departments, and cars.
ABAC Rule: Moreover a seller can sell if the rating (based on reputation) value is bigger than the specific value, as well whether the price is above some specific level. Those rules represent an attribute-based access control (ABAC) scenario where access decisions are made based on the attributes of the entities involved.

Implementation

We can either use AVP-CLI with scenario, or do it manually within the console.

AVP-CLI approach

I've prepared the scenario.

Simply run it locally:



➜  avp-cli git:(main) ✗ node index.js
Welcome to AVP CLI!
This tool is designed to help you interact with the AWS Verified Permissions (AVP) service. You can use it to create, manage, and delete policy stores, schemas, and policies.
Please ensure that you have set up your AWS credentials correctly to use this tool.
? What would you like to do? Use prepared scenarios
? Choose a scenario Ecommerce with Hierarchy and ABAC Scenario

After a couple of seconds all resources will be deployed to AWS, grab the policy store ID from the output table and navigate to the AVP Test Bench to continue.

Manual approach

Navigate to the AVP console, and create a new policy store with empty store. Open the Schema and paste it:



{
    "EcommercePlatform": {
        "entityTypes": {
            "Department": {
                "shape": {
                    "attributes": {
                        "name": {
                            "type": "String"
                        }
                    },
                    "type": "Record"
                }
            },
            "Seller": {
                "shape": {
                    "type": "Record",
                    "attributes": {
                        "rating": {
                            "type": "Long"
                        },
                        "department": {
                            "name": "Department",
                            "type": "Entity"
                        }
                    }
                }
            },
            "Car": {
                "shape": {
                    "attributes": {
                        "price": {
                            "type": "Long"
                        },
                        "department": {
                            "name": "Department",
                            "type": "Entity"
                        }
                    },
                    "type": "Record"
                }
            }
        },
        "actions": {
            "Sell": {
                "appliesTo": {
                    "resourceTypes": [
                        "Car"
                    ],
                    "principalTypes": [
                        "Seller"
                    ]
                }
            }
        }
    }
}

Policy

Now we can define policy as follows:



permit (
    principal,
    action in [EcommercePlatform::Action::"Sell"],
    resource
)
when
{
    principal.department == resource.department &&
    principal.department.name == "luxury" &&
    principal.rating >= 8 &&
    resource.price > 1000000
};

Testing

We can either test it with AVP-CLI Test Scenario, or we can test it with Test Bench feature in AVP.

Switch to json mode and fill it as follows:

Principal: EcommercePlatform::Seller
ID: 1
Resource: EcommercePlatform::Car
ID: porsche
Action: EcommercePlatform::Action
ID: Sell

Leave Context untouched.

For Entities use:



[
    {
        "identifier": {
            "entityType": "EcommercePlatform::Seller",
            "entityId": "1"
        },
        "attributes": {
            "department": {
                "entityIdentifier": {
                    "entityType": "EcommercePlatform::Department",
                    "entityId": "1"
                }
            },
            "rating": {
                "long": 8
            }
        },
        "parents": []
    },
    {
        "identifier": {
            "entityType": "EcommercePlatform::Car",
            "entityId": "porsche"
        },
        "attributes": {
            "price": {
                "long": 10000000
            },
            "department": {
                "entityIdentifier": {
                    "entityType": "EcommercePlatform::Department",
                    "entityId": "1"
                }
            }
        },
        "parents": []
    },
    {
        "identifier": {
            "entityType": "EcommercePlatform::Department",
            "entityId": "1"
        },
        "attributes": {
            "name": {
                "string": "luxury"
            }
        },
        "parents": []
    }
]

Above dataset defines entities for an e-commerce platform, specifically detailing sellers, cars, and departments. It outlines a seller with a rating and department affiliation, a luxury car with its price and associated department, and a department named "luxury" to which both the seller and the car are linked.

Feel free to now test it, the decision should be "allow".

Next steps

That's it for today. In the upcoming article, I'll dive deeper into the avp-cli, exploring its capabilities and demonstrating how it can improve your AVP workflows. If there are specific topics related to Cedar or AVP you'd like me to cover, please let me know.

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part VIII: Integration with Cognito

Daniel Aniszkiewicz — Thu, 03 Aug 2023 15:43:44 +0000

Welcome back to my last blogpost of series on AWS Verified Permissions (AVP)! In the previous blogpost, we discussed the importance of auditing and pricing in an enterprise-grade authorization system. Today, we're going to explore how to integrate AVP with AWS Cognito, a powerful identity service that can help you manage user identities and authentication in your applications.

Integrating AVP with AWS Cognito

In any application, managing user identities and controlling their access to resources is a crucial aspect. Amazon Cognito is a service that helps you manage your users and their authentication. When integrated with AVP, Amazon Cognito can provide the identity context for your authorization policies. This means that you can use information from a user's Cognito identity, such as their user attributes, to make fine-grained access control decisions in AVP.

However, it's important to note that AVP doesn't currently process the cognito:groups claim, which means that Cognito integration can be used primarily for ABAC (Attribute-Based Access Control) rather than RBAC (Role-Based Access Control). The team is working on enabling support for group claims, which would allow for RBAC-type policies.

Use Case: E-commerce Application

Let's consider an e-commerce application where we have Sellers. Each seller has a custom attribute called discountPrivilege which is a string indicating whether the seller has the privilege to give discounts or not.

Creating the Schema

In AVP, we define the structure of the entities, actions, and context that the policy will use in a schema. For our use case, our schema will include a "Seller" entity type with a "custom:discountPrivilege" attribute, and a "Product" entity type. Our actions will include "Read" and "Discount".

Here's how our schema looks:



{
    "MyEcommerceApp": {
        "entityTypes": {
            "Product": {
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            },
            "Seller": {
                "shape": {
                    "type": "Record",
                    "attributes": {
                        "custom": {
                            "attributes": {
                                "discountPrivilege": {
                                    "required": true,
                                    "type": "String"
                                }
                            },
                            "required": true,
                            "type": "Record"
                        }
                    }
                }
            }
        },
        "actions": {
            "Discount": {
                "appliesTo": {
                    "resourceTypes": [
                        "Product"
                    ],
                    "principalTypes": [
                        "Seller"
                    ],
                    "context": {
                        "type": "SellerContext"
                    }
                }
            },
            "Read": {
                "appliesTo": {
                    "resourceTypes": [
                        "Product"
                    ],
                    "context": {
                        "type": "SellerContext"
                    },
                    "principalTypes": [
                        "Seller"
                    ]
                }
            }
        },
        "commonTypes": {
            "SellerContext": {
                "attributes": {
                    "token": {
                        "attributes": {
                            "client_id": {
                                "type": "String"
                            }
                        },
                        "type": "Record"
                    }
                },
                "type": "Record"
            }
        }
    }
}

Setting Up the Identity Source with Cognito

Before we can create our policy, we need to set up an identity source in AVP. The identity source is where AVP gets the identity context for authorization decisions. In our case, we're using Cognito as our identity source.

Here are the steps to set up a Cognito identity source in AVP:

In the AVP console, navigate to "Identity sources" and click "Create identity source".
For "Cognito user pool details" please select AWS Region and Cognito User Pool.
For "Principal details" for "Principal type" select "MyEcommerceApp::Seller". For "App client", enter the ID of the app client in your user pool that will be making requests to AVP. For "Client application validation", select "Only accept tokens with matching client application IDs". This ensures that AVP only accepts tokens that were issued for the specified app client. Provide the "Client Application Id" (It's located in Cognito, we will cover it in the Testing section) Click "Create identity source".

Now it should looks like this:

Creating the Policy

Next, we define the rules for access control in a policy. Our policy allows a seller to apply discounts to a product when the seller's "custom:discountPrivilege" attribute is set to "agreed".

Here's how our policy looks:



permit (
    principal,
    action in [MyEcommerceApp::Action::"Discount"],
    resource
)
when { principal.custom.discountPrivilege == "agreed" };

How It All Works Together

With our schema, identity source, and policy set up, here's how the authorization process works:

A Seller logs in through Cognito and receives an ID token. This token includes the seller's user attributes, including the custom:discountPrivilege attribute.
The seller makes a request to our application to perform an action, such as applying a discount to a product. The request includes the seller's ID token.
Our application sends the ID token to AVP along with the requested action and resource. This is done through the IsAuthorizedWithToken API operation.
AVP validates the ID token and extracts the identity context, which includes the custom:discountPrivilege attribute.
AVP evaluates the policy using the identity context, action, and resource. If the policy permits the action (i.e., if the custom:discountPrivilege attribute is set to "agreed"), AVP returns an "ALLOW" decision. Otherwise, it returns a "DENY" decision.
Our application uses the decision from AVP to either allow or deny the seller's request.

This process allows us to make fine-grained access control decisions based on user attributes from Cognito. It's a powerful way to implement attribute-based access control (ABAC) in our application.

In the next section, we'll walk through how to test this setup to ensure everything is working as expected.

Testing the Setup

This time we cannot use the Test Bench from AVP, we need to do it differently. We first need to create a Cognito user pool and an app client.
Here's a quick guide on how to do this:

Create a Cognito User Pool: In the AWS Management Console, navigate to the Cognito service and click on "Manage User Pools". Click "Create a user pool", give it a name, and click "Review defaults". On the next page, click "Create pool".

Set Password Policy: Make it default.
Disable MFA: In the "MFA and verifications" settings, set "Which second factors do you want to enable?" to "None". This is for simplicity in our testing setup; in a production environment, you would typically want to enable MFA for added security.
Add Custom Attribute: In the "Attributes" settings, click on "Add custom attribute". Set the attribute name to "discountPrivilege", the attribute type to "String", and check the "Mutable" box. This allows the attribute to be changed after the user is created.

Create an App Client: In the "App clients" settings, click "Add an app client". Give it a name, uncheck all the "Auth Flows Configuration" options except for ALLOW_ADMIN_USER_PASSWORD_AUTH and ALLOW_USER_PASSWORD_AUTH, and click "Create app client".

Now that we have our Cognito setup, we can create a user and assign them the discountPrivilege attribute. Here's how:

In the Cognito user pool, navigate to "Users and groups" and click "Create user". Fill in the required fields, set "Email verified" to "True", and in the "Custom attributes" section, set discountPrivilege to "agreed".
Note down the "App client id" from the "App client settings" in your user pool. We'll need this for testing (user pool as well).

Testing flow with AWS CLI

With our Cognito setup ready, we can now test our AVP integration. Here's how:

Before we can test our setup, we need to authenticate our user and obtain an ID token (Not the access token, as there will be not custom claims included). When a user is created in Cognito, they are required to change their password after their first sign-in. This process involves initiating an authentication flow, responding to the new password challenge, and then authenticating again with the new password to get the ID token.

The command to do it is like follow:



aws cognito-idp admin-respond-to-auth-challenge \
    --user-pool-id user-pool-id \
    --client-id client-id \
    --challenge-name NEW_PASSWORD_REQUIRED \
    --challenge-responses USERNAME=username,NEW_PASSWORD='YourNewPassword' \
    --session "YourSessionString"

Here's how to do this with the AWS CLI:

Initiate the Authentication Flow: Use the admin-initiate-auth command to initiate the authentication flow. This command requires the user pool ID, the app client ID, and the user's username and password.



aws cognito-idp admin-initiate-auth \
    --user-pool-id <user_pool_id> \
    --client-id <client_id> \
    --auth-flow ADMIN_USER_PASSWORD_AUTH \
    --auth-parameters USERNAME=<username>,PASSWORD=<password>

Deal with New Password Challenge, and auth again. Then we should obtain the ID token, we will use it to test our AVP policy.

If you decode it with jwt.io it should looks like this:



"email_verified": true,
  "iss": "https://cognito-idp.eu-west-1.amazonaws.com/eu-west-user-pool",
  "cognito:username": "92d514d4-0071-70fa-2ab7-201b7f22167a",
  "custom:discountPrivilege": "agreed",
  "origin_jti": "e166c8de-3798-49be-9e39-0ddfe3055cda",
  "aud": "4bagaej4rb8m1t028lv5vsio8o",
  "event_id": "519e9b73-2231-4afc-b881-f748b9d6000e",
  "token_use": "id",
  "auth_time": 1691072849,
  "exp": 1691076449,
  "iat": 1691072849,
  "jti": "f33a5626-5f5d-45ce-8848-61a115bbdce7",
  "email": "example.com"
}

Testing the AVP Policy

Now that we have our ID token, we can use the is-authorized-with-token command to test our AVP policy (make sure you have updated AWS CLI). This command requires the policy store ID, the ID token, the action, the resource, and the context.



aws verifiedpermissions is-authorized-with-token \
    --policy-store-id <policy_store_id> \
    --identity-token <id_token> \
    --action actionType="MyEcommerceApp::Action",actionId="Discount" \
    --resource entityType="MyEcommerceApp::Resource",entityId="Product" \
    --context '{"contextMap": {"custom.discountPrivilege": {"string": "agreed"}}}' \
    --region <region>

This command will return a decision ("ALLOW" or "DENY") and the policies that determined the decision.



{
    "decision": "ALLOW",
    "determiningPolicies": [
        {
            "policyId": "XBN1W6aDjwYdDC1HQyVGXX"
        }
    ],
    "errors": []
}

And that's it! You've successfully integrated AVP with AWS Cognito and tested your setup using the AWS CLI.

Using avp-cli for the Scenario

The scenario we've discussed in this post is included in the avp-cli tool. This command-line interface tool simplifies the process of creating and managing schemas, policies, and policy stores in AVP. However, to use the tool for this scenario, you need to have your Cognito setup ready as per the instructions provided in this post.

In the library there is also support for isAuthorizedWithToken so we can easily make an authorization request.

Conclusion

In the next blogpost we will focus on hierarchies. I'm also working on enhancing the avp-cli to add more functionalities to it, so stay tuned for updates!

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part VII: Audit and Pricing

Daniel Aniszkiewicz — Wed, 26 Jul 2023 18:45:43 +0000

Welcome back to my series on AWS Verified Permissions (AVP)! In the previous blogpost, we delved into the concept of Policy Templates and how they can simplify policy management in your applications. Today, we're going to discuss two important aspects of any enterprise-grade authorization system: auditing and pricing.

Auditing with AVP

In any enterprise-grade system, auditing is a crucial component. It allows you to track and record every action taken within your system, providing a clear and transparent record of who did what and when. This is not only important for security and compliance purposes, but also for troubleshooting and understanding user behavior.

With AVP, you can leverage AWS CloudTrail to audit your authorization system. AWS CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your AWS account. It provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services.

When integrated with AVP, CloudTrail can record all API calls made by or on behalf of AVP in your AWS account. This includes calls made by the AVP console and code calls to the AVP APIs. By using CloudTrail, you can log, continuously monitor, and retain information about these API calls for a period of time defined by your organization's requirements.

Let's see how we can set up auditing for our AVP usage:

First, we need to ensure that AWS CloudTrail is enabled in our AWS account. You can do this by navigating to the CloudTrail console and following the prompts to create a new trail.
Once CloudTrail is enabled, it will automatically record all API calls made by AVP. These logs are stored in an Amazon S3 bucket specified during the setup of CloudTrail.
To view the logs, navigate to the CloudTrail Dashboard (it displays an overview of your trails and recent events). Navigate to Event history to see the most recent events in AWS account.

Open one of these events to view the details of the API calls. You'll see information such as the identity of the caller, the time of the call, the source IP address of the call, the request parameters, and the response elements returned by the AVP service.

You can also use CloudTrail to set up alarms and notifications (CloudWatch) for specific API activities. This can be useful for monitoring specific actions or detecting unusual activity in your AVP usage.

Feel free to generate some activity in AVP and see how it appears in our CloudTrail logs. You can use AVP CLI tool to create a policy store, add a schema, and create a policy. After running these commands, you can check our CloudTrail logs to see the recorded API calls.

By auditing your AVP usage with CloudTrail, you can maintain a comprehensive record of all authorization activity in your application. This can help you meet compliance requirements, detect security incidents, and gain insights into user behavior.

Feel free to read more about AVP with CloudTrail here.

Pricing of AVP

Understanding the cost of using a service like AVP is crucial for planning and budgeting your application's infrastructure. AVP pricing is based on the number of authorization requests and policy management actions your application performs each month. Let's break down these costs:

Authorization Requests: These are calls to the isAuthorized API operation. The cost depends on the number of requests, with the first 40 million requests per month costing $150 per million requests, the next 60 million requests costing $75 per million requests, and any additional requests costing $40 per million requests.

Policy Management Actions: These are calls to API operations that manage policies, such as CreatePolicy, UpdatePolicy, DeletePolicy, GetPolicy, ListPolicies, CreatePolicyTemplate, UpdatePolicyTemplate, DeletePolicyTemplate, GetPolicyTemplate, and ListPolicyTemplates. These actions cost $40 per million requests, regardless of the number of requests.

Now, let's consider two examples to understand how these costs might add up in real-world scenarios:

Example 1: Small Application
Suppose you have a small application with 10,000 active users, each of whom makes 3 authorization requests per day. This adds up to 30,000 authorization requests per day, or 900,000 requests per month. In addition, let's say you perform 10,000 policy management actions per month. Your charges would be calculated as follows:

Authorization Requests: 900,000 requests * $150 / 1,000,000 = $135
Policy Management Actions: 10,000 requests * $40 / 1,000,000 = $0.4

Total Charges: $135.4/month

Example 2: Large Application
Now, let's consider a larger application with 1 million active users, each of whom makes 2 authorization requests per day. This adds up to 2 million authorization requests per day, or 60 million requests per month. In addition, let's say you perform 1 million policy management actions per month. Your charges would be calculated as follows:

First 40 million Authorization Requests: 40 million requests * $150 / 1,000,000 = $6,000
Next 20 million Authorization Requests: 20 million requests * $75 / 1,000,000 = $1,500
Policy Management Actions: 1 million requests * $40 / 1,000,000 = $40

Total Charges: $7,540/month

Pricing discussion

The cost of using AVP can vary significantly depending on the scale of your application and the number of authorization requests and policy management actions you perform. It's important to consider these costs when planning your application's architecture and budget.

However, it's also crucial to consider the alternative: building your own authorization system from scratch. This approach can be time-consuming and challenging, especially if your team is not familiar with Rust, the language in which Cedar is written. The development costs can also be high, as you'll need to invest significant resources into creating, testing, and maintaining your own system.

Moreover, if you choose not to use AVP, you'll miss out on several key features. AVP provides a policy store, a test bench, configuration with identity sources, and auditing with AWS CloudTrail. If you build your own system using the Cedar engine, you'll only have the authorization decision functionality, and you'll need to implement these other features yourself.

In contrast, using a managed service like AVP can save you a lot of time and effort. AVP is ready to use right out of the box, and it's designed to scale with your application as it grows. Plus, because AVP uses Cedar as its policy language, you have the flexibility to switch to a self-hosted Cedar system in the future if AVP becomes too costly.

There's been a lot of discussion within the community about the pricing of AVP. Some developers are concerned about the potential costs of using a managed service, especially for larger applications. However, it's important to remember that building and maintaining your own authorization system also has costs, both in terms of time and money.

When you're considering whether to use AVP, think about the resources you have available and the needs of your application. If you have a small team or a tight budget, using AVP could be a more cost-effective option than building your own system. If you have a larger team and more resources, you might prefer the flexibility and control of a self-hosted system.

In the end, the best choice depends on your specific circumstances. But no matter which option you choose, using a policy language like Cedar can help you implement fine-grained, attribute-based access control in a secure and efficient way.

Next steps

In the next blogpost, we'll continue exploring advanced features of AVP. We'll delve into another critical aspect of application security: identity management. We'll explore how to integrate AVP with AWS Cognito.

Authorization and Amazon Verified Permissions: A New Way to Manage Permissions - Part VI - Policy Templates

Daniel Aniszkiewicz — Thu, 20 Jul 2023 20:48:43 +0000

Welcome back to my series on AWS Verified Permissions (AVP)! If you've been following along, you'll know that we've covered a lot of ground so far. We've explored the basics of AVP, looked at how to use the Test Bench feature, and much more. In this sixth blogpost, we're going to dive into a powerful feature of AVP: Policy Templates. I'll explain what they are, why they're useful, and how to use them in the context of our ongoing ecommerce example. As always, we'll provide step-by-step instructions for both the AWS console and our handy AVP CLI tool.

Policy Templates

Policy Templates in AVP are reusable policy definitions that can be linked to multiple principals and resources. They are a way to define a policy once and then apply it to many different entities. This concept is from Cedar, a policy management system that also uses templates to simplify policy creation and management.

In the context of AVP, a Policy Template is a blueprint for a policy that can be applied to different principals and resources (but not for actions). It's a way to define the permissions once and then apply them to multiple entities, ensuring consistency and reducing the complexity of your policy management.

For example, in our ecommerce system, we might have a policy that allows sellers to list products. Instead of creating a separate policy for each seller, we can create a single policy template and link it to each seller. This not only reduces the number of policies we need to manage, but also ensures consistency across all sellers.

Why Use Policy Templates?

Policy Templates offer several benefits:

Efficiency: Instead of creating individual policies for each entity, you can create one policy template and link it to multiple entities. This can save time and reduce the complexity of your policy management.

Consistency: By using a policy template, you ensure that all entities linked to the template have the same permissions. This can help prevent errors and inconsistencies that might arise from manually creating individual policies.

Flexibility: Policy templates can be linked to different types of entities (e.g., users, roles, groups) and resources, providing a flexible way to manage permissions across your system.

Granular Control: Policy templates provide a more granular level of control compared to using groups or allowing all access. They allow you to specify exactly what actions a principal can perform on a resource, reducing the risk of over-permissioning.

Static Policies vs Template-Linked Policies vs Policy Templates

Before we dive into how to use policy templates, let's clarify the difference between static policies, template-linked policies, and policy templates.

Static Policies: These are standalone policies that define permissions for a specific principal and resource. They are not linked to a template and can't be reused for other principals or resources.

Template-Linked Policies: These are policies that are linked to a policy template. They inherit the permissions defined in the template and apply them to a specific principal and resource.

Policy Templates: These are reusable policy definitions that can be linked to multiple principals and resources through template-linked policies. They define a set of permissions that can be applied consistently across multiple entities.

Policy Templates in action

Let's walk through the process of creating and using a policy template for our ecommerce scenario.

Two approaches:

Manually in AWS Console

Open the AWS Management Console, find the AVP service, and create a new policy store. Select Empty policy store.

Navigate to Schema and add below json:

{
    "EcommercePlatform": {
        "entityTypes": {
            "Product": {
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            },
            "Seller": {
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            }
        },
        "actions": {
            "List": {
                "appliesTo": {
                    "principalTypes": [
                        "Seller"
                    ],
                    "resourceTypes": [
                        "Product"
                    ]
                }
            },
            "Remove": {
                "appliesTo": {
                    "principalTypes": [
                        "Seller"
                    ],
                    "resourceTypes": [
                        "Product"
                    ]
                }
            },
            "Update": {
                "appliesTo": {
                    "resourceTypes": [
                        "Product"
                    ],
                    "principalTypes": [
                        "Seller"
                    ]
                }
            }
        }
    }
}

Navigate to the "Policy Templates" section. Click on "Create Policy Template". You'll be asked to provide a name and a policy definition. The policy definition should be a JSON object that describes the permissions granted by the policy. For our ecommerce example, we might create a policy template that allows a seller to list a product.
For description use "Policy template that allows a seller to list a product", and for "Policy template body" use:

permit (
    principal == ?principal,
    action in [
        EcommercePlatform::Action::"List"
    ],
    resource == ?resource
);

Once the policy template is created, you can link it to principals and resources. Navigate to the "Polices" section and click on "Create Template-Linked Policy".

Select already existing policy template, and click next.

Now you need to provide values that are injected into the template to create the policy (principal - seller and resource - product), and create a policy.

After creating the template-linked policy, you can review it in the "Template-Linked Policies" section. You'll see the policy template, the principal, and the resource, along with any other template-linked policies you've created.
At the end we can test it in Test Bench section.

That's it!

Via AVP-CLI

We can also avoid doing it manually within the AWS console, and use avp-cli for deploying it via CLI.

For the purpose of this blogpost I've created scenario Ecommerce policy template scenario which is the exact usecase.

Simply download it, and run "Ecommerce with Template-Linked Policies Scenario" from the avaliable scenarios.

➜  avp-cli git:(main) node index.js
Welcome to AVP CLI!
This tool is designed to help you interact with the AWS Verified Permissions (AVP) service. You can use it to create, manage, and delete policy stores, schemas, and policies.
Please ensure that you have set up your AWS credentials correctly to use this tool.
? What would you like to do? Use prepared scenarios
? Choose a scenario 
  Documents Scenario 
  Ecommerce with Context Scenario 
  Ecommerce with Group Scenario 
❯ Ecommerce with Template-Linked Policies Scenario

After it will be successfully finished, open the AVP in AWS console to play around with that.

Next steps

That's all for today. I encourage you to play around it more. In addition, I encourage you to try the official AVP workshop from AWS where there are also policy templates.

As for the next blogpost, I will describe the topics of audit and pricing of the service.

Authorization and Amazon Verified Permissions: A New Way to Manage Permissions - Part V - Test Bench

Daniel Aniszkiewicz — Tue, 11 Jul 2023 09:13:05 +0000

In the previous article of this series, we've been exploring Amazon Verified Permissions (AVP) and Cedar, its underlying policy language. We've learned how to define fine-grained, attribute-based access control policies, and how to structure our authorization system using AVP schemas. We've also delved into more advanced topics such as including context in our schemas and defining groups of entities.

Now, it's time to put our policies to the test. In this article, we'll introduce the AVP Test Bench, a powerful tool for testing our policies. I'll explain what it is, how it works, and how to use it effectively to ensure our policies behave as expected.

What is the Test Bench?

The Test Bench is a feature of AVP that allows you to test your policies before deploying them. It provides a controlled environment where you can simulate principal requests and see whether they would be allowed or denied based on your policies. This can help prevent potential security issues and save you from headaches down the line.

How to Use the Test Bench

Using the Test Bench is straightforward. Here's a step-by-step guide:

Navigate to the Test Bench: From the AVP console, select your policy store and click on the "Test Bench" tab.

Set up your test: You'll need to specify a principal, an action, and a resource for the test. You can also include a context if your policies use one.

Run the test: Click on the "Run Test" button. AVP will evaluate your policies and show whether the request would be allowed or denied.

Testing Policies with Context

Let's take a look at how we can use the Test Bench to test policies with context. In our ecommerce scenario, we have a policy that allows customers to view products only when the context region is set to "US".

In order for you to test this yourself, you need to have defined policy store, schema, and policies. To do it, you can do it in two ways:

Use avp-cli It's a CLI for making life easier with AVP. Moreover there are prepared scenarios, and we can reuse them for the purpose of this article.

Inside the GH is a manual. In a nutshell, download the repository, install dependencies, make sure you have AWS credentials added, then use in terminal:

node index.js
Welcome to AVP CLI!
This tool is designed to help you interact with the AWS Verified Permissions (AVP) service. You can use it to create, manage, and delete policy stores, schemas, and policies.
Please ensure that you have set up your AWS credentials correctly to use this tool.
? What would you like to do? Use prepared scenarios
? Choose a scenario Ecommerce with Context Scenario
Starting creating scenario: Ecommerce with Context usage Scenario

This will generate for you a policy store, schema ecommerce, and a policy from context).

manually add to the AWS console (in the AVP service), inside the policy store add schema and policy) and then go to test bench.

First, either use an existing one or create a new policy store.
Add schema:

{
   "EcommercePlatform":{
      "entityTypes":{
         "Customer":{
            "shape":{
               "type":"Record",
               "attributes":{

               }
            }
         },
         "Product":{
            "shape":{
               "type":"Record",
               "attributes":{

               }
            }
         }
      },
      "actions":{
         "View":{
            "appliesTo":{
               "principalTypes":[
                  "Customer"
               ],
               "resourceTypes":[
                  "Product"
               ],
               "context":{
                  "type":"Record",
                  "attributes":{
                     "region":{
                        "name":"region",
                        "type":"String",
                        "required":true
                     }
                  }
               }
            }
         },
         "Edit":{
            "appliesTo":{
               "principalTypes":[
                  "Customer"
               ],
               "resourceTypes":[
                  "Product"
               ]
            }
         }
      }
   }
}

Then add policy:

permit(
  principal,
  action in [EcommercePlatform::Action::"View"],
  resource
) when {
  context.region == "US"
};

Now we can test it. Navigate to the AWS Console, open our policy store, and open "Test bench" in the left side panel.

To test this policy, we would set up a test with a principal of "Customer", an action of "View", and a resource of "Product". We would also include a context with a region of "US". Running this test should result in the request being allowed.

Next, we can change the context region to something other than "US" for instance "EU", and run the test again. This time, the request should be denied, demonstrating that our policy is working as expected.

Testing Policies with Groups

In AVP, you can also create policies that apply to groups of principals. For example, we might have a policy that allows customers who belong to the VIP group to preorder products.

Again, two approaches to setup it in AVP.

With AVP CLI. This time select Ecommerce with Group Usage Scenario:

➜  avp-cli git:(main) AWS_PROFILE=personal node index.js
Welcome to AVP CLI!
...
? What would you like to do? Use prepared scenarios
? Choose a scenario Ecommerce with Group Scenario
Starting creating scenario: Ecommerce with Group Usage Scenario

manually add to the AWS console (in the AVP service), inside the policy store add schema and policy) and then go to test bench.

First, create a new policy store.
Add schema:

{
    "EcommercePlatform": {
        "entityTypes": {
            "CustomerGroup": {
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            },
            "Product": {
                "shape": {
                    "type": "Record",
                    "attributes": {}
                }
            },
            "Customer": {
                "shape": {
                    "attributes": {},
                    "type": "Record"
                },
                "memberOfTypes": [
                    "CustomerGroup"
                ]
            }
        },
        "actions": {
            "Create": {
                "appliesTo": {
                    "resourceTypes": [
                        "Product"
                    ],
                    "principalTypes": [
                        "Customer"
                    ]
                }
            },
            "Preorder": {
                "appliesTo": {
                    "resourceTypes": [
                        "Product"
                    ],
                    "principalTypes": [
                        "Customer",
                        "CustomerGroup"
                    ]
                }
            },
            "Delete": {
                "appliesTo": {
                    "principalTypes": [
                        "Customer"
                    ],
                    "resourceTypes": [
                        "Product"
                    ]
                }
            },
            "View": {
                "appliesTo": {
                    "principalTypes": [
                        "Customer"
                    ],
                    "resourceTypes": [
                        "Product"
                    ]
                }
            }
        }
    }
}

Then add policy:

permit (
    principal in EcommercePlatform::CustomerGroup::"VIP",
    action in [EcommercePlatform::Action::"Preorder"],
    resource
);

Now we can test it. Navigate to the AWS Console, open our policy store, and open "Test bench" in the left side panel.

To test this policy, we would set up a test with a principal that is a member of the specified group ("VIP"), an action of "Preorder", and a resource of "Product". Running this test should result in the request being allowed.

The Importance of Deny Policies

One important thing to note about AVP is that deny policies take precedence over allow policies. This means that if you have a policy that allows a certain action and another policy that denies the same action, the action will be denied.

This can be useful for creating exceptions to general rules. For example, you might have a policy that allows all customers to view products, but a deny policy that prevents a specific customer from viewing products. Even though the allow policy would normally grant the customer access, the deny policy takes precedence and the customer's request is denied.

Next Steps

In this article, we've explored the AVP Test Bench and how it can be used to test our policies. We've seen how to set up tests for policies with context and groups, and we've learned about the precedence of deny policies.

As you continue to work with AVP, remember that testing your policies is a crucial step in ensuring that your authorization system behaves as expected. The Test Bench provides a powerful tool for doing this, and I encourage you to make full use of it.

If you want to experiment with AVP and Cedar, consider using the avp-cli tool. It provides a convenient way to create, manage, and delete policy stores, schemas, and policies, and it includes prepared scenarios that you can use as a starting point for your own policies.

In the next article of this series, we'll dive into policy templates in AVP. These templates allow you to define reusable policy patterns, making it easier to manage complex authorization systems. Stay tuned!

Remember, the best way to learn is by doing. Don't be afraid to experiment with different policies and scenarios, and see what you can build with AVP and Cedar!

Forem: Daniel Aniszkiewicz

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XVI: AVP meets new pricing

Recap on pricing

Cache?

New pricing

Will You Still Cache?

My opinion

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XV: AVP with Cognito groups

Cognito groups support

Practice

Cognito part

Policy Store part

Identity Source.

AVP CLI for CreateIdentitySource

Policies

Approach with AVP-CLI scenario

Prepration for tests

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XIV: AVP Getting Started

Learning curve

Getting started

What AVP Getting Started does for us:

What we will build today?

Starting point Gateway and Cognito

Gateway

Cognito

AVP time!

Gateway actions

Identity Source

Assign actions to groups

Deploy policy store

Show me AVP!

Lambda

Let's test it in practice

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XIII: Cloudformation

Introduction

Let's build!

Create a policy store

Adding Schema

Policy Store ID

Adding policies

Deployment

Final words

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XII: Terraform

Introduction

Terraform provider for AVP

Let's build!

Create a policy store

Adding Schema

Adding policies

Final words

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part XI: Batch Authorization

Batch Authorization

isAuthorized vs batchIsAuthorized

E-commerce example

Schema Overview

Policies

Admin Role - Order Editing Policy

Customer Role - Basic Access Policy

Premium Membership - Special Privileges Policy

Testing Policies

Single Authorization Request Tests

Batch Authorization Tests

Conclusion

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part X: AVP-CLI

The Big Picture behind avp-cli

What is avp-cli?

Features of avp-cli

Dive in and experiment

Cedar Policy Language Slack

Looking Ahead

Next steps

Authorization and Amazon Verified Permissions - A New Way to Manage Permissions Part IX: Hierarchies and ABAC

Hierarchies vs Groups

Entities and Attributes in AVP

Cedar vs AVP Format: A Comparative Look

Cedar Format:

AVP Format:

Ecommerce example

Implementation

AVP-CLI approach

`isAuthorized` vs `batchIsAuthorized`