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:

• The XACML architecture was created to detach authorization and policy rules from application code and is the basis of many modern authorization solutions.
• OPA was designed later as an alternative to XACML, with distributed applications in mind. 
• OPA offers some much-needed features that XACML does not. It comes with a declarative policy language, making it easier to implement, and meets the speed and reliability requirements of cloud-based systems. 

The need for advanced cloud-native authorization solutions

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.

What is eXtensible Access Control Markup Language (XACML)? 

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

• An attribute-based access control (ABAC) based policy language 
• Terminologies within an architecture
• A flow (from a user request to a final decision, based on ABAC)

The XACML architecture consists of the following five fundamental components:

Abbreviation and Terminology	Purpose
PAP: Policy Administration Point	This is the primary place of policy creation and authorization management
PDP: Policy Decision Point	At this stage, requests are evaluated against enforced policies
PEP: Policy Enforcement Point	PEP is a decision-making point where approval or rejection is sent back from the PDP after the request is evaluated next to a policy set
PIP: Policy Information Point	If attributes are missing for the request, the PIP will seek to locate them at this stage and evaluate the policy further
PRP: Policy Retrieval Point	A database for the storing of XACML policies

XACML flow

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

• When a user interacts with the application, a request is sent through the PEP. 
• The PEP converts it to an XACML authorization request and forwards it to the PDP. 
• In the PDP, the request is evaluated against the configured policies (managed by the PAP) and a decision is made. 
• If the PDP requires additional information to make this decision, it retrieves it from associated PIPs. 
• The request is then sent back to the PEP and access is either granted or denied. 

What are the challenges with XACML?

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.

Why Open Policy Agent (OPA) has become the de facto authZ standard

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. 

What are the advantages of using OPA over XACML?

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. 

XACML vs OPA: the final verdict

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. 

What is the best way to implement OPA?

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.

FAQs

Why is OPA open source?

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. 

Is OPA only for cloud-native environments?

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

How can I learn Rego? 

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.