Intellyx BrainBlog: Implementing Authorization in your Apps Doesn’t Have to be a Nightmare

SCRUM MASTER: Our application is almost ready to go live. One more sprint should do it.

DEV TEAM: Hooray!

SCRUM MASTER: There’s just one more thing. We need to implement authorization.

DEV TEAM: Didn’t we take care of that when we implemented the login screen in sprint #1?

SCRUM MASTER: That was authentication. Now we need to set up access by roles – customer, admin, etc. Oh yes, and by attributes as well – only the users who pay for a service can access it, that kind of thing. Think you folks can handle it? You have two weeks. And don’t worry, you’ll get some home-brewed beer at the wrap party if you finish on time.

The scenario above may be oversimplified, but it’s surprising how many organizations give authorization a low priority when building applications.

The problem is subtly complex – how to handle different types of admins? What to do if someone changes roles? How do attributes and roles combine to decide the proper permissions? Who can manage permissions? The list goes on.

And to make matters worse, hand-coding authorization can be a nightmare, as every capability in the application may require some sort of custom permissioning. Further complicating matters: authorization may depend upon dynamic data which may come from outside the organization.

Fortunately, there are simpler, more secure approaches than hand-coding everything. Here’s a closer look.

The Cloud Native Context for Authorization

In part one of this series, I framed the discussion of cloud-native authorization by delineating six core best practices, including a declarative control plane, zero trust, stateless microservices, and more.

In the second article, my colleague Jason English discussed the challenges of ‘home brewing’ permissions – and how important open-source software and open protocols like Open Policy Agent (OPA) and Open Policy Administration Layer (OPAL) are for implementing flexible permission rules that don’t require ongoing manual rewrites.

Open-source software and open protocols, however, are only part of the solution to implementing authorization in cloud-native applications.

Remember, declarative control planes are a core cloud-native best practice. Control planes are abstractions that separate the underlying software implementation from the configurations that drive the behavior of the software.

Just so with authorization. The software necessary to properly implement authorization infrastructure should ideally support the configuration-centric control plane instead of requiring developers to code permissions into their software directly.

The Three Aspects of Cloud Native Authorization Configuration

Above the control plane – where developers set up authorization in their applications, and admins configure the permissions – is where the full story of cloud-native authorization plays out.

As with other control planes, there should be a no-code user interface that supports the manual configuration of roles and attributes and the permissions associated with them, as well as other business logic specific to authorization.

Who is authorized to do what and why, after all, may depend on many factors and may also change over time. Organizations may have arbitrarily complex permissions policies. Supporting the configuration of such policies is straightforward with a no-code capability like Permit.io’s.

Third, developers need to be able to access underlying authorization infrastructure via APIs. APIs, in fact, enforce the control plane abstraction for permissions as well as declarative control planes while allowing developers to build authorization directly into their application microservices.

Permit.io’s authorization platform makes incorporating APIs into cloud-native applications straightforward because the behavior of the APIs is transparent.

Where before, implementing permissions required a few dozen lines of code and references to static elements like ‘ADMIN’ or ‘EDITOR,’ leveraging the Permit.io API requires a single line of code:

if (await permit.check(user, "close", `doc:${doc.id}`)) {
	// allowed to close issue
}

In the example above, permit.check accesses an API that hides its underlying implementation. That code may run in the same application context as the application itself, or for that matter, it may be running on a cloud somewhere.

The Power of SaaS-Based Authorization

Permit.io runs its authorization infrastructure as a SaaS-based offering, with all the benefits of SaaS, including pay-as-you-go pricing, built-in scale and reliability, and behind-the-scenes maintenance and security.

Furthermore, this SaaS offering supports APIs, low-code workflow construction, and a GUI control plane dashboard, giving Permit.io customers all the flexibility they require to implement cloud-native authorization in their applications.

The Intellyx Take

The most familiar approach to implementing application permissions is role-based access control (RBAC), where admins assign permissions and users to roles. Everyone with a particular role thus has the permissions assigned to that role.

Sometimes RBAC is sufficient – but in many situations, organizations require finer-grained control over permissions. In those situations, relationship-based access control (ReBAC) or attribute-based access control (ABAC) become necessary.

Development teams looking to roll their own authorization (like the simplistic example at the top of this article) may find RBAC to be relatively straightforward to implement. Before long, however, stakeholders require ABAC, which presents a far more complex, convoluted challenge for the developers.

Working with an authorization platform like Permit.io, therefore, is essential for keeping those stakeholders happy, shifting developers’ focus away from complex authorization tasks to features unique to their applications so that they can wrap up their work on time and earn that delicious home-brew at the party on Friday.