Authorization and Cedar: A New Way to Manage Permissions - Part I

As Amazon Verified Permissions (AVP) has recently been released, I have decided to create a series of articles where we will learn together how to create an authorization decisions system for an e-commerce platform scenario, using AVP and Cedar.

The Series on AWS Verified Permissions (AVP) and Cedar

This blogpost is part of a series where we explore the power and flexibility of AWS Verified Permissions (AVP) and the Cedar language. Here are the other articles in the series:

• Authorization and Cedar: A New Way to Manage Permissions - Part II

• Authorization and Amazon Verified Permissions: A New Way to Manage Permissions - Part III

• Authorization and Amazon Verified Permissions: A New Way to Manage Permissions - Part IV - Schema

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

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

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

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

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

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

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

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

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

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

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

Security

When it comes to securing applications, there are two key concepts that often get mixed up: authentication and authorization. Let's start by clarifying these terms with a simple analogy.

Imagine you're at a music festival. When you first arrive, you show your ticket at the entrance. This is authentication - proving who you are. Once inside, you might want to access the VIP area. But just because you've been authenticated (you have a ticket), doesn't mean you're authorized (have a VIP pass) to enter every area. This is authorization - determining what you're allowed to do or where you're allowed to go.

While authentication is about verifying who you are, authorization is about what you can do. It's about permissions. And that's where Amazon's Verified Permissions (AVP) and the Cedar language come in.

RBAC and ABAC

There are two main models for handling authorization: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

RBAC is like having different types of tickets at a music festival (e.g., General Admission, VIP, Artist). Your access is determined by your role (the type of ticket you have). This model is simple and works well for many applications, but it can be inflexible when dealing with complex access control scenarios.

ABAC, on the other hand, is more flexible. It's like having a wristband with different colored tags. Each tag gives you access to different areas, and they can be mixed and matched in any combination. In ABAC, access is determined by attributes (the tags on your wristband). This model allows for more granular control over access, but it can also be more complex to implement and manage.

Why Authorization Isn't Always Simple

In the early days of web development, authorization was often as simple as checking if a user was an admin or not. But as applications have grown more complex, so have their authorization needs. Today, you might need to check if a user is part of a certain group, if they have access to a specific resource, or even if they meet certain contextual conditions like being in a specific location or using a certain device.

For example, in a healthcare application, a doctor might have access to all patient records, but a nurse might only have access to the records of patients they are assigned to. Furthermore, access might be restricted based on the time of day or the location of the user.

This is where Policy as Code comes in. Instead of hardcoding these complex rules into your application, you can define them in a separate, readable, and maintainable policy language. This is what Cedar is all about.

Introducing Cedar

Cedar is an open-source policy language developed by AWS. Cedar was created to address the need for a language that could handle the complexity of authorization in a cloud environment. When Cedar was launched in 2022, there were already many existing authorization grammars. However, none of them met the specific needs of AWS, leading to the creation of Cedar.

Cedar was developed to support services like Amazon Verified Permissions and AWS Verified Access. It supports both RBAC and ABAC, making it a versatile choice for many different types of applications.

With Cedar, you can define complex authorization rules in a clear, structured way, making your authorization system more maintainable and scalable.

Feel free to read more about the origin of the Cedar language here.

Basics of Cedar

In Cedar, the authorization decision is based on four main components:

• Principal: The entity that is making the request. In our E-commerce scenario, the principal could be a customer, a seller, or an administrator.

• Action: What the principal is trying to do. This could be viewing a product, placing an order, or managing a product listing.

• Resource: The object that the action is being performed on. This could be a product listing, an order, or a customer profile.

• Context: Additional information that can be used in the decision. This could include the time of the request, the location of the principal, or other relevant details.

For example, a policy might state that a customer (principal) can view a product (action) if the product is in stock (resource attribute) and the customer is shopping during store hours (context).

E-commerce Platform Scenario

Let's consider a typical E-commerce platform. It has several types of users (principals) such as customers, sellers, and administrators. These users perform various actions like viewing products, placing orders, managing inventory, and handling customer service issues. The objects they interact with (resources) include product listings, orders, customer profiles, and more.

In this scenario, we need to control who can do what to which resources. For example, a customer should be able to view products and place orders, but they shouldn't be able to modify product listings. A seller can manage their own product listings and view orders for their products, but they can't view other sellers' product listings or orders. An administrator can view and manage all resources.

This is where Cedar comes in. With Cedar, we can define policies that specify who can perform which actions on which resources.

Applying Cedar to the E-commerce Scenario

Let's see how we can apply these concepts to our E-commerce scenario.

For the principal, we can define different types for customers, sellers, and administrators. Each principal type can have attributes that are relevant to them. For example, a customer might have attributes like customer_id and membership_status, while a seller might have seller_id and store_name.

For the action, we can define actions that correspond to the operations that can be performed in the system. These might include view_product, place_order, manage_listing, and handle_issue.

For the resource, we can define resource types for the different objects in the system. These might include Product, Order, and Profile. Each resource type can have attributes that are relevant to it. For example, a Product might have attributes like product_id, seller_id, and price.

Finally, for the context, we can include any additional information that might be relevant to the decision. For example, we might include the time of the request to enforce time-based restrictions, or the location of the principal to enforce location-based restrictions.

Where to find out more about Cedar?

• First of all, I invite you to read the official Cedar documentation which can be found.
• The tutorial where we can see Cedar in action is also very useful.
• In addition, the playground which includes two examples of applications using Cedar.
• Cedar SDK tutorial blog post.
• Cedar SDK tutorial longer version.
• And finally, Github and Slack are great resources for getting help and staying up-to-date with the latest developments.

Next steps

In the next article, we will dive deeper into how to define these components in Cedar and how to write policies that use them to make authorization decisions. Later, we will also start to translate these concepts into the Amazon Verified Permissions (AVP) service, which uses Cedar under the hood. Stay tuned!