Hi there! Daniel here with another digest 💌
What do mico-irrigation and real-estate insurance have in common with managing voting registration in Maricopa County, one of the largest voting jurisdictions in the United States? I don’t even have a joke for this one. It’s the need for Fine-Grained Authorization. That’s what.
Every application needs a way to determine who has access to what once they’re logged in. An “Authorization” layer, if you will. We keep saying it, and you probably believe us at this point, but heck, I’m going to talk about it anyway.
It’s not only about “Needing authorization.” Sure, you can slap a bunch of if
statements inside your application logic and call it a day, but that doesn’t really cut it if you are trying to build a secure application distributed across multiple microservices and is used by more than 3 people in the same room.
There’s also the whole “We need to implement an authorization layer into our application without it becoming the number one focus of half the dev team for the next six months” issue. We’ve seen development teams fall down that rabbit hole dozens of times.
You might even successfully build something that solves your problem for now, but it usually comes at the cost of your developers kind of forgetting what your application did in the first place and losing their precious sanity from overexposure to Google Zanzibar articles.
This time, though, you're not going to hear about all of these issues from me. Enough Daniel. Let’s let other people do the talking instead.
I present to you three case studies of three very different organizations: Maricopa County, one of the largest voting jurisdictions in the United States; Rivulis, a leading company in the micro-irrigation sector; and Honeycomb Insurance, a real-estate insurance provider.
They all have one thing in common - the need to implement Fine Grained Authorization in their application (And also the lack of will to build it themselves from scratch, but more on that later).
Rivulis: Irrigating Innovation for Innovative Irrigating
Rivulis is at the forefront of micro-irrigation tech. The nature of their software, which serves as a SaaS platform for irrigation planning, required an efficient solution to handle multi-tenancy, granular permission management, and an ever growing scale of users.
They had to juggle multiple layers of access for everyone - internal teams, external contractors, and growers while making sure everything stayed secure and separate. They also needed this system to support more than just RBAC. They needed to define precise rules about who could access specific data and perform particular actions within the platform by considering attributes and the relationship between different entities. That means creating Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC).
Now, you can build this type of authorization system in-house. I mean - you can. I can’t. But you know what I mean. It’s possible. The Rivulis team estimated it would take about 30% of their development effort to create and maintain such an authorization layer. Considering this has nothing to do with their actual core offering - that’s kind of ridiculous.
So what’s the solution? Wait for it. Let’s look at the second case.
Maricopa County: Developers Securing Democracy Outside
’Call of Duty: Modern Warfare’
Election security is a big deal. Won’t even risk making a joke about that one.
When you’re responsible for one of the largest voting jurisdictions in the U.S., keeping things secure is kind of a non-negotiable. Maricopa County oversees a massive voter registration system, handling sensitive data for millions of voters.
But software is software, and here - especially here, you can see how important it is for only specific people to be able to access very specific data.
Maricopa had to deal with two big challenges with this:
They needed precise control over who could access what within the system. A huge number of temporary employees are brought in during election seasons, and you have to be able to manage permissions for them in a very precise way. That obviously translates to:
Scaling requirements
The need for granular permissions that can consider various attributes and relationships
But wait! There’s more. They also needed to handle all of this without creating a massive bottleneck for their IT department. They can’t have a whole team of people sit down to manually create rules based on if
statements for every new person they need to allow access to their system—that would be extremely time-consuming and anything but a secure way of doing things.
Honeycomb - Ensuring Insured Insurance
On the insurance front, Honeycomb encountered very similar issues.
Managing millions of dollars in commercial property insurance across U.S. real estate, Honeycomb needed an authorization system that could ensure proper access control for a wide range of users, including underwriters, customer success teams, agents, and third-party agencies.
Given the high stakes in managing millions of dollars worth of property insurance, it was critical to ensure compliance while enabling secure access to sensitive data, such as policy details, claims, and underwriting reports.
Honeycomb, too, understood building an efficient access control system from scratch in-house means diverting valuable time and resources away from the core product.
Not only that, but every time they needed to make a small change or add new functionality to their platform’s permissions, they had to assign their developers to write custom code—time-consuming, to say the least. Their homemade solution lacked the flexibility they required and demanded excessive developer time for maintenance. It was clear to the Honeycomb team that this wasn't a sustainable long-term strategy.
What do these have in common?
Rivulis and Maricopa County may operate in completely different fields (There’s a farming joke somewhere in there I just know it)—one’s about innovative irrigation, and the other’s securing the integrity of elections—but they share some surprisingly similar challenges when it comes to authorization. Both organizations found themselves requiring complex, large-scale access control needs that couldn’t be easily solved in-house.
1. Fine-Grained Authorization (FGA)
In both cases, traditional Role-Based Access Control (RBAC) just wasn’t enough. Both organizations needed a more nuanced approach. They had to consider attributes, relationships, and other factors to ensure that only the right people had access to the right data at the right time. FGA allowed them to implement more sophisticated controls that went beyond simple roles, offering a deeper level of security and precision.
2. Handling a Large, Fluctuating Scale
Both Rivulis and Maricopa County had to deal with fluctuating user numbers. For Rivulis, it was just the growth of their product, and for Maricopa, it was an influx of new users during peak times. Managing such a large, shifting scale is a big challenge, and both organizations needed a solution that could handle this complexity.
3. Avoiding the Pain of Building In-House
GPT told me to start this section by saying, “Building a custom authorization system in-house might sound tempting.” - I have no idea to who (Yeah, I use GPT to help me write. Sue me. More on that here). Yes, it is possible to build security features in-house. But it consumes valuable time, money, and development effort from your development team. It comes at the expense of working on your main offering, and, to top it all - it poses a security risk that just might get Kanye West elected (Finally managed to squeeze out that election joke).
Instead of resorting to the whole build-from-scratch thing, they both turned to Permit.io to externalize their authorization needs.
4. The Power of a No-Code UI
One of the game-changers for both organizations was Permit.io’s no-code UI (They said it, not me. Look at the videos. You can barely see the person from our team holding the giant spider and threatening to release it if they don’t). Instead of manually writing and maintaining complex authorization policies, they could use a visual interface to create and manage these policies dynamically. This meant that managers—not just IT—could adjust permissions without writing code and focus their efforts on auditing what goes on within the system instead of manually granting permissions by editing lines of code.
The Big Takeaway
Whether you’re working on micro-irrigation tech, managing voter data, or insuring real estate, you are bound to need efficient authorization. FGA is a must-have if you want to keep your systems secure and not build them in-house, and using a no-code UI to manage it can help avoid focusing your entire dev team on this one task.
If you’re curious about how implementing FGA can make your life easier, Google it, read more here, and join our Slack community - we can help you there.
That’s it for this week—until next time,
Daniel 🌼