BrainBlog for Permit.io by Jason Bloomberg
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.
Read the entire BrainBlog here.
