Sibling teammate here!

A caveat: I haven’t had experience with any AuthZ Elixir libraries, so I can’t really compare OPA with them.

My team had a rocky start with OPA, but we have reached a point of comfort and confidence with the policies we are now defining and maintaining.

An obvious downside to using OPA, is that your team will have to learn a new language and structure for thinking about authorization. As someone with a background in imperative languages, I was certainly challenged by the declarative nature of Rego. However, I’m pleased by how clean and concise OPA can be. When done right, policies read very clearly – for example it is easy to see that a user with an administrator role is allowed certain actions in contrast with other user roles.

My team initially structured our authZ policies in a somewhat naive way. Thankfully, when pain points quickly began to arise, we were able to re-think our approach on OPA and discover better practices for defining policies. This required revisiting the (somewhat limited) OPA documentation. I also found this deep dive from KubeCon to be extremely helpful. I highly recommend it. After re-thinking and re-writing our policies, we arrived at a much better state. The false start was somewhat of a blessing in disguise, because it allowed us to see exactly what we didn’t know about OPA and then learn it quickly.

Another thing I’ll mention is testing. I don’t have any specific complaints about OPA tests, except that they aren’t ExUnit! I have become so accustomed to writing tests in ExUnit, that it’s hard to write tests outside of that framework.

Overall, my team has had a positive experience with OPA. Placing authorization policies in a different language forced as to separate our concerns from the rest of our code. I think this helped us make good decisions regarding our code organization. The declarative nature of OPA/Rego makes it very clear to us and to non-developers which types of users have which types of permissions and have access to which types of resources.

One of my sibling teams at work is using OPA as a sidecar to one of our Phoenix/Absinthe services, and write most or all of their business-domain authorization logic using its syntax and testing support and then delegate to that logic from within various Elixir code paths. I’ll reach out and see if any of them care to leave specific comments here about their experiences so far, but they have at least a few months under their belt with this approach.

Hey, welcome to the Elixir community!

My team initially structured our authZ policies in a somewhat naive way. Thankfully, when pain points quickly began to arise, we were able to re-think our approach on OPA and discover better practices for defining policies.

Do you have an article about it? I would like to see what were your pain points and avoid them if I can.

Also, how are you dealing with maintaining the policies today?

I can’t find any good practices in from OPA documentation or talks, especially on how to deny access to particular request right away.

Are you using any particular package for integration with OPA? I was about to write some Elixir package for the full integration since it seems that there is no integration at the moment.

Hey, welcome to the Elixir community!

Thank you!

Do you have an article about it? I would like to see what were your pain points and avoid them if I can.

Unfortunately we haven’t publishing anything yet. I will post a link back here if we do.

Also, how are you dealing with maintaining the policies today?

So far we haven’t needed to do too much maintenance. After the re-write, our rules became granular and decoupled from each other. We are still actively developing the product, and as we define new user actions, it has been easy to add new policies without having to make changes to the existing ones.

I can’t find any good practices in from OPA documentation or talks, especially on how to deny access to particular request right away.

I wish there was more documentation, too! But I can help you with that.

Here’s an example from the online doc:

# allow bob to perform read-only operations.
allow {
    user == "bob"
    method == "GET"
}

This could alternatively be written as:

# allow bob to perform read-only operations.
allow = true {
    user == "bob"
    method == "GET"
}

So if you wanted to explicitly deny an operation, you could do something like:

# disallow eve from performing read-only operations.
allow = false {
    user == "eve"
    method == "GET"
}

Are you using any particular package for integration with OPA?

Not at the moment. We wrote some Plugs to distill a web request into user and resource fields, and then another Plug to send the document to OPA for an “allow” rule check. It is fairly simple, but it has been working pretty well for what we need.