Menu
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.
635
OPA supports ABAC policies as shown below. In OPA, there's nothing special about users and objects. You can attach attributes to anything. And the attributes can themselves be structured JSON objects and have attributes on attributes on attributes, etc.
For example, you might use the RBAC system to hide sensitive servers from new employees. Then, you might use ABAC systems to control how people alter those documents once they do have access. Researchers say blending RBAC and ABAC can help administrators get the best of both systems.
The ABAC model's time-based rules prevent access to sensitive data at times it's not needed, thus preventing exfiltration and data breaches. Companies with a simple structure: When your organization's workgroups have a simple structure with few roles, RBAC is a better choice.
PBAC focuses on policies that grant or deny the end user access to a resource, and ABAC focuses on the specific attributes that influence the policies.
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).
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).
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 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.
There are many other implementations of XACML you can consider (both open-source and commercial):
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.
52
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
