OPA vs. XACML: Which Is Better for Authorization?

Modern microservices applications built using containers are complex — often requiring complex authorization solutions, due to the sheer number of access possibilities involved. Indeed, as IT infrastructure has migrated to the cloud, along with the applications running on it, security and privacy concerns have only increased. As microservice applications became ubiquitous, open-source authorization tools have come to the fore for many organizations. 

This post compares two methods of authorization — Open Policy Agent (OPA) and the traditional eXtensible Access Control Markup Language (XACML) — and explains why OPA is more suited to authorization for cloud applications and infrastructure.  

Some key points are:

Before stand-alone authorization solutions, developers built authorization and policy rules into the programming code of applications and information systems. The downside was that every time a user requested a new role, the developer would have to go and rebuild the authorization system again.

Microservices further complicated authorization and policy handling. With monolithic applications, authorization could be built in one place using a specific framework. When an application consists of multiple services, authorization has to be applied to each service individually. So, to make a policy change or add a new feature, you would have to update each microservice individually.

With the COVID-19 pandemic, cloud usage increased substantially. Thanks to the scalability and flexibility benefits it provides, cloud-native development will continue to grow in the future. In its report on strategic technology trends, Gartner predicts that, “By 2025, cloud-native platforms will serve as the foundation for more than 95% of new digital initiatives — up from less than 40% in 2021.” 

With the rise of the cloud, the risk of compliance and security issues increases as attack surfaces grow. Reducing ecosystem risk by implementing access controls and enforcing policies that engineers and non-engineers (business personnel) could fine-tune became increasingly important.

In 2001, OASIS (a consortium for developing and implementing cybersecurity standards and more) launched XACML, laying forth the following foundations:

The XACML architecture consists of the following five fundamental components:

A typical XACML architecture handles access requests using the following authorization flow: 

XACML’s primary focus was API security, generally speaking. While it excelled in the authorization of information requests, XACML, today, isn’t necessarily the best fit for scalable cloud infrastructure and modern applications. In the XACML ecosystem, for instance, whenever a request is received, the algorithm must check each policy to see if it applies. Moreover, for microservices, the single XACML policy engine usually isn’t enough to handle the large number of components deployed in modern applications. Performance issues like delays and high latency usage can crop up as well, because there is typically much back and forth between the PDP and the PRP, where policies are stored. Finally, XACML’s XML-based language hasn’t necessarily aged well, as most developers would admit.

Still, it must be said: the XACML “architecture” mentioned above still represents the model for how OPA handles integrations, just in a more modern, distributed way — an impressive feat, given that that model was created about twenty years ago.

The Open Policy Agent was created by Styra, particularly for cloud-native environments, and later donated to the Cloud Native Computing Foundation (CNCF) in 2018. It is now an open-source policy engine that provides a unified policy framework across the entire cloud-native stack and enables developers to decouple policy decision-making from policy enforcement. This decoupling allows them to make policy updates without changing or interrupting the service. 

When a user makes a request, the policy engine receives all three inputs — data, query input and the policy. OPA then evaluates the request against the policy and data and reaches a decision, which is sent back to the service in JSON format. RESTful APIs can send JSON data over HTTP, allowing integration with other programming languages. You can use OPA as an operating system daemon or a library and even run it on the command line. Built upon a similar architecture as XACML, it is comparable to the PDP component of the authorization system, where it handles all policy decisions. 

OPA’s main advantage over XACML is that it comes with a more expressive coding language. With its high-level language Rego (based on Datalog), policymakers can focus on what their policies do rather than how to implement them. Another advantage is the ability to store all policies in cache memory, which significantly reduces latency with no performance impact. These policies are stored as code (Rego) — policy as code, in other words — instead of an XML schema, making them easier to understand and test. 

OPA’s deployment is also straightforward, and you can use an interactive shell/REPL (read-eval-print loop) to experiment and test new policies quickly. It has widespread use cases, such as microservices, Kubernetes, CI/CD pipelines and API gateways, to name a few. 

While OPA and XACML share similarities, OPA has been ultimately been responsible for the phasing out of XACML authorization solutions. OPA is interactive, flexible and has a thriving community behind it. More importantly, OPA meets the needs of cloud-native environments in a way XACML cannot, and is future-proof in case access control requirements change.

Due to its purpose-built design and benefits, organizations such as Netflix, T-Mobile and Goldman Sachs have already made the switch to OPA to provide access control across their cloud-native environments. 

Now that we have made the case for OPA, you might be wondering how you can get started using OPA for your organization. The best way for enterprises to implement OPA is by using Styra DAS, a control pane that delivers a single solution for the deployment, management and maintenance of multiple OPAs across the entire stack. It has a built-in policy library and policy packs that saves teams time and effort.   

Sign up for a Styra DAS demo today to see how you can deploy and manage OPA within minutes. 

To create a unified policy language that grew organically, the creators of OPA knew it had to be open source. Because of the community behind OPA, it has many more contributors and integrations and solves real-world problems. 

While OPA excels at providing authorization for cloud-native applications, these benefits also translate to regular software deployments. Indeed, OPA, being technology agnostic, has the architectural flexibility and performance power to meed any authorization need. Learning Rego for OPA can help you reduce the authorization burden and reach a quicker time to market. You can get started with Rego by visiting. Styra Academy or going through the OPA documentation pages.

To create a unified policy language that grew organically, the creators of OPA knew it had to be open source. Because of the community behind OPA, it has many more contributors and integrations and solves real-world problems. 

While OPA excels at providing authorization for cloud-native applications, these benefits also translate to regular software deployments. 

Learning Rego for OPA can help you reduce the authorization burden and reach a quicker time to market. You can get started with Rego by visiting Styra Academy or going through the OPA documentation pages.