top of page
Search

Authorization: To Code or Not to Code?

Updated: Jan 12

Author: Alex Babeanu

Laptop on a desk with code.

The Necessity of Coding

Dynamic Authorization is a fast-paced, ever changing field these days. New solutions and vendors have emerged in the past couple of years, all promising to solve the “next problem in Identity”. While many consider Authentication a solved problem (the advent of passkeys providing the last nail to that coffin), all agree that Authorization is another beast altogether. The problem is orders of magnitude more complex than the simple “you’re in” or “you’re out” decision a system makes after checking some subject credentials.


Whereas it’s “easy” (in comparison) for the whole world to agree on what constitutes a valid credential, every organization, public or private, has its own set of rules when it comes to filtering the access of its authenticated users to its internal resources. There is no finite list of all possible access policies, standardization is therefore not possible at that level. Instead, any effort to model authorization policies must involve some kind of programming language, as we’ve known since the XACML days.


Modern Authorization coding

Developers have therefore been hard at work programming authorization policies in their own ways directly within the Apps they’ve been building, using their own favourite programming languages and so since the dawn of modern authorization times - say since ACLs (1964).  Because development teams have been mostly working in silos all this time, they have also re-invented the “Authorization-Wheel” many times over. This has led us to where we are today, a time when all organizations, public or private, suffer from Role Explosion, have a hard time determining who has access to what at any given time, can be the victim of devastating data breaches because of privilege creep and have to engage in costly and often ineffective Access Certification programs.


Given the problems above, and the perceived need to implement access policies in computer code, several Dynamic Authorization vendors have emerged that provide their own specialized programming languages. These vendors would like all developers to stop using their language of preference in favour of their own Rego, Oso, or other Cedar language (see the Taxonomy of Authorization Models for a more complete list). While externalizing authorization is indeed the way to go in order to solve the various challenges organizations face nowadays, using yet another (sometimes notoriously cryptic) programming language is not necessarily the panacea. Is there really no alternative?


What Authorization Systems Really Need

An authorization system, whatever it may be, needs to be able to express any type of access policy, from the most coarse to the finest-grained. That is really the business requirement. Using a programming language, on the other hand, is not really part of what the business requires; business just needs its resources to be protected, the how is beyond the point. Insisting on using a programming language is therefore not necessarily the best/easiest approach, and may actually hide a few truths…


Programming takes time, there is a steep learning curve in learning a new language, it is very much error prone and programmed rules are not easy to prove.


Moreover, developers don’t come-up with the actual policies they are tasked to implement, Business does (Business Analysts, Product owners, Product managers, Architects, C-suite,...). Thus, stepping back from the nitty-gritty details that developers see, from a business standpoint an authorization system should at the very least:


Basic AuthZ Requirements:


  1. Be able to represent and implement any access policy, at any level of coarseness.

  2. Provide a way to know at any given time who has access to what.

  3. Be provable. In the sense that it should be possible to easily prove that the given rules will actually perform as expected.

  4. Enable Policy change automation in any environment.


Now, one could cite many other possible requirements, but we are really only discussing here the basic core features an authorization system must have. In any case, these requirements have so far been put in the hands of Developers, with the mixed success we’ve discussed above, it is time to look at better alternatives.


No-Code Platforms

The adoption rate of No-code/Low-Code application development platforms (LCAP) have been growing steadily in the Enterprise world, with Gartner predicting between 20 to 30% growth in that market for 2023 (Happy New Year 2024!). While the application development and enterprise world are embracing these LCAPs in growing numbers, once again, our small world of IAM is still lagging. Not surprisingly really, since most organizations still use 1990’s technology and standards to enforce Authorization (RBAC/LDAP anyone?). Yet the potential for LCAPs to change the way we do Identity is huge. Let’s review a couple of options…


AI

Firstly, specialized AI / LLM chatbots are likely going to shift the burden of creating access policies to non-technical users in the very near future (actually now even). Some vendors have already embarked on this endeavor. These LLM-backed solutions may well be able to (one day? now?) create any access policy at any level of coarseness (Requirement #1 - see above). The first step here for any LLM-backed specialized chatbots would be to translate plain-English sentences into specialized Code (Rego, Cedar, Oso, other), and thus easily ensure the continuity of these Authorization specialized languages.


But we are nevertheless still left with the problems facing these language/code-based solutions in the first place, as well as meeting our AuthZ requirements 2, 3 and 4. To compound the problem, the authors of the Access Rules (the Business users speaking plain human language) are now different from their maintainers (developers or IT techies), both sides relying on AI interpreters. All parties must therefore now trust that the rules created by the AI's will actually perform as expected. LLMs are notorious black boxes, which explainability is still the subject of active scientific research. How could we ensure the provability of these solutions? And besides, would such a system really help if developers must double-check any code created automatically by AI? They might as well just code the rules themselves.


Low-Code Authorization Platforms

No, these Authorization-specific LCAPs would not just be LLMs, since as we’ve seen they wouldn’t meet all our requirements, not in the near future anyway. Instead, and ideally, what is needed here is a system that both Business Users and Developers can understand: a way to represent Access Policies that enables both business and technical users to actually collaborate in building their authorization rules, be auditable, provable, enable automation, and yet still present all the benefits of LCAPs (lower costs, faster time to market, implementing best practices OOTB, hyper automation). A lot to ask for?


Luckily, the Graph paradigm is perfect for the task and can absolutely be used in a low-code way to meet all these requirements.


Let us quote Sir Tim Berners-Lee here, the father of the World-Wide Web, who wrote in his famous paper in 1989:

“When describing a complex system, many people resort to diagrams with circles and arrows. Circles and arrows leave one free to describe the interrelationships between things in a way that tables, for example, do not. The system we need is like a diagram of circles and arrows, where circles and arrows can stand for anything.” - Tim Berners-Lee

Exactly. Everything is a Graph, including the World Wide Web.


Everybody understands diagrams where ideas and concepts are related to each-other in meaningful ways. Many people use mind-maps regularly, or whiteboard ideas. And we know at least since Google Zanzibar (and even before if you’ve heard me speak at conferences prior to 2019), that Graphs can successfully model access Policies (through Relationship-Based Access Control - ReBAC). Furthermore, ANSI has provided us with a way to model any ABAC policies in graph using their Next-Generation Access Control (NGAC) Standard. Note here that NGAC is currently the latest standard for authorization, and the only purely authorization-specific standard other than the XACML/ALFA family. The work that the OpenID AuthZEN group will not in any way replace or supersede these other standards.


We can therefore now model any access policy, at any coarseness, as a Graph. And here comes the LCAP part…


3Edges is currently the only platform on the market that enables you to Draw an Access Policy graph using ReBAC or NGAC, in a simple drag-and-drop interface. It encapsulates exactly the idea that Mr Berners-Lee had back them: being able to just draw the idea, and then have the platform actually build it. No code written. Let’s see how 3Edges meets our requirements:


  1. It can implement any Access Policy, using well documented practices and actual standards (NGAC).

  2. Because it uses data in a Graph as its actual policies, assessing any access just requires graph path traversal, which modern graph data platforms excel at. Any access can thus easily be evaluated at any given time. Additionally, because 3Edges uses Knowledge Graphs, it is possible to query its ontology directly to get even higher-level answers from it.

  3. The provability of the rules also boil down to path traversal. Graph-based Access policies are typically very obvious because they relate the subjects and objects directly. Provability is baked-in.

  4. 3Edges provides a GUI-based control plane that eases the deployment and management of its services. All its Graph policies can be exported in JSON Graph Format (JGF), and added to source control or loaded into the platform directly via its APIs. It’s a Kubernetes-based microservices platform, so insert here your favourite k8s automation tools.


What is the value of such a platform? Aside from meeting the basic requirements for authorization systems, 3Edges:


  • Let business users and developers speak the same language: “if you can whiteboard it, you can do it.”.

  • Enables very fast app development and time-to-market. You can bring your development effort down to minutes from weeks or months!

  • Provides OOTB automation in cloud or hybrid environments.

  • Opens-up the graph world to Identity teams. Graphs are a cornerstone of LLMs and AI. And graph analytics libraries and tooling can make true sense of any data. Similarities, recommendations, data clusters, anomaly detection, etc…

  • Because of its dynamic nature, and support for events, NGAC is a future-proof standard, well suited for modern standards such as OpenID’s Shared Signals Framework (SSF).


Conclusion

Do you really need to code your Access Policies?


No, not really. There are better, faster alternatives nowadays. Developers’ time is better spent implementing actual business Requirements - the work they do best - rather than reinventing the wheel every time to build Authorization engines that may, or may not, work as expected using new more-or-less cryptic languages that require complex reasoners to prove.


Talk to us to try 3Edges today!


Comments


bottom of page