Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Policy Agent

openpolicyagent.org

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Open Policy Agent

#31

Post by andyroid »

ffk wrote: post #30
shriek wrote: post #28

Earlier quoted context omitted.

This feels very much like OpenFGA[0]. I've been evaluating authorization tool for one of my side projects and honestly most tools feels like creating relationships in a graph-like database and querying to see if there is/isn't relationship between two entities. Is there more to this (besides the implementation details) or am I missing something from these tools? [0] https://openfga.dev/

On the first point, OPA is much older than OpenFGA. To really illustrate the point, OPA became a graduated project about a year before OpenFGA had their first code drop in the public GitHub repo. The OpenFGA people are aware of OPA and I'm sure they learned from the tradeoffs OPA made. To the main point, what you described reflects the current trends of authorization. Define a data model, define data that adheres to…

Not sure why that matters, but OpenFGA is an implementation of Zanzibar, which isn't exactly new. There are many similar implementations to choose from should one want to model authorization via a graph database.

Re: Open Policy Agent

#32

Post by i_play_stax »

AgentOrange1234 wrote: post #15
charlieegan3 wrote: post #11

Earlier quoted context omitted.

I detailed a comparison of OPA and Cedar with verified permissions here: https://www.styra.com/knowledge-center/opa-vs-cedar-aws-veri...

Seems pretty damning. Why would someone choose Cedar? Is there some upside that isn’t captured here?

https://docs.opal.ac/

Universally, people I've met and worked with (20-30) hate writing rego (OPA).

I'm always skeptical of Styra's analysis; they are literally selling you something.

AuthZed looks interesting and they have good "ride along" videos in YouTube, e.g. replicating GitHub auth.

https://authzed.com/

Re: Open Policy Agent

#33

Post by samarthr1 »

bullcitydev wrote: post #23

We're currently evaluating OPA for adding RBAC to our open-source application [0]. We plan on using the Go API [1] and doing the policy eval directly in our app since our app is also written in Go. The thinking is we'll have some basic built-in policies (like admins can do X, editors can do Y, etc) but also allow users to configure their own policies if they want by writing rego and loading their policy rules at star…

Not affliated with AuthZed, but spiceDB may be a good fit for your use case?

Re: Open Policy Agent

#34

Post by shriek »

ffk wrote: post #30
shriek wrote: post #28

Earlier quoted context omitted.

This feels very much like OpenFGA[0]. I've been evaluating authorization tool for one of my side projects and honestly most tools feels like creating relationships in a graph-like database and querying to see if there is/isn't relationship between two entities. Is there more to this (besides the implementation details) or am I missing something from these tools? [0] https://openfga.dev/

On the first point, OPA is much older than OpenFGA. To really illustrate the point, OPA became a graduated project about a year before OpenFGA had their first code drop in the public GitHub repo. The OpenFGA people are aware of OPA and I'm sure they learned from the tradeoffs OPA made. To the main point, what you described reflects the current trends of authorization. Define a data model, define data that adheres to…

Yeah, that's what I've noticed too. Conceptually, they're more or less same giving an option of RBAC, ABAC or ReBAC and each offer their own DSLs (e.g. Oso, Ory Keto etc) and deployment strategies. It's been a bit harder to pick one honestly but I guess I'll just have to just use them to find which one fits for me.

Re: Open Policy Agent

#35

Post by cryptos »

I tried to implement some simpler cases with the policy language, Rego (https://www.openpolicyagent.org/docs/latest/policy-language/), of OPA and found it overly cumbersome. A simple check like "if user is in group A and in group C, but must not be in group C" is hard to express in this language. It would be a trivial task in any somewhat decent programming language (e.g. JavaScript).

I understand why restricting the possibilities with an external DSL might be a good idea, but I consider Rego to be to restricted. I mean, in the the a policy is just a function saying basically "yes" or "no" (I know, it's not that simple with OPA, but it boils down to access yes/no, anyway).

Re: Open Policy Agent

#36

Post by cryptos »

tekla wrote: post #13
mstade wrote: post #5

Earlier quoted context omitted.

OPA, or rego? My experience working for Styra was that most people seemed to grok where OPA fit in fairly quickly, but struggled with rego. It's a very powerful language and well worth learning I think, but it's an investment for sure.

I agree, Rego was a hell of a thing to try and figure out.

Rego is a DSL and the main purpose of DSLs is to simplify things (compared to general purpose programming languages), so in my opinion Rego is not a good DSL.

Re: Open Policy Agent

#37

Post by sarahcec »

AgentOrange1234 wrote: post #15
charlieegan3 wrote: post #11

Earlier quoted context omitted.

I detailed a comparison of OPA and Cedar with verified permissions here: https://www.styra.com/knowledge-center/opa-vs-cedar-aws-veri...

Seems pretty damning. Why would someone choose Cedar? Is there some upside that isn’t captured here?

The benefit of Cedar mainly comes down to the language. Cedar was designed to sit in the middle of a runtime call, so it has reliably low latency (see comparison here: https://twitter.com/Sarah_Cecc/status/1766141060370329748) even at high scale. It's way more readable so it's easier to author and debug. And it's validated against formal methods proofs so certain properties of the language (like default deny) are mathematically proven. More about the benefits of Cedar here: https://cedarland.blog/design/why-cedar/content.html

Re: Open Policy Agent

#38

Post by gsarjeant »

For application authorization, Oso is a compelling solution. (Disclaimer: I work for Oso). It provides a DSL and a prescriptive, but flexible data model that are capable of modeling RBAC, ReBAC, ABAC, or whatever else you'd like to model. Obviously I'm biased, but I think it strikes a great balance between opinion and flexibility.

One significant complication that all centralized authorization solutions share is that you end up needing to reproduce application data in the authorization system. We've been doing a lot of work in this area to simplify data management and have some beta functionality available. I'll include some links to the docs for those.

Sync and reconcile data: https://www.osohq.com/docs/guides/data/sync-data#initial-syn... Filter lists with decentralized data (about halfway down): https://www.osohq.com/docs/guides/enforce/filter-lists

Re: Open Policy Agent

#39

Post by charlieegan3 »

cryptos wrote: post #35

I tried to implement some simpler cases with the policy language, Rego ( https://www.openpolicyagent.org/docs/latest/policy-language/ ), of OPA and found it overly cumbersome. A simple check like "if user is in group A and in group C, but must not be in group C" is hard to express in this language. It would be a trivial task in any somewhat decent programming language (e.g. JavaScript). I understand why restricting t…

I am not sure how your groups are structured, but something like this might work for this [0] use case:

    package play

    import rego.v1

    default allow := false

    allow if {
        user := input.id

        user in data.groups.A
        user in data.groups.B
        not user in data.groups.C
    }
[0] https://play.openpolicyagent.org/p/adMo9TE9bS

Re: Open Policy Agent

#40

Post by ogazitt »

shriek wrote: post #28
ogazitt wrote: post #12

OPA is a great tool for implementing a policy-as-code system. But if you're trying to use it for application authorization (e.g. fine-grained authz for B2B SaaS or a set of internal applications), you may find that its policy story is strong, but it doesn't really have a "data plane": you either store data in a data.json file and rebuild the policy any time that data changes, or make an http.send call out of the poli…

This feels very much like OpenFGA[0]. I've been evaluating authorization tool for one of my side projects and honestly most tools feels like creating relationships in a graph-like database and querying to see if there is/isn't relationship between two entities. Is there more to this (besides the implementation details) or am I missing something from these tools? [0] https://openfga.dev/

Topaz is essentially a combination of OPA (which is used as the decision engine, with full support for Rego), and a Zanzibar-style directory, which is fairly isomorphic to what OpenFGA has implemented.

The advantage is that it's a single container image (or go binary, if that's how you want to run it), and supports a combination of RBAC, ABAC, and ReBAC. ABAC is accomplished via the Rego language, which is as "standard" as it comes in the cloud-native world.

Post reply on HN