PEP and PDP for Secure Authorization with Cognito

In one of my previous posts Building a serverless connected BBQ as SaaS - Part 4 - AuthZ I touched on the topic around Authentication and Authorization with distributed PEPs (Policy Enforcement Points) and a centralized PDP (Policy Decision Point). In this post I will dig a bit deeper and expand on that setup. I'll explore how these concepts work in practice, the benefits they offer, and how we can leverage them in our serverless architecture using AWS Lambda, API Gateway, and Cognito User Pools.

Additionally, I’ll talk about Role-Based Access Control (RBAC) model, how to implement it using Cognito Groups and DynamoDB, and how caching can boost the performance of our authorization system.

The entire setup, with detailed deployment instructions, and all the code can be found on Serverless Handbook PEP and PDP

Let's start with a short recap.

Authentication (AuthN) vs. Authorization (AuthZ)

It’s crucial to distinguish between Authentication and Authorization, two terms that often get mixed up, and that I have had to explain on so many occasions, but serve very different purposes.

Authentication (AuthN)

Authentication is all about verifying identity. It answers the question, Who are you? When a user logs into our application, authentication ensures that they are who they claim to be. This could involve something as simple as a username and password or more complex multi-factor authentication (MFA).

Authorization (AuthZ)

Once a user’s identity is authenticated, authorization kicks in. This process answers the question, What can you do? Authorization determines what resources, data, and actions a user is permitted to access based on their roles and permissions.

What are PEP and PDP?

Before diving into how to implement them in AWS, it’s essential to understand the roles that PEP and PDP play in authorization.

PEP (Policy Enforcement Point)

In simple terms, the PEP is the gatekeeper. It is the points in our system where access control decisions are enforced. When a user attempts to access a protected resource, the PEPs is the component responsible for checking whether the request is allowed or denied based on the user’s permissions.

In our case, the Lambda Authorizer in API Gateway acts as the PEP. The Lambda Authorizer intercepts every incoming API request, validates the JWT token (typically from Cognito User Pool or any identity provider), and forwards the user’s information (claims) to the PDP for authorization evaluation.

The PEP ensures that the JWT is valid, checks its expiration, verifies its signature, and validates claims (like aud, iss, and sub). It then passes the claims to the PDP for a final decision on whether the user is authorized to access the requested resource.

PDP (Policy Decision Point)

The PDP is where the authorization logic resides. Once the PEP checks the JWT and ensures that the token is valid, the PDP determines whether the user is allowed to access the requested resource based on their roles, permissions, or policies.

The PDP is a separate, implementation, a separate micro service. In our case a Lambda function, that performs the actual authorization decision. It checks the user’s roles, which are stored in the groups claim in the JWT (from Cognito), and compares them against the permissions required to access a specific resource, stored in a data store. In our case we'll use DynamoDB.

The PDP validates if the user has the necessary permissions (like Admin, User, or Manager) to access the resource (e.g., GET /admin, POST /profile). The PDP can also incorporate additional business logic, such as checking time-based access or geo-fencing.

Benefits of using PEP and PDP in Authorization

Implementing distributed PEP and centralized PDP offers several benefits, especially as our applications scales.

Separation of Concerns By splitting the concerns of enforce (PEP) and decision (PDP), we gain cleaner, more maintainable code. The Lambda Authorizer (PEP) is focused purely on validation and enforcement. While the PDP is dedicated to policy evaluation.

Reduced Latency: By placing PEPs close to where decisions need to be enforced, we can reduce the latency, with an caching strategy this can be reduced even more.

Management: With a centralized PDP, all of our authorization logic is centralized in one location. This makes it easier to manage and update policies as our requirements evolve. Whether it’s modifying roles or adding new permission sets, having a central PDP reduces the overhead of updating policies in multiple places.

Consistency and Compliance: Every request is evaluated against the same set of policies, ensuring consistent decision-making across our system.

Scalability: Both the PEP and PDP components scale independently based on demand. If our system needs to handle a larger volume of requests, API Gateway and Lambda can scale automatically. Additionally, the PDP can be optimized for performance by implementing caching.

Flexibility: A PDP allows us to adapt the authorization model to our needs. If our requirements change (for example, moving to attribute-based access control (ABAC) or introducing a more granular permission system), we can easily modify the PDP to accommodate these changes without affecting other parts of the system.

Using PEP and PDP in AWS with Serverless Architecture

In AWS, the PEP and PDP integration fits perfectly with serverless components like Lambda and API Gateway.

PEP - API Gateway Lambda Authorizer

When a client sends a request to our API Gateway endpoint, the Lambda Authorizer (PEP) intercepts the request before it hits our backend service. Our implementation will perform several key steps.

JWT Validation: It decodes the JWT, validates the signature, and checks if the token has expired.

Forwarding Claims: After verifying the token, the Lambda Authorizer forwards the claims (such as sub, groups, and role) to the PDP for further authorization checks. In our solution we will actually forward the entire JWT token.

To reduce the number of calls to our PEP and also PDP we can utilize the authorization cache that exists in API Gateway.

PDP - Authorization logic Lambda function

The PDP is implemented as separate Lambda function, in our case, and will receive the entire JWT token, or claims, to perform the authorization logic, that will include several steps.

Check the user’s role (using the groups claim from Cognito).
Query a DynamoDB table that contains role-to-permission mappings (e.g., which roles have access to which API endpoints).
Evaluates whether the user’s role matches the required permissions for the requested, resource or API endpoint.

ID Token vs Access Token

As we implement the PEP and PDP workflow, it’s essential to understand the difference between ID Tokens and Access Tokens, as both are often used in authorization workflows.

ID Token

The ID Token is primarily used for authentication and contains information about who the user is. It contains claims about the identity of the authenticated user, such as name, email, and phone_number.

Access Token

The Access Token is used to grant the user access to protected resources, authorization. The Access Token contains information about the user’s permissions, such as what resources they are allowed to access and the scopes they have been granted, which define what the user can do (e.g., read:profile, write:profile). The access token do not include the aud claim.

Token customization in Cognito

With the Pre token generation Lambda trigger we could before only customize the ID Token, therefor it was often used for authorization as well. With the introduction of new V2 event in Cognito User Pools we can customize both the ID anf Access token.

Implementing PEP and PDP

With that introduction completed let's dig into implementing a PEP and PDP with RBAC. Our PEP will be the Lambda Authorizer in API Gateway and our PDP will be a separate Lambda function. The PDP will use using Cognito Groups and DynamoDB for the RBAC authorization logic.

Architecture Overview

Just as a reminder, the entire code and all of the architecture can be found on Serverless Handbook PEP and PDP

In this solution we will implement our PEP using Lambda Authorizer in API Gateway. The PDP in this case will also be implemented using a Lambda function. We will assign users a Role using Cognito Groups and we keep an Role - Permission mapping in DynamoDB.

To better understand the flow during an API access.

As seen we will not use an API Gateway for our PDP. Instead our PEP will invoke the PDP Lambda function. There are pros and cons with this approach of course. On the pro side we have lower latency, a direct Lambda invocation is often faster than an API call. Lower cost as we don't have to pay for the API Gateway invocation. On the backside, we do create a more tight coupling and changing the PDP implementation might get harder. We would need to implement a separate cache in the PDP, using an API Gateway we could rely on the API Gateway cache.

However, the approach you choose need to be a case by case approach, there is not a golden rule exactly how to implement this.

Deploy authentication and Cognito

The first thing we will do is to deploy and setup Cognito and the resources needed for login. We will setup the Cognito User Pool, configure the managed login, and a simple website that will handle the callbacks from Cognito and display our JWT tokens. For simplicity it will just be a static html page from CloudFront and some Lambda@Edge functions. I will use the setup that I have described in this blog post, so for a deep dive I recommend that you read that.

So as a first step deploy the Lambda@Edge, CloudFront distribution, and SSL certificate from Serverless Handbook PEP and PDP

Next, let's deploy and setup Cognito. We will create the UserPool, a client, login style, etc.

With this deployment done we can move over to the Console and create groups that users can be added to. I will create three groups, Admin, Developer, and Test. Click on Create Group and give it a name. The group name would represent the Role that the user will have and determine what permission he/she will get, more on that setup further down.

We can then create some users and assign them to one of the groups.

To test this setup we can navigate to the webpage deployed with the CloudFront distribution and inspect the JWT tokens, cookies.

If we copy the access token and decode that, I use jwt.io, we can see that my user has the claim cognito:groups that our PEP and PDP will use later for permissions.

Setup and deploy PDP

Next we can deploy our Authorization service, our PDP, responsible for making permission decisions.

Logic will be implemented in a Lambda function and to manage role-based permissions, we will create a DynamoDB tabe that stores permissions for each role. Each permission defines what resources the user can access this could be a specific API endpoint and HTTP method, but of course not limited to that. We'll model the table data

PK (Partition Key): The Role (e.g., Admin, User). SK (Sort Key): The resource, for example endpoint and Method e.g. GET /unicorn. Action: The action e.g. GET, PUT, WRITE, READ, LIST etc Resource: The Resource, for example the endpoint /unicorn Effect: The Effect, Allow or Deny Description: A description of the permission.

PK	SK	Action	Resource	Effect
Admin	GET /unicorn	GET	/unicorn	Allow
Test	POST /unicorn	POST	/unicorn	Allow
Developer	DELETE /unicorn	DELETE	/unicorn	Deny

This allows us to efficiently look up permissions for each role using a simple DynamoDB query.

Role Authorization logic

The PDP Lambda will decode the JWT, retrieve the role from the cognito:groups claim, and query the DynamoDB table to check if the role has permission to access the requested resource.

Deploy API and PEP

Now we can deploy our API and PEP, Lambda Authorizer.

We set our PEP as the default authorizer that way it will be added to each resource and method. To reduce the number of calls to our PDP the Authorization cache in API gateway is used with a TTL of 600 seconds.

PEP Authorization logic

The PEP Lambda Authorizer will decode the JWT, check the validity, and then call the PDP for a final permission decision.

Importance of caching

Caching is important in optimizing our authorization flow. By reducing calls to the PDP and speeding up decision-making, caching helps improve the overall performance, scalability, and cost-efficiency of our application.

Reduce Latency: By caching role and permission data, the PEP avoids repeated calls our PDP, leading to faster response times and lower latency for each request. Decrease PDP Load: Caching minimizes the number of calls made our PDP, reducing the risk of hitting rate limits or throttling. Improve Scalability: With fewer requests hitting our PDP, our architecture can scale more efficiently. Lower Costs: Caching reduces the need for repeated PDP invocations, which directly lowers Lambda invocation costs.

Summary and conclusion

Implementing PEP and PDP in our authorization flow offers a highly scalable, flexible, and secure way to control access to resources. By leveraging AWS Lambda and API Gateway, we can build a serverless authorization system that separates authentication and authorization concerns, scales with demand, and simplifies policy management.

With the addition of Role-Based Access Control and DynamoDB for storing permissions, combined with in-memory caching for enhanced performance, we can create an authorization solution that fits both current and future needs.

Understanding the difference between ID Tokens and Access Tokens ensures that our system uses each appropriately, helping us build a more secure and efficient authorization system.

Happy coding, and stay secure!

Source Code