DEV Community

Cover image for Low-code ABAC: a prerequisite for the Future
Or Weis for

Posted on • Updated on • Originally published at

Low-code ABAC: a prerequisite for the Future

Today we are excited to share an important milestone in Permit’s product roadmap, and perhaps more than that - a key milestone in how we think about access control: Low-code Attribute Based Access Control (ABAC).

As applications are becoming more complex, their policies have to follow suit.
Policies for billing (e.g. "only users who paid for a feature can use it"), location, time, trust level, quotas, anomaly, fraud, and risk profiles are becoming basic requirements, with these examples just scratching the surface, as even greater complexity awaits just around the corner (think AI agents, Web3, DeFi, IoT, metaverse assets, …).

Before and the concept of permissions-as-a-service, developers were forced to build and rebuild authorization over and over again to meet the constant stream of requirements coming from customers and fellow stakeholders (e.g. product, security, compliance, support). With Permit’s RBAC solution, policy-as-code became as easy as checking a checkbox - generating the needed code for you, wrapping it nicely into Git, and API / UI interfaces.

We had ABAC in mind from day one, and we supported it via direct code and Gitops. Still, to have complex policies (e.g. ABAC), users had to write code. We recognized that as long as policies remain accessible only through complex R&D work and steep learning curves (e.g. writing Rego code), developers would remain bottlenecks. This results in locking the other stakeholders out of the conversation, and leaving customers thirsty for their modicum of freedom within products- a thirst constantly manifesting as an unending stream of feature requests.

We knew that when it comes to ABAC, low-code is a must. We can only meet these ever-increasing challenges if we make access controls inclusive and empowering for everyone.

The secret sauce behind this launch is the understanding that ABAC should be as simple as RBAC (Role Based Access Control) - ABAC should be as simple as assigning a role. RBAC’s simplicity is why it became the bread and butter of the IAM world.
Working on this problem, we refused to relent until we found an elegant and simple solution. The eureka moment came in the form of breaking down ABAC into several independent yet connected systems, each one simple enough for a non-technical user. These systems enable the most complex patterns while converging back into a single source of truth as code managed in Git.

A User Set living side by side with a regular role, both using resource sets (large files - i.e. files filtered with a size attribute)

With concepts like User-Sets and Resource-Sets (aka Condition-Sets), the ABAC system allows users to transition from RBAC to ABAC smoothly and use complex attributes and conditions on them as if they are RBAC roles.

Defining a User Set with two attributes from different sources

With the new ABAC system, developers can customize every little aspect (with API or directly with code), but more importantly - they don’t have to - as the low-code interfaces are both simple and powerful enough to enable the entire team, including non-developers as well as the customers themselves, to work independently on access-control within the bounds set by developers/owners.

As we launch low-code ABAC support, we are excited about what this means for software and access control, but most importantly, we are excited to see what you build with it.

Ready to get started with ABAC? Read the docs here, and simply try it out directly

Got questions? Join our Slack community, or chat with us on Zoom.

Top comments (0)