DEV Community: Daniel Bass

Protecting Democracy Through Fine-Grained Authorization

Daniel Bass — Thu, 22 Aug 2024 12:08:50 +0000

Protecting Democracy Through Fine-Grained Authorization

In recent years, the integrity of the election process has come under intense scrutiny, making it more important than ever to ensure that voting systems are secure, transparent, and reliable. Ensuring that only authorized personnel have access to sensitive voter data is critical in maintaining public trust. A breach could not only compromise the election but also erode confidence in the entire democratic process.

From a software development perspective, this responsibility requires a refined approach to system access and permissions. Developers are on the front lines of this defense, tasked with creating and maintaining systems that must balance functionality with security.

Maricopa County, one of the largest voting jurisdictions in the United States, encountered this challenge firsthand. Their solution, which manages vast amounts of voter data while maintaining strict security measures, offers a compelling case study on the importance of Fine-Grained Authorization (FGA).

Watch the full case study video here

The Challenge: Scaling Security for a Massive Voting Jurisdiction

As the fourth-largest county in the U.S., Maricopa County’s Recorder's Office oversees a voting system that serves millions. Dealing with such a scale is no joke - especially given the delicate nature of the issue. This presented two key challenges:

First, there is a need for precise control over who can access specific data and perform specific actions within the system. Traditional role-based access control (RBAC) wasn’t sufficient for the level of granularity required, so they had to employ more precise control over who could access specific data and perform particular actions within their systems.

Second, the challenge of managing permissions for a large and fluctuating workforce, especially during election periods. Temporary staff needed access to specific parts of the system without compromising sensitive voter information. Manually managing these permissions by writing policy code was a complex and time-consuming process that placed a significant burden on the IT department.

As these challenges increased over time, the county’s voter registration system, known as Arrow, must handle an unprecedented level of complexity.

The Solution: FGA and No-Code UIs

To address the challenge of complex authorization policies, namely those that required considering a large number of attributes to enforce granular authorization decisions, Maricopa County turned to implementing Fine-Grained Authorization (FGA) as a solution.

FGA goes beyond simple role-based access control by considering a broader set of factors when making authorization decisions. Instead of relying solely on user identity or role, FGA can make
make nuanced authorization decisions based on multiple factors, such as attributes with Attribute Based Access Control (ABAC) and relationships with Relationship-Based Access Control (ReBAC), allowing precise control over who can access what, down to the level of individual tasks and actions within a system.

By implementing FGA, the county could ensure that each user, whether a full-time employee or a temporary staff member, had access only to the tools and information they needed for their role—nothing more, nothing less.

To facilitate this implementation, Maricopa County utilized the capabilities of Permit.io. This allowed their developer team to integrate fine-grained authorization into their systems without completely refactoring their own solution and building a new one in-house. With Permit.io, permissions could also be set not just at a user level but at the API interaction level, allowing for even more detailed and secure control over who could access what within the system.

Permit also allowed for automation in the permission management process. Instead of having IT staff manually assign permissions to each new user, they were able to create predefined permission sets through Permit’s no-code UI, which could be adjusted dynamically as an employee's tasks changed. Temporary workers brought in for election periods could, for example, be given access only to the specific functions they needed, and those permissions could be automatically revoked when their role ended.

The Impact: Security and Efficiency

The transition to Fine-Grained Authorization and the adoption of no-code UI for managing authorization had critical impacts on Maricopa County’s operations. First and foremost, it helped ensure no employee had more access than necessary, aligning with the principle of least privilege and preventing unauthorized access, whether intentional or accidental.

Delegating permissions management to department managers, rather than centralizing it in IT, made the process faster and more responsive. Managers could directly control access, reducing bottlenecks and freeing IT resources for more critical tasks. IT, in turn, could focus on monitoring the processes happening within the system with automatically generated audit logs instead of manually writing policy codes and assigning roles and permissions.

This shift allowed the voter registration department to take greater ownership of its security processes in its day-to-day operations. The ability to adjust permissions without the need for constant IT intervention meant that the office could remain agile and responsive, even during the intense periods leading up to elections.

A Broader Lesson for Developers

Maricopa County's experience is a great example for developers. Protecting data—whether it involves consumer information or the democratic process itself—is a technical responsibility.

Fine-grained authorization is a tool that developers should consider, especially in high-stakes systems. FGA enhances security by ensuring that access is precisely controlled, while implementing it with a no-code authorization UI can help streamline operations by reducing the administrative burden on IT departments.

In every system where integrity can have far-reaching consequences, developers' responsibility extends beyond just building functional software. They must anticipate vulnerabilities, implement efficient security measures, and adapt to emerging threats. Maricopa County’s experience shows how a strategic shift to FGA can meet these responsibilities.

Maricopa County's challenges are not unique; they are indicative of the broader issues that arise in managing large, complex systems. By embracing Fine-Grained Authorization, the county not only solved its immediate access control challenges but also set a standard for how other development teams might approach similar issues.

If you want to learn more about the best ways to implement FGA, make sure to join our Slack community, where there are hundreds of devs building and implementing authorization.

How Discord Built `Access!` - An Authorization Management Portal

Daniel Bass — Tue, 18 Jun 2024 15:15:18 +0000

Managing access permissions is a critical aspect of application security, especially for large platforms like Discord. In a great blog, “Access: A New Portal For Managing Internal Authorization,” Elisa Guerrant, Security Engineer at Discord, details how they built “Access!” - a secure, accessible internal authorization portal.

This blog will discuss the importance of creating permission management systems that balance security and accessibility for all application users. It will also introduce "Permit: Elements," a set of prebuilt, embeddable UI components designed to further streamline and enhance permission delegation. Thus demonstrating how to improve the accessibility of your own authorization management system. Let’s dive in!

Authorization: Security First, Accessibility Second

Building and managing a system that can handle access permissions is a must for basically any application these days, especially one as large as Discord. With applications growing ever more complex and the reality of microservice-based architectures, ensuring that the right users have appropriate access to the right resources at the right times is a bigger challenge than ever.

When building authorization, especially considering it’s a feature mostly built in-house and requires a very large amount of effort to develop, developers tend to focus on building authorization that provides the required level of security and restrictions their app needs. This approach is great, but it comes with a catch—it often overlooks the importance of developer and user experience.

To understand why experiences are important in authorization, let’s talk about who uses our app.

Who Uses Our Application?

Every modern application consists of several levels of users. It’s never as straightforward as end-users and developers.

End-users interact with our application in multiple areas, each of which must be considered when designing our authorization layer. This includes what users can see in the application, ****which actions they can perform, and what data they can access.

App developers need a level of user permissions management that allows them to create and handle new policies, requests, and processes.

This obviously doesn't mean their access is unlimited, and it requires monitoring and management as well. Who decides what developers can access and what level of control they have over our application's authorization layer? More often than not, a specific person or group will be directly in charge (albeit reluctantly) of managing the application’s user and role management.

Depending on our application, there are more possible levels here. Internal Users who are members of our organization might need different levels of access, and some may need to manage and delegate access to end-users. Organizational Stakeholders, such as DevOps, RevOps, and AppSec teams, require access to specific parts of the application, as well as the ability to manage user roles and delegate access management to internal users.

How Do We Handle All These Users?

The prospect of creating all-powerful superusers is alluring to many developers. What can be more secure than directly calling all the shots yourself? And while that’s true to some extent, this approach backfires very quickly. If you, as a developer, are the person directly in charge of all user roles and permission management in your organization, you will very quickly realize the strain this will have on you and the entire R&D team as you turn into a bottleneck for the entire business operation.

Only one person/group can manage authorization for every user of your application? Great - it’s their full-time job now.

The opposite approach, delegating all power away from developers to other stakeholders, is often equally dangerous, as it can create a slow-moving, inefficient bureaucracy or an unstable, risk-filled environment.

What this means is that our authorization layer needs not only to provide a solid, secure basis for determining who has access to what within your application, but it must also be approachable and easy to understand. This is emphasized even further in Elisa’s blog, where she mentions the fact that 74% of all breaches involve the human element, with privilege misuse and stolen user credentials being two of the primary threats.

This is the direct result of developers’ tendency to focus on authorization being secure (which is great) while neglecting the need for it to be accessible (Which is bad).

As Elisa mentioned in her article:

“Policies designed to manage permissions tend to cause headaches for end-users and leave the decisions about “who can access what” in the hands of people who don’t have much information about the resources – often IT or Security”.

At Permit.io, we encounter this all the time. Many developers come to us because their homebrewed authorization solutions lack both developer and user experience.

Let’s see what Discord did to help solve these issues:

What Did Discord Do?

To address these concerns, the folks at Discord built an internal portal for staff to manage user permissions for their internal users, organizational stakeholders, and developers. Focusing on workforce identity (We’ll get to customer identity in a sec with Permit.io), they created it with the goals of being secure, transparent, and easy to use, and eventually made the tool publicly available and free to use.

What was their goal?

Discord uses Okta as its authentication solution for SSO. As they grew, they wanted the ability to further customize access controls for their employees. These were the goals they set for themselves:

This tool needed to be security-focused and enforce the principle of least privilege.
It needed to have an intuitive user experience that didn’t require staff to have deep knowledge of the access control tool or the systems being managed. This would help ensure the tool’s adoption within the company.
The tool needed to be “self-serve” and allow delegation within their internal policies. As we mentioned previously, having IT or Security teams exclusively manage permissions would create a bottleneck in one particular organization and slow down the whole operation.
Finally, they wanted a system that was transparent and discoverable. Users would be able to see what access they or their teammates have, what resources are controlled by the system, and what permissions they had in the past but have since expired. They should also be able to request access to resources freely, empowering them to troubleshoot their own permissions and solve issues through access requests.

After what Elisa describes as “weeks of development time and dozens of cups of coffee”, the Discord team ended up building “Access” - an RBAC-based solution for managing their internal user access control.

What features does this tool provide?

Let’s see what features Discord’s tool ended up providing and how these concur with the Best Practices for Effective User Permissions and Access Delegation:

Delegated control: Each group or app has a set of owners who control membership and access related to that resource, ensuring each group or app has designated owners responsible for managing membership and access. This follows the best practice of having a primary admin or owner who manages permissions, preventing conflicts such as two admins being able to remove each other and ensuring that those with the most context handle permissions.
Time-bounded access: This feature mitigates the risk of accumulating unnecessary permissions over time by allowing access to be set for predetermined periods.
Access requests: Access requests enable users to discover and request necessary permissions, which are then reviewed by appropriate owners. This delegation supports a cascading model of permissions, ensuring that those with the best understanding of the needs grant permissions, balancing the load across different levels of the organization.
Audit logs: Every user, group, and role in Access has a page viewable by all employees that shows complete membership and ownership history. These comprehensive audit logs allow all users to see complete membership and ownership histories. This transparency supports the generation of audit logs, which are crucial for tracking changes and understanding permission alterations at every level of the system. ‍

Using classic policy models for ‘high-level’ authorization policies (e.g., RBAC, ABAC): Access was built based on an RBAC model, which helped ensure consistency and ease of understanding across the system, lowering the cognitive load on system managers and users.
Building an easy-to-use UI: The intuitive and user-friendly interface built by the Discord team enables effective permission management. It makes permission management accessible and straightforward so that all users, regardless of technical expertise, can effectively manage and understand their permissions.

Implementing Accessible Authorization Elements

The tool built by Discord provides a masterful solution to the problem of effectively handling user permissions and access delegation. As mentioned before, we at Permit.io encounter this problem with our users all the time, and it spans beyond internal users.

Permit.io aims to provide a comprehensive solution for managing user permissions for all application users, from end-users to application developers, in a single, unified interface.

When we initially launched Permit, our goal was to provide developers with the building blocks needed (SDKs, gateway plugins, data updates) to integrate permissions into an application. This included a no-code UI for creating and managing permissions with RBAC, ABAC, and ReBAC support.

Permit.io’s permission management UI with RBAC, ABAC, and ReBAC policies, all together in one interface.

To further improve accessibility, we introduced “Permit Elements,” a set of prebuilt and embeddable UI components that provide fully functional access control. These components allow you to safely delegate permissions to your end users.

Permit Elements enable crucial permission management functionalities (such as User Management, Audit Logs, Access Requests, and Process Approval) to propagate through your user stack—from developers to internal users and end users, ensuring efficient and secure access management without bottlenecks.

By incorporating Permit Elements, you can enhance the accessibility and usability of your permission management system, ensuring that it is not only secure but also user-friendly and efficient.

Conclusion

Building an accessible permission management system is crucial for maintaining both security and efficiency in modern applications. Discord's innovative approach with its "Access" portal showcases how balancing security with user-friendly features can streamline operations and enhance overall security. By incorporating intuitive design and robust delegation capabilities, Discord has set a high standard for internal authorization management.

To further enhance your permission management system, we covered "Permit: Elements” - a set of prebuilt, embeddable UI components that offer fully functional access control. These components enable you to delegate permissions safely and effectively to your end users. By adopting such solutions, you can ensure that your authorization processes are not only secure but also accessible and efficient for all users.

Turning Secure Access Into Child’s Play with Permit Access Request APIs

Daniel Bass — Mon, 22 Apr 2024 14:23:47 +0000

When we build an application, some parts will be accessible to users, while others will be restricted. That’s a given. But building this kind of capability has its fair share of complexions - especially when these limitations aren’t static but change with the circumstances. As I’ll show you in this blog, enabling user access requests can be as simple as a children's story.

Let’s get into it -

The Challenge

Creating strict rules that allow certain users access to certain parts of the app isn’t a big issue - but that’s rarely enough for practically any modern application. In most cases, circumstances and user requirements constantly change over time. This gives us two options:

Either manually make changes to your authorization layer every time or create an automated system (An Access Request API) that allows users to request access and allows administrators to grant them access based on certain conditions. Let’s look at the manual option -

Say a user wants access to a certain part of the application which can only be approved by a specific type of admin. This means that you will have to create a system which:

Associates the specific application segment to the relevant admin, and has their contact information.
Allows the user to send an access request email/message requesting access. This will probably require the integration of some third-party tool.
Once the request is sent, the user will need to wait for the administrator's approval, which might take time. While not directly your problem, this will create a UX issue that you’ll probably be expected to solve at some point.
If the administrator approves the access request - there’s still the task of changing the actual authorization rule that enforces the access. This is, again, a problematic bottleneck that might require a different solution, especially as things scale.
Once the appropriate changes to the authorization layer have been made, you’ll have to inform the administrator, who will need to inform the user.

This process will be required for any new access request.

As you can quite easily see, building this system and having you make manual changes to the code every time a user needs access to a new portion of the application (Say, if a user paid and should now have access to premium features) is obviously highly impractical. So let’s talk about creating an Access Request API that does this automatically.

What is an Access Request API?

An Access-Request API serves as a centralized mechanism for handling access requests within the application environment, streamlining the process by allowing users to directly request access to specific features or data sets from within the application, eliminating the need to do so manually.

The benefits of using an Access Request API

Using an Access Request API provides the following benefits:

It allows users to request access directly within the application without you having to set up 3rd party channels like emails/DMs. This doesn’t only make the process more comfortable for the user, but, more importantly - it makes it manageable.
With access requests all managed in one place, it becomes far easier to maintain a comprehensive history of requests, serving as documentation for access granted within the application.
Additionally, it allows multiple individuals to approve or deny access according to the rules you define. This reduces both waiting times for access requests and enables efficient management of your admin team.
Having multiple admins also allows you to follow which requests have been approved or denied and why.
Sometimes you might need to grant someone access to a role within a specific time limit. having a well-organized access control API helps you manage who, and more importantly, for how long, a user has access to a resource within your app.

How to implement an Access Control API?

You can build an access control API yourself as long as you follow some important best practices for building authorization. Another option is to use the Permit.io Access Control API, which generates access requests tailored to specific roles or resource instances and can be integrated into your app pretty quickly. It also allows you to assign suitable moderators who can evaluate and make decisions on user requests, helping make sure access is granted or denied in accordance with your specifications.

We also plan to release an Access Request Element, one of a few UI components we provide that allows you to safely delegate access control to your end users.

What does an Access Control API implementation look like?

To demonstrate how Access Control APIs work with Permit.io, let’s look at it through the simplest example possible - Goldilocks and the Three Bears. Imagine if the three bears had an application that used the Permit Access Request API - that story would look completely different:

In the forest, hidden among the trees, stood the cozy cottage of the three bears. In it, three rooms, three beds, and three bears: Papa Bear, Mama Bear, and Little Baby Bear.

In his shrewdness, Papa Bear decided to implement Permit’s Access Control API to track and manage access in their home.

One day, the three bears were away, while a little girl with locks of gold, stumbled upon their home. Goldilocks was her name, and hungry she was. Lured by the scent of tasty porridge, and lack of authentication, she made her way in. Famished, Goldilocks spotted a sign on the wall.
It read: “Access Restricted”. So she submitted an access request.

Papa Bear, deep in the forest, received a surprising access request. All the bears are here, yet some user named Goldilocks123 wants to eat their delicious porridge! Knowing Mama Bear’s hospitality well, he hastily approved the request and continued with his morning hike.

After savoring the porridge, Goldilocks grew sleepy. Before settling into one of the beds for a nap, she requested permission for her impromptu rest. Recognizing her adventurous spirit, Papa bear granted her request and offered a playful warning: "This is the last time, young lady!"

When the three bears returned to their home, they found Goldilocks there. She thanked the three bears, and swiftly left the cottage. As Goldilocks departed, Papa Bear chuckled:
“There’s nothing like properly implemented access control”.

The moral of the story

So what did we learn?

Most modern applications require an authorization system that allows not only static restrictions on user access but also the ability to adapt to reality. Allowing your users to request access to certain parts of your app is not something you want to do manually, and there are many benefits of having this capability embedded in your app in the form of an Access Request API.

In this blog, we learned how to use Permit.io’s Access Request API to create a safer, more secure experience for both you and your users, handling access requests quickly and efficiently in both make-believe and real-life settings.

How to build authorization like Netflix with Open Source?

Daniel Bass — Sun, 19 Feb 2023 11:24:46 +0000

This blog is based on the video "Build Authorization like Netflix with Open Source"

Netflix has over 220 million active users and is worth over 100 billion dollars. With such an enormous user base, they are responsible for managing a vast amount of personal information. A big part of that is ensuring relevant people have the permissions required to access that information, while others do not.

How does Netflix handle the challenge of managing its authorization? Where does open-source come in? How can you adopt this solution? (Or build something even better) Let’s find out.

With Great Power -

In 1997, Netflix was little more than an upstart DVD rental company. Fast forward two decades, and Netflix has become one of the biggest TV and movie studios in the world.

As a company grows, the responsibility it has towards its customers grows as well, and security becomes increasingly important with every new user joining the platform.

The first challenge is authenticating users when they log into the system - that’s authentication. Once users are in the system, the second step is to decide what they have access to - that’s where authorization comes in.

Why is authorization critical?

Authorization (Not to be confused with authentication) is the process of managing access to resources **based on a user's identity and the permissions **assigned to that identity. This is typically done by comparing a user's credentials against a set of rules (policies) to determine what they are allowed to access.

Authorization is crucial for Netflix - not only to make sure only paying customers have access to shows but also as a means of maximizing potential revenue. How you may ask? By being able to tailor shows based on specific countries or user interests, by offering purchasing power parity - adjusting their prices in accordance with income levels per country, and more.

Authorization is a complicated task

Writing authorization policies is quite a complex task. To address this issue, Netflix chose Open Policy Agent (OPA) - an open-source general-purpose policy engine that unifies policy enforcement across the stack.

OPA provides a high-level declarative language called Rego that lets you write policy as code, along with a simple API to offload policy decision-making from your software (As pairing authorization logic with application logic is a bad idea). OPA can be used to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more.

The thing is - Rego is quite hard to master, thus limiting the ability to manage policies to a very small chunk of people. Netflix encountered a problem where very few people in the organization could actually write Rego policies, yet they wanted to distribute the ability to create and manage policies across the organization.

How did Netflix solve its authorization problem?

Netflix built a UI on top of OPA, which allowed them to create Rego policies and simplify the process. That solved the issue, but then another problem emerged:

Once the policy was in place, did they actually capture its intent?

They knew in plain English what they wanted to achieve with the policy, and they proceeded to define it in the UI, but they didn't know if it would actually perform. To solve this issue, Netflix ended up building unit-testing mechanisms for the UI.

You want a policy to be implemented in the system? Write it, write a test for it, and make sure that the test passes. Before you save and the policy change gets pushed, all the tests are run, and then if they all pass, the changes get applied to production. Voila.

This allowed Netflix to create a solution on top of open-source components, saving them much of the effort it would take to build a homebrew authorization layer from scratch. Unfortunately - Netflix kept this solution to themselves, never exposing it to a wider audience.

A great video by the CNCF where Manish Mehta and Torin Sandall from Netflix tell the story of how Netflix solved authorization with OPA in much more technical depth:

How can I implement this solution?

While Netflix never open-sourced their solution, the solution they built on top of OPA inspired another open-source project: OPAL

OPAL (Open Policy Administration Layer) is an open-source administration layer for OPA that allows you to easily keep your authorization layer up-to-date in real time. As you push updates to your application's stores (e.g. Git, DBs, S3, SaaS services) OPAL will make sure your services are always in sync with the authorization data and policy they need.

A similar high-level architecture to Netflix's is expressed within OPAL:

The Aggregator is the OPAL server, the Distributor is the split between a server and a client, and the Updater is the OPAL client.

You can learn more about OPAL’s architecture here

Using this inspired approach allows OPAL to aggregate policy and data from different sources, and integrate them seamlessly into the authorization layer in real-time. The project is free and available to everyone as a public project and is already being used by companies like Tesla, Cisco, Palo Alto Networks, and Walmart.

If you want to go even further, Permit.io provides a no-code UI that allows you to create, manage and enforce Rego policies and is based on a combination of OPA and OPAL. Allowing you to implement complex RBAC and ABAC policies into your application, and manage them with a simple UI anyone in your organization can use.

Help OPAL grow

OPAL is an ongoing open-source project which is already keeping hundreds of policy agents updated in real-time. You can join OPAL’s Slack community to chat with other devs who use OPAL for their projects, contribute to the open-source project, or follow OPAL on Twitter for the latest news and updates.

The four mistakes you make building permissions

Daniel Bass — Sun, 21 Aug 2022 15:46:00 +0000

Access control is a must in almost any application, yet most developers end up building and rebuilding it time and time again - forced to refactor with new customer, product, or security demands coming in.

Why? Usually, they make one or more of four crucial mistakes that prevent them from having a flexible access control layer that can be upgraded without having to rebuild it every time a new product demand comes in.

Before we dive into these, we first need to acknowledge that Permissions are hard, and they're becoming harder as the world moves into cloud-native ecosystems and microservices. Let’s try and understand why -

What makes permissions complex?

Moving from monoliths to distributed microservices

Back when applications were structured as monoliths, the decision-making process of who connects to what within an application could be baked into one place, usually by using a specific framework such as Spring, Django, or Python.

When working with distributed microservices, especially in a polyglot structure, these solutions are no longer applicable, so you end up having to sprinkle a bit of access control into every little microservice and component you're building. This creates an issue where we struggle to upgrade, add capabilities and monitor the code overall as it is replicated between different microservices.

Connecting to 3rd party services

It’s not just about the services you provide anymore: The ability to connect your application to 3rd party services (Like authentication, billing, analytics, machine learning agents, or databases) has become a crucial aspect of building any application - this requires us to manage access control for elements outside our own cloud.

New, complex permission models

The policies, rules, and models we want to enforce permissions with are also becoming more complex. Applications often start with an Admin / Non-Admin model and quickly move to increasingly complex models such as RBAC, ReBAC, and ABAC. Our expectations for applications and the different ways we can collaborate within them have never been higher, creating a need for ever-evolving complex policies.

Security and Compliance

If back in the day, doing SOC 2, ISO, or meeting GDPR or CCPA standards was out of the ordinary, today, these standards are common for basically any B2B (and often B2C) application. These standards, along with HIPPA and PCI, all have lots of requirements related to having checks and balances for your application's access control.

We can significantly reduce the amount of hardship we need to go through to meet compliance standards by implementing good access control. Having a feature like auditing, combined with visibility into your access control level, which you can share with your auditors, security, and compliance, is expected from almost any solution being built - maybe not on day one, but probably quickly down the road.

If that's not enough, there's a lot of security friction and vulnerabilities surfacing from challenges in building access control. It's no surprise that broken access control is the top A1 item on OWASP’s list of vulnerability sources, with the highest occurrence across all the surveys.

Permissions are not only a problem in how we manage and build things, but it is also creating security issues in our production, which we may face as security incidents.

Now that we understand the depth of the problem, let's jump into the common anti-patterns that people often end up implementing into the access control that they're building, creating security vulnerabilities.

The Antipatterns

1. Mixing ‘Auths’ - Authentication VS Authorization

Mixing up authentication and authorization is probably the most common pitfall out there. Despite both belonging to the IAM space, the two are very different. In short - the IAM space consists of three parts: Identity Management (IM), Authentication (AuthN), and Authorization (AuthZ).

Identity management solutions like OKTA and Azure Active Directory are used on the organization side, defining different organizational identities and their relationships.
Authentication is done on the product side, where you verify identities before allowing them into the product (Log in).
Authorization is the layer that lets us enforce and check permissions within the product.

These three steps trickle down into one another, but we must understand their differences.

Role translation

One source of confusion between identity management, authentication, and authorization stems from their use of Roles. The concept of Roles exists through the IAM space, but the meaning varies in each part.

Identity Management Roles indicate a role within an organization (Like “Head of Marketing” or “Member of Security Team”). These roles are drastically different from those used on the application level (Like “Admin,” “Reader,” or “Viewer”). Translating IM organizational roles into application-level Authorization roles is not always a straightforward process, but it is an issue that clearly needs to be addressed.

The result of this translation (For example - Deciding that our Head of marketing, who is part of the marketing team, should have an editor role for the CMS) should be saved as part of the JSON web token (JWT) produced by the authentication layer.

What else should JWTs be used for? Glad you asked.

Using JWTs

Basically, the translation of the IM role into an authorization layer role (Or - the translation from an organizational role into an application level role) should be the only thing included in the JWTs.

Developers often tend to overuse JWTs, sometimes going as far as storing all the routes that a user should access within them. That is a bad idea for several reasons:

Mixing the authentication and authorization layers messes up our code.
Changing roles requires the user to log out and log in again, which can hinder the user experience and overall application performance.
As the JWT is sent for every request with a RESTful API, GraphQL, or any other HTTP-based solution, creating a bloated JWT would significantly slow down the application’s performance.
There is a limit to how much data can be stored within a JWT. If we keep adding more rules, we will eventually run out of storage space.

The best way to avoid this is to have the JWT only include the claims and scopes for the user's identity and their relationship within the organization and keep all other authorization-related information in a separate layer within the application.

Speaking of creating a separate layer for authorization, the next common mistake devs make is mixing up application logic with authorization logic.

2. Mixing up App-logic and Authorization

When building an application, we have the logic of what the application is supposed to do, and we have the logic for who is allowed to perform which actions within it.

The combination of these two logic sets could easily result in us having spaghetti code composed of a mix of unrelated elements. If we will need to upgrade the application or the authorization layer (Which is rather likely to happen at some point), we'll end up having to cherry-pick different elements of code, trying to figure out which are application related and which are authorization related.

When these two logic sets are combined, they inevitably grow organically and become increasingly cumbersome, turning any future effort of separating, editing, updating, or upgrading them into a nightmare.

There’s also an issue of performance here - Let’s say our application checks a user's payment status to approve or deny access to certain features. Checking this every time as part of the application flow could significantly hinder the application’s performance.

A much better way to approach this issue is to decouple our policy from our code. This way, the authorization layer can run in the background and monitor the user’s payment status. Whenever we want to check that status, it will already be available in the authorization layer, eliminating the need to fetch it every time.

3. Mixing up your Access control layers

Every application requires multiple layers of access control -

Physical access control, like having locks on our doors and windows.
Network level access control, like firewalls, VPNs, and zero trust networks.
Infrastructure level access control, like limitations on which services can talk to each other.
And lastly, application level access control.

Each of these layers has different demands, requirements, policies, and models. Ideally, we would have a unified interface/back-office where we can view, manage and audit all these different layers. The ability to manage them as code would be even better, as it allows us to manage and run tests on them as part of our source control.

The main mistake we often see developers making in this aspect is combining their application-level access control with a tool that was built to manage infrastructure access control, like AWS IAM.

Initially, this might look like a great idea - AWS IAM is a very powerful tool that can map many things into objects, which is why engineers use it to map their application-level access control. So why is this not a good idea? Let's look at a specific example.

We often encounter engineers mapping their application-level access control using SS3 buckets in AWS. Because their data is stored in a bucket anyway, they feel they might as well use the access control for the bucket for the application itself. Although this may sound great on the surface, it's easy to see when things start to go wrong -

The moment you’ll want to move to a different cloud or even a different storage layer within the same cloud, there’s a good chance you won't want to use the buckets anymore - you’ll want to use RDS, Redshift, or Snowflake. Just because the requirements for your application have changed, you will have to completely refactor your access control because it was coupled into that specific cloud component infrastructure.

It can also be a major problem to rely too much on how things are built for these specific components. A lot of people rely on the way you configure the API gateway to do enforcements for your application. Sadly, AWS encourages you to put routes inside the JWT - a practice devs end up adopting as something they can take into production in scale and end up regretting in the long run.

Ultimately, it's important to remember that different access layers have different needs. If we ignore these needs, we might regret it later and end up having to refactor large parts of our applications.

4. Thinking that you can solve it once and for all

The last major mistake developers tend to make when thinking about permission building is more of a conceptual one - Thinking they can solve it once and for all.

Many young companies fall for this misconception and end up rebuilding their access control over and over again instead of developing crucial new features in the application itself. The worst thing about that is that every time they do it, they think this time will be the last. In reality - if you follow even just some of the anti-patterns we described here, there's a good chance that every time a new requirement comes in from a customer, partner, security, or compliance, you just might have to throw out everything you've built and start from scratch.

The only way to avoid this scenario is to plan for it. Building an ever-growing, ever-developing application, you have to assume that you will have to evolve your authorization layer to support more policies and complex roles. You have to assume you will move from RBAC to ABAC or other even more complicated models and provide interfaces on top of them.

This doesn’t mean you should try and build a perfect, future-proof permission management system from day one - especially if you are working in a startup company. You’ll just never finish. Instead, focus on setting the right groundwork - if you plan ahead and avoid the mistakes we discussed in this post, you will be able to upgrade your permission layer with much more flexibility - instead of having to rebuild it from scratch every three to six months.

Most companies go through the same steps - they initially build good schemas for their data layers and authorizations, but gradually, as they move forward, these schemas stop working, and they start facing performance issues. The only way to avoid this is to decouple your authorization layer from your application’s logic and be ready to update it gradually as demands come in.

Let's sum everything up -

Whether it's the move to distributed microservices from monoliths, the requirement to integrate 3rd party services into your application, the necessity of using complex permission models, or the rise of security and compliance requirements, permissions have become more complex than ever.

All of these changes require us to adopt new best practices and avoid common mistakes developers make when thinking about authorization:

Mixing Authentication and Authorization, especially when it comes to the somewhat confusing translation of organizational roles into application level ones and the correct usage of JWTs, mixing up application logic with authorization logic, using tools designed for infrastructure access control (like AWS IAM) to manage application level access control, and thinking that we can solve our authorization problems once and for all on day one.

Most importantly, it's important to understand that developing a good authorization layer in a constantly changing application requires planning ahead and building a flexible solution that can be upgraded without having to rebuild it every time a new product demand comes in.

Building authorization? Got questions? Come talk to hundreds of developers working on solving their IAM challenges in our Slack community!

How to Implement Multitenancy in Cloud Computing

Daniel Bass — Thu, 04 Aug 2022 12:15:00 +0000

Cloud-based SaaS solutions, as well as most other solutions, need multi-tenancy. Let’s quickly review what Multitenancy is, what we can gain from it, and how to easily implement it with two simple layers.

What is Multitenancy

At its core, multi-tenancy allows every part of the service (i.e., every microservice) to cater to multiple customers without deploying separate instances for each.

For a SaaS solution to scale affordably, meet customer demands, and be elastic in doing so (i.e., cost-effective in cloud resources), it has to support multi-tenancy.

A multitenant architecture provides many great and often essential features:

Allowing the application to serve multiple customers at once while sharing the underlying infrastructure and services
Secure and compliant access separation
Load balancing and scaling

The two layers of Multitenancy

At the end of the day, multi-tenancy is easy once you understand it, and it basically requires only two things: Application level access control and managing data schemas.

Let's break it down into two planes:

The data plane is all about how you transmit, store **and manage **the siloed data (i.e., How the underlying infra avoids mixing up the data of different tenants). Multi-tenancy for the data plane is often implemented as partitions on the data layers - e.g., separate partitions, tables, columns, identifiers, and/or labels on the data storage schema (how you save it in the database) and topics (e.g., Kafka topics), tags, domains, sockets, and/or ports, for the data at transit.

Example of DB tables with simple column-based tenant separation

The application plane is about how you silo context and access within the logical layer, i.e., have the same code work for different tenants. Authorization is the component within the application plane implementing multi-tenancy.

Example application route enforcing multitenancy with Permit.io’s SDK (check it out on Github)

Implementing multi-tenancy

An authorization layer is the fastest and most reliable way to upgrade from a single-tenant application to a multi-tenant one safely. In addition, the authorization layer can implement separation without requiring changes to the services themselves by applying a policy across all relevant services.

Choosing the right policy model can simplify this transition even further, with classic models like RBAC + Tenancy, ReBAC + Hierarchy (tenants becoming root-level relationships), or plain vanilla *ABAC *(with tenancy as an attribute).

The great thing is we don’t need to implement multi-tenancy authorization on our own, and instead can enjoy ready-made open-source tools and services.

Implementing multi-tenancy with OPA + OPAL (Open-Source)

Open source is a great option to start implementing your authorization layer for multi-tenancy. While there are multiple options, Open Policy Agent (OPA) is among the most promising.
OPA acts as an authorization microservice that we can add to our application and use to enforce access with rules written in its proprietary Rego language.

Combining OPA with OPAL (Open Policy Administration Layer) enables us to manage our authorization layer in scale, using Pub/Sub topics to keep our agents up to date with policy (Rego code) and data (JSON documents). The topics, for example, can be our tenant names or IDs, allowing us to sync our agents with changes per tenant.

Implementing multi-tenancy with Permit.io (Service)

App authorization solutions (Such as Permit.io 😇 ) solve the application aspect out of the box and layer easily on-top of the data plane by providing (or correlating according to) unique identifiers that can be used to partition the data plane.
⁠
Permit builds on top of OPA and OPAL, adding management interfaces, including a tenants list, tenant resource management, and per tenant user management.

Switching between tenants in Permit.io’s dashboard

To sum things up -

Multi-tenancy allows our application to cater to multiple customers without deploying separate instances for each. Multi-tenancy enforcement in gist consists of two planes: data and application. One of the best ways to achieve Multi-tenancy is by creating an authorization layer that can implement separation without requiring changes to the services themselves. Although you can build your own authorization layer, there are also open-source options (Such as OPA + OPAL) and *Services *(Such as Permit.io) that allow you to implement one in your application - making the critical shift into multi-tenancy more accessible.

Considering multitenancy for your app? Got questions? Join our Slack community and chat with fellow developers building authorization!

OPAL + OPA VS XACML

Daniel Bass — Thu, 19 May 2022 12:57:19 +0000

Introduction

Way back in 2013, various devs were either announcing or debating the death of XACML - yet XACML’s goal to promote a common terminology and interoperability between authorization implementations remains valid, and it still serves as a solid base to describe the structure of authorization architectures.

The IAM landscape, authorization included, has evolved drastically in the past couple of years and allowed for new XACML alternatives to be created. This significant shift was a result of the rising demand for increasingly advanced authorization, which was generated by the growing complexity of applications and their migration to microservices and cloud-native structures. With advancements in technology, the emergence of shift-left and low/no-code developers, and the need for event-driven dynamic authorization - a replacement for XACML had to evolve.

One such XACML alternative is OPA + OPAL. Open Policy Agent (OPA) is an open-source project created as a general-purpose policy engine to serve any policy enforcement requirements that unifies policy enforcement across the stack without being dependent on implementation details. It can be used with any language and network protocol, supports any data type, and evaluates and returns answers quickly. OPA’s policy rules are written in Rego - a high-level declarative (Datalog-like) language. You can find a more detailed introduction to OPA here. It’s important to note that OPA itself only provides an alternative to XACML’s PDP (More on that further). OPA is enhanced by OPAL (Open Policy Administration Layer) - another open-source solution that allows you to easily keep your authorization layer up-to-date in real-time. More information about the project is available here. The combination of OPA and OPAL provides a solid alternative for XACML.

To better understand this alternative, we’ll compare the traditional XACML architecture authorization flow with the one provided by OPA + OPAL and then discuss the differences. It's important to note that while being a primarily Attribute-Based Access Control (ABAC) system XACML can also be used to describe Role-Based Access Control (RBAC) and other models.

A few basic terms to understand the flow:

The architecture of XACML consists of a few different modules that make up the process of making authorization decisions. Let’s take a look at those different parts:

PEP - “Policy Enforcement Point”:
The PEP intercepts a user’s access to a resource, and either grants or denies access to the resource requested by the user. PEPs don't make the decisions; they enforce them.
PEPs can potentially also adjust requests or their results before passing them through (aka data-filtering). Examples of PEPs are in-code control flow (i.e. “if”), middleware, reverse proxies, and API gateways.

PDP - “Policy Decision Point”:
The PDP evaluates authorization requests against relevant policies and a data snapshot aggregated from the distributed data layer and makes an authorization decision.

PAP - “Policy Administration Point”:
⁠The PAP is in charge of managing all relevant policies to be used by the PDP.

PIP - “Policy Information Point”:
The PIP is any data source (Internal or external) that contains attributes that are relevant for making policy decisions.

PRP - “Policy Retrieval Point”:
⁠The PAP is the main source of policies - it stores all relevant policies to be used by the PDP, and is managed by the PAP (In OPA it's a bundle-server, and in OPAL this is often a Git repository or an HTTP bundle server).

Traditional XACML Architecture

Let’s start by reviewing the architecture of traditional XACML and its authorization flow:

Everything starts with a user (or automated entity) interacting with an application. The user sends a request to access and perform an action on any sort of resource within the application. Before being submitted to the application logic, the request passes through the PEP. The PEP is in charge of either granting or denying a user’s request for access to the resource.
The PEP translates the user's request into an XACML authorization request. It is important to note that one user request can trigger multiple authorization queries (as it interacts with multiple resources).
To know whether the request should be approved or rejected, the PEP sends the authorization request to the PDP.
The PDP makes make authorization decisions based on pre-configured XACML formatted policies.
The policies are stored in the PRP and are managed by the PAP.
If needed - the PDP queries relevant PIPs per query for any additional relevant information.
The PDP reaches a decision (Permit / Deny / etc.) and returns it to the PEP.
The user is either granted or denied access to the resource by the PEP, based on the PDP’s decision.
⁠

OPA + OPAL Architecture

While based on similar principles, OPA and OPAL provide a slightly different authorization model with significant benefits:

The first step is identical to XACML - the user / automated entity sends a request and it passes through the PEP.
The PEP converts the user's request into queries for the PDP (In this case - OPA).
The queries are submitted by the PEP to the PDP (OPA) to know whether the request should be approved or rejected. So far so good - here is where things are a bit different. First of all, OPA stores all relevant policies within its cache. Second - the policies are represented as code (In Rego), unlike XACML where they are represented as configuration (as XML schema).
The PAP (In this case - the OPAL Server) serves a dual function. It both functions as a Policy Administration Point and a Policy Information Administration Point.

4.1 As a Policy Administration Point - The OPAL server is in charge of managing all relevant policies and supplying them to OPA, within the PDP.

Policies are stored as code in a GIT repository (default option, though others exist), which acts as the PRP. The OPAL Server receives policy updates from the PRP and instructs the OPAL clients to update OPAs’ caches accordingly. Every time a change in a policy happens in GIT, it is pulled by the OPAL Server and pushed into OPA’s cache via the OPAL clients which listen to the server (based on topics) and are located next to the OPA instances. By leveraging GIT and policy as code, OPAL allows us to use Gitops best practices (e.g. tests, code-review, benchmarking)

In this manner, OPA always stays up to date with the latest policy changes in real-time without the need for redeployment.

4.2 As a Policy Information Administration Point - the OPAL server informs the OPAL Client within the PDP on changes to data within the PIPs according to selected topics. With the updates to the client, the server sends instructions on how to query the PIPs, and the OPAL Client fetches the data directly from the PIPs (according to the instructions) and updates OPA with the most recent information. As this process is continuous, the information stored in the PDP cache is always up to date with the latest data needed to make access decisions in the most accurate way possible.

The PDP (OPA) reaches a decision (Permit / Deny / etc.) and returns it to the PEP.
Based on the decision made by the PDP (OPA), the PEP either grants or denies the user’s access to the resource.
⁠

The differences

From the differences in the authorization flow between the traditional XACML and OPA+OPAL, we can note three significant benefits which the latter provides:

Component	XACML	OPA+OPAL
Policy	XAXML Configuration	Rego code
PDP	-------------------	OPA (+OPAL Client)
PAP	-------------------	OPAL server
PRP	-------------------	GIT (Or any other policy source)
Policy loading	As part of the deployment	Real-time
Paragraph	As part of a query	Real-time

The OPAL server’s ability to receive updates from GIT (Or any other policy source) keeps OPA up to date with the most recent policies - allowing us to make policy changes on the fly and have them utilized by the PDP with minimal latency. Leveraging policy as code within a GIT repository enables the adoption of configuration as code and Gitops in general.
The OPAL server not only manages the policies themselves, but also the PIPs from which additional data is often required to make a policy decision. The OPAL Client constantly listens to changes in relevant PIPs (Internal or external databases) and uses data fetchers to keep OPA’s cache constantly up to date with the latest information needed to reach an authorization decision. Because this is an ongoing process and not done per query, OPA can have all the relevant information in its cache to make policy decisions even if the PIP is not available - preventing the PDP from making the authorization decision.
While not evident from the authorization flow which we described, it is important to note that policy in Rego is much more accessible and easier to read/maintain than in XACML. Check out this example: (For a more detailed explanation of this example check out this guide)

Same policy side to side - Rego and XACML

The differences between Traditional XACML and OPA+OPAL highlight the drastic changes in the authorization space that occurred in recent years. OPAL’s ability to receive both data and policy updates in real-time allows for the creation of event-driven dynamic authorization. At the same time, OPA provides the ability to define more complex authorization structures fit for microservices and cloud-native structures, and its policy language Rego is easier to read/maintain and provides accessibility to low/no-code developers.

OPAL is a mature open-source project which is already keeping hundreds of policy agents updated in real-time. You can join OPAL’s Slack community to chat with other devs who use OPAL for their projects, contribute to the open-source project, or follow OPAL on Twitter for the latest news and updates.

Real-time dynamic authorization - an introduction to OPAL

Daniel Bass — Thu, 28 Apr 2022 09:33:55 +0000

TL;DR

OPAL is an open-source administration layer for Open Policy Agent (OPA) that allows you to easily keep your authorization layer up-to-date in real-time. OPAL detects changes to both policy and policy data and pushes live updates to your agents - bringing open policy up to the speed needed by live applications.

As your application state changes (whether it's via your APIs, DBs, git, S3, or 3rd-party SaaS services), OPAL will make sure your services are always in sync with the authorization data and policy they need.

The challenge of building authorization

Cloud-native / microservice-based products can be quite complicated, and so is building access control and managing permissions for them. Distributed applications and microservices require a lot of authorization points by design and the ever-changing requirements and regulations from various departments constantly challenge every authorization solution. Moreover, even the simplest miscalculation in the authorization layer can lead to devastating consequences for your application in the form of security vulnerabilities and privacy/compliance issues.

There are several best practices for building an authorization layer correctly (and avoiding the need to constantly rebuild it) - the first of which is decoupling policy and code. In short - Having the code of the authorization layer mixed in with the code of your application can result in trouble upgrading, adding capabilities, and monitoring the code as it is replicated between different microservices. Each change would require us to refactor large areas of code that constantly continue to drift further from one another as these microservices develop.

To avoid this, we recommend creating a separate microservice for authorization that will be used by the other services in order to fulfill their authorization needs. Open Policy Agent (OPA), which is the default policy engine for OPAL, allows you to do just that. You can read more about OPA here.

Another best practice, which OPA alone does not fulfill, is making your authorization layer event-driven.

Why event-driven?

Almost all modern applications rely on abilities such as user invites, role assignment, or the usage of 3rd party data sources. All of these abilities have one thing in common: They have to be managed in a real-time fashion. Every time an event that affects authorization happens, we need it to be pushed into our authorization layer ASAP so it can stay in sync with the application, any relevant 3rd party data service, or changes in policy.

Here’s an example - Say you want to control who has access to a specific feature in your application based on a user’s payment status. If the user paid for the feature - they have access. This scenario creates three main challenges:

The data about the payment status of users (As well as various other types of data relevant to making authorization decisions) often resides in a database external to your organization, or a 3rd party service like Stripe or PayPal. You need your authorization layer to be aware of any relevant changes in these databases and make decisions based on the most up-to-date information available. To achieve this, we’d need something that listens to changes in the data sources relevant to us, and pulls them into our authorization layer so it can make the most accurate, relevant, and up-to-date decisions.
Delays in updates to the authorization snapshot can create consistency problems. Consider this example - a request is being handled by two microservices in the same chain. The first microservice can consider the request in one state (e.g. This user is not a paying user), while the following microservice considers the request in another state. This can cause the overall request to fall into an undefined state.
Different microservices need different subsets of policy and data, just keeping track of the needs of each one can be challenging without an event stream to guide us.

Being a common problem, large organizations such as Netflix and Pinterest who rely on OPA as their policy engine were required to create their own solutions, building multiple administration layers on top of OPA. Manish Mehta, a senior security officer from Netflix, shared Netflix’s permissions design in a talk at KubeCon. Unfortunately, these giants haven’t open-sourced their solutions; but their work did inspire the creation of OPAL.
⁠

How Netflix uses OPA in permissions enforcement talk at KubeCon, 2017.

How OPAL helps solve these challenges:

OPAL is an open-source solution that helps us solve these two challenges by providing two significant features:

The ability to track a designated policy repository (Such as GitHub, GitLab, Bitbucket) for changes (by either setting a webhook or web polling every X seconds), thus serving as a PAP (Policy Administration Point) and propagating these changes into OPA (The PDP - Policy Decision Point in this case) thus always keeping it up to date.
The ability to track any relevant data source (API, Database, external service) for updates via REST API, and fetch up-to-date data back into OPA.

These two features make sure that OPA is always up to date with both the latest policy information and the latest data - allowing it to always make the most accurate and relevant authorization decisions.

OPAL’s ability to solve these challenges led to its adoption by a number of leading organizations such as Tesla, Zapier, and Accenture.

How does it work? A little deep dive into OPAL’s architecture:

OPAL consists of two main components: the OPAL Server and the OPAL Client.

The OPAL Server is responsible for two things:

It tracks a designated policy repository for changes via webhook or polling for policy updates and pushes these changes to the OPAL Client.
It tracks all relevant data sources for changes via webhook, signals the OPAL Client about any changes via WebSocket, and provides it with information on where the data is located.

In both of these cases, the OPAL server creates a pub/sub channel that the OPAL client(s) can subscribe to with topics they need to track. As soon as there’s a change, the OPAL server notifies the subscribed clients.

The OPAL client is deployed alongside OPA and provides real-time updates of all relevant data and policy from the OPAL Server to OPA, so it also has a dual function:

Policy changes: Whenever there is a relevant policy update in the policy repository, it is pulled by the client from the server, and propagated into OPA.
Data updates: Whenever there’s a relevant data update in a topic that the OPAL client is registered to, the OPAL server will push an update to the OPAL client with information on where to pull the newly updated data from. The client will then reach out to fetch the latest relevant data with the help of OPAL Data Fetchers.

OPAL Data Fetchers are configured to grab updates from a specific data source. A data fetcher has two main methods: fetch(), which is in charge of querying the data source, and process() to filter the data and convert it to JSON format, OPA’s format. The OPAL Data fetchers retrieve any relevant data from their designated data source and propagate it to OPA.

Another important feature of the OPAL client is its ability to only subscribe to the specific data that it needs. If your application requires large amounts of data to support authorization logic, the OPAL client can subscribe only to the specific parts needed for that specific agent - this provides benefits both in terms of security (By keeping access to data on a “need-to-know” basis) and manageability.

This way, OPA is able to make policy decisions based on the most recent policies and data. A deeper dive into OPAL’s architecture and communication flows is available in OPAL’s documentation.

Keeping OPA up to date in real-time is crucial, especially when dealing with authorization at the application level. By using OPAL we enhance OPA’s authorization capabilities with two major abilities:

Updating our policies in real-time, and having our authorization decisions made on the most up-to-date policies available.
Pulling relevant data from any source, thus being able to make authorization decisions based on data from any Database or service.

Help us grow -

Authorization is changing - how we can harness the benefits?

Daniel Bass — Sun, 13 Feb 2022 10:46:38 +0000

The landscape of authorization has changed drastically in the last few years - Today’s applications require complex authorization systems and call for well-designed, adaptive solutions. In this post we will try to answer what changed, both in terms of the challenges and the solutions, and how we can adapt to these changes.

But first, before we dive into this - let’s establish the space that we're going to be discussing:

The IAM landscape

IAM (Identity Access Management) is composed of three separate parts: Identity management, Authentication (AuthN), and Authorization (AuthZ).

Identity management

⁠⁠Identity management is about being able to tell who's part of your organization, what attributes they have, and which departments they belong to. This allows you to create identities that can be aggregated and managed in a unified interface.

Authentication

⁠⁠Authentication is all about verifying the identity of the person connecting to your product. These are designated to monitor who has access to the product itself.

Authorization

⁠⁠Once a user has logged in to the product, authorization handles deciding who can do what and in what context within the product.

As you can see, each stage relies on information gathered from the previous one. ⁠A more detailed introduction to the IAM waterfall can be found here.

Building (and re-building) authorization

Up until recently, developers have mostly been building authorization by themselves from scratch. As a developer, you might think -

“Ok, so I’ll start off with two types of users: Admin, and non-admin, and make decisions based on this distinction”.

Then, a user comes in and asks you to create an editor role.
⁠So you rebuild your authorization system to allow an editor role.

Later, stakeholders from your company ask you for access to audit logs, and the ability to monitor them on their side.
So you rebuild your authorization system to allow that as well.

Then sales approach you and ask you to create an impersonation tool that allows them to see the system from a different perspective.
And you rebuild again.

Another stakeholder asks you for their own back-office that will allow them to manage new users they onboard into the system.

You see where we’re going with this.

As your product evolves, building authorization yourself requires you to keep rebuilding it time after time in order to adapt it. From the very beginning, you have to ask yourself - Who can access my application, work with it at the infrastructure level, manage it as the developer or work with it as a user? The answer to this question will help you determine how complex the authorization building process will be.

How microservices changed AuthZ

If you look at this issue in the context of the emergence of microservices, it becomes even more complicated. When you built a monolith application, you had the ability to bake in the decision-making process of who connects to what within the application into just one place - usually by using a specific framework such as Spring, Django, or Python. As you start breaking an application into multiple services, you end up having to replicate the authorization code across each and every microservice. And each time you want to restructure, change something, or add another feature, you have to do it in each microservice separately.

The rising demand for increasingly advanced authorization, the rising complexity of the applications themselves, and their migration to microservices and cloud-native structures magnified the pain of building authorization into the application itself.

The good news is that the field of authorization is adapting, and new solutions to resolve these issues are beginning to develop. These become available now thanks to the overall evolution of the cloud space, both in technology and mindset.

Rethinking services, new technology, and a shift-left midset.

There have been a couple of major developments that allow us to view authorization differently: An advancement in technology, a change of approach towards microservices, and the emergence of shift-left and low/no-code developers.

In terms of technology, to create significant changes in authorization we needed the previous layers - identity management and authentication to be working well. Until we had SAML and SSO connect between identity management and authentication, that entire area wasn't stable enough to build upon. The maturity of those standards enabled the entire Authentication space to blossom almost a decade ago, and now again with Passwordless. Before we had standards like the JSON Web Token in the authentication layer, it was basically impossible to connect to it in a standardized way. JSON Web Tokens (JWT), which only became mature in recent years, are a great way to communicate from the authentication layer into the application, and specifically into the authorization layer.

The authentication process ends when the JWT is handed to the application - specifically, to the authorization layer within it. While the authentication layer provides claims that affect the access policy, it's still up to the authorization layer to translate and enforce those claims based on the JWT and, often, additional context data.

In terms of thinking about services, if you go back five years, people were still thinking things like billing, authentication, or databases, being core and critical, require developers to implement them themselves. Thanks to companies like Stripe, Auth0, and MongoDB, developers have realized how complex these issues are, and how problematic it is to try and build them yourself. Thus, a mindset of adopting critical services as part of an application you're building became legitimate. Moreover - it became a consensus that you have to adapt these kinds of solutions since the risk of making mistakes when trying to build them yourself just isn’t worth it.

The overall trend of shift-left, which has been discussed in the security sphere ad nauseam, and the increasing number of people who are becoming low/no-code developers (eg. product, security, compliance) makes it critical for us to enable them to work on such fundamental experiences as access control.

So what can be done about this?

Modern authorization, finally.

This new reality has created an understanding that new solutions to resolve these issues should be built. Thankfully, the developer community has started creating these solutions with open source projects (e.g. OPA, OPAL). This way, you can adopt them as building blocks into your application without paying anything, and more importantly, they allow you to implement practices that prevent you from repeating the mistakes of the past.

The most important matter here is that while building applications, we understand the complexities that come with creating a functional authorization layer, and the best practices that should be implemented while building it in order to avoid constantly having to rebuild them.

There are already good ready-made solutions (e.g. Permit.io) out there - as open-source or as services that you can build upon while avoiding common mistakes. You can also approach this by building it yourself, but if you choose to do so, you have to do it right.

Summary

The drastic changes in the landscape of authorization over the last few years make it necessary for us to change our mindset and adopt new best practices in order to avoid constantly rebuilding authorization. The advancement in technology, a change of approach towards microservices, and the emergence of shift-left and low/no-code developers created an environment in which we can adopt existing solutions and use them as building blocks for our applications.

How to Implement Attribute Based Access Control (ABAC) using Open Policy Agent (OPA)

Daniel Bass — Mon, 17 Jan 2022 12:13:40 +0000

Building authorization can be a complicated endeavor. There are different models for building authorization and different ways of implementing them. At the end of the day, only one thing matters - we want the right person to have the right access to the right asset.

For this purpose, we want to review a couple of authorization models (ABAC and RBAC), and then explain how (and why) should you implement them using Open Policy Agent - which allows you to create a separate microservice for authorization, decoupling our policy from our code.
⁠

So why ABAC and RBAC?

ABAC and RBAC are the two most basic and commonly used authorization models, and they provide the baseline for most other complex and specific ones. Let’s start by getting to know them a little better:
⁠

What is RBAC?

Role-based access control (RBAC), is an authorization model used to determine access control based on predefined roles. Permissions are assigned onto roles (Like “Admin or “User”), and roles are assigned to users by the administrator. This structure allows you to easily understand who has access to what.

The combination of three elements - who (What role are they assigned?) can do what (What actions are they allowed to perform) with a resource (Which resources) is called a policy.

⁠You can also check out our tutorial on implementing RBAC in OPA
⁠

What is ABAC?

ABAC (Attribute-based access control), determines access based on a set of characteristics called “attributes”, rather than roles. Attributes include parameters such as a user’s role, security clearance, time of access, current time, location of the data, current organizational threat levels, resource creation date or ownership, data sensitivity, etc.

It's important to note that the attributes examined in ABAC are not just the user's - but of the accessed resource, the overall system, and anything else that is relevant in this context.

ABAC based policies are based on a combination of four elements: Who (The identity of the user) can do what (What actions are they allowed to perform) with a resource (Which resources) in what *context *(What are the circumstances required for the action to be performed).
⁠

RBAC VS ABAC

The choice between RBAC and ABAC depends on the needs of your organization -

RBAC provides a rather simple solution for determining authorization. Having evolved from RBAC, ABAC provides a more in-depth approach for authorization needed in order to prevent unauthorized access. While requiring more processing power and time, ABAC provides a more complex and detailed authorization method factoring a much greater number of variables.

In many cases, RBAC and ABAC can be used together hierarchically, with broad access enforced by RBAC protocols and more complex access managed by ABAC. That being said, it is important to choose relevant authorization methods tailored to your organization’s needs - so the authorization process is neither too simplistic nor too complex.

For the purpose of this post, we’ll assume you decided you want to set up your policies with ABAC.
⁠

The challenge of setting up policies with ABAC

In case you decided to set up your policies using ABAC, it is important to note the challenges you’ll have to face along the way:

The set of policies for each individual service has to be manually set up inside the service itself. This can be kind of a pain to do - as the amount of policies, users, and services grows, updating them in each relevant service becomes super tedious and time-consuming. Not only that, but considering the fact that policies change all the time - they have to be at least somewhat fluid.

Another issue can come from having the code of the authorization layer mixed in with the code of the application itself. This creates a situation where we struggle to upgrade, add capabilities and monitor the code as it is replicated between different microservices. Each change would require us to refactor large areas of code that only drift further from one another as these microservices develop.

So how can we solve these challenges?

By creating a separate microservice for authorization, thus decoupling our policy from our code. Controlling access management centrally through a separate authorization service allows you to offer it as a service to every system that needs to check whether a user can or cannot access its resources. This can be done by using Open Policy Agent (OPA).

⁠

What OPA gives us?

OPA unifies all policies across each individual service in one server.
Takes on the role of policy decision-making and enforcement from the service: The service queries OPA, OPA makes a decision and sends an output to the service, The service acts according to OPA’s reply.
It allows you to have a policy as code, that can be easily reviewed, edited, and rolled back.

While we have a centralized authorization solution, the enforcement itself is still distributed -

We have an OPA agent next to every microservice, providing decisions and enforcement with near-zero network latency. The OPA agents are distributed and can grow as the services scales.

⁠

How to implement ABAC in OPA?

With attribute-based access control, you make policy decisions using the attributes of users, objects, and actions involved in the request. For this we need three types of information:

Attributes for users
Attributes for objects
Logic dictating which attribute combinations are authorized

For example, let’s take the following attributes for our users:
Squid:

Joined the company 10 years ago
Is a cashier

Pat:

Joined the company 6 months ago
Is a cashier

We would also have attributes for the objects, in this case, menu items:

Burger:

Is sold on the menu
Costs 3$

Shake:

Is sold on the menu
Costs 1$

If we try and write up an example ABAC policy in English, it will look like this:

Cashiers may process orders of up to 1$ total.
Cashiers with more than 1 year of experience may process orders of up to 10$ total.

⁠OPA supports ABAC policies as shown below:

package abac

# User attributes
user_attributes := {
    "Squid": {"tenure": 10, "title": "cashier"},
    "Pat": {"tenure": 0.000114155, "title": "cashier"}
}

# Menu attributes
menu_attributes := {
    "Burger": {"items": "Menu", "price": 3},
    "Shake": {"items": "Menu", "price": 1}
}

default allow = false

# All cashiers may process orders of up to 1$ total
allow {
    # Lookup the user's attributes
    user := user_attributes[input.user]
    # Check that the user is a cashier
    user.title == "cashier"
    # Check that the item being sold is on the menu
    menu_attributes[input.ticker].items == "Menu"
    # Check that the processed amount is under 1$
    input.amount <= 1

}

# Cashiers with 1=> year of experience may ⁠process orders of up to 10$ total.
allow {
    # Lookup the user's attributes
    user := user_attributes[input.user]
    # Check that the user is a cashier
    user.title == "cashier"

    # Check that the item being sold is on the menu
    menu_attributes[input.ticker].items == "Menu"
    # Check that the user has at least 1 year of experience
    user.tenure > 1
    # Check that the processed amount is under is under $10
    input.amount <= 10
}

⁠Now let’s review the following input:

{
  "user": "Squid",
  "menu": "Burger",
  "action": "sell",
  "amount": 2
}

⁠Querying the allow rule with the input above returns the following answer: True.

Congrats! You have successfully implemented ABAC in OPA!
⁠

To sum things up:

Let’s do a quick review of what we learned:

RBAC is an authorization model based on predefined roles, while ABAC determines access based on a set of characteristics called “attributes”.
While RBAC provides a rather simple solution for determining authorization that fits most organizations, ABAC is a more complex and detailed authorization method factoring in a much greater number of variables.
It is important to choose an authorization model that fits your organization's needs, so it’s neither too simple nor too complex.
The main challenges of setting up policies with RBAC are the requirement to manually set up the set of policies for each individual service, and having the code of the authorization layer mixed in with the code of the application itself. Both can be solved by using OPA.
OPA solves these issues by unifying all policies in one server, taking on the role of policy decision-making and enforcement from the service, and allowing you to manage policy as code.
We saw an example of how to successfully implement ABAC in OPA :)

⁠Want to learn more? check out the rest of our Blog for more useful tutorials, or join our ⁠Slack channel to ask questions and talk about authorization.

How to Implement Role Based Access Control (RBAC) using Open Policy Agent (OPA)

Daniel Bass — Tue, 11 Jan 2022 10:08:17 +0000

For this purpose, we want to review a couple of authorization models (RBAC and ABAC), and then explain how (and why) you should implement them using Open Policy Agent - which allows you to create a separate microservice for authorization, decoupling our policy from our code.

So why RBAC and ABAC?

RBAC and ABAC are the two most basic and commonly used authorization models, and they provide the baseline for most other complex and specific ones. Let’s start by getting to know them a little better:

What is RBAC?

Role-based access control (RBAC), is an authorization model used to determine access control based on predefined roles. Permissions are assigned onto roles (Like “Admin or “User”), and roles are assigned to users by the administrator. This structure allows you to easily understand who has access to what.

The combination of who (What role are they assigned?) can do what (What actions are they allowed to perform) with a resource (On which resources) is called a policy.

What is ABAC?

ABAC (Attribute-based access control), determines access based on a set of characteristics called “attributes”. Attributes include parameters such as a user’s role, security clearance, time of access, location of the data, current organizational threat levels, resource creation date or ownership, data sensitivity, etc.

RBAC VS ABAC

The choice between RBAC and ABAC depends on the needs of your organization -

RBAC provides a rather simple solution for determining authorization and is usually sufficient for most organizations. In some cases, a more in-depth approach for authorization is needed in order to prevent unauthorized access - This is where ABAC comes in. While requiring more processing power and time, ABAC provides a more complex and detailed authorization method factoring a much greater number of variables.

For the purpose of this post, we’ll assume you decided you want to set up your policies with RBAC.

The challenge of setting up policies with RBAC

After you decided to set up your policies using RBAC, it is important to note the challenges you’ll have to face along the way:

Another issue can come from having the code of the authorization layer mixed in with the code of the application itself. This creates a situation where we struggle to upgrade, add capabilities and monitor the code as it is replicated between different microservices. Each change would require us to refactor large areas of code that only drift further from one another as these microservices develop.

But how can we solve these challenges?

By creating a separate microservice for authorization, thus decoupling our policy from our code. Controlling access management centrally through a separate authorization service allows you to offer it as a service to every system that needs to check whether a user can or cannot access its resources. This can be done by using Open Policy Agent (OPA).

What OPA gives us?

OPA unifies all policies across each individual service in one server.
Takes on the role of policy decision-making and enforcement from the service: The service queries OPA, OPA makes a decision and sends an output to the service, The service acts according to OPA’s reply.
It allows you to have a policy as code, that can be easily reviewed, edited, and rolled back.

How to implement RBAC in OPA?

In order to use RBAC, we need two types of information:

Which users have which roles
Which roles have which permissions

Once we provide RBAC with this information, we decide how to make an authorization decision; A user is assigned to a role and is authorized to do what the role permits.

For example, let us look at the following role assignments:

User (Who is performing the action)	Role (What is the user’s assigned role)
`Crab`	`Admin`
`Bob`	`Cook`
`Plankton`	`Villain`

User

(Who is performing the action)

Role

(What is the user’s assigned role)

Crab Admin

Bob Cook

Plankton Villain

And this role/permission assignment:

Role	Operation (What are they doing)	Resource (What are they performing the action on)
`Admin`	`Write`	`Secret formula`
`Admin`	`Read`	`Secret formula`
`Cook`	`Read`	`Secret formula`
`Villain`	`Want`	`Secret formula`

In this example, RBAC will make the following authorization decisions:

User	Operation	Resource	Decision (Should the action be allowed, and why?)
`Crab`	`Write`	`Secret formula`	`Allow` because `Crab` is in `Admin`
`Bob`	`Read`	`Secret formula`	`Allow` because `Bob` is in `Cook`
`Villain`	`Read`	`Secret formula`	`Deny` because `Plankton` is in `Villain`
`Villain`	`Want`	`Secret formula`	`Allow` because `Plankton` is in `Villain`

With OPA, you can write the following snippets to implement the example RBAC policy shown above:

package rbac.authz

# Assigning user roles 

user_roles := {

    "crab": ["admin"],

    "bob": ["cook"],

    “plankton”:[“villain”]

}

# Role permission assignments
role_permissions := {
    "cook":    [{"action": "read",  "object": "secret_formula"}],
    "admin":   [{"action": "read",  "object": "secret_formula"},
                {"action": "write", "object": "secret_formula"}],
    "villain": [{"action": "want",  "object": "secret_formula"}]
}

# Logic that implements RBAC.
default allow = false
allow {
    # Lookup the list of roles for the user
    roles := user_roles[input.user]
    # For each role in that list
    r := roles[_]
    # Lookup the permissions list for role r
    permissions := role_permissions[r]
    # For each permission
    p := permissions[_]
    # Check if the permission granted to r matches the user's request
    p == {"action": input.action, "object": input.object}
}

Querying the allow rule with the following input:

{
  "user": "plankton",
  "action": "read",
  "object": "secret_formula"
}

Results in the response you’d expect: False.

⁠Congrats! You have successfully implemented ABAC in OPA!
⁠

To sum things up:

Let’s do a quick review of what we learned:

RBAC is an authorization model based on predefined roles, while ABAC determines access based on a set of characteristics called “attributes”.
While RBAC provides a rather simple solution for determining authorization that fits most organizations, ABAC is a more complex and detailed authorization method factoring in a much greater number of variables.
It is important to choose an authorization model that fits your organization's needs, so it’s neither too simple nor too complex.
The main challenges of setting up policies with RBAC are the requirement to manually set up the set of policies for each individual service, and having the code of the authorization layer mixed in with the code of the application itself. Both can be solved by using OPA.
OPA solves these issues by unifying all policies in one server, taking on the role of policy decision-making and enforcement from the service, and allowing you to manage policy as code.
We saw an example of how to successfully implement RBAC in OPA :)

Want to learn more? check out the rest of our Blog for more useful tutorials, or join our ⁠Slack channel to ask questions and talk about authorization.