Building a serverless connected BBQ as SaaS - Part 4 - AuthZ
In part four of the series about the world of BBQ, where tradition and technology rarely cross paths. The future of grilling is here, and it’s connected, smart, and runs on the cloud! We look at the key difference between Authentication and Authorization in a SaaS solution. We introduce a new authorization architecture with a centralized Policy Decision Point (PDP) and distributed Policy Enforcement Points (PEPs) implemented serverless with API Gateway and Lambda.
Published Sep 20, 2024
We’ve already touched on data isolation and row-level security in a multi-tenant SaaS environment. Now, it’s time to look at how to handle authorization, the process of controlling access to data and functionality based on who the user is and what they’re allowed to do.
In this post, we’ll explore the architecture of a centralized Policy Decision Point (PDP) with distributed Policy Enforcement Points (PEPs) to ensure consistent and secure authorization across your SaaS platform. We’ll also break down the key differences between Authentication (AuthN) and Authorization (AuthZ).
Before we get into building the architecture we need to establish a common understanding. 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 is all about verifying identity. It answers the question,
Who are you? When a user logs into our SaaS 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).We are using Amazon Cognito User Pools for our authentication in this series.
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.In a multi-tenant environment, getting authorization right is important. We need to ensure that users can only access the data and functionality relevant to their tenant and role. This is where a robust, scalable authorization system comes into play.
Now that we’ve clarified the difference between AuthN and AuthZ, let’s focus on building a authorization system using a centralized PDP and distributed PEPs.
A Policy Decision Point (PDP) is where all your authorization decisions are made. It’s the brain of the authorization system, evaluating each request against predefined policies or roles and determining whether to allow or deny the request. There are some clear benefits with a centralized PDP:
Consistency: Every request is evaluated against the same set of policies, ensuring consistent decision-making across our systems.
Management and Compliance: With all policies managed in one place, updating and audits are made easy. Logging decisions for audit purpose is important for some regulatory compliance.
Management and Compliance: With all policies managed in one place, updating and audits are made easy. Logging decisions for audit purpose is important for some regulatory compliance.
However, some drawback would be increase latency. Routing every authorization request through a single PDP can slow things down, especially in a distributed system.
Using Amazon Verified Permissions (AVP) a centralized PDP is required.
Policy Enforcement Points (PEPs) are where the authorization decisions made by the PDP are enforced. These points are distributed across our system. Our Lambda based Authorizer is an example of a PEP. Front door of our microservices can then also act as PEP and call our PDP.
We have some benefits running our PEPs in a distributed way.
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.
Scalability: As your system grows, distributed PEPs ensure that no single point becomes a bottleneck, specially with caching enabled.
Scalability: As your system grows, distributed PEPs ensure that no single point becomes a bottleneck, specially with caching enabled.
In our new authorization architecture we will introduce a new authorization service, that will be our central PDP. The logic for authorization will be moved from our previous Lambda Authorizer to the PDP, instead our Lambda Authorizer will now call the PDP that will return access decision.
The first thing we need to do is to create our Authorization Service (PDP), as shown this will be an API Gateway and a Lambda function. One interesting approach that we could use is to remove the API Gateway and just use Lambda Function URLs. However, for some easier extensibility later I decided to use an API Gateway.
Our API will use AWS IAM for machine-2-machine authorization, just as our admin API that we created in our previous part.
Next we move our AuthZ logic from our Lambda Authorizer to our new PDP implementation. We will handle both authorization for user and tenant access and introduce two new resources
tenant and tenantUser.Next we of course need to update the Lambda Authorizer to call our PDP for authorization.
With those changes we have moved our authorization to a centralized PDP with a distributed PEP setup. This create a good foundation for us to keep evolving our AuthZ. In later posts we will introduce a RBAC (Role Based Access Control) and ABAC (Attribute Based Access Control), we will also move to use Amazon Verified permissions.
The complete setup with all the code is available on Serverless Handbook
In this post, we looked at the architecture of a centralized authorization system using a PDP and distributed PEPs. We’ve also highlighted the differences between Authentication (AuthN) and Authorization (AuthZ).
In the coming posts we will start looking at device onboarding and data, stay tuned!
Check out My serverless Handbook for the code to the solution built in this series of posts.
As Werner says! Now Go Build!