using open policy agent (OPA) as an ABAC system

Question

I have a project that requires ABAC for access control for my projects resources. I've been looking at OPA and authzforce as options to implement ABAC and OPA looks like it might be less complicated than authzforce. I see that OPA compares itself to other systems and paradigms but the example it gave for ABAC leaves a lot to be desired. Mainly because ABAC requires the use of points that enforce policies, makes decisions around policies, fetch subject and object attributes for policy decisions. I feel like OPA has everything but the last part covered but it's hard to tell if that's true since their ABAC example is just a one-off.

I've been looking all over the internet for examples of OPA being used as an implementation for ABAC but I haven't found anything.

My project is a web app that allows end-users to create resources and create policies for their resources. I plan to create a UI for the end-users to create their policies. my plan is to abstract away the coding aspect of it and instead, give them dropdowns and buttons this UI will use a custom syntax behind the scenes that I will interpret into an OPA policy.

The main issue I'm having is how to implement this as ABAC, is it as straight forward as building the part that will fetch the attributes for the subject, object, and environment and create the glue between it and OPA (essentially creating a PIP) since OPA itself appears to be a defacto PEP and PDP?

I feel like I'm drowning in the documentation and there seems to be quite a bit missing from OPAs own docs to explain how this can be done.

Unpleasant

Answer 1

OPA looks like it might be less complicated than authzforce

There are a couple pros and cons to either approach. First of all, as you realized both OPA and AuthZForce are ABAC implementations (you can read more on ABAC here and here).

OPA

Open Policy Agent is a relatively novel model aimed mainly (but not only) at tackling fine-grained authorization for infrastructure (e.g. Kubernetes). They even have pre-built integration points for Istio and Kubernetes. OPA provides a PEP (enforcement / integration) and a PDP (policy decision point) though it does not necessarily call them that way. The language it uses is called REGO (a derivative of DATALOG).

OPA itself appears to be a defacto PEP and PDP

Yes you are absolutely right and that puts the burden on you to implement an alternative for PIPs.

I feel like I'm drowning in the documentation and there seems to be quite a bit missing from OPAs own docs to explain how this can be done.

Reach out to Styra - they sell services around OPA. Alternatively reconsider your choice and look into XACML (see below).

Drawbacks

• the language (REGO) is not easy to understand
• the language is not standardized
• OPA does not support Policy Information Points (PIP) - that's by design.

Implementations

I've been looking all over the internet for examples of OPA being used as an implementation for ABAC but I haven't found anything.

Have a look at the work they did at Netflix. That's the main implementation I am aware of. You can also reach out to Styra, the company behind OPA, and they'll be able to help out.

AuthZForce

AuthZForce is an open-source Java implementation of the XACML (eXtensible Access Control Markup Language xacml) standard. It provides a full ABAC implementation (PAP, PEP, PDP, PIP). It's part of Fiware (an open source initiative) and it's actively developed by a team at Thales.

AuthZForce Drawbacks

• it does not seem to have a graphical interface to author policies. I found a reference to KEYROCK PAP but couldn't see any screenshot
• it does not support ALFA, the abbreviated language for authorization.

Implementations

There are many other implementations of XACML you can consider (both open-source and commercial):

• AT&T XACML
• SunXACML
• WSO2 - part of their WSO2 Identity Server platform - it's called Balana
• Axiomatics (commercial - this is where I work) - we have a large customer base using our platform ranging from Fortune 50 companies to agile startups.

Benefits of XACML & ALFA

One of the key benefits of XACML / ALFA is that they are standards and widely adopted. The standard has been around since 2001 and interoperates with other standards e.g. SAML, OAuth, and SCIM.

Nodose

after digging further into authzforce I see that it doesn't provide a PIP out of the box, but rather, it requires you to create one (which it calls an attribute provider) that it can use to fetch attributes that aren't provided in the request. so that means OPA and authzfoce have the same drawback – Unpleasant

No. AuthZForce's architecture plans for PIPs. Whether it comes with pre-built ones is a different conversation. If you want OOTB, look into Axiomatics who do have connectors for jdbc, rest, and more. – Nodose

Excellent post! I'd add that the Netflix example linked in this post is interesting also because they demonstrate a policy-authoring UI like the one described in the question. – Chelyabinsk

OPA is [...] aimed mainly (but not only) at tackling fine-grained authorization for infrastructure (e.g. Kubernetes).. I'm confused about this. Why just for infrastructure? Why not for regular user authorization? – Shagreen

It can now do both but historically it was aimed at infrastructure use cases – Nodose

Answer 2

Perhaps the most concrete answer is a detailed description of how Chef Automate uses OPA to implement application authorization.

More generally, we are planning a guide describing how to use OPA for application authorization--it requires more detail than a SO answer. But using OPA (or any policy engine) for application authorization depends a bit on your application, its architecture, your SLAs, etc. But here are a few key issues to consider:

• Policy: how much expressiveness do your end-user policies need? Do they just define say user-attributes or user-roles, or do they map user attributes/roles to permissions too? OPA lets you solicit those end-user policies as JSON objects and then write policy rules that make decisions using those JSON objects. And for efficiency, you can compile those JSON objects into bona-fide OPA rules.
• Enforcement: where do you need to enforce authorization policies (e.g. gateway, microservice, database)? Your requirements around latency, size of data, expressiveness of database query languages will all impact this decision. OPA is flexible enough to help with all of these and has a couple of specific integrations that will help: Envoy and similar service-mesh systems for microservices and SQL/ElasticSearch for databases.
• Data: how much attribute data is there, how frequently does it change, what consistency guarantees do you need, what mechanisms do you have for getting the data into OPA (e.g. caches, event-streams). Here's a guide for injecting data into OPA; it uses LDAP/AD as an example data-source, but the principles are the same for any data-source.

We are always happy to talk through the details of your application and help you find the right fit for OPA. Feel free to reach out on the OPA slack channel.

Timepiece