,
resource
);

permit (
principal in PetStore::UserGroup::”us-west-2_iwWG5nyux|owners”,
action in
[PetStore::Action::”delete /admin/{proxy+}”,
PetStore::Action::”post /admin/{proxy+}”,
PetStore::Action::”get /admin/{proxy+}”,
PetStore::Action::”patch /admin/{proxy+}”,
PetStore::Action::”put /admin/{proxy+}”,
PetStore::Action::”post /pets”],
resource
);
Validating API security
A set of terminal-based curl commands validate API security for both authorized and unauthorized users, by using different access tokens. For readability, a set of environment variables is used to represent the actual values. TOKEN_C, TOKEN_E, and TOKEN_O contain valid access tokens for respective users in the customers, employees, and owners groups. API_STAGE is the base URL for the PetStore API and demo stage that we selected earlier.
To test that an unauthenticated user is allowed for the GET / root path (Requirement 1 as described in the Overview section of this post), but not allowed to call the GET /pets API (Requirement 2), run the following curl commands. The Cognito-PetStorePool authorizer should return {“message”:”Unauthorized”}.

curl -X GET ${API_STAGE}/

…Welcome to your Pet Store API…

curl -X GET ${API_STAGE}/pets
{“message”:”Unauthorized”}

To test that an authenticated user is allowed to call the GET /pets API (Requirement 2) by using an access token (due to the Cognito-PetStorePool authorizer), run the following curl commands. The user should receive an error message when they try to call the POST /pets API (Requirement 3), because of the AVPAuthorizer. There are no Cedar polices defined for the customers group with the action post /pets.

curl -H “Authorization: Bearer ${TOKEN_C}” -X GET ${API_STAGE}/pets
[
{
“id”: 1,
“type”: “dog”,
“price”: 249.99
},
{
“id”: 2,
“type”: “cat”,
“price”: 124.99
},
{
“id”: 3,
“type”: “fish”,
“price”: 0.99
}
]

curl -H “Authorization: Bearer ${TOKEN_C}” -X POST ${API_STAGE}/pets
{“Message”:”User is not authorized to access this resource with an explicit deny”}

The following commands will verify that a user in the employees group is allowed the post /pets action (Requirement 3).

curl -H “Authorization: Bearer ${TOKEN_E}”
-H “Content-Type: application/json”
-d ‘{“type”: “dog”,”price”: 249.99}’
-X POST ${API_STAGE}/pets
{
“pet”: {
“type”: “dog”,
“price”: 249.99
},
“message”: “success”
}

The following commands will verify that a user in the employees group is not authorized for the admin APIs, but a user in the owners group is allowed (Requirement 4).

curl -H “Authorization: Bearer ${TOKEN_E}” -X GET ${API_STAGE}/admin/curltest1
{“Message”:”User is not authorized to access this resource with an explicit deny”}

curl -H “Authorization: Bearer ${TOKEN_O}” -X GET ${API_STAGE}/admin/curltest1
{“Message”: “User authorized for /demo/admin/curltest1″}

Try it yourself
How could this work with your user pool and REST API? Before you try out the solution, make sure that you have the following prerequisites in place, which are required by the Verified Permissions setup wizard:

A Cognito user pool, along with Cognito groups that control authorization to the API endpoints.
An API Gateway REST API in the same Region as the Cognito user pool.

As you review the resources generated by the solution, consider these authorization modeling topics:

Are access tokens or id tokens preferable for your API? Are there custom claims on your tokens that you would use in future Cedar policies for fine-grained authorization?
Do multiple authorizers fit your model, or do you have an “all users” group for use in Cedar policies?
How might you extend the Cedar schema, allowing for new Cedar policies that include URL path parameters, such as {petId} from the example?

Conclusion
This post demonstrated how the Amazon Verified Permissions setup wizard provides you with a step-by-step process to build authorization logic for API Gateway REST APIs using Cognito user groups. The wizard generates a policy store, schema, and Cedar policies to manage access to API endpoints based on the specification of the APIs deployed. In addition, the wizard creates a Lambda authorizer that authorizes access to the API Gateway resources based on the configured Cognito groups. This removes the modeling effort required for initial configuration of API authorization logic and setup of Verified Permissions to receive permission requests. You can use the wizard to set up and test access controls to your APIs based on Cognito groups in non-production accounts. You can further extend the policy schema and policies to accommodate fine-grained or attribute-based access controls, based on specific requirements of the application, without making code changes.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the Amazon Verified Permissions re:Post or contact AWS Support.

Kevin Hakanson
Kevin is a Senior Solutions Architect for AWS World Wide Public Sector, based in Minnesota. He works with EdTech and GovTech customers to ideate, design, validate, and launch products using cloud-native technologies and modern development practices. When not staring at a computer screen, he is probably staring at another screen, either watching TV or playing video games with his family.

Sowjanya Rajavaram
Sowjanya is a Senior Solutions Architect who specializes in identity and security solutions at AWS. Her career has been focused on helping customers of all sizes solve their identity and access management problems. She enjoys traveling and experiencing new cultures and food.”]